リーン開発_第5章_スピード
スピードが出せるということは、ムダがないということだ。
スプリント≒並行反復イテレーション
ペイシェント・キーパー社の場合
- すべてのスプリントを、最終的に製品リリースに結びつける。
- 品質保証部は、開発者が最初のコードを更新するとすぐにテストに取りかかる。品質保証部は、独立してビルドプロセスを開始でき、また任意のあいている品質保証用サーバでビルドしても良い。
- スプリントの中盤までに、インストールチームがリリース候補１を顧客に導入する。そこで顧客は、内部の品質保証部門と並行でテストする。
- 顧客から問題のフィードバックが届き始めるとすぐ、品質保証部が見つけた問題と合わせ、開発者が問題を解決する。
- 機能要求は、顧客が絶対必要と考えれば、スプリントの終了直前まで出し続けてかまわない。急な要求であっても、受け入れる、それによって、製品がすべての顧客にとって、より速く、より良いものになるためでもある。
- 通常、稼働までに２〜３のリリース候補を出す必要がある。すべての開発タスクを完了し、すべての品質保証上の問題が解決され、すべての顧客問題が完了する。そして、品質保証部はシステム全体へ回帰テストを終えている。
- スプリントの終わりに、すべてを新しいソフトウェアに切り替える。ときには、何百という医師用PDAユーザや数千のウェブユーザを持つ、複数の病院を結ぶシステムの場合もある。通常はスプリントの最後に３〜５組の顧客に対応する。
- すべての顧客が、目立った重大な問題なしにシステムを使うことができれば、それで完了である。このシナリオでは、品質保証部と開発が密接に関係するのと同様、顧客と導入チームも密接な関係にある点に注目して欲しい。
ジェフ・サザーランドは
すばやいタイムサイクルを次のように説明
- 学習量を増やす
- バグだらけのソフトウェアをなくす。直さないとひどい目に遭う。
- 導入プロセスをすっきりさせる。年間45回も導入しなくてはならないのに、インストールが面倒だったらやっていられない
- アップグレードプロセスを改善する。必須のアップグレードが常にあるので、プロセス改善によってアップグレードが簡単になる。
- 持続可能なペースでの実装が徹底される。そうしなければ、消耗死することになる。
時間：普遍的な通貨
- 時間（特に、タイムサイクル）は、なにかが間違っていることを警告してくれる、リーンの普遍的な計測基準である。
タイムサイクル
- 有効な開発プロセスとは、確実かつ繰り返し可能なペース
- 認識した顧客のニーズを顧客価値として提供するプロセスのことである。
- 組織にペースを与え、価値の流れを引き起こし、製品に品質を作り込ませ、企業の許容能力を明確化するのがタイムサイクル。
ソフトウェア開発プロセスの品質を計測する
- 開発から終了までの平均タイムサイクルを計測をするのがいちばん。
- 顧客のニーズかが出されてからそれを満たすまでにかかっている平均時間を計測しなくてはならない。
誤りの計測方法
- 特に、繰り返し確実に、コンセプトをキャッシュに変えていくには、あるいは顧客の注文からソフトウェア導入までにこぎつけるには、平均としてどれだけの時間がかっているだろうか？このタイムサイクルの、一例だけを計測するのではないという点がミソ。
リリースサイクルを設ける
- 2週間毎、6週間ごとでも、6ヶ月ごとでも自分たちにとって現実的な期間で良い。
- 管理可能な、なるべく短い期間が良い
- 一度のリリースで完了できる業務量を見極めて、それ以上の作業は受け付けない。
- 何かが出来てないからといって、リリースを遅らせてはならない。
- 定期的なリリースが行えない状況なのであれば、プロジェクトの上限を設定できるように（必死で）努力しよう。目標は、6ヶ月ぐらい。
- プロジェクトの規模に上限を設けたら、プロジェクトを２つか３つにグループ分けしよう、緊急、小、大などのカテゴリに分ける。それぞれのカテゴリにおける「サービス水準」に達するよう努める。
- 開発作業がどれだけ大規模で、小さなスッテプに分割し完成できる。
リトルの法則
- リトルの法則とは
安定したシステムにおいて、何かがあるプロセスを通り抜けるまでにかかる平均時間は、
そのプロセス内にあるものの数を其の平均完成率で割った値に等しいという主張である。
リーン開発組織の目標はサイクルタイムの短縮
短縮する方法の１つめ 速く完成させること、つまり平均完成率を上げればよい。
短縮する方法の２つめ（開発資金に余裕がない場合） プロセス内のものの数を減らすという方法。
変動と使用率
- リトルの法則で不安定なシステムになる要因
要因１：変動
- 例：ソースコードを統合しなくてはならなくなった場合 それが、６週間分の作業なら、確実にたくさんの問題が起きる。 しかし、６０分の作業であれば、過ちの量も限られてくる。
大規模なプロジェクトならスケジュールの変動も大きくなる。 小規模のプロジェクトならスケジュールの変動はそれよりはるかに地位いさくて済む。
要因２：高い使用率
開発者のプロジェクトに対する使用率（稼働率）が80%を超えると開発速度が落ち、 タイムサイクルも長引き始める。
小さな仕事に分割して、割り振りを行う流れを意識すれば、実際には効率が良くなる。 ただし、決して使用率を最優先の目標にすべきではない。
サイクルタイムの短縮
待ち行列理論は、サイクルタイムを短縮するための教科書的な方法をいくつか提示してくれている
- 1.作業の到着率を平準化する
- 2.プロセス内のモノの数を最少化する
- 3.プロセス内のモノのサイズを最小化する
- 4.一定のリズムを確立する。
- 5.作業を許容範囲に制限する。
- 6.プル型のスケジューリングを利用する。
1．作業の到着率を平準化する。
すべてのリーンプロセスにの核心には、均一の作業レベルがある。
- 例 工場では、月間１万の部品を作るという計画が、毎分１部品という意味になる。 そして、その工場での作業は、毎分１部品という決まった速度で生産するように調整される。
開発作業の安定した流れを作るということになる。
開発プロセスの最初に待ち行列があれば、開発組織に同じペースで仕事を出せるため、 待ち行列の置き場所としては適切であるように思える。 しかし、そのような待ち行列の長さは、作業到着の平準化に必要な程度まで抑えるべき。
2．プロセス内のものの数を最小化する
- 開発の場合 リリースサイクルは長く、商用リリース前にいろいろなことを積み上げておく。 承認プロセスのせいで、組織の対応能力を大幅に超える作業が、一挙にまとめて詰め込まれる。 シーケンシャルなプロセスにより、まとまりのない作業が大量に出来上がる。欠陥は長い待ち行列を作っている。
一般的にやるべき作業の長い待ち行列は、非現実的で不要である。
待ち行列を対処するアイデア
1．まずは「この待ち行列の中で、現実的に考えて絶対に対処することのない項目はいくつのあるのか？」と問いかけよう。どう考えても作業に着手することがないと思う項目を、今すぐすべて削除。
2．次に残っている項目だけを選び出し、パレート分析を行う。 それぞれの項目に、１〜５までの点数をつけよう、絶対に必要な項目には、５点。あまり重要ではない項目には、１点をつける。 それが出来たら、４点と５点のもの以外はすべて消す。
3．ここで、残された項目だけを選び出し、それが何日分、何ヶ月分、何年分の作業になるのかを計算する。 この先もっと重要な、ほかの項目がリストに加わるだろうか？ それを考慮したうえで、あなたには、リストにある残りの項目の近い将来にこなせるだけの力を蓄えているだろうか？もし、ないのなら、追加の要員を加えるべきだろうか？
4．リストが依然として現実的でないくらいに長いのなら、すべき事とすべきでない事を効果的に決定する以上の、くだらない要求をはなつけたりするために長いリストがあるのかもしれない。 もしそうなら、そのリストを２つに分けよう。ひとつは外部向けのリスト、もうひとつは短く保ち、残作業を減らしていくためのリストにする。
3．プロセス内のもののサイズを最小化する
リーンな視点からで見れば
- リリースとリリースの間の時間を延ばすのは、まったく正解とは逆方向に進むことになる。
- リリースに時間が長くかかりそうでも、リリースまでの時間を延ばすべきではない。
- それほどに時間がかかっている原因を見つけ出し、それを解決しよう。
- 苦手なことでも、頻繁に行えばずっとうまく出来るようになるはず。
4．一定のリズムを確立する
- イテレーションは開発組織のリズムである。
- 作業がむらなく流れていれば、正しいリズムだということ。
- イテレーション終わりに大騒ぎするようなら、おそらくイテレーションが長すぎる。
- イテレーションを短くすれば、作業負荷が平準化される。
- イテレーション間隔は、顧客がイテレーションの終わりまで、変更依頼を出さずに待てる程度に短く、システムを安定させる程度に長くする。
5．作業を許容範囲内に制限する
- 開発組織では、時間をいくらでもひねり出せると思っているふしがある。
- 一時的に集中して残業を行えば、より多くの作業を済ませられることもある。
- しかし、残業漬けは長続きしない。疲れて注意散漫になる。
- スピードアップするどころかスローダウンすることになる。
組織が許容能力を大きく超えた作業をこなそうとして、スラッシングを起こして、 作業がまったく進まなくなってしまうこともある。 開発の重要なメンバーが対応能力を超えるほど酷使されると、そうなってしまう。
6．プル型のスケジューリングを利用する。
- 一度のイテレーションで完成を約束する作業を選ぶ場合、ルールとしてチームメンバーは完成させる自信がある（細かくブレークダウンされた）項目だけを選択しなくてはならない。
- チームが妥協な作業のみを選択するために必要な情報は数回のイテレーションを行えば、作業量が把握できるので得られる。
- 実際に、開発チームは待ち行列から作業を「プル」しているのだ、このプルの仕組みによって、チームに期待される作業量が、チームの許容範囲内に制限される。
- プルシステムのよって、作業のゆとりが生まれる。
待ち行列は、便利なマネージメントツールである。 待ち行列によって、マネージャは開発チームに自分で作業を管理させておきながら、 優先順位を変えたり、サイクルタイムを管理したり出来るようになるかである。
待ち行列を使うには一般的なルールがある
- 1.待ち行列は短くなくてはならない。おそらく、作業の2サイクル分あたりが適当だろう。その程度の長さであれば、開発プロセスの間中、要求の平均サークルタイムを管理できる。
- 2.マネージャーは、待ち行列にある項目をいつでも改定したり、変更したりできる。しかし、一旦チームがある項目に着手したら、マネージャーが日々の開発作業に干渉してはならない。
- 3.チームは、待ち行列から作業をプルし、その作業が完了するまで、一定のリズムで作業を行う。プルシステムによって、作業を許容範囲に収めながら、常にチームに仕事を与えられる。
- 4.待ち行列がありさえすれば、チームに応対する時間がなくても、そのうち要求に応対してもらえる。という誤解を与えてはならない。
