リーン開発の現場
という本のノートを描いて見た。この本は実例を交えながら紹介している本である。
当ノートは自分なりに本の中身を元にまとめて見ている。 個人的に後から考えてもいいのではみたいな章は省いたり、簡約したり纏めたりしてる。他にも自分で知っていることを含めて見たりもしているので必ずしもこれが正解とかは言えない可能性もあるのを忘れずに。
さて、そもそもアジャイルとかリーンとは何じゃ、ということをざっくり説明します。
アジャイルの概要
ソフトウェアコミュニティの17人のオピニオンリーダーたちが2001年にユタ州のスキーリゾートに集まってソフトウェア開発を成功させる方法について議論しお互いの考えを擦り合わせていくうちにアジャイルソフトウェア開発という言葉が誕生しました。そしてソフトウェア開発を成功させる方法に関する共通のビジョンを見つけて文章化したもので、いわゆるアジャイルマニフェストと呼ばれる文章になったもの。 内容を以下に示す。
私達は、ソフトウェア開発の実践、あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を。
包括的なドキュメントよりも個人と対話を。
契約交渉よりも顧客との協調を。
計画に従うことよりも変化への対応を。
価値とする。すなわち、左記の事柄に価値があることを認めながらも私たちは右記のことに価値を置く。
- 顧客満足を最優先し、価値のあるソフトウェアを速く継続的に提供する
- 要求の変更はたとえ開発の後期であっても歓迎する。変化を味方に身に付けることでお客の競争力を引き上げる。
- 動くソフトウェアを２〜３週から２〜３ヶ月という短い時間の間隔でリリースします。
- ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働かなくてはいけません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事終わるまで彼らを信頼します。
- 情報を伝える最も効率的な方法はフェイストゥフェイスで話すことです。
- 動くソフトウェアこそが最も進捗の重要な尺度である。
- アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなくてはなりません。
- 技術的卓越性と優れた設計に対する普段の注意が機敏さを高めます。 シンプルさが本質です。（言い換えると無駄なく作れる量を最大限にすること。）
- 最良のアーキテクチャ・要求・設計は、事故組織的なチームより生み出されます。
- チームがもっと効率を高めるかどうかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイルという言葉自体は2001年に誕生したが、ほとんどのアジャイルの方法論は１９８０年代にはすでに作られていた。アジャイルはこれらを包括的に指す言葉で、様々な共通点があればアジャイルとも言えなくもない。 つまり全てアジャイルとも言える。 逆に言えばではあるが、これらの共通点原則を持つものをアジャイルという多面的な表現を許容することでもあると考えれる。
スクラムの概要
ソフトウェア開発のフレームワークのことである。1990年ごろにできた。 スクラムは経験則に基づいたプロセス制御や複雑適用系理論を元にしている。 以下にコアコンセプトを説明する。
順番付けされたプロダクトバックログ
実現すべき事柄を小さくリリース可能な作業一覧に分割することを指している。
プロダクトオーナー（OP）はプロダクトビジョンを定義して、ビジネス価値やリスク、依存関係などのエレメントに基づきプロダクトバックログを作る。
要は全体の仕事の山を分割する。
- 職能横断型チーム
- スプリント
- 開発期間を短く固定されたイテレーションのことを指す。例えばリリース期間とかのこと。
- 目標まで走り抜けるのでスプリンターから来てる。
- しかし。短距離ランナーではなくペース配分をするマラソンランナーの方が現実は正解なのであるのは忘れずに。
- 継続的にリリース計画を調整する。
- プロダクトオーナーはリリース計画を最適化し、各スプリント後のフィードバックを顧客と強調しながら優先順位について更新する。
- 継続的にプロセスを調整する。
- それぞれのフィードバック後の振り返りによって最適化していく。
大人数で長い期間大きなものを作るのではなく、少人数で短期間で小さいものを作るのがスクラムであるということである。
XPの概要
1990年中盤に生まれたエクストリームプログラミングとは
シンプル
コミュニケーション
フィードバック
勇気
敬意
というジャンプばりの五つの価値を基盤にしたものである。 スクラムと並行して進化して来たためにほとんど同じ要素を持っている。例えばXPにおけるオンサイト顧客はスクラムのプロダクトオーナーとほぼ同一。
じゃあスクラムと何が違うかというと外向的か内向的かである。
スクラムはしばしばXPを取り囲んでると言われる。何故ならば組織構造の課題や外部とのコミュニケーションに着目しているからである。
ではXPはどうかというと、エンジニアリングプラクティスが主幹的だったりする。
- 継続的インテグレーション
自動ビルド、自動的な統合。そしてチームが開発したコードを自動テストする仕組み。これによって作業の品質が関わる早期のフィードバックをチームはより早く得ることができる
- ペアでプログラミングする。学習や設計品質を最大限引き上げることができる。また欠陥の発生を最小限にできる。
ペアのレベル差が大きいと片方のレベルが格段に上がる。
- テストコードを書いてテストを通すためのコードを書く。
またリファクタリングをしてコードを洗練させていく。
コードの共同所有
チームメンバは全員ソースを修正することが許されている。また奨励されている。これにより理解が進み協同的な感覚が生まれる。
インクリメンタルな設計の改善
- 初めはシンプルで実現可能な設計から始める。
- その後改善してブラッシュアップしていくアプローチ
カンバンの概要
カンバンはアジャイルソフトウェア開発におけるリーン的なアプローチだ。これは日本語から来てて工場にあるカンバンと同じところから来ている。つまるところ物理的な伝達システムのこと。
しかし、勘違いしてはいけないのが2004年にデイビットアンダーソンがソフトウェア開発におけるカンバンとしたのだ。間違っても天井に貼り付けるあのカンバンとは微妙に違う。
カンバンのルールを以下に示す
- ワークフローを可視化する。
- 作業を小さく分けてそれぞれをカードに書いて壁に貼り付ける。
それぞれのカードがワークフローのどのstatusであるのか可視化するためにそれのラベルのついたものに貼り付ける。
WIPを制限する。
サイクルタイムを測定し管理する。
- これを元にプロセスを最適化していく。
- 例えば人員の転換やさらに仕事の分割など。
リーンの概要
リーンとは「TPS」というトヨタ生産方式を元にしたものである。（というかぶっちゃけ同じで西洋でTPSと呼ばれるだけの話。）このTPSという方式は様々なものに適用可能とされている。その中にはソフトウェア開発も含まれる。
よくある勘違いとしてアジャイルとリーンは共通の価値があるために親戚や同一視されるが起源は異なっている。 リーンは製造業から、アジャイルはソフトウェア開発から誕生した。お互いの原則は相性が良く、適用できる範囲も広い。 最近多いのは製品コンセプトの開発〜デリバリまでというエンドツーエンドの開発の流れ全体でアジャイルとリーンをどう組み合わせて適用していくのかということが探求されている。
このリーン（TPS）の原則を、リーンソフトウェア開発として提唱したのがメアリー・ポッペンディークとトム・ポッペンディークである。
全体を最適化する
システムの一部分の最適化に時間をかけても必ずしもシステム全体の最適化にはならない。
- ストリーム全体を最適化する。
つまりコンセプトからデプロイまでの包括的な部分を指している
完全な製品を提供する。
- 顧客の一番の目的は問題解決なのでそれを解決できるソフトを作ろう。
無駄をなくす
無駄とは、顧客に価値を付加することのないあらゆるものである。ソフトウェア開発では3つの大きな無駄がある。
間違ったものを作るという無駄。
学び損ねるという無駄。
頻繁な引き継ぎや現場からかけ離れれた意識決定などいわゆる方針のブレのことを指してる。
過度な作業切り替えによる無駄。
品質を作り込む
プロダクトのテスト段階で毎回過度の欠陥が見つかるのであればプロセスに問題があると言える。
最終テストで欠陥を見つけないような仕組みづくり。
テスト駆動開発による誤りを防ぐプロセス。信頼を担保し続ける必要がある。
依存関係を断ち切る。
- 機能追加や変更を可能な構造をすべきで疎結合なものであるシステムアーキテクチャである必要があるべき。
たゆまぬ学び
計画は立てることに意味があり、学びを得ることにその本質がある。この学びというのは実験を重ねることなどを指している。
成果の予測可能性はフィードバックにより高まる。
選択肢を幅広くもつ。
変化への耐性を持たせる。
意思決定を最終責任地点まで遅らせる。
- 取り返しのつかない所に来る前に（決定とも表現） 可能な限り学習をしてできるだけ実験を重ねる。
速く提供する
ステークホルダー全員についての深い理解と、彼らにとっての価値を何かということを考えるところをから始めるべき。 それによって継続的にビジネス価値を生み出していく流れを作る。
素早いデリバリと更新しつ。低コストでの実現。
待ち行列理論は鯖だけではなく開発にも応用できる。
ゆえにプロセスには作業の塊を小さくして少しずつ流す。代わりにサイクルタイムを短くしていく。
ワークフロー管理はスケジュール管理よりも簡単にできる。
- 任意の日にリリースする最善の方法はイテレーションやカンバンシステムを使ってしっかりとイテレート可能なワークフローを確立することにある。
全員を巻き込む
優秀なメンバーは起床資源である。チームメンバーは公平かつ公正に適切に対価を得る人々であり、自律、熟達、目的に応じて意欲を感じるのだ。
- 自立
効率よく働くチームのメンバーというのは半ば自律しているチームである。チームにはメンバーの精神面を支えるリーダーが存在し、リーダーは完了させるべき作業や意義のある作業について始めから終わりまで責任を持つ。
熟達。
人に敬意を払うことでチームの誰もが素晴らしい人なるための挑戦やフィードバック環境が生まれる。
目的。
- 仕事と価値を繋ぐものが目的である。仕事の意義を感じることで初めて人々は目的の達成に没頭する。
改善を続ける
結果が重要なのではなく、人と結果を出せるシステムを育てるのが重要なのである。
- 失敗とは学ぶ機会である。
小さな失敗でえ注意深く調査し、修正すれば最高に信頼できるパフォーマンスを生み出せる。
標準は挑戦や改善のために存在する。
現在の標準になっている物への挑戦や変更を奨励していく。その上で現状最も知られていて誰もがわかる理解を標準化していく。
科学的な方法を使う。
- 仮説の検証法、早くたくさんの実験を行うやり方、簡潔なドキュメントの作り方。これまでとは違った良いやり方をやる。
つまるところある種の信頼が担保されたものを実行することである。 何言ってるんだって感じなのでつまるところ、
- 顧客の目で「価値」を定義。
2.その価値の流れを可視化する。
3.それを「エンドツーエンド」で「細く、速く」流れるようにする。
4.その流れの改善活動を現場で実際に仕事をしてる人が行う。
ということである。以下から実際に当該書籍を元に紐解いていこう。
一章 プロジェクトについて
スウェーデンの国家警察で作ってるPUSTという新しい捜査報告システムを元に紹介する。これを実現するにはある要件を満たす必要があった。
膨大な量のレガシーなシステムと統合
相手に質問しながらリアルタイムでシステムを使うため警察官にとって簡単に使えるシステムである必要がある
堅牢なセキュリティ
たくさんの複雑な法律や規則を遵守しなくてはいけない
スケジュールが厳しい
タイムライン
スタートは2009年9月から。一年後にはリリース。その後は隔月でリリース。 スケジュールの中で重要なマイルストーンは
1.0の最初のバージョン
1.4の警察全体で使えるようなったバージョン
早めにリリースしていくスタイルである。 理由としてはバグや思い込みなど仕様をすり合わせつつ行うことのできる点にある。よって頻繁なリリースをするというのは一度のリリースに抱えるリスクを減らすと言えるだろう。 また、リーンの特徴として開発のプロセスがどんどん変わって、進化し続けることが挙げれる。
スケジュール分割について
大きなプロジェクトでリスクを最小化する鍵は大きな像を分割する方法を見つけ出すことである。こうすることで、小さい機能を徐々に増やしていくことができてシステムを何度もリリースするインクリメンタルリリースを行える。リスク分散の観点からもユーザーにそれぞれ価値を送りフィードバックをされていくというより良くしたいという流れからも良い作業と言える。 今回の場合は地理的な場所と犯罪者別という点から最小化にかかった。
- リリース1.0から1.2
- 一つの地域のみに対応。
- 飲酒運転など武器の所持。よくある多い犯罪種のみ対応。
徐々に犯罪種のサポートを増やした
リリース1.3:
- ２つ目の地域に対する拡張リリース
これをメインリリースとした
リリース1.5
- 犯罪種別を追加押収品の管理システムなど他のシステムと統合したバージョンをリリース このような形に分割した。
顧客について
これは警察組織のプロジェクトで顧客やユーザも身内であった。がこれは当該プロジェクトではある一人が主役である「顧客」として振る舞った。 エピックにあってるかどうか、詳細なフィードバックをもらうなどを行った。 （エピックは一般的には壮大な作品という意味だが、この文脈では大まかな要求、大きなストーリーという意味である。）
二章 チーム編成
ソフトウェア開発プロジェクトにおける難題の一つとしては適切な人数でチーム編成して、不空のチームが強調して動くためにはどうすれば良いのかというのが挙げれる。 メンバーの人数が増えるに従ってコミュニケーション問題やコラボレーションの難しさにぶち当たる。組織が成長する際によく発生する痛みの症状と同じ。 初めの小さい頃は疑問があれば人数が少なく近くにいることが多いのでどのように運営するかなど方針に対する容易に行えた。 これに対して、実際人数が増えたが上手くいけたのはメンバーが一つの場所で働いていたことにあるだろう。また柔軟にチーム編成を進化させた。今では５チームで行っている。
要求分析
機能開発が３チーム
チームではなく、プロジェクトマネージャや構成管理、パフォーマンステスト、コーチなどがいる。
さて。 三つの開発チームは基本的によくあるスクラムチームで構成されている。職能横断型で、自己組織化していて、昨日全体と開発とテストする能力がある。 要求分析のチームは仮想的なチームでアナリストが所属していて、基本的に他のチームに所属しながらなので仮想的。 これによってプロジェクトメンバー全員が分散して配置されている。 また、この理由としてアナリストと各プロジェクトの人たちがコミュニケーションを取りやすいようになっている。
基本的に要求分析チームは３つの役割をこなすことになる。
何人かのアナリストは機能開発チームの一つに所属し、開発者からの質問に答えて要求を明確にするために、開発からチームの開発をサポートする。
何人かのアナリストはどの機能開発チームにも参加せずシステムの全体像の分析に重点を置いて取り組んでいいる。彼らはシステムの概要となる昨日エリアを定義するために、将来像を見定める。
残りのメンバーは上記の２つのうちどちらかに柔軟に横断して必要な作業を行う。
テストチームも同じように、
何人かのテスターはシステムの全体像に対するテスターで、リリース候補版の概要レベルのシステムテストや結合テストの実施に力を入れている。
残りのメンバーは２つのうちどちらかに柔軟に横断して必要な作業をする。
初めはチームは担当する作業で分けて編成していた。要求分析チーム、テストチーム、機能開発チームをはっきり区別し、テスターやアナリストがいなかった。
しかし、これによってコミュニケーションの問題でスケールが上手くいかなかった。さらには担当するチームで分けてしまうとチーム間のコミュニケーションを文章で行ってしまうことが多くなった。そして問題責任の押し付け合いが始まってしまった。また、それぞれのチームは自分の仕事だけの完了だけをしようと考えがちであった。
例えば、アナリストであれば機能が本番環境にリリースするまでに行われる開発やテストに付き合わなくなったりする。これは要件定義を書き終え、自分の手から離れた時に機能に関する自分の仕事が完了したと考えてしまうからである。 コラボレーションの質は、スクラムのような職業横断型のチームに進化したことで劇的に改善した。
しかし、何でもかんでも一つのチームで行うのではなく、何人かのアナリストやテスターを機能開発チームから引き離してシステム全体を見るようにした。
三章 ミーティングについて。
当該書籍では朝10:15前までに３段階のミーティングを行う。
第一段階：機能開発のスタンドアップミーティング
自分たちが使っているtaskboardに立って今日やることや取り組むべき問題や課題について意見交換をしていく。 場合によっては昨日やったことや昨日やること、困っていることと言った3つのことを話すと言うことをしている。
第二段階：スペシャリティ同期（synchroの方）ミーティング
チームごとの話や各場所で行ったことを初めに決めたグループを超えて話し合う。
第３段階：プロジェクト同期ミーティング
これは組織をバラバラに考えて少数精鋭で行ったりする。これは全体的に長期的なスパンで俯瞰したり、フォーカスを広く持つことをひつようとする。
これらのミーティングの特徴として、ボトムアップからのアプローチであることが挙げられる。 細かいディティールから大きな対局へ見ていく。 その際には人を変え、場所を変え、問題を変えて課題を認識して解決していく。
これによって大きな問題を分割していくことができる。
また、これに関してはある固定した期間を持たせて無制限で行わない。また必要に応じてこれをなんどもイテレートする。 ex,9時ごろミーティングを15分、お昼に15分、帰り前に15分。 場合によっては柔軟に増やしていく。
四章 プロジェクトボード
プロジェクトボードとは、プロジェクトにおいてコミュニケーションの大元になるものとすべきものである。具体的にはプロジェクト全体の状況などを見せる。これは、カンバンシステムであったり、ストーリーマッピングであったり、様々な形が考えられる。
当該書籍におけるプロジェクトのカンバンを例に取ろう。 アイディア->機能->次の作るべき１０機能->開発->システムテスト->ユーザー受け入れテスト->本番 となっている。 これらはすべてフローとなっている。
何点か細かいディティール例をあげたいと思う。
- 機能
- 大局として考える。
- ユーザーストーリーと呼ばれるフォーマットで書かれている
- XとしてYをしたい、何故ならばZだから
- と言うフォーマット
ex:捜査官として住所を検索するときに地域によって絞り込みをしたい。何故ならば住所を早く見つけることができるからだ。
次の１０機能
- これは先ほどのエピックといえる機能を細かく分割する。
- 具体的に詳しい機能や必要な要求を展開する。
ここの中身こそミーティングでブラッシュアップを必要だったりする
開発とシステムテスト
- 継続的インテグレーションを行っていき、機能レベルのテストが出来ならばシステムテストを行っていく。
- このときgit上には別バージョンのブランチを作って扱おう。
- ここで素晴らしい点はここも大きい単位でテストを行うのではなく、小さい細かい単位でテストを行うこと、当該書籍の言葉を使うと継続的システムテストを行っている。
ウォーターフォールとの大きな違いとしては、初めから要求を完全に分析しているかしていないかの違いである。 カンバンシステムでは全てのフェーズを並行して進める。これよってフィードバックによるアイディアを組み込みやすく、フローとして価値を作り続けているのである。
ここでもひとつ忘れるべきではない点について、緊急の課題や、ボトルネックについての処理である。 パターン的にはマーカーをつけていろんな人からフォローをもらわなくてはいけないとわかる。
しかし、これをどのように機能させればいいのか。少人数なら気にすることはないが、大人数ならばどのようにすればいいのか。 それについて次章に入ろう。
五章 カンバンボードをスケールする
一般的にプロジェクトが進むスピード大部分は、メンバーがどれくらい状況を理解しているかによって決まる。 もしも、メンバ全員が何をしていてどこにいるのか、何が起きてるのかを理解していれば同じ方向に進むことは容易であると言えるだろう。 そう。そのためのカンバンボードである。
しかしながら、人数が増えてやることも増えたら付箋だらけだったりカードだらけでとても扱いにくいものになるだろう。 そこでカンバンを分割してあげることをする。例えば開発についてであれば複数チームがいる際に、自分のところに今やるべきメインの課題などは機能開発チームが持っていることをメインのカンバンで示してあげて、議論が深くなるであろうディテールの部分は各開発チームのボードに書き込むなどをすると言ったことができる。
ここでのポイントは階層に分けることである。しかし流れスタックは溢れてしまうものなのでWIPの制御をして行うことなどをしよう。またちゃんと同期しないとあとあと大変なことになるので注意。
六章 プロジェクトゴールの管理
プロジェクトの全体のゴールを理解していると、プロジェクトメンバーはゴールに向かって集中するようになる。 それはそうという話ではあるんですが、実際に行っていくと意見の食い違い等があることがわかる。 なのでゴールへの理解のすり合わせを行う。具体的にはミーティングのプロジェクト同期ミーティングで行ったりするべき。 彼らは初めの方はなかなか難しいという評価をするかもしれない。しかしそれに対してどのようにモチベーションをあげていくのか。また、仕様書は共通認識ではないということを理解して、ストーリーマッピングをするということを行わなくてはいけない。
これらのことは定期的に行うべきである。これによって現状とゴールのチェックを行うというのは、進捗とチームの士気と意識についてを知ることである。
技術課題を捌くとバグを捌く
以下は章に合わせず必要なことを纏めて書き留めていく。
技術課題さばき
技術課題が出てくるのは仕方ない。なのでどれくらいそれにコストがかかっているかを機能の情報と別に用意して作る。要は機能カードと技術課題カードにそれぞれどれくらい労力を必要としてるか見えるようにしよう。
やるべきものにうまく乗っていくために。
例えばリファクタリング。あまりにも技術的負債が大きいと、とてもやりたくないものである。しかし、これを嫌だからと言って看過してしまうとその後技術的負債は増大していく。
この場合は、実際にこの脅威を可視化するといい。 この場合であれば実際にそのクラスファイルを印刷をかけて、どれくらいが理想のコードサイズであるかを示すべきである。 それによって僕らが行わなくてはいけない技術的負債の線引きガン見えてくるだろう。
また、リリースの前のパイロット版にはそれに対するリハーサルをコストとして見ていこう。どこまで用心することに越したことはない。
バグさばき
カンバンを使わないで捌くとテスターがバグを見つけて、開発のサイクルの終わりにバグを見つけては要求分析にプライオリティをつけて、変更管理ミーティングをしてそれに対するコストにシンクロさせていく。
が、しかしこんなのは厳しいのでしっかりとカンバンを使いたおそう。
- 継続的システムテスト
- 要は大きいテストをやるのではなく、一つのスプリントごとなど小さいうちに部分のテストを行っていこうというスタイル。
これの良い点はバグを探すなど無駄な本質から離れたことで時間を多く取らなくても済む点である。そう考えると結果として最後にまとめてテストする場合と比べると時間に関するコストが明らかに軽減される。
さっさとバグをぶっ殺せ。
- テスターがバグを見つけたらさっさと殺す。いっそその場で殺しにかかるのがベターだろう。
- 後からバグとかで揉めるより効果的
- 会って話すというコミュニケーションをするということはバグトラッキングのシステムに状況を記述するよりも対面でのコミュニケーションの方がドキュメントコミュニケーションより多くを知ることができからである。
- しかし、これについてはただ会って、口頭で話すというだけではなくユーザーストーリーのフォーマットなどある種のフォーマットで簡潔に述べたものを用意してそれに対するディティールとしてテスターが受け持つのが良いと言えるだろう。
- また、引き受けたことがあるバグに近いタイプのをなんども引き取ってしまうことがあるので、バグに関する統計を取るのおも良いと考えれるだろう。
- 開発者とテスターがお互いの仕事に関して学び合うのでチームとしての改善点など多くが見えてくると考えれる。
- 簡単な細かい古いバグが含まれたタスクカードの管理に無駄な時間を使わなくても良い。（難しいのは適宜対応
- では大きい難しいのはどうするのか。そういうものを優先して積極的にバグとしてバグトラッキングシステムに登録する。細かいものは統計は取るが、追加などはしない。
- この際、どこまでもサイズが増大する可能性がある。よってバグの登録数にはラインを引く。30個とか適当なサイズを。また、バグのレベルとしてはブロッカー（絶対リリースに支障が出るバグ）かどうかなどを問い合わせて重要度を決めて登録するか決める。
バグを可視化する
何をやるべきでどんだけ今後やるべき仕事があるのか。あまりに多いならプロセス改善が必要だし、余裕があるならば今後のイテレーションに関する学習を行うことができる。
また、くりかえし起きてしまうバグに対してどのようにアプローチしていくか。繰り返し発生するバグのステージから引きずり下ろすために分割統治的なアプローチをかけていくべき。 例えば根本原因を見つけるために因果関係図を描くなどをすべき。 これを用いて本来やるべきモジュールなど、何が問題であるのかなど本質を捉えるのに役立たせる。
例えばこれによって、
不要なモジュールのリファクタリング
ドキュメント作成に対してコストを取る。
（テスターや作り手同士で）お互いの技能を幅広く活用するためにどこぐらいのレベルでコラボレーションしていくかを示していく。
バグの根本原因が必ずしも技術的課題だけではないということをまずはしっかりと念頭においてほしい。ここで述べてるのは自分の技術に依存しない整理して本質を得るために書いていることを再度認識しよう。
みんなもないだろうか。数学の計算をする際に急ぎすぎて字が汚くてケアレスミスをしてしまって間違ってしまったこと。これにプロジェクト開発は似ている。多くの人がそれによって手戻りで失敗してしまう。
プロダクト（方針や開発を進めること）の中で生まれたバグというのはプロセスのバグから生まれる症状である。じゃあプロセスってどうすればもっとより良くしていけるのかを考えていこう。
継続的プロセス改善とバージョン管理
プロセスをデザインするというのはとても難しい。何故ならばプロセスというのはスケーラビティを求められるプロジェクトに包まれるものである。つまり、プロセスもスケールして変化を求められる。
そこでプロセス改善エンジンを導入していく。要は機械学習と同じで評価関数を決めてそれに対して定常偏差を合わせていくといったイメージである。下に一般化して示す。
- 明確さ
- プロジェクトがどのような状況なのか誰にでも伝わるように目立つところに誰もがわかる明確なゴールを示す。
一週間目標などを用意して目標を層にするの有効である
コミュニケーション
チーム内で定期的にプロセス改善ミーティングを開く
統計データ
- プロセスを改善できたかどうか。できるだけシンプルな方法で動向を追跡する。
- 例えば、ベロシティ（開発した機能の数）、サイクルタイム（機能一つあたりのかかった週）の二軸で見るなど
この三つである。これを行なっていくことで自己組織化を目指していく。
さて、これを行うに当たってチームの振り返りなどは必須である。 良くある振り返りの方法として、他者を呼んで、外部的視点を見てもらうことをしてもらうこと。他にも色々方法はある。
さて、それを通じて良くある改善内容としては
もっとコードをコミットしよう
ミーティング方法を変えていく
コーディング規約を更新
チーム内に新しい役割を増やす。バージョン管理の主幹の人を作ったり、様々なインフラ的な問題が起きた場合主幹となって動くゴールキーパーを作ったり。
これらの振り返りのキーとして、エスカレーションポイントを用意することである。エスカレーションポイントとはチームを超えて影響を与えたる、一緒に解決したりする。たとえ他のことをしているとしても、お互いにプロセスの改善を行うことで視点が養われてシナジー効果が期待できる。
プロセス改善ワークショップ
振り返りの手引きをざっくり示したい。 これを開く意義は、仕事のベクトルを明確に、そして改善することである 当該書籍ではスクラムオブスクラムで示されているが、ここで話される取り組みというのは他にも適用可能だと考える。 以下に示す。
- 場を設定する
テーマを決めてそれに集中する
データ収集
以前に実施したワークショップから行なったことを話し合う
アイディアを出す
- データをもとにそれらにどんな意味があるのかを議論する
そして辛いポイントを出して、それを今後どうするのかを具体的に示していく
何をすべきか決定していく
振り返りを終了する
- 次のワークショップまでに誰が何をすべきかを決めてクロージングする
ワークショップではみんながさっさと話せるように心がけるべきである。今思っていることをサッサといってみようと投げるぐらいの勢いで手早くしていくのがいいだろう。 しかしながら目標を見失っていくのではダメで、期待すべき事柄をしっかりと示していくことが大切。
これは運用次第であるが、リーン主義で居続けるなら漠然としたことを許さない可能性もあるが、クリエイティブな、カンバンといったことであるならばブレインストーミングや直感で決めるというのも大切である。ただしいつかは抽象から具体に変えなくてはいけないのを念頭におくべき。
早すぎても難しい
当該書籍では興味深いことを述べている。 以前は変化が少ないことが問題であった。今回は変化が多すぎることが問題だった。 ほどほどというのが必要だと感じる話だ。
こういう時はプロセス改善提案書を書いて一手間加えるワンクッションを入れてもらうことにしている。 理由は提案者に対して簡単に出しすぎないようにする枷であり、何故こうしたいのかということの再認識をすることができるからである。
あなたが改善したい問題は何？
この変更で誰が影響を受ける？
この変更を実施する上でどのように進めるべきなのか？
どれくらいのコストがかかってくるものなのか？
これを実現するのにどのように分割できるのか想定させることができる（注意すべきはここまではやらせるべき範囲が違う。ここでは問題を分割するのではない。）
迷ったらシンプルな解決策を選ぼう。
因果関係図
根本原因分析を行うのに有用な方法である。 なんでこれが必要かというと、適当に解決するとまた浮き彫りになlって厳しいことになるからである。 具体例を挙げると * 寝室に煙が充満してる * 窓を開けて、また寝る（ダメな例） * 煙の発生源を見つける。おっと危うく火事になるとこだったぜ（良い例）
といった話である。
A3シンキング
リーンシンキングの中核にある教えの一つとして、継続的なプロセス改善を表す「カイゼン」という言葉がある。 トヨタ曰くこの正しい問題解決手法を厳格に運用にしたからであると表現している。これをA3の用紙に描くのでA3シンキングという。
A3シンキングのサンプルやテンプレートはネットにあるので要参照 テンプレートリンク
因果関係図の使い方
基本的な流れはこう。
問題を選んで書き出す。
明らかな損害やそれの弊害を上向き（トップダウン）に突き止めていく
- つまりこの書き出した問題が理由として扱えるように描く
- 問題：リリースした奴がバグって死んでる
突き止め：リリースした奴がバグって死んでるー＞客がキレる
根本原因を下向き（ボトムアップ）に見つけていく。
- テスト不足
描く時間が不足してたなどが上の例には当てはめれる
図に現れた循環（基本的に悪循環）を特定して目立つように描く
図を洗練するために上記をイテレートする。
根本をどう解決するか（ミーティングに持ち込んだりする）
これを行なっていく。 もし今回の場合はテスト自動化のトレーニングとかが足りないとかそういうとこに帰着するであろう。
因果関係図の書き方
ぼっちなら線画ツール好きなの使って頑張ってくれ。
複数人8人以下ならホワイトボードや付箋と模造紙で書いて作ろう。
30人以下とかの大規模なら人数を分けて具体的な問題の一つに着目して纏めたりしておく。最後に持ち寄って纏めたりする
定期的にこれをちゃんと認識できるシステム組み込みが必要だったりするのでそこはアナログツールに頼ったりしていくべき。
よくある失敗
幅優先ではなく、深さ優先探索で見ていこう。
問題領域が広すぎる場合がある。分割可能な問題になのではないのかということを見極めよう。
簡略化しすぎない。専門用語ではなくできるだけ一般化した言葉で話すべきである。
具体例に頼ったり、専門用語に頼るのは説明ではない。一般化してる表現で説明してこそ本当の説明なのだ。
いらないのが出てくるけどそこは問題ではなく、根本に辿れるかが問題。あくまでブレインストーミングのような形でも問題はない。
個人攻撃をしないように気をつける。しばしば誰かが足を引っ張ってることがるだろう。しかしそれはチームで解決すべき問題だ。出来ないならばそれを解決するプロセスが工数なだけなのだ。そもそとして問題解決ができるのはそのシステムに要因があると仮定できた時のみなのだ。
なぜ因果関係図を使うのか
- 共通理解を構築するためある。
他の手法としてはストーリーマッピングが挙げれる
問題がどのようにビジネスに影響を与えるか明確にする。
根本原因を見つける
悪循環のループを見つけ、潰す
なぜやるかを意識して問題解決に当たろう。
終章 まとめ
なんでこんなのを纏めたかというと、学生が情報技術を学ぶというの通じて楽しいというのを続けたいならば、それを業務にうまくたたみこむ必要が有るんだぜということが最近よくわかってきたからというのが大きい。
結局最近思うのは実用技術＞＞＞大局的な開発手法ということがやればやるほど僕らは痛感するだろうと思う。現に本質的ではないgitがわからなくて右往左往してみたりまだまだ辛いものはある。精進したいものである。
間違えがあったらそっと教えてください。
