小さな変化を生み出すときの「エバンジェリスト」の小さな自覚
「それまでなんとなく，特段良いわけではないが，とりあえずうまく回っている」ような組織に新しい「変化」を起こすことはちょっと怖かったりする．
労務管理の文脈で言えば，それまで常態化していた長時間労働のマインドを180°変えて生産性を上げて勤務時間を短くしようとしたり，
古くから使われている比較的生産性の低いプログラミング言語でのソフトウェア開発を脱却して，モダンでイケてるプログラミング言語を導入しようとしたり，
もっと一般的にビジネスの文脈で言って，それまで経験や知見のない分野で新規事業を立ち上げてみたり．
その是非はそれぞれの文脈において語られることなので置いておいて，その「変化」を導く立場は，総じていつでも大変なものだと思う．
そもそも自分が正しいことをやっているのか自信を持てなくなることもあるし，その変化の向かう先にあるものについて，自分だって本当にマスターしたり理解しているわけでもない． ただ，「変化」を導くことの一番の大変さは，周囲の人々の認識や気持ち，習慣を変える大変さだと思う．
周囲の人々がその変化の関心を持っていなかったり，必要を感じていなかったり，もしくはその変化にそれまでいい思い出がないから，少し敵対心を持っていることもあるかもしれない．
それこそ，先日の Regional Scrum Gathering Tokyo 2018 で行われた Open space technology では，そんな「変化を起こしたいけれどもどうしたらいい？」という悩みが元になったディスカッションテーマもたくさんあった．
例えば，それまで混沌とした開発をしていた組織に，スクラムやアジャイルの導入という「変化」を起こそうとする．そのとき，変な反骨心を買って反発を呼んだり，自分の変化の起こし方がうまくなくて失敗してしまった時，周囲の人達に，「たまたま，彼があの状況でうまくできなかった」と理解されたり評されたりするのは，すごい幸せなことだと思う．恐ろしいのは，「あの変化は起こすべきじゃなかった」と言われること．スクラムで言えば「ほら見たことか，スクラムなんて導入するのが間違いだったんだ」と言われることだ．
どこかのアイドルの「私のことは嫌いになっても，AKB48 のことは嫌いにならないでください」というセリフがどんな背景で発せられた言葉なのかは理解していないけれど，まさしくそんな言葉も言いたくなるような状況だなぁ，と思う．
その「変化」を主導する立場の人にとって，ちょっとした「エバンジェリスト」の自覚って大事なんじゃないのかな，という気がしている．まさに，そのような「変化」の現場では，その変化を先導する役割はまさに「変化」そのものなのだ．自分が彼らの「変化」をうまく導けなかったら，それはまさしくその「変化」自体にダメだったという烙印を押されかねないという，大げさに言えば覚悟みたいなものは持つべきなんじゃないのかなという気がしている．
「エバンジェリスト」とは，もともとの意味は「伝道師」である．まさに，その「教義の伝道」に失敗した時，その宗教自体が「良くないもの」と捉えられかねない．自分の評判が落ちることはまだしも，その変化自体が意味のないものだと思われることは，その「変化」を信じる人にとっても痛手であるという意味で影響する範囲が大きいということを何処かで感じているべきなんじゃないのかな，とか思うわけである．
「組織」の「変化」と言えば，真っ先に Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン という本が浮かぶ人もいるだろう．この本の48のパターンの1つ目は，まさに「エバンジェリスト」である．自分がその「変化」に情熱を傾け，自分自身を突き動かす，というパターンが1番最初に書かれている．なによりも「変化」を主導するのに，その「変化」を自分ごとにする情熱こそが一番の原動力であるというメッセージが，48パターンの1つめというところにあるのかなと思う．
そして一方で，このパターンの注意点もこの本には書かれている．引用したい．
一方で、あなたが新しいアイデアに対して情熱的になりすぎると、周囲の人が引いてしまうリスクがある。情熱をコントロールし，決して我を忘れてはならない。(中略) あなたが身につけるべき重要な能力の一つが、忍耐強さと性急さの両方を同時にもつ能力かもしれない。
「エバンジェリスト」を中心に置いた考え方をすれば，この書籍に書かれた残りの47のパターンは，エバンジェリストの情熱が暴走しすぎないために，忍耐強く「変化」を推し進めるためのテクニックなのかもしれないな，と思った次第．
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (16件) を見る
チームを自己組織化を促進するための「境界」の引き方
最近，チームを自己組織化させるためにどうするかみたいなことをよく話したり考えたりするのだけれど，チームの自己組織化を考えるうえで，特に組織の「境界」をどこに引くかはとても重要なんじゃないかなあと思うので，今の考えをまとめておく．
基本的にはどのような組織にも当てはまる話ではあるが，主にソフトウェアシステム開発の現場での経験が元になっていることをご理解いただきたい．
自己組織化とは何か
いろんな定義があると思うのだけど，自分は Scrum Alliance の認定スクラムマスター研修にて日本人唯一 *1 の認定スクラムトレーナーである江端一将さんが仰っていた定義がわかりやすいと思う．
1. チームのゴールが明確であること
2. チームの仕事や裁量の境界が明確であること
3. チームメンバーが，自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること
また，最近同僚と話していた中で出た言葉で分かりやすかったのは 「チームが勝手に最適化されること」 という言葉だった．
ソフトウェアエンジニア的に「最適化」という言葉がわかりやすくて，何らかの「最適化」がなされるためには，そもそも最適化されるべき指標が明確でないと最適化のしようがない (上記の江端さんによる定義の1つめ) . 例えば，アクティブユーザーの拡大を目的とするべきなのか，売上の拡大を目指すべきなのかの認識がチーム内でずれていれば最適化は絶対にできない．その組織は間違いなく自己組織化されていない．
そして，組織がどのようなシステムを用いてその指標を弾き出すのかも明確でなければいけない (江端さんの定義の2つめ)．例えばチームの携わるプロダクトが弾き出す売上を最大化するために，ソフトウェアシステム自体の改良だけが裁量の範囲なのか，営業アプローチの見直しまで入るのかでアプローチは変わるだろうし，その裁量の範囲が曖昧であればチームが自らアクションを自ら決めることは出来ない．
境界を設定することでチームはどうなるのか
で，チームの境界を明確にすることは自己組織化を促す上で大きな役割を果たすと考えているのだけど，それは以下のようなメカニズムからだと思う．
1. チームの境界が明確になることで，チームの仕事や裁量の境界が明確になる
2. チームの境界が明確になることで，チームの目指すべきゴールや注力するべき指標が明確になる
3. チームの境界が明確になることで，チームのゴールに向けたメンバーの自発的かつ自由なアイディアやアプローチを促進しやすくなる
境界は引くだけではダメで，引いた後に，その境界の内側でチームメンバーが如何に活発に活動してくれるかが重要になることには疑問はないだろう．その意味では，境界の内側でのファシリテーションや心理的安全性の確保が大事なのは言うまでもない．
逆に境界が存在しないなかで活発な活動を促してしまうと，それが正しい方向を向かなかったり，不適切なアプローチを取ってしまって，結果としてチームとしてのまとまりが欠如したり，チーム全体での最適化から大きく離れてしまうだろう．
境界の引き方を間違える例
境界は何でもかんでも引けばいいというわけではなくて，上手く狙いを持って境界を引かないと逆効果になりうる，というのが最近の自分の課題意識．
これまで自分の周りで見たり，自分がやらかしてきた「境界の引き方の失敗」の例を挙げると以下のようなものがある．
境界を引かない
単に「境界を引くことを知らない」というよりは，「みんなで一体となって仕事をしよう！」というメンタルモデルに引っ張られすぎて，組織デザインを怠ったりするケース．
組織の最適化するべき KPI も明確でないからコミットメントも弱くなるし，全員が目指す成果が存在しないので達成感も生まれず，チームビルディングをしようにも無理矢理な方法しか取れなくなってしまう．無理矢理なチームビルディングは持続可能でないし，どこか悲しい．
境界を引きすぎてしまう
逆に組織デザインについて勉強したばかりで，とにかくサブチームみたいなものを引いてしまう例．
スクラムでは，開発チームの人数について「小回りが効く程度に小さく，1スプリントに意義ある仕事を完成できる程度には大きく」ということで3人から9人とスクラムガイドにて規定されている．特に「3人未満だと充分なインタラクションが生じず生産性が出ない」と書かれている．組織を小さくすることを覚えてすぐのとき，チームと言いながら1人で何らかの仕事を任せているだけだったり，2人でチームを名乗らなければいけなかったりしているケースはよく見られるし，自分もやったことがある．
また，「小さすぎるチーム」ではなかったとしても，分けなくてもよい粒度で境界を引いてしまうことで，組織にムダが生じることはよくあるのではないだろうか．
境界を作って自己組織化を促すことの大きなメリットのひとつは，知識移転が容易になることだ．境界を定めてサブチームを作ってしまうと，知識移転が滞ったり，サブチームそれぞれが知識の体系化を別々に行ったり，問題解決をそれぞれが取り組んでしまうという無駄が生じてしまう．
(これを対策するのがマトリクス組織なんだろうけど，なかなかうまくいかないよねぇ…)
引いてはいけない境界を引いてしまう
目指すべき目標をベースに境界を引いて自己組織化を促すべきなのに，職域で境界を引いてしまうケースはよくあるのではないだろうか．給与体系とか採用といった人事的な都合は必要なのだけれど，仕事をする上ではその境界というか区別をそのまま持ってくるのはアンチパターンだと思っている．
たとえば，グループウェアのような SaaS システムの販売をする営業組織と開発組織の間に境界を強めに引いてしまうと，営業が見込み顧客から吸い上げた要望を開発組織に伝えてプロダクトの機能に反映するまでのリードタイムや正確さが失われてしまう．これは一種の知識移転の阻害だ．
知識移転が阻害されてしまうだけならまだ良いが，それぞれのサブ組織の間での目標や推奨される行動が矛盾してしまったり，そもそも目標を基準に境界を引いていないが故に組織全体の目標にサブ組織の目標が寄与しないというケースも生じがちだ．
一度引いた境界を見直さない
目標ベースで境界を引いて，ある程度の期間は成功したとしても，時間の経過とともにそのサブチームが掲げていた境界が最適なものでなくなることもある．
例えば，それまで中価格帯の品揃えを展開していた店舗チェーンが，新たに低価格帯の店舗を展開するとなると，組織内に境界を引いてサブ組織を形成するだろう．
当初は，低価格帯の店舗チェーンが想定した顧客セグメントに充分に受け入れられることを実証することがミッションになるし，何よりも組織やシステムを立ち上げることがファースト・ミッションになる．なぜなら，そのサブ組織のミッションを成し遂げることが組織全体の成長にも貢献するからだ．
しかし，その低価格帯の店舗チェーンのマーケティングやシステムが軌道に乗ると，ただシステムやオペレーションを洗練することではなく，収益性や知名度を上げることに最適化した組織へと変更する必要がある．システムやオペレーションの完成度を上げるだけでは，組織全体の成長にはそれまでほど大きく貢献できないからだ．
どう境界を引くか
ここまで境界を引くときの失敗パターンばかりを挙げてきたが，正直，どのように引けば正解になるかはよくわからない．正確に言えば，正解は文化や文脈といった様々な前提に左右されるし，失敗パターンの最後に触れたように，時間の経過とともに正解が変わってくることもあるから，正しい選択が出来ているのかどうか，境界を引くための正しいアプローチをとれているか，常に自問自答するべきなんだろうなぁと思っている．
以下，自分のこれまでの経験の中で有用だと感じているアプローチをいくつか書いておく．
組織に名前をつける
kawasima さんが チーム力向上のためのエトセトラ - Qiita にて書いているけど，チームとかサブシステムに名前をつけるのは非常に重要だと思う．アイデンティティを醸成することも出来るし，チームメンバーが勝手に境界を意識してくれるようになる．
ポイントは，名前をしっかり考えること．例えば，雑誌制作を行っている会社が新たに雑誌に掲載する広告の募集・原稿管理を行うシステムを開発するときに「広告システムチーム」と名付けても悪くはないのだけれども，アイデンティティや愛着は生まれないだろう．このような命名アンチパターンを，個人的には「飼い犬に犬と名付けるパターン」と呼んでいる．"ポチ" でも "モカ" でも "大五郎" でもなんでも良いけど，家族の一員として認めたい愛犬なのだったら愛せる名前をつけたいですよね．
物理的に近くで仕事をする
エクストリーム・プログラミング (XP) における Colocation のこと．個人的には，チームメンバーも含めて本格的にリモートワークと向き合ったことがないのだけれど，同じオフィスに居るとしても雑談ができる近さは本当に大事だと思う．
境界を意識させる上でも近くにいることは大事だし，自己組織化を促してスムーズな知識移転を実現したとしたら，その知識移転の大半は形式建てられたミーティングではなく，日々の雑談から生まれるものなんだと信じている．
会議体の出席者を調整する
境界外の人が参加するべき会議と，参加するべきではない会議を明確にするべきだ，ということ．
失敗しがちなのが振り返り会で，境界を意識せずに振り返り会を行うことで共感を産んだり課題感を共有して対策を考えることが難しくなったり，上司を含む重要なステークホルダーを同席させてしまうことで心理的安全が損なわれてしまうケースが多い．
また，スクラムでもスプリントプランニングにステークホルダーを参加させないとか，スプリントプランニングの中でも前半はプロダクトオーナー同席で取り組むプロダクトバックログを決めて，後半はプロダクトオーナー不在でスプリントバックログの書き出しを行う，とか工夫したりする．
結論
最近，ソフトウェア開発の文脈の外に出て経営学の観点から 組織デザイン (日経文庫) *2 という本を読んでみたりしたのだけど，車の製造やサプライチェーンの構築と比べると，ソフトウェア開発はプロダクトもプロセスも作って壊すというサイクルも圧倒的に早く回せるし，クラウド時代がやってきたことで物理的資源の制約も格段にゆるくなっているため，チームビルディングとかモチベーションを優先できるという意味で組織デザインの自由度が高いなぁ，と感じた．
しかし，自分もまだ全然理論的な側面で学びきっていない自負もあるので，「こういうことを学んで違う観点から考えると面白いよ」みたいなものを教えてもらえたら嬉しい．
喜び・情熱・大義 - Regional Scrum Gathering Tokyo 2018 に参加した
Regional Scrum Gathering Tokyo 2018 に参加してきた．
昨年から会社のお金で行かせてもらえているのだけれども，去年は色々とわけがあって1日目のみの参加だった．今年は，初日の説明から3日目の Closing Keynote までもれなく参加できた．嬉しい．
聴いたトークを順々に振り返る．
Build a Workplace People Love – Just add Joy (Rich Sheridan)
書籍『Joy, Inc.』の著者による基調講演
この本読んだこと無かったんだけど，メンローベイビーズの取り組みを聞いたときにはあまりに想像の向こう側を行き過ぎていて，即売会で書籍を購入し，それから行き帰りの電車とかでめっちゃ読んでいる．トークの内容は，ほとんど書籍の内容を実際の写真などを交えての紹介でした．
即売会はサイン会付きでした！ 本当は僕の最良の読書時間である風呂の時間にガンガン読んでいきたいのだが，Rich 本人だけでなく，翻訳者5人全員のサインまで入った書籍は，流石に水没のリスクには晒せず…
Cultural context is everything (Matteo Carella)
Agile の取り組みは，どのようなドメインかだけでなく，そのチームの文化や文脈に依存するから，具体的なやり方だけを真似してもうまくいかないよ，という話．事例紹介は，その背後にある原則や価値観を知るためでしかないよ，というのは本当にそうだなと思う．
で，文化は "Intangible" つまり形にはならないから触れられないけれども，"Ritual" つまり儀式としてその文化の一員になる手筈を整えることで，少し Tangible になるよ，という話は面白かった．
サーバント・リーダーシップを掘り下げて考えましょう (Rochelle Kopp)
日本の会社の生産性を上げるための経営コンサルタントをしているロッチェルさんは，今年の活動のテーマをサーバント・リーダーシップに置くとのこと．
チームを主役にするサーバントリーダーこそ，コーチングのスキルって大事なんだろうなぁ，とか思った．
6 Years Of Teaching Certified Scrum Developers: Re-spec, Re-design & Re-entry (Terry Yin)
Odd-e での認定スクラム開発者研修 (CSD) のトレーナーである Terry によるセッション
CSD 研修では，前の回の研修で参加者が取り組んだプロダクトに，新たに機能を追加する開発をするんだって！(すごい
ソフトウェア開発は「知識を」「創出し」「保存する」という3つが大事，ということを5日間かけて教えるのが CSD の研修とのこと．この3つの重要性は考えてみれば当然ではあるのだけど，端的に言えている言葉だなぁ．どういう人が CSD 研修に参加しているのか，ちょっと気になった．
Walking Scrum History with Patterns (Kiro Harada)
あんまり原田さんの良い写真が無かった…
スクラムがどのように生まれたかという話を，パターンランゲージという観点から振り返るという話．ScrumPLoP 知らなかった
Embrace Collaboration and Fun of Coding (Michimune Kohno)
アメリカの開発チームに参加することで感じた文化の変化，アジャイルへの転換などの話.
お仕事がとても楽しそうなお話ぶりで素敵だった．いちいち刺さる言葉ばかりだったけれども，写真にある「Agile 開発とはバックログと共に生きることと見つけたり」は，素晴らしい言葉だなと思った．バックログがなくなったときはプロダクトの終わりだし，バックログが積み上がっているということは，プロダクトはまだ成長する可能性があるということ．これから積極的に使っていきたい．
Scrumが難しいのは幻想 -情熱の再定義- (kyon_mm)
とても楽しみにしていた id:kyon_mm さんの発表
(スクラム | アジャイル) をやるには情熱が必要，という，人のメンタルに頼っている状態を良しとしない，それを突き詰めたら「情熱はシステムと同じ」という結論に至った，という話．1時間スプリント，今の自分が出来るとはまったく思えないけど，なんか割りと簡単にできるように思えちゃうようなお話ぶりだったのが不思議だった．
全くレベルは違うと思うけれど，「システム開発も開発プロセスの策定も，フロー単位とリソースの最適配置の問題という意味では同じ」ということを考えていた自分にとっては，進んでいく方向は間違ってないんだなぁと思うことが出来た．
スクラムチームとして、妨害リスト（Impediments List) を運用して見えてきた課題解決方法 (Narichika Kajiwara)
eureka の梶原さんによる，Impediments List の話
妨害リストはスクラムガイドにも出てこないし，運用事例もあまり聞いたことがなかったので，とても貴重なお話でした．
「レトロスペクティブをシングルループ学習と捉えて，妨害リストはダブルループ学習と捉える」とか，「チーム外も含めた透明性の担保が大事」とか，「やってみるとうまくいきそう！」という話が満載でした．
モヤモヤ女子大生がプロダクトオーナーになったら！
Odd-e Japan の実施したインターンで3ヶ月のプロダクト開発をした中で，プロダクトオーナー (P.O.) ロールを担った5人の女子大生の物語．
スクラムマスターのロールを努めた知花さんの力量の賜物でもあるのかもしれないけど， P.O. を努めた女子大生は誰もプログラミングなどのバックグラウンドを持たず，その中でこれだけ出来たよ，という事例はもっと色んな場所で広まってほしい．
実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。 (パネルディスカッション)
企業内での新規事業立ち上げを行う中でのカネと (社内) 政治の問題にどう立ち向かうかという話題．
黒田さん (id:i2key) の「資金調達のタイミングもアジャイルにならなければいけない」という話が非常に興味深かった．あとは「グレーゾーン わざわざ聞くから 黒になる」最高の標語w
山崎さんいわく，コクヨには2つの標語があるそうな．これもとても良かった．
- ギブギブギブテ (Give と Take の比率は圧倒的に Give が多くないといけないということ)
- 角を立てずに波風立てる
Open Space Technorogy : 「UI の無いプロダクトのスプリントレビューをどうやるか」
Open Space Technorogy は，ちょっと勇気を出してテーマを出してみた．広告配信システムを作っている中で，UI より先に入札配信システムを作っていたりしたので，その時の悩みをぶつけてみることに．
喋りながらだったからあまりイーゼルパッドには書けてないのだけど…
思った以上に人が来てくれて，30分ワイワイと議論できました．最初数人だったから自己紹介回してたけど，あれよあれよと人が増えたから途中で中断せざるを得なかったw
API を作っている人とか，スプリントレビューにどのステークホルダーを呼ぶのかを気をつければ良さそうだよね，みたいな話とかしていた中，
原田さんが「551 メソッドを使えばいいんだよ」と一言．
プロダクトバックログに「あるとき/ないとき」を書けば，そのプロダクトバックログの価値がわかる．そうすれば，UI がなくても何を作ってどれくらい価値が生まれたかがわかる．
なんだ！端的でめっちゃわかりやすい！とかなってました．
あなたの中に世界がある / You are the World (Akiko Iwakiri)
翔泳社の岩切さんによるクロージングキーノート．
大義は自分の中にある，それを (仕事を通じて) 満たすことできっと自分や世界が変わる． 今風に言うと最高にエモくて，3日間を締めくくるのに最高のセッションでした．Agile2017 のクロージングキーノート "Banish Your Inner Critic 2.0" もめっちゃエモかったんですけど，やっぱりこういうの狙うんですかね．
自分の大義を付箋に書く，というアクティビティがあったのですが，私はこう書きました．
なんというか，最近，今後のこととか，周りのこととか，いろいろ考えますけど，その悩みとか迷いとか思い切りを反芻すると，割とすんなりと出てくる言葉でした．今年はちょっと "大義" を意識してみよう．
ということで，3日間本当に楽しかったです！長い間準備を頑張ってくださった実行委員会とスピーカーの皆さまに感謝！
来年またお会いしましょう！
「フロー効率」をチームの常識にする - 『This is Lean』の内容をチームメンバーにレクチャーした話
フロー効率性と「This is Lean」
あくまで自分の観測範囲での話ではあるのですが，2017年，ソフトウェアやITシステムの開発プロセス関連に興味がある人たちの間でホットだったキーワードのひとつが「リソース効率性とフロー効率性」だったと思います．
私自身，それまで「リソース効率性とフロー効率性」という概念は知らなかったのですが，9月にあった XP 祭り2017 での発表を拝見してから，自分の中では一気に火がつきました． 具体的に「リソース効率性とフロー効率性とは何か」という話は，その時の発表者である id:i2key さんの発表資料やブログのほうが詳しいと思うので，興味のある方はご覧いただければと思います．
www.slideshare.net
簡単に言うと，「効率良く仕事をする」と言っても2つの方向性があり，それが「リソース効率性 (Resource Efficiency)」と「フロー効率性 (Flow Efficiency)」です．
「リソース効率性」とは，「プロセスを構成するリソース (ソフトウェア開発プロセスなら人，病院なら医師や医療機器) の稼働率を高くする」というアプローチで，一方で「フロー効率性」とは「プロセスを流れる価値の単位 (ソフトウェア開発なら開発機能や不具合，病院なら患者) がプロセス内で価値の付加されない待ち時間をなくしてリードタイムを短くする」というアプローチです．
この「リソース効率性とフロー効率性」という概念を明瞭に解説しているのが，i2key さんの登壇資料にもある『This is Lean: Resolving the Efficiency Paradox』という書籍です．
This is Lean: Resolving the Efficiency Paradox (English Edition)
- 作者: Niklas Modig,Pär Åhlström
- 出版社/メーカー: Rheologica Publishing
- 発売日: 2014/04/27
- メディア: Kindle版
- この商品を含むブログを見る
この書籍は，以下のような構成になっています．
- まず，前半にリソース効率性とフロー効率性について解説
- 次に「リーン」という言葉の生い立ちについて解説した
- リソース効率性とフロー効率性のバランスをどう取るかの戦略の観点から「リーン」という言葉の正しい意味を明らかにする
壮大なネタバレ: リーンとは
世間には 「リーン」という言葉を冠した書籍がたくさんありますが，簡潔に「リーンとは何か」を書いている書籍はほとんど無かったように思います．
- 「リーンな UX 開発は小規模な仮説検証を行う」
- 「リーンなソフトウェア開発では品質を作り込み，ムリ・ムダ・ムラを徹底的に排除する」
- 「リーンな製造業では在庫を持たない」
このような「リーンな組織はこういう行動をする」という具体的な手法はそれぞれの書籍に書いてあるし，リーンという言葉を知っている人だったら聞いたことがある人も多いと思います．しかし「リーンとは何か？」という問いに，上に挙げた3つのリーンな組織の具体的な手法を説明することの出来るような答えを用意できる人は多くないのではないでしょうか．
This is Lean という書籍の壮大なネタバレになってしまいますが，本書の中の解説では，Lean とは以下の2つの特徴を持つ，ビジネス戦略を実行するための実行戦略です．
- リソース効率性とフロー効率性のどちらも最高にある状態を目指すこと
- 最初にフロー効率性を高め，その後リソース効率性を高めるという順にアプローチすること
リーンはどのようなビジネス戦略を実現するか (例えば，低価格で利用できる航空便を展開するとか，高価格で至れり尽くせりのコーチングがついてくるスポーツジムを展開するとか，従来より燃費がよくリーズナブルな価格の乗用車を生産するとか) を規定するものではありません．ビジネス戦略によってリーンな実行戦略を実践する具体的な手法は異なるので，例えばリーンな乗用車生産プロセス (TOYOTA Production System とされるもの) の具体的手法のみをソフトウェア開発で模倣しようとすると，期待したとおりの効果を引き出せないことも多いでしょう．その結果として「リーンは車を作るためのもので，ソフトウェア開発には向かない」と結論付けられてしまう問題点も，This is Lean の中では指摘されています．
リソース効率性とフロー効率性のどちらも高い状態 (書籍の中では「Perfect State」と呼ばれ，その中でもそれぞれ100%な効率の状態は「The Star」と呼ばれています) を目指すのはスッと理解できそうですが，なぜリソース効率性でなくフロー効率性を最初に高めるという順になるのか，というのは書籍の前半に解説された2つの効率性の性質や，書籍のサブタイトルにもある「効率性のパラドクス」が大いに関係しているので，詳細が気になる方はぜひ書籍をご一読いただくことをおすすめします．
「This is Lean」レクチャー
で，この書籍の内容に痛く感激した自分は，2日間 (各1時間) をかけて，その内容をチームメンバーにレクチャーしてみました．
レクチャーを通じて「リソース効率」と「フロー効率」という言葉をチーム内での一種の「常識」としてしまうことを狙いとしました．例えばスプリントごとのレトロスペクティブでチームの改善をするときに方向性がブレなくなったり，プロダクトバックログを書き起こす際の粒度が大きくなることを防ぐことができるのではないかという意図です． *1 まだ明らかな効果が出ているというわけではありませんが，そこそこ良い方向に向かっているのではないかという実感はあります．
また，この書籍を自分が読んでいるときにも感じていたし，チームメンバーも気づいていたのですが，プロセスのフロー効率向上を阻害する要因として書籍の中で取り上げられている「リトルの法則」 「制約理論」「ばらつきへの対処」は，システムやマイクロサービス構成を考えるときにも有用な考え方です．2回のレクチャーを通じて，「開発プロセスを整備することも，システムを作ることも，フロー単位とプロセスを構成するリソースの最適配置を考える問題という意味では同じ」という考えをチームメンバーの間で共有できただけでもやってよかったのかなと思っています．
ということで，この記事を読んで興味が湧いた方はぜひ This is Lean を読んでみていただければ良いのではないかと思います！
Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き
これはなに
世の中の3人~8人程度のソフトウェア / システム開発チームの多くは，俗に言う「アジャイルな開発手法」のプラクティスを実践し，1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。
そして，日本の多くの現場では，「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います．
私が開発リードを務めているチームでは，KPT とは違ったフレームワークで週に1度のふりかえりを行っていて，割とうまくいっていると思っているので，それを紹介しようと思います．
KPT は「チーム」のふりかえりには向かない
最近個人的に思っているのは，KPT はチームのふりかえりには，適していないとまでは言わずとも，あまり向いていないのではないかということです．
よくある KPT の進め方は，K / P / T のそれぞれ，つまり「チームが続けるべきこと」「問題になっていること」「次のタイムボックスで試みること」を付箋に書いたり，その内容を順番に発言したりして発表していくかと思います．これをチームの振り返りのフレームワークとして用いると，いくつか不都合なことがあるのではないかと考えています．
透明性を担保するフェーズが無い
アジャイル開発フレームワークの一つであるスクラムは，「検査 (Inspection)」「適応 (Adaption)」「透明性 (Transparency)」 を3つの柱としています．透明性を担保した上で，それまでのチームの生産性や成果物などを検査し，変化や問題に対して適応していく，ということですね．
学習や改善のループを表す 「PDCA」という言葉の「Check」も，改善のループの中で行ったアクションに効果があったのか，計画通りに行動ができているのかを確認するというフェーズです．
これらの考え方に共通しているのは、全ての改善活動は，まず現状の把握から始まる，ということです。
「K/P/T をチームメンバーが思いのままに挙げる」というアクティビティからふりかえりを始めてしまうと，直近のタイムボックスにてチームに起きた事実を振り返るタイミングが無いのが問題だと思っています． 「前回の KPT で出た Try やアクションを振り返ることから始める」というチームもあるかと思いますが，そもそも透明性を担保するべきなのは ふりかえり で出た事項だけでなく，チームの日々の仕事で起こったこと全体ではないでしょうか．
チームのアクションは個人が決めるのではなくチームが決めるべき
「次のタイムボックスに何を続けるか」「次のタイムボックスに何を試してみるか」の主語は，当然ながら「チーム」であるべきです． *1 しかし、チームが主語になる Keep / Problem / Try をチームメンバー各々が挙げるというアクティビティには、いくつか欠点があります。
例えば、あるメンバーにとってやってみたいと思う Keep や Try という具体的なアクションが挙がっても、それが本当にチームで取り組むべきアクションであるかどうかは別なこともあるでしょう。チームで実際に何に取り組むかを決める上で、一度チームメンバーが挙げた項目を否定しなければいけないというのは、ふりかえりに参加するチームメンバーにとっての心理的安全を阻害する要因にもなってしまう可能性があるでしょう。
それに、そもそも対処したい問題に関する視座が揃っていないでアクションの話をしてもファシリテーションコストがかかってしまうのも、限られたふりかえりの時間を無駄にしてしまう要因となってしまいます。
透明性の担保から始める「Good/Bad」と「事実/気持ち」
では私のチームではどうやっているかというと，横軸に「Good/Bad」，縦軸に「事実/気持ち」という2軸でマトリクスを書いて，そこにチームメンバー各自が思いついたことを付箋に書いて貼っていく，というアクティビティから初めています．*2
上半分の「事実」パートには、そのタイムボックスで起きた事実を書き出します。写真の右上なら「良い事実」や「前向きな事実」を書くことになるので、例えば、「xxx のユーザーストーリーマッピングがうまく行った」とか「平均のレイテンシーが 2 ミリ秒を切った」「差し込みでの作業対応が減った」といったことでしょうか。
下半分の「気持ち」パートには、ネガティブなものだと「不安」とか「愚痴」「辛い」といったもの、ポジティブなものだと「心地よい」とか「皆に知ってほしい」「楽しい」といったような話を書いていきます。例えば左下の象限は「良くない気持ち」「後ろ向きな気持ち」を書く場なので、他のチームはなんで柔軟に対応してくれないのか…」とか「XXX とのシステム接続がうまく行くか不安」といった内容を書いたりします。
自分の挙げる項目がこの4象限のどこに当てはまるのかはメンバー各自の裁量に任せています。
チームメンバーから付箋が出きったら、順番に付箋の内容を読み上げながら翌タイムボックスで実践するアクションを参加者で検討していくように話を進めていきます。
Good な項目で、翌タイムボックスでの仕事の生産性を上げる施策として取り組めないか、Bad な項目は根本な原因を考えたり、それに対するチームとしての取り組みができないかを考えます。
4象限のどこから始めてどういう順に会話を進めていくかはファシリテーションの裁量だと思うのですが、自分はいつも「Good な事実」から始めて「Bad な事実」「Bad な気持ち」「Good な気持ち」という風に、反時計回りに進めるようにしています。良い事実を確認することでふりかえりの雰囲気を明るくし、後ろ向きな事実や気持ちに向き合いつつ、最後には前向きな気持ちをチームで共有することでポジティブな雰囲気を作ってスプリントを終えるようにしたい、というのが狙いです。
何が良いか
この形でふりかえりをやるようになって3スプリントくらいになるのですが、以下に述べるような良い点があると思って続けています。
事実を洗い出した上でチームで取り組むことを議論させるように持っていきやすい
チームメンバーに書き出してもらうのは、「良い事実」とか「良くない気持ち」といった 現状の確認 であり、具体的なアクションではありません。そのため、前述したような、最初にアクションから考えてしまうことによるファシリテーションコストのムダも減らせます。
また、事実を並べた上でチームで議論してアクションを決定するという流れを作ることで、「チームで決めたこと」という納得感を作った上で翌タイムボックスで改善活動に取り組むという流れを作りやすいのも良いところです。
「気持ち」という欄でチーム内の共感を生みやすい
最初は「Good / Bad」という1つの軸のみで事実を振り返るというかたちで振り返りを進めていたのですが、「クリック率にフォーカス出来るのが楽しい」「xxx をリファクタしておきたい」「テストデータをもう少し拡充させたい」といった、事実とは少々違った話題が多く出るようになり、その中にこそチームの改善のヒントがあるだろう、ということで後から導入したのが「事実と気持ち」という軸でした。
それまでの振り返りでも「気持ち」にまつわる付箋は各参加者が書き出していたのですが、明示的に欄として設けることで、その流れを促進することが出来るようになり、ふりかえりの内容が一段と濃いものになったように思っています。
なにより、ふりかえりの中で「気持ち」を表明することを促すことで、他のチームメンバーもその気持ちに対する共感を表すこともでき、結果としてチームビルディングにも良い影響があるのが良いところです。
ときには愚痴っぽい話がメインになってしまうこともあるかと思いますが、最終的に前向きに改善に臨むためのアクションを議論するようにファシリテーションをするようにさえすれば、ふりかえりの主目的である改善活動をしつつ、チームワークの醸成にも一役買っているのかな、と思っています。
KPT でやっていけないわけじゃない
KPT にしろ、今回紹介した「Good/Bad と 事実/気持ち」にしろ、議論を行う上でのフレームワークはファシリテーションを行う上での道具でしかないし、結局はファシリテータに高いファシリテーション能力があったり、チームが充分に自律し自己組織化していれば、どんな形式でふりかえりを行ってもチームや日々の仕事を改善していくことは出来ると思います。
ではフレームワークは何のためにあるかといえば、やらなくてよいことをやらずに済ませるようにすることでムダを省いたり、ファシリテーションスキルが高くない中でもある程度のパフォーマンスを出せるようにするためなのだと思います。
もし普段 KPT でふりかえりを行っていて、どこか上手く行っていないような気がするという場合は、今回紹介した進め方でふりかえりを試してみても良いのではないでしょうか。
じゃぁ KPT ってどういうときに有効なの？
記事の特性上、「KPTってイケてない」と思われてしまうような方もいらっしゃるのではないかな、という危惧が無いわけではないのですが、KPT 自体が悪いわけでもありません。
KPT が向いているのは、個人のコーチングやメンタリングをする文脈ではないでしょうか。なぜなら、トレーナーやメンティーが、自省を踏まえて自分の裁量で各種アクションを決めれば良いからです。トレーニーやメンティーが自分の Keep するべきことや Problem になっていることや Try することを自分なりに考えた上でトレーナーやメンターとの 1 on 1 のミーティングに臨んだり、1 on 1 の中で KPT の各項目を埋めていったりするのは非常に有効だと思います。
XP祭り2017 に行ってきた #xpjug
行ってきた．個人的に2週連続のカンファレンス参加．
聴講したセッションについて．
基調対談: ワークスタイル改革を実践する2人が働き方の本質を語る
まずは，サイボウズの青野さんとソニックガーデンの倉貫さんの働き方改革についての話．
ウォーターフォールの何が辛いか，それぞれの会社のアジャイル文化の話，DevOps 化，有給や昇給や経費の管理，キャリアに対する考え方などの幅広い話題について．アジャイルの考え方は，本当の「働き方改革」とすごい親和性があるなぁという，非常に面白い話だった．
ひたすら Twitter で実況していたのだけど，一番個人的に面白いなと思ったのは，ソニックガーデンの「YWT」の話．
倉貫「YWT やったこと，わかったこと，次にやることを面談する．#xpjug #xp祭り
— むらみん (@Mura_Mi) 2017年9月16日
倉貫「YWT を続けるとみんなか従業員が考えるようになる．社会人になるまでは進路相談という形で自分の人生を考える節目があったが，社会人はその進路相談がなくなる．ソニックガーデンでは YWT を進路相談と呼んでいる」#xpjug #xp祭り
— むらみん (@Mura_Mi) 2017年9月16日
倉貫「YWT を続けると，若いことベテランで内容が変わってくる．若い子のYはきらきらしたこと．ベテランは「自分には向いてないとわかった」みたいな話になる．でも普通の会社で，できなかったとを話したらダメ．#xpjug #xp祭り
— むらみん (@Mura_Mi) 2017年9月16日
YWT進路相談の続き
— むらみん (@Mura_Mi) 2017年9月16日
倉貫「ベテランは，できないことをわかったと言えるし，それを理解した上で，自分の得意なところに強くコミットするようになる．歳とったら弱みを見せる，全部やらない」#xpjug #xp祭り
実況ツイートで拾えていない部分もあるので補足を．
キャリア面談として定期的に話す内容を YWT というフレームワークに沿って挙げているということなんだけど，
そこで「これは自分に向いていないことがわかった」とか「すごいしょぼいとわかった」みたいな話を人事考課のような文脈で出してしまうと絶対マイナス評定になるんだけど，
でもソニックガーデンでは個人の人事評価もないので，そこを正直に話せるし，ベテランになると「じゃぁ自分はこれを頑張る」というのをしっかり持てるので良い，という話で非常に興味深かった．
DevOps 時代のプロジェクトマネジメントを考えよう
登壇する内容で「壮大な三部作」という構成を作れるってすごいですよね．
大きい SI の企業の中でピラミッド型チームをフラットなチームにする途中の段階として，ピラミッドの最下層に球拾いを出来るリーダーシップを設けるっていうのは斬新というか，良い過渡期の設け方だなと思った．
色んな要素で「大構築時代」と「DevOps時代」を対比している点は非常に整理されていて腑に落ちるセッションでした．
全ては Fearless Change から学んだ，開発組織の変革を支えた実践的アプローチ
初めて @kakakakakku さんこと よっしー さんのセッションを聴講したのですが，25分という短い時間にこれでもかと詰め込んだ内容で，本当にエネルギーの溢れる方でした．
「達人」のサポートを得ることでチームのポテンシャルというか能力を限界突破させるというアプローチはとても効率良いな，と思ったし，せっかく幅広い達人を抱える会社なのだから活用できるようにならないとな，と思った．
xUTP から学ぶ記述性の高いユニットテスト
Agile2017 @ Orlando でもお見かけした高橋陽太郎さんのセッション．
given-when-then などの構造を紹介しながら，メンテナビリティの高いテストコードを書く技術について．
個人的には，一番最初のスライドに出てきた，メンテナンスコストと享受するメリットのグラフが良かったですね．
ScalaTest のこういう事例とかセオリーを誰か出してくれないかなぁ.
シンプルデザインについて
『Real World HTTP』の著者である渋川よしきさんの公演は，XP の 1st edition で原則の中にあった「シンプルデザイン」について．
スライド見当たらないようですが．
シンプルデザインは，ユーザーや開発者や出資者などのそれぞれの視点で，同じデザインでもシンプルかどうかは違うので，そのトレードオフをしっかり選択することや，シンプルなデザインを表すパターン・ランゲージを考えている，という話．
パターンというと GoF のデザインパターンをみんな真っ先に思い浮かべるけれど，パタン・ランゲージはそれを組み合わせて会話をしなければいけないので，そういう意味では逆演算をたくさん紹介している『リファクタリング』のカタログのほうがパタン・ランゲージとしては完成度が高い，という渋川さんの考えが非常に興味深かった．
リソース効率性とフロー効率性について
www.slideshare.net
個人的には今回のベストトークでした．ここまでプロダクト開発の「効率」って突き詰めて整理できるんだ，という目からうろこ．
持てるリソースの稼働率を 100％ に近づけるリソース効率性と，機能や価値が提供されるまでのリードタイムを最短にするフロー効率性はトレードオフではなく，どちらも両立できること，その状態に持っていくためにはまずフローの効率性を高めてからリソースの効率性を高めましょう，という話．
詳細は触れられていなかったけど，高橋さんがフロー効率性を担保しようとしたつもりがリソース効率性を高めようとしてしまったという話が非常に興味深かった．そのために，リソース効率性を高めなければならなくなるような制約 (例えばタイトな納期とか) をいかに，交渉だけでなく技術的なアプローチも使いながらコントロールするかが大事．
チームをワークさせるために最も大事なコミュニケーション意識していますか？
www.slideshare.net
職場のプロダクト外活動でなにかとお世話になっている吉田浩一さんのセッション．
普段から組織内コミュニケーションとかリーダーシップとかについてはめちゃめちゃよく話しているんですけど，そのときによく話題に上がる問題意識とかに溢れたトークでした．
特に「自分がいなくなっても回るような自立 / 自律的なチームを目指す」という点は，自分もよく意識していますが，このスライドにあったような権限委譲の段階みたいなのを強く意識するのは大事ですよね．
おまけ & まとめ
感謝！ #xpjug #xp祭り pic.twitter.com/JGb4HXS7JT
— むらみん (@Mura_Mi) 2017年9月16日
初参加ということで，協賛出版社からの見本書籍をいただきました．ありがとうございます！
来年はぜひとも，小さい枠でも登壇したいな！
Scala関西Summit 2017 に行ってきた
来たでー。 #scala_ks pic.twitter.com/bjbtHD0hKc
— むらみん (@Mura_Mi) 2017年9月9日
気がついたら全然写真撮ってなかったんだけど，Scala関西Summit 2017 に行ってきた．
東京のフツーの Scala エンジニアだったら ScalaMatsuri があるからわざわざ関西まで行くこともないんじゃない？というのは自分も思ってるのだけど，
今年の2月にあった ScalaMatsuri の頃，僕は Java エンジニアだったし，今回の Scala関西Summit のタイムテーブルを見たら自分の中でホットな話題も多かったので，思い切って行ってみた．結構行ってよかったと思っている．
印象に残ったセッションについて書いておく．
Non-Functional Programming in Scala (@takezoen さん)
www.slideshare.net
竹添さんによる，「Functional じゃない感じで敷居を低くする Scala の使い方」についてのセッション．
Scala は手続き的な書き方もファンクショナルな書き方もできるがゆえに，チームが成熟するにつれて，プロダクトのコードはだんだん複雑になっていって新規メンバーにとってハードルの高いものになっちゃうよね，という話は本当にそうだなぁ，という感想．
ただ， var や while を許す，というのは個人的には関数型なのかどうかよりも前にコーディングが良くないんじゃないかなと思っていて，そういうのはちゃんとコードレビューで潰すべきなんじゃないかなぁ，という気も．
もちろん，そこも含めてチームの成熟度とかだと思いますけどね．
実践 ScalaでDDD (@crossroad0201 さん)
Scala で DDD なプロダクトを実装するには？という話．
case class の copy メソッドをラップしてエンティティの属性を変更する操作に名前をつけたり，
アプリケーションサービスの処理で Either や Try や Option を返す処理をメソッド内で def で定義して for { ... } yield { ... } で並べて書くことでユースケース仕様書ぽく書いたり，
エンティティが特定の条件下でのみ特定の振る舞いをすることを Role Object という implicit class で表現したりとか，
Scala の機能を DDD を実践するためにどう使うかというのがイチイチ絶妙でかっこよかった．いろいろ参考にして自分も実践してみたい．
Reladomo in Scala (@itohiro73 さん / @seratch さん)
www.slideshare.net
ゴールドマン・サックスが昨年 OSS 公開した Reladomo という Java の O/R Mapper を Scala で利用するためのライブラリを開発したよ，という話．
Microsoft が VSCode を，トークセッションの最中に github で public に公開した時のように，トークの最後に瀬良さんが push することで公開となりました．
自分的には JJUG CCC などでの Reladomo の紹介を見て良いなぁ使いたいなぁと思っていて，仕事でちょうどウェブ UI アプリケーションを新規に作るので O/R どうしようと考えていたところなので，積極的に検討したいなと思った．
ただ，現状の reladomo-scala の機能ではエンティティを case class で生成して target 下の src_managed に吐き出しているので，独自にドメインロジックを表す API を書いたりという拡張ができないようで，ここは implicit class とかで生やすっきゃないのかなあ？とか色々考えている．
スライドの中や，公開されたサンプルコードの中で NewPerson というクラスが出てきて，これなんだろうなと思ったけど，DB 上の Auto Increment な id を付与する前の id を持たないインスタンス用のクラスだよ，というのを懇親会で瀬良さんに解説していただいた．セッションでは端折られている説明だったので助かった．
瀬良さんが開発している Skinny-ORM ではレコードの insert をする際に case class を Dao 的な API に渡すという方法がなくて， createWithAttributes('attribute -> value, 'attribute -> value, ...) という書き方がメインなんだけど，これも同様の理由で id のない状態のエンティティを扱うときに case class を新規に作るとしたら id = null とするのか？というのに対する答えなんだそうで．
Skinny-ORM だとエンティティ定義は case class を直接書かなきゃいけないけど， Reladomo の場合は XML ファイルを書いてコンパイルに通すと case class が生成されるという形なので， Person クラスの他に NewPerson を生成することが出来る，という話でした．
Property Based Testing でドメインロジックをテストする (@gakuzzzz さん)
Property Based Testing でドメインロジックをテストする
Property Based Tesは，なんとなくウェブ上での解説記事を読んで，その効能があんまりイメージできなくて真剣に考えたことが無かったけど，上手く使うと良さそうだなと思えたセッションでした．
最後に質疑応答で伺ってみたけれど， whenever(...) で生成されたフィクスチャをテスト実行のタイミングで絞ろうとすると whenever 条件の中に実装と同じことを書いてしまってトートロジーなテストになっちゃわないかな，というのは思ったので，上手く使い方を考えたいなと思った．その中で，がくぞさんのおっしゃっていた「普遍的な条件を見つけることにこだわらない (特定条件にしぼってテストする)」「視点を変えて満たすべき性質を見つけ出す」というのは非常に参考になった．
最初のセッションで「null 書くとがくぞさんに消される」というパワーある言葉を聞いてたから怖い人かと思ったけど，すごい朗らかな方だった #scala_ks #scala_ks_main
— むらみん (@Mura_Mi) September 9, 2017
懇親会
#mm_beer #scala_ks #kirin 懇親会ー！
ぼっちでの参加だったのだけど勇気を持って懇親会に参加したら，色んな人とお話できて非常に有意義だった．
すごいプライベートな話だけど，大学の同級生がいたのはびっくりした．いかんせん文系しかない大学で，特に自分たちのいた商学部は，会計士になるか，商社とか金融機関でキャリアを積む人が多いので．
自分の印象に残ったセッションのスピーカーの方とちょっと踏み込んだところまで話せたりするし，こういう機会は尻込んじゃいけないな，と改めて思った次第．
あと，会場のさくらインターネット株式会社様のオフィスがめちゃめちゃオシャレだった！びっくり．
翌日: 大阪食い倒れ
翌日は新幹線までちょっと時間があり，せっかく大阪に来たので，たこ焼きと串かつ．大阪駅からすぐそこだし，ちょっと混んでいても回転が早い!! もちろん美味しい！おすすめです．
