リーン開発_第4章_ムダ - ゆるい感じのプログラムを書きたい。

ZARAでは技術適用する際に５つの原則をあげている

1．ITは判断を支援するものであり、判断を下すものではない

情報システムは、経営者が意思決定をする際に必要となるデータの整理を手助けするものである。
情報システムがを意思決定するわけでも、提案するわけでもない。

2．コンピュータとは、標準化することであり、目標を絞る

販売店であれ地域であれ、共通の企業システムの枠からはみ出すことは許されない。
開発者はシステム機能を最大にするのではなく、最小に絞る。

3．技術の導入は内部からはじめる。

ビジネス目標が、常に企業における技術の使い道を規定する。その逆はない。
IT部門が、ラインのマネージャとともに働き、彼らが必要とするものが何かを理解してから、利用可能な技術を探するのである。

4．プロセスが焦点である。

販売店のPDAは、マネージャの使う「個人用生産工場機器」ではない、PDAは毎日の販売のレポートと、週２回の発注や発送を支えている。
PDAが全店にわたって一貫したプロセスを浸透させている。

5．組織全体で一丸となる

CEOにITマネージャーの経験があることは有益だが、ビジネスとITを統合するにはそれだけでは足りない、ビジネス側の人間と、技術側の人間が互いの世界を本当に理解し合う。
我々と彼らと分けたり、ソフトウェアを壁越しに投げたりするようなことがあってはならない。

複雑さ

市場の需要が明確になるまで、機能は作ってはならない。
不要なコードを書くぐらいなら、開発者にはサーフィンでもしてもらったほうがよっぽどいい。
結局使わないコードを書いても、システムが稼働している間ずっと代償を払うことになる。
必要最小限の機能ごとに開発しない理由はない。

複雑さを自動化するな

プロセスを自動化する前に、まず取り組みべきことは、明確化と単純化であり、既存の自動化さえ取り払うことを考慮する。
そうして初めてプロセスがはっきりと理解でき、効果的な自動化のポイントが見えてくる。
プロセスに必要なのは単純化であり、自動化ではない。
自動化により、今ある複雑さを封じ込めてしまったら、注文プロセスも単純化するチャンスを失ってしまうはずだから。

7つのムダ

1．未完成の作業のムダ
2．余分な機能のムダ
3．再学習のムダ
4．引き継ぎのムダ
5．タスク切り替えのムダ
6．遅れのムダ
7．欠陥のムダ

未完成作業の例

1．未完成の作業のムダ

コード化されていないドキュメント
設計や要求を記録したドキュメントが書棚に置かれている期間が長いほど、それだけそのドキュメントには変更が必要になる。
要求が変更されるのは、顧客にすれば要求が書かれるのが早すぎるだけ。

2．同期されていないコード

作業スペースや並行で開発されるコードは、出来る限り頻繁に同期すべきである。別々に存在する期間が長いほど、マージも困難になる。

3．テストされていないコード

欠陥をすぐに検知するに方法を備えずにコードを書くことは未完成の作業という在庫を作り出している一番の近道。
コードの結合、テスト、受け入れが完了している状態でなければ「完了」にはならない。

4．ドキュメントのないコード

ドキュメントが必要なら、コードと同時に書くべきである。
理想はコード自体がドキュメントの役割を果たすべきだが、それ以外のユーザ向けドキュメントやヘルプ画面も必要になる。
テクニカルライターもまた開発チームに属するのでドキュメントは必要

テクニカルライター

専門的な技術に関する文章を書くライターです。
テクニカルライターの業務には、製品の取扱説明書などを書く
「マニュアルライティング」と、技術的な文章を翻訳する「技術翻訳」があります。

5．導入されていないコード

環境によっては、理想的な頻度でコードを導入できない場合もある。
新しいソフトウェアが、顧客の今している仕事の邪魔になることもある。
しかし、出来るだけすぐにコードを導入するように務める出来である。
事実、ユーザは少しずつ変化を吸収していく方が楽な場合が多い。
すぐに導入したほうがトレーニングの量が少なく、混乱も最低限に抑えられる。

余分な機能のムダ

１．常識的に考えよう。これはガイドラインに過ぎないことを忘れないでほしい。
２．顧客の仕事に焦点を合わせる。ある仕事に必要なソフトウェアを作り出すのに、イテレーションが数回分かかったとしても、仕事上、絶対に必要な機能であるならばムダではない。
３．出来る限り機能を追加しない。機能の必要性について、いくらかでも疑問があるなら、時期尚早ということだ。手を付けずに待とう。
４．すぐにではないが、後で機能を追加できるようにアーキテクチャじょうにの仕組みを作るのは良い。ある企業向けに再利用可能なサービス「フレームワーク」を抽出するとよいかもしれない。ただし、何でも設定できるような仕組みを持ったアプリケーションフレームワークは、これまでの実績から考えると、失敗に終わる可能性が高い。その違いを理解しよう。

再学習のムダ

設計書などのドキュメントを作成しても二度と見ないので、再度、調査を行い同じ発見や仕様を学ばなくてはならない。
上記を効果的に達成するのに役立つ知識を記録しておく手法をチームと協力し合って考え出そう。第７章でさらにアイディアを紹介。

引き継ぎのムダ

引き継ぎは乗り方を知らない人に自転車をあげるのに似ている。
乗り方について教本をあげてもいいが、調子が出るまでバランス感覚を掴む手伝いをしたほうが良い。
ちょっとしたアドバイスをするほうが、たとえ言葉で説明しなくても、すぐに乗り方がわかるようになるはず。
このような知識は「暗黙知」と呼ばれる。
暗黙知は、ドキュメントではなかなか他の人に引き継ぎにくい。

引き継ぎによるムダを減らす方法

１．引き継ぎの回数を減らす。
２．設計、構築チーム（部署の枠を超えた完全なチーム）を作り、チームメンバー同士でお互いに乗り方を教えられるようにする。
３．コミュニケーション料を増やす。ドキュメントでは、ほぼすべての暗黙知が取り残される。ドキュメントの代わりに、顔を合わせて議論をしたり、直で見てもらったり、モックアップやプロトタイプ、シュミレーションで対話方法を見せたりしよう。
４．作業に対するフィードバックがもらえるよう、検討材料として、部分的な作業や試験的な作業リリースをする。現実的な範囲で出来るだけすぐに頻繁にリリースすること。

タスク切り替えのムダ

同時にいくつものタスクに取り組むことは通常意味がない。
タスクが３つあり、１週間毎に一つずつ取り組んでいけば、１週間毎にタスクAの価値が出て、タスクBの価値が出て、三週間後にはすべてのタスクが完了し、その頃には多くの価値が実現されている。

３つのタスクを同時に取り組んだ場合。

上記と比べて、３週間後にも完成できているタスクは一つもない。タスクを完了させるのにムダな時間が必要となるばかりではなく、完成させれば提供されていたはずの潜在的な価値もムダにされている。

開発と保守を行う手法の例

1.チームから２人ずつ選出し、月ごと、あるいはイテレーションごとの交代制で、２人の期間中のすべての保守作業を担当させる。
２．毎日、午前中の２時間を、チーム全体で過去の24時間に発生したすべての問題に対処する時間にする。その後に毎日の進捗ミーティングを行い、残り時間は新規開発に集中する。
３．保守要求を積極的に選別し、緊急の作業のみ、すぐに対応する。１〜２週間に一度、時間をとって、大きな保守案件に対応する。その周期が十分に短ければ、ほとんどの要求に待たせておくことが出来た、要求がなくなることさえあるだろう。このテクニックは、保守作業の平準化に役に立つ。
４．すべての顧客に１つのコードベースで対処し、毎週新しいバージョンをリリースする。どのような問題もすべて、このリリースで対応し、問題を抱えている顧客には、最新バージョンにアップグレードしてもらう。

遅れのムダ

開発者が待つ場合、以下の３つの選択肢がある。

１．作業を中断し答えを探す。
２．他のタスクに切り替える。
３．ただ推測して作業をすすめる。

上記は３つは間違った手法である。

解決として完全なチームを１ヶ所に集めて、定期的なフィードバックが得られる短期イテレーションを用いれば、遅れは大幅に減り、決定の質も上がる。

ソフトウェアはどうしてそんなに時間がかかるのですか？

１．開発者は、我々が何が本当に欲しいのか示さないかぎり、問題解決にとりかからない。どうやったら何がほしいかわかるというのか？
２．開発者はプロジェクトの承認を得るために、何ヶ月も待っている。
３．開発者が担当が決まるまで、延々、待っている。
４．担当になって人たちが手が空くまで待っている。
５．いらただしい変更承認プロセス。何ヶ月も待たせておいて、こちらのビジネスに変化が起きてないとでも思うのだろうか？
６．今まさに必要になっている重要機能を手にするのに、システム全体が出来るまで待っている。
７．コードがテストを通るまで待っている。どうしてテストにそこまで時間がかかるのか？
８．新しいソフトウェアが、既存のプログラムをめちゃくちゃにしないようになるまで待っている。あるいはその逆。やってみなくてはわからない。

欠陥のムダ

アジャイルチームでは欠陥発生率が極端に低い、それはコードにポカヨケを施し、欠陥が日常的に発生しないようにすることを最重要視しているからである。
そして、第２に、できるだけ早期に欠陥を見つけ、同様の欠陥の再発防止策を探すことを重視している。

重要：テストファーストの考え

コードを書く前に単体テストを書くことで、シンプルに理解しやすく、テストしやすいコードになる。テストがコードや最終的な製品が、どのように動くことになっているのかを正確かつ詳細に教えてくれる。だからテストはシステムの最高のドキュメントになる。

広範囲にわたる要求仕様書を書いてきた組織であれば、実行可能な仕様としてテストを書くことで、仕様を書いたり、仕様書からコードを追跡したりするのにかかる時間を、大幅に短縮できるのである。

顧客の環境でテストできないので、かならず欠陥が見つかる。

改善活動を立ち上げ、インストール時に頻繁に起きる失敗を箇条書きにして、根本原因の解決に優先度の高いものから取り組み、顧客現場での欠陥発見がほとんどなくなるまで、やり続けよう。

バリューストリームマップ

ムダを表出化するのに非常に効果がある。

流れの中での遅れは間違いなく、重要なムダがあることのサイン

長期の遅れ(待ち行列がある暗示)
差し戻し(揺れ動きが起きている暗示)

を探すことでプロセスに潜むムダが浮き彫りにされる。

準備

開発の場合、難しい事が多い。代わりに平均的なプロジェクトを１つ選んでマップにすると良い。
よくあるのは、保守要求を３つのカテゴリにわける。カテゴリごとに解決時間を約束するというもの。

例：

非常に緊急の問題ならば２時間以内
重要な問題ならば１日以内
些細な問題であれば２週間毎の次回リリースで対応

など。

時間軸の開始と終了を選択する

目的はコンセプトをキャッシュに変えるまでのバリューストリームマップを描くことである。

組み込みソフトウェア開発の場合時間軸の開始は、顧客のニーズが明確になった時か、または組織が製品の開発を確約した時点であり、終了は製品が世に出たときである。
顧客要求を受け入れてソフトウェア開発を行う場合要求を注文とみなし、顧客要求が出された時点から、時間軸を開始するのが一般的。顧客が気がかりなのは、自分たちが出した要求が対応されるのに、どのくらいの期間がかかるのかである。

バリューストリームオーナーを見つける。

顧客要求の責任者がいないと、人々は境界内にこもって部分最適化ばかりしてしまう。
要求は、待ち行列の中で承認前に陳腐化してしまうか、延々と放っておかれたあげくに別の機能に変更されるか、永久に導入されないかである。

システム全体にわたって顧客要求に責任をもつバリューストリームオーナーがないのは、ムダの根源に取り組む権限を与えられた人がいないも同然

シンプルに保つ

バリューストリームマップは、ムダを発見を手助けしてくれる診断ツール。
目的は、ムダを排除するために、ムダを発見する方法を学ぶこと。
バリューストリームマップを利用することで顧客の眼鏡をかけ、顧客の目で開発のプロセスが見れるようになる。
目標は１〜２枚の紙に、顧客が注文してから、顧客が満足するまでのプロセスを１０個程度の大まかなステップに分けて、マップに描くこと。

重要なのは、最初から最後まで、コンセプトがキャッシュに変わるまでを隙間なくつないでいくことであり、狭い範囲を細かく掘り下げることではない。

マップを描きあげたところで、２つの質問に答えて欲しい。

1.製品の開発が終わるまで、あるいは顧客の要求が満たされるまでに、どれだけの時間がかかるか？(経過時間であって、実際の作業時間として計上する時間ではない)
2.経過時間に対して、実際に価値を付加するのに使った時間は何パーセントか？(これを「プロセスサイクル効率」と呼ぶ)

実際利用してわかること。

開発者のリソースを完全に食い尽くそうという幻を追い求めると長い待ち行列になる。
実際には、優先度の低いタスクでゆとりを作り、優先度が高いタスクにジャストインタイムでスケジュールすることで、待ち行列にかかるオーバヘッドを取り除いている。
リリースは定期的でも結合テストを頻繁に行わないと最終テストでいつも欠陥がみつかるのでは、テストが遅すぎる。目標は早い段階で見つけることだ。

バリューストリームマップとは

コンセプトから製品を世に出すまで、もしくは機能要求からコードを導入するまでのステップの時間軸である。マップが描きあがったら、揺れ動きと遅れを見つける。

揺れ動きはタイミングの問題を示す。
テストと修正の揺れ動きは、テストの開発と実行が遅すぎることを示す。
組織が成し遂げられる量まで仕事を制限すると、仕事がシステムを通過するスピードがとても速くなる。
遅れはさらに組織的境界を示している場合もある仕事の準備ができていない組織に仕事を引き継ぐと遅れが生じるこの対処方法は、引き継ぐ前に受け取る側の組織の人に深くかかわってもらうことである。

将来のバリューストリームマップ

将来のマップを理想のマップにしてはならない。
すぐに改善にとりかかるための道筋が示されている必要がある。
最も大きな遅れ、最長の待ち行列、最悪の揺れ動きを把握する。
３〜６ヶ月以内で、組織が到達できる１つから３つの鍵となる変更を示す新しいマップを描こう。
それらに変更があったときが、新たな現状のバリューストリームマップを描くときである。
次に重要なのは、取り組むべき部分をピンポイントで示してくれる。