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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続きを読む

「よいコード」を書くためのはじめの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歩を忘れてコードを書いていることが未だに多いです。
まだまだ、練習が足りませんね。

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

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

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

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

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

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

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

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

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

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

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

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

続きを読む

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

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

ソフトウェアを実利用者の文脈に沿ったものとして届けるために、利用者を知ることが大切であると言われます。
利用者を知るといった場合に、インタビューや行動観察をしてユーザーデータを集めることはとても重要ですが、その結果を分析しなければ、意味のないデータになってしまいます。
今回の記事ではまず、人間中心デザイン(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 より引用しました。)

定冠詞”the”の重要性を、アジャイルマニフェストから学ぶ。

ギルドワークス 前川です。

自信を持って言えるほどではありませんが、英語はちょっとは読み書きできます。そもそも英語の強さは、二種類あると思います。

一つは、語彙力。じつはこれ、僕はあんまりありません。なので結構英辞郎やロングマンの英英辞典を引っ張ってくることは多いです。

もう一つが、文法力。というか、英語のルールを知っておくこと、ですね。こっちのほうが僕は少し得意です。

文法と聞くと、あんまりいい顔する人はいないでしょうが、本来英文法ってのは英語の考え方を知るためのツールなんです。なので、幾つか知っておくだけで格段に英語の見方が変わりますよ。

そんなわけで、恐らく最も簡単な英単語の一つ、にして、多くの人が重要性を意識せず使っている”the”についてお話します。

定冠詞 “the”

“the”は文法上の分類で「定冠詞」と呼ばれます。「定冠詞」があれば「不定冠詞」はあるのか?というと、あります。”a”です。どちらも英語を勉強してごくごく初期にでてくるものですね。

この2つの違いは何でしょうか?実はもう名前の時点で答えが出てるんですが、定まったもの=文脈上一意に特定できる/するものを定冠詞で表します。バカみたいな例で恐縮ですが。

This is a pen.

は単独で意味が通りますが、

This is the pen.

は文単独では意味不明です。“the pen”ってどれなの!?となります。なので、例えば。

I found a pen yesterday. This is the pen.

みたいに文脈を付けないと意味がわかりません。

このように、”the”にはそれが指すものが一意に特定できている、という暗黙的な意味があるのです。逆に”the”を付けなかったり、”a”を使う場合には、これはふわっとした一般論を指しているという意味合いがつきます。

アジャイルマニフェストと原則における”the”の扱い

では、具体例としてアジャイルマニフェストアジャイル原則の原文を見てみましょう。

まずは、あまりにも有名なマニフェストの4つのセンテンスを引用します。

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

いかがでしょうか?そうです。Theは欠片もでてきません。マニフェスト中でTheがでてくるのは

That is, while there is value in the items on the right, we value the items on the left more.

このように、上に書かれている4センテンスで既に挙げられているものの、左のほうなのか右のほうなのか、を指定している部分だけなのです。

では、アジャイルの12の原則ではどうでしょうか?一つ目からいきなり、こうです。

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

the customer“なんです。特定できて、目の前にいる、そのお客さんなんです。

公式日本語訳は、こうなっています。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

もちろん意味は正しいし、日本語としても綺麗です。でも、この訳だと原文は”a customer”や”customers”でもいいんです。

「顧客満足を再優先する」だけでは、あまりにも元の英文が持つ鋭い意味合いから乖離してしまっている。

だって現場には目の前に製品を届けるお客さんがいるはずなんですから。「現場のお客様を」とか「目の前のお客様を」とかの方が良い表現に思えます(語調は汚くなりますが)。

他の原則はどうでしょうか?例えば、三番目のセンテンス。

Business people and developers must work together daily throughout the project.

“the customer”だけでなく、”the project“です。プロジェクトも、メンバーがちゃんと全員”the project”と言える状態に、メンバー全員が自分ごととして認識して「そのプロジェクト」で通じる状態になっている、という前提なんです。

このように、アジャイルマニフェストとアジャイル原則は、定冠詞という観点から見ると大きく印象が異なるものです。言ってしまえば、アジャイルマニフェストは一般論としてのふわっとした言葉です。

対して定冠詞が非常に多く登場し、対象が明確化されるアジャイル原則は、より開発現場に近いところで利用する実践的な言葉、といえます。

このような視点で、一度アジャイルの原典であるこの2つの文章、英語で味わってみるのはいかがでしょうか。

クリエイティブの道は禅に通ずるや否や?

こんにちは、ギルドワークスの藤田です。

この6月で、ギルドワークスに入社して3ヶ月が経ちました。あまりの濃密さに1年くらい経ってるんじゃないかという気持ちがするのですが、まだ3ヶ月、されど3ヶ月。3ヶ月も働いているのに、何も貢献できてないんじゃないか…とか、お客様やパートナーのみなさまにご迷惑をおかけしているんじゃないか…とか、ギルドワークスで働いていて楽しさや嬉しさがあればあるほど、逆方向の闇スパイラルに陥ることもしばしばです。

こんなとき、皆さんは、「出家したい」と思ったりしませんか。私はしょっちゅう出家したいなあ、と思っています。
先日、私があまりにも出家したい、出家したい、と言っていたので、見かねた取締役の増田からこの本を勧められました。

zenmind『禅マインド ビギナーズ・マインド』鈴木俊隆 著

あわせて面白い話を聞いたのですが、人間の内臓にかかわることで、「呼吸」だけはある程度コントロールがきくそうです。
考えてみれば、私たちは、私たち自身の体であるにも関わらず、心臓を止めることも動かすこともできないし、さっき飲んだお酒を今すぐ分解しろ!と、肝臓を働かせることもできません。自律神経とはよくいったもので、私たちの体はこうした意志とは、基本的につながっていません。
ただ、「呼吸」だけは、なんとかなる。
大きく吸うことも、大きく吐くこともできるし、逆に短く吸って吐くこともできる。
唯一自分自身でなんとかコントロールできる「呼吸」に集中することで、自分に向き合い、自分がどのようにあるのか、ということを、否定もせず、肯定もせず、ただそのようにして受け止めることができる、と。
だから座禅のときは、呼吸が大切なんだそうです。

この話を聞いて、そして『禅マインド』を読んで、なるほどなあ、と、思ったのは、呼吸というのはフックであったりきっかけにすぎず、「そうしたものがそのようにしてあること」を、否定してはいけない、ということです。心に浮かぶものはコントロールできない(自由にできるものではない)のですから、おそれや不安といった暗い感情も、打ち消すためになにかするのではなく、それは、そのようにしてあるのだ、というのを、眺めておく、客観的に見る、ということで、マイナスな感情に呑みこまれずに済むのではないでしょうか。

これだけだと、「ギルドワークスには性格の暗い人がいるな」というだけで終わってしまいそうですが、もうひとつの気付きは、禅と、エンジニアやデザイナーの進む方向に、通じている部分があるのではないか、と、いうことです。

『雑阿含経典(第33巻)』に、四種類の馬の話があります。卓越した馬、優秀な馬、普通の馬、劣った馬、の四種類です。
誰しも「卓越した馬」でありたい、「卓越した馬」になりたいと望んでしまうことがあるのではないでしょうか。
ところが、ブッダは、この四種の馬の中で、「劣った馬」を、もっとも大切にするのです。不完全であるからこそ、劣っているからこそ、多くを学ぶことができ、多くを乗り越えるための力をもち、そしてそのための意志をもちやすいのです。

これを読んだとき、『情熱プログラマー』の中の一章、「一番の下手くそでいよう」を思い出しました。
エンジニアも、デザイナーも、能力的にすべてよし、という状態はおそらくなくて、不完全なところから、劣っているところからはじめて、よりよいものをつくったり、よりよいとりくみをしていく努力ができるのではないでしょうか。
私自身、実際にものを作る段階には、外界をシャットアウトし、まさしく「自分に向き合う」ところから始めることが多いのですが、この、「自分に向き合う」というのも、はじめに書いた、「そのようにしてある」というありようを、受け入れることでもあるように思います。
また、クリエイティブな仕事というのは、何か「業」のようなものを抱えているので、禅の思想に近しいと捉えると、すこし、自分たちの仕事の別の一面が見えてくるように感じます。

自分は完璧にセルフコントロールができている!というかたは少ないと思いますので、カジュアルな出家の前にぜひお勧めしたい著作です。

slackの投稿は血液として組織を駆け巡る

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

私は宮城で働くリモートワーカーで、以前の記事(ギルドワークスのリモートワークを支える技術)でご紹介した通り、様々なツールを使ってリモートワークを実現しています。
その中で最も利用頻度が高いツールは slack です。
今回はこの slack についてお話したいと思います。

mac phones full

リモートワークをしていると感じる瞬間

業務時間中、slackの投稿がふと途絶える瞬間があります。
こんな時、少し不安になってしまうことがあります。
小さな不安ですが、リモートワークをしているとなおさらかもしれません。
もちろん、これはみんなが仕事をしてないわけではなく、単に客先打ち合わせや作業中で投稿がなくなっただけです。

逆に、slackの投稿が急に増えることがあります。
よくあるのは、連携している pivotal tracker や github からの更新通知が大量に届くことです。
ある一人がその大量更新に関わっていることが多いので、だいたい「◯◯無双」という言われ方をすることがあります。
この場合、その大量の通知に紛れて重要な書き込みを見逃してしまったりしてないか、不安になったりします。

組織の血の巡りがslackに現れる

このように、slackでは投稿が多過ぎても少なすぎても、ある種の不安が出てきます。
これは、身体の脈拍に似ているな、と思います。つまり、slackの投稿は組織の血液のようなものです。

そして、一定のリズムで流れていることが大事なのではないかと考えるようになりました。

それぞれの組織に合ったリズム

人間で考えたら、低血圧な人や、健康をずっと維持する人、夜型の人など様々です。
そう考えると、組織にも様々なリズムがあるでしょう。
slack は各種連携などもあり、様々なリズムに合いやすいツールであるから、気軽さが生まれるのだと思います。
ちなみに弊社のslackは8〜10時頃に高い心拍数になっています。朝のジョギングのようなものだと思います。

まとめ

今回は、リモートワークをしている観点から、slackの投稿が組織の血液循環のように感じる、というお話をしました。
普段は意識しないけれども重要なファクターという意味で、リモートワーク中のコミュニケーションを考えてみると、面白い発見があるかもしれません。

告知です。
そんなリモートワークをテーマに、私・佐々木がその中で20分ほどお話することになりました。
6月27日(土)に山形にて「Telework Remote worker Beerbash in Yamagata#01」と題した集まりが開催されます。
もしお近くにいらっしゃれば、お気軽にご参加ください。

(アイキャッチ画像はhttps://brandfolder.com/slack より引用しました。)