リーン開発_第7章_知識
ラリー社の事例
少しづつ反復的に考えられるようになることが、アジャイル的な考え方の重要な指針になる。
- 開発は受け入れテスト駆動型であるべき。
- アプリケーションの規模が大きくなっても、技術をアジャイルに保つには、それしかない。
- 重要なのは、何が負債を生むのかを理解すること、追いつくために速度を落とすこと、そして、先が長いことを理解すること。
- 知識を作り出す最善の方法を強調している。
- つまり、会社おの成功の邪魔になっている最大の問題点を見つけて、社員全員をその問題解決方法発見に集中させる。
- 一歩づつ前進し、どこまで進んだのかを確認し、何度も何度もそれを繰り返す。
- それを全員の仕事の本質にするといい。
問題は具体的には何ですか？
トヨタ生産方式が開発された頃、トヨタには豊富な資金もツールもなかった。
ただ、単純な、目標が４つあった。
- 1.可能なかぎり最高の品質とサービスを顧客に提供する。
- 2.お互いを尊重し合い、協力し合って、社員一人一人の潜在能力を開発すること。
- 3.どのようなプロセスかたもムダを排除し、コスト削減につなげること。
- 4.市場の変化に対応できる、柔軟な製造現場を作り出すこと。
多くのリーン活動が失敗してきた根本的な原因の古候補は
- 1.リーン手法の実践において、基本的な問題の解決よりもツールやプラクティスばかり重視していること。
- 2.リーンのトレーニングが、自然な作業チームの問題解決スキルよりも、スタッフをスペシャリストとして育成することに重点をおいていること。
リーン活動は「どのように利益を出すか」を明確に思い描き、その邪魔になっている最大の問題を的確に理解するところから始めなくてはならない。
科学的思考法方法
科学的方法とは
- 1．現象や現象群を観察し、記述する
- 2．その現象を説明する仮説を立てる。
- 3．その仮設を使って、ほかの現象や新たな観察結果を予測する。
- 4．実験して、予測が正しいかどうかを確かめる
- 5．実験が仮説どおりになれば、理論や法則として認められる場合がある。
- 6．実験の結果が仮説と異なれば、取り下げるか修正をしなくてはならない。
作業チームには、すべての観察、仮説、実験そしてその結果の記録が求められている。
少なくとも、失敗した実験からも、問題の解決策発見によって生まれた知識と同じ量の知識が作り出されているのだ。
知識を記録する
反復開発の最大の問題点は何か？
- 試したことをすべてを記録できないこと。また同じところに戻って、何度も同じ教訓を学習し直す。
- 人は学習した内容を忘れてしまう。
- 一人一人が学習したことを覚えていたとしても、使いやすい形で残しておかなければ、組織はその学習内容を役に立てられない。
- 発明家のノートは、発明家自身や同僚が定期的にチェックするなかで、簡潔にまとめられ、図やグラフが散りばめられていく。
- ソフトウェア開発では、ソフトウェアに埋め込まれた知識を文章化するために、厳密かつ簡潔でちょうどよい組み合わせがテストとコード。
- 開発中の製品で、決定に至るまでに試した実験や調査した選択肢は、簡単に忘れられてしまう。
- なぜなら、決してソフトウェアという形にならないからだ。
- 書き留めて置くだけでそれが知識にあるとは限らない。
- また、文章化しておなかった場合と同様、多すぎても、情報は膨大なドキュメントの底に簡単にうずもれてしまう。
- 知識はそこにかいてある内容を必要な人のためのことを思って考えて、書かなくてはならない。
レポートの書き方
トヨタのエンジニアたちが入社時に書いている A3レポートについて
問題解決のためのレポート
- 問題の要約
- 根本原因分析
- 対策の提案
- 予定されている実験
- 計測結果とフィードバック
知識共有のためのレポート
- 特定のデッドロック問題の固定
- デッドロック事例を縦軸に、原因と思われるメカニ済みを横軸にとった散布図
- デッドロックの既知の原因一覧
- 入れ子になった呼び出しとその入れ子での処理時間のトレードオフ曲線に 、デッドロック発生の有無を描き入れたもの
- それ以外の疑わしいデッドロックの原因についての考察
有用な機能のミニマムセット
- ソフトウェアが行うべき顧客の作業についての説明
- 顧客/開発組織への経済的価値
- 機能セットが完成すると顧客は何ができるようになるのか
- 含まれているものと含まれていないものを示す図
- 他のシステムとの相互作用を示す図
- 理想的なスケジュール
顧客の目標のため
- １ページのユースケース
- その目標を達成するためのユーザーインターフェース設計
ジャストインタイム
- 決定を下さないと行けない場合
まず、いつその決定を下さなくてはならないのかを見極めなくてはならない。それから、決定を下すその時まで待つ。
その時、タイムリミットを越してはならない。 そんなことをしたらなにかに衝突してしまうかもしれない。
製品開発プロセスを指導する際には、製品開発とはすなわち学習することであり、決定を遅らせれば遅らせるほど、多くを学習出来ることを認識していなくてはならない。
実験もせず、フィードバックも得ないなら、学習していないのと同然。
つまり、どのようなソフトウェア開発プロセスであれ、その目的はソフトウェアに組み込む知識を生み出すことなのである。
集合ベース設計
- 影響が大きく、撤回できない決定を下すのに適した手法
集合ベース設計とは
会社に大災害がおきたと想定 すぐに対応しないといけない２点が発生
- 1．.絶対にずらせない締切がある
- 2．締め切りに間に合わないという選択肢はない。
絶対に成功させたいのであれば、対応のために３つの開発チームを配備するとよい
- チームA
その締め切りまでに絶対、間に合わせられるシンプルな対応策を開発させる。
- チームB
すべてが順調に運べば間に合わせられるかもしれない、もう少しまともな解決策を開発させる。
- チームC 理想的な解決策を開発させるが、締め切りに間に合う見込みは薄い
締切期日になったら、解決策が出来ているはずであり、それはその時点で最高のものであるはず。
さらに、締め切りが前倒しになってもなお、きちんと動く解決策が用意できる。
逆に締め切りが後ろ倒しにずれた場合には、最適の解決策が完成しているかもしれない。
プロセスがするなら、企業はまず解決策Aを実施するところから始め、解決策Bに切り替えて、最終的に解決策ｃに移行すれば良い。
リファクタリング
リファクタリングの背後にある原理は次のようなものがある
1.必要になるかどうかわからないうちに機能を追加すれば、複雑さが増し、ソフトウェア開発で最悪の形のムダになる。ゆえに、ほとんどの機能は徐々に追加していくべきである。
2.機能追加や既存のコードベースへの変更を行う際には、複雑さを加えないことが非常に重要である。
3.リファクタリングによってコードベースの複雑さが軽減され、設計がシンプルになる。それによって、複雑さを最低限に抑えて、新しい機能が導入できるようになる。
リファクタリングには、自動テストへの積極的な取り組みが必要になる。
コードベースの複雑さを軽減するための変更を開発者が行う場合、予期せぬ欠陥を招き入れないと確信できるようなツールが手元になくてはならない。
設計をシンプルにしているうちに、うっかりコードベースに入り込んでしまった欠陥をつかまえる、テスト装置が必要。
継続的なインテグレーションや、欠陥が見つかった瞬間でのライン・ストップも必要。
自動テストや継続的なコードベースの改善、それにまつわるテストに投資した時間と労力は、ムダの排除と複雑さの軽減に費やした時間。
リファクタリングは、広告の売り文句のように「損せずに得する」もの。
レガシーシステム
ビジネスや技術の変化に比較的適合しにくい、変化しにくいシステムが、ソフトウェア開発の世界では「レガシー」のレッテルが貼られる。
レガシーシステムへの対処には、3つの方法があると述べている。
- 1．書き換えて捨ててしまう。
- 2．リファクタリングを手なずける。
- 3．覆い尽くす。
1．書き換えて捨ててしまう。 レガシーシステムを書き換える際には、そもそもレガシーシステムが変更を受け付けなくなった元凶である。
複雑さを取り込もうとする場合が非常に多い。2．リファクタリングを手なずける。 リファクタリングという手法のほうが適している場合が多い。
リファクタリングにはテストの装置が必要ようとなる。 コードに期待されているビジネス上の振る舞いの一例を表現する、受け入れテスト（ストーリーテスト）を作る。
参考文献として、「WorkingEffectiveWithLegencyCode」 はレガシーコードをリファクタリングする上でのバイブルと呼ぶに相応しい書籍。3．覆い尽くす。 レガシーコードを覆い尽くすには、レガシーコードの一部を修正する度に、覆うコード（と自動テスト）を加えていく。
変更が必要な振る舞いをすべてせきとめて、古いコードの代わりになる。古いコードの代わりになる新しいコードに送る。 その間、資産を新しいデータベースに移動させる必要も出てくる。
実際に使われていた古いシステムがすべて入れ替わるまで、徐々に新しいコードとデータベースを構築していく。
問題解決
- 秀逸な組織の証しは、問題がないことではなく、組織がシステムとして問題が無いことである。
- ソフトウェアの特異性に悩む人達に、対処法を提案しなければ、ソフトウェア開発プロセスには何の意味もなく、どのようなチームにも、行く手の困難を体系的に発見し、対処するための時間が、定期的に確保されるべき。
規律ある手法
問題解決に規律ある手法を用いることで、
チームには希望的観測から抜け出し新たな知識や特定の対策、恒久的な成果を手にする。
- 1．問題を定義する
- 2．状況を分析する
- 3．仮説を立てる
- 4．実験を行う
- 5．結果を検証する
- 6．フォローアップ/標準化する。
1.問題を定義する
- チームが「顧客の要求にもっと応えたいと」する。
- このチームの最大の問題は、要望が無視されていると文句を言う顧客からの、長い苦情リストである。 そこでチームは、問題をもっとよく調査してみることにした。
2.状況を分析する
- チームは過去４階分のリリースで導入した機能に着目し、機能のサイクルをパレート図に書いた。
- 機能の４分の３以上は要望を受けてから６週間以内に導入していたので優秀な対応をしていた。
- しかし、メンバーは要望の待ち行列に無視されている項目も数多くあることを知っていた、主に機能が常に追加され続けているからである。
現在待ち行列にある機能が待ち行列に追加されてからの時間をパレート図に表した。
そのデータから待ち行列にある要望の６０％以上は、追加されてから８週間以上経っていることがわかった。
前のグラフからも、８週間以降に実際に提供された機能は9つしか無いことがわかる。
チームはごく最近の要望だけ取り組んで、古いものには取り組んでいないらしい。
3.仮設を立てる
- 問題解決を急ぐチームが見落としてしまいがちなのが、テスト可能な仮設を立てること。
チームメンバーは、上位の３つの優先カテゴリ（緊急、至急、重要）に属する要求の平均発生率が１０であり、それがほぼチームの出力と同じだ。という点に着目した。
つまり、待ち行列を要望40〜50件までに短くし、「普通」「低」の要望を受け入れないようにし、要求への対応スピードを少し上げれば、9割がた、新たな要望に4週間以内に応えられる。という仮設を立てることが出来る。
4.実験を行う
1週間以内に確認が取れない場合には、要望はキャンセルしてもよいのもとして扱った。
チームメンバーは、出されてから16週間以上立つ要望の99パーセントは、もう求めておらず。
8週間以上たつ要求の77パーセントは、すでに有効ではな無いことに気づいた。
依然として必要だという確認が取れた29件の要望を調べれると既に「重要」の優先度が付けられていることがわかった。
今度は優先度が「普通」「低い」の要望を出した顧客に、同様のメールを送って確認をした。
これによって、待ち行列は要望100件にまで短くなった。
優先度の低い要望への対処法を実験し、いちばん成果のあった実験は、チームの顧客サポート担当に、低い優先度の要望を出している人たちに電話をかけさせ、
共同でその問題を解決する別の方法がないかどうかを見つけ出す。といことで解決できた。
低い優先度の４分の３は、このように個人宛に連絡してみることで、取り消された。
5.結果を検証する
6.フォローアップする/標準化する
- チームメンバーは、顧客ほとんどの要望に対し、４週間以内に対応することを通知したが、そうすればさらに顧客からの要望が出せることになることに気づき、チームメンバーの１人に、カスタマーサービスのコールセンターを支援させた。
そうすることで、要望の到着率を抑制し、優先度の低い要望に対しては、回避策が見つけられるようにした。
それに加え、対応までに掛かる時間が短縮されたこともあって、リリースごとの完成率は２８件にまでにあげることが出来た。
カイゼンイベント
- ときにはチームを日々の活動から少し離して、プロセスの重要な部分の改善だけに意識を集中させるのも良い。
- 改善による変化が、企業の複数の部署に影響を与える場合には、特に有用である。
- だからこそ、異なる役職の人たちや、別々のチームからのメンバーを参加させなくてはならない。
- 大グループでの改善イベントはさまざまな理由から失敗することが多い。
１．中核となるビジネスプロセスの注力が足りず。。
- 行き当たりばったりの改善になる。
- 全体ではなく、局所的な最適化につながってしまう。
これは、小グループでの改善イベントを行っても起こりうる問題だ。
改善によって解決されるべきなのは、最も重大で目につく、ビジネス上の問題なのである。
２．多くのアイディアが承認されても、ほとんどは実践につながらない。なぜなら
- 誰も、アイディアを実践に移す責任を負わないためである。
- 職務の境界を超えた変更を行う権限が与えられていないためである。
- 変更を行う人達に、そのための時間が確保されないためである。
- 主催者によるフォローアップがないためである。
フォローアップがないと、特に大グループイベントの場合には問題であり、大勢を落胆させることになる。
失敗させるくらいなら、そのようなイベントは行わないほうがましである。フォローアップが出来ないようでは、イベント参加者に対する敬意を欠く。
改善は通常の作業チームによって行われるもの、作業チームを継続的に、規律をもって、ビジネス全体の成果の改善をじゃましている現在の最大の制約を認識し、取り除くべきである。
