coach-551562_1280

ギルドワークスの「現場」コーチ

先日市谷の投稿にもありましたが、Agile Shimane(松江)にお招き頂き、お話してきました。

私自身、ギルドワークスの一員として、ギルドワークスの仲間と一緒に喋る、というのは初めての経験でしたので、結構緊張しました。 私の話は、ギルドワークスの「現場」コーチとは何か、というものでした。

そう、今回の発表で伝えたかったのは、ギルドワークスは「現場」コーチだということです。アジャイルコーチでもなければ、開発コーチでもない。現場を良くするためなら手段を問わない、越境していく、そんな姿勢でコーチという役割に向き合っています。

そんなギルドワークスの現場コーチに興味がある方は、こちらからお気軽にお問い合わせください。

すでに市谷の資料は上がっておりますが、Kent BeckのXP本 に二人共ふれていたりと、当日の二人の発表は、違う内容を話しつつ同じような発想へと最終的には至っているように私は感じました。

Joinしてから二ヶ月、ギルドワークスの一員として馴染んで行けているのかなぁ、、、と勝手に感慨にふけったりもしています。

capture

「『企業とカイワする』というエンジニアの選択肢 〜自社サービス「カイワジョブ」の立ち上げ舞台裏〜」をお話します

ギルドワークスの佐々木です。

弊社は、「越境」を知り、実践するためのカンファレンスと題して「開発者ギルドカンファレンス2015」を2015年7月23日(木)に開催します。

「開発者ギルドカンファレンス2015」とは?

ギルドワークスが一年強の間に手がけた開発プロジェクトは、新規事業を含む30件以上。これらをわずか7名のコアメンバーが中心となり、50名を超える”ギルド”メンバーに支えられながらやり遂げてきました。

正しいものを探るためクライアント側に大きく越境​し、正しく作るために開発メンバーも互いの役割の中で越境しながら開発を行っています。
また、「現場コーチ」として、実際の開発現場を劇的に変えてきました。ただ技術ややり方を教えるだけでなく、現場に越境​してチームの意識を前向き・上向きにさせ、越境できるチームをつくるサポートをしています。

このように、よりよい製品・サービスをつくるためには、様々な越境が必要だとギルドワークスは考えています。
その越境を知っていただく機会として、本カンファレンスを開催します。

このエントリでは私がお話するセッション「『企業とカイワする』というエンジニアの選択肢 〜自社サービス「カイワジョブ」の立ち上げ舞台裏〜」について、ご紹介します。

続きを読む

IMG_1448

「よいコード」を書くためのはじめの2歩

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています
木目沢(@pilgrim_reds)と申します。

このような場で記事を書かせていただけることになりまして大変緊張しております。

今回は、Kent Beckが書いた「実装パターン」という本を紹介したいと思います。

出版社の都合で絶版になってしまっているのですが、素晴らしい本ですので、もし手に取る機会がありましたらぜひ読んでみてください。

この本のテーマは、「よいコードを書く方法」です。
190ページという薄い本ながら、「よいコードを書く」ためのパターンが100個近く掲載されています。

なにより素晴らしいのは、パターンを紹介するだけでなく、

  • そもそもよいコードとは何か?
  • なぜよいコードを書く必要があるのか?
  • パターンとは何か?
  • どのようにパターンを選択し、適用すればよいのか?

という本のテーマの「前提」となる部分がきちんと説明されていることです。(まえがき、1章〜4章)

全てをこの場では紹介しきれませんので、今回はこのなかから、「よいコードを書くためのはじめの2歩」を紹介します。これは、Kent Beck自身が歩んだ最初のステップということで「1章 はじめに」で紹介されています。

1歩目・・・プログラミングを行うと同時に意識的になること。

Kent Beckがこの本を執筆しはじめたころの話だそうですが、当時、すでに、何年もプログラミングの経験があり、プログラミング上の決定はスムーズにすばやく行われているのに、なぜメソッド名をその名前にしたのか、そのオブジェクトにそのロジックを含ませるべきだと確信した理由は何なのかを説明できなかったことに気がついたそうです。

そこで、よいコードを書くための第一歩は「自分で何を考えているかを意識できるぐらいに思考速度を落とす」こと、直感でコードを書く「振り」をやめることを挙げています。

2歩目・・・他人の重要性を認識すること。

プログラミングというのは、1人の人間と1台のマシンとの孤独なコミュニケーションであることは、ほとんどありません。
また、他人を気に掛けるということは、意識的な決定であって、練習しないと身につかないものです。

同じくKent Beckが書いた「XPエクストリーム・プログラミング入門 — 変化を受け入れる 第2版」の原書出版が2004年。「実装パターン」原書出版が2007年ですから、当時、すでに達人の域に入っていたといってもいいでしょう。
つまり、新人でも中級者・上級者であっても気がつかなければ最初の一歩も踏み出せないということです。

ここまで、こんなことを言っておいてなんですが、私自身、はじめの2歩を忘れてコードを書いていることが未だに多いです。
まだまだ、練習が足りませんね。

誤解していただきたくないのは、「常にゆっくり」コードを書けといっているわけではありません。いわばトレーニングの一環といったところです。
最終的にはよいコードを書くことを「習慣化」するというのが、そもそもの本書の目的であります。

最後にこの「実装パターン」ですが、ギルドワークスの増田さんが、ドメイン駆動設計を実践する中で、何度も読み返して参考になさっている文献のなかの一冊に挙げられています。

ドメイン駆動設計を実践されている方にもぜひ手に取っていただきたい一冊です。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

26156_normal_1433927572_ぎるかん

「現場コーチから見えてきた越境する現場の3つの特徴」をお話します

こんにちは、ギルドワークスの中村 洋です。

「越境」を知り、実践するためのカンファレンスと題して「開発者ギルドカンファレンス2015」を2015年7月23日(木)に開催します。

「開発者ギルドカンファレンス2015」とは?

ギルドワークスが一年強の間に手がけた開発プロジェクトは、新規事業を含む30件以上。これらをわずか7名のコアメンバーが中心となり、50名を超える”ギルド”メンバーに支えられながらやり遂げてきました。

正しいものを探るためクライアント側に大きく越境​し、正しく作るために開発メンバーも互いの役割の中で越境しながら開発を行っています。
また、「現場コーチ」として、実際の開発現場を劇的に変えてきました。ただ技術ややり方を教えるだけでなく、現場に越境​してチームの意識を前向き・上向きにさせ、越境できるチームをつくるサポートをしています。

このように、よりよい製品・サービスをつくるためには、様々な越境が必要だとギルドワークスは考えています。
その越境を知っていただく機会として、本カンファレンスを開催します。

このエントリでは私がお話するセッション「現場コーチから見えてきた越境する現場の3つの特徴」について書いています。

続きを読む

2434031231_e11977262b_z

利用者を取り巻くあれこれを可視化する

ギルドワークスの佐々木です。

ソフトウェアを実利用者の文脈に沿ったものとして届けるために、利用者を知ることが大切であると言われます。
利用者を知るといった場合に、インタビューや行動観察をしてユーザーデータを集めることはとても重要ですが、その結果を分析しなければ、意味のないデータになってしまいます。
今回の記事ではまず、人間中心デザイン(Human Centered Design:HCD)の観点から整理してみたいと思います。

Contextual Design

コンテクスチュアル・デザイン(Contextual Design)という手法・考え方があります。これは、ユーザー中心デザイン(User Centered Design)の手法として、1990年代後半にHugh Beyerと Karen Holtzblatt によって提案されました。この手法は以下の6つのプロセスより成り立っていますが、今回は Work modelingにフォーカスします。

  • Contextual inquiry:インタビューによるユーザー調査
  • Work modeling:5つのワークモデルを用いた分析
  • Consolidation:分析結果の統合
  • Visioning & StoryBoarding:統合結果をシナリオ化しリデザイン
  • User Environment Design:ユーザーをとりまくシステム環境を描く
  • Prototyping and Implementation:プロトタイプと実装

Work Modeling

Work Modelingでは、前段のコンテクスチュアル・インクワイアリーで得られたデータをモデル化します。このモデル化には、5つのワークモデルが使われます。

  • Flow model
  • Sequence model
  • Cultural model
  • Artifact model
  • Physical model

Flow model

フローモデルは、利用者が行なうべきコミュニケーションを可視化します。利用者があるタスクを行なう際に、どんなコミュニケーションを必要としているかを、公式・非公式区別なく記載していきます。必要であれば、人工物も描くようにします。
フローモデル

Sequence model

シーケンスモデルは、時系列で流れをみるものです。ある利用者がどんなタスクをどんな順番でこなしているのかを可視化します。流れ作業でやってしまっているステップでも、書き出してみると実は必要のないステップであることに気付いたりすることがあります。
シーケンスモデル

Cultural model

カルチュラルモデルは、ある利用者が何かのタスクを達成するために、周りの人にどんな影響を受けているかを可視化します。何かを意思決定する時、その人個人だけが独立して判断していることはほとんどありません。周りの何らかの影響を受けていることが多いです。重要なステークホルダーを洗い出すことで、デザインにつなげます。
カルチュラルモデル

Artifact model

利用者がゴールに向かうために使う人工物・道具を可視化します。単に「同僚に連絡する」と言っても、チャットツールを使う人も居れば、狼煙を使う人もいるでしょう。その使う道具を洗い出して、デザインのヒントを得ます。

Physical model

利用者が置かれている環境を可視化します。どんな部屋でシステムを使うのか、モバイルデバイスを使っているのか、近くにはどんなものが置かれているのか。そういったことを洗い出すことで、どんなものを届けたらよいのかが判断できるようになります。

カスタマージャーニーマップ

紹介した5つのワークモデルを利用しているデザイナーは、あまり見かけなくなりました。その代わりに活用されているのは、カスタマージャーニーマップサービスブループリントであると思います。

(参考)
2時間で作るカスタマージャーニーマップ――実例とともに考える新しい「おもてなし」のカタチ
ブループリント | Service Design Tools

これらは、短時間でワークショップ形式でユーザーの行動を追うためにとても有用なツールであると考えます。一方で、多数のステークホルダーが関わったり、多様なストーリーがある場合に、1人の利用者、1つのストーリーに強くフォーカスが当たってしまう傾向があります。そういったトレードオフを理解しつつ、利用者を取り巻く環境を可視化する手法を組み合わせ、利用されるソフトウェアの開発に繋げていければと思い、日々活動しています。

まとめ

ユーザーの調査結果を分析する際に、どんな可視化の方法があるかを簡単にまとめました。
次回は、システムを設計する視点からのモデリング方法についてまとめたいと思います。

ギルドワークスでは「価値探索」というサービスを提供しています。その中では、想定利用者のインタビューを実施し、マップやキャンバスを駆使しながら、利用者により良いシステムを届けるお手伝いをしています。
本日、弊社で実施している内容をご紹介する資料を公開し始めました。ご興味がありましたら、こちらよりご覧ください。

(アイキャッチ画像は https://flic.kr/p/4H63FH より引用しました。)