アジャイルの最近のブログ記事
考えは大きく、行動は小さく、失敗するなら早く、学習は迅速に。
「リーン ソフトウェア開発」
リスクは、それに最もうまく対処できる側が持つべきだ。定額契約では、本来顧客が対処すべきリスクが、ベンダーに移されているように見える。問題が技術的に複雑であれば、そのリスクに最もうまく対処できる立場にいるのはベンダーだ。だから、ベンダーがリスクを受けるのが適当だろう。しかし、問題がはっきりしない場合や変化している場合には、顧客がリスクを対処するのに最適の立場にいる。したがって、定額契約は避けるべきリスクである。定額契約が避けられない場合は、変更が入るのは確実なので、コストが決められた額を大きく超えるという事態を顧客自らが招くことになるだろう。
「リーン ソフトウェア開発」
全てが測定されるような方法を確実に行うには、全体を測定すべきであり、分解して測定すべきではない。すなわち、測定手段を1段階下ではなく、1段階上へ移動させることだ。ニューコアは、個人ではなくグループの生産性を測定したことを思い出していただきたい。３Ｍは、製品のコストではなく、製品により生み出されるビジネスの利益性を測定する。
「リーン ソフトウェア開発」
「測定したものしか得ることができない」という基本原則はこの場合でも成り立つ。重要なものすべてを測定できない場合、部分的に測定すると局所最適な計測手段となる可能性が高い。もし、ビジネス全体としての成果を最大化するのに必要な「すべて」を測定できないのであれば、局所最適化した部分的計測などない方がよい。中途半端な計測手段を持っていると、局所最適な行為を助長する大きな危険にさらされるだろう。
「リーン ソフトウェア開発」
多くの人は、新製品を発表し大きな成功を収めている企業が、製品開発プロジェクトのコストやスケジュールを管理していないと聞くとびっくりする。なぜかって？コストとスケジュールがプロジェクト管理では重要なことである、と思い込んでいるからだ。コストとスケジュールは局所最適化のための計測手段であるということがなかなかわからない。そのうえ、コストとスケジュールに注目すると。究極の目的、すなわち顧客の要求に合致し、競争優位のある利益の高い新製品を開発して商売する、ということが見えなくなってしまう。
「リーン ソフトウェア開発」
自動テストスイートは、建築中の大きな建物のようなソフトウエアを仕上げる際に、システムの建築者に安全と通路を提供する足場であるといえる。この足場なしに、他のツールを効果的に使うことはできない。テストを作成すると開発が遅くなるように思えるかもしれない。実際には、テストはコストではなく、開発期間中とシステムライフサイクル全体の両方で利益をもたらす。
「リーン ソフトウェア開発」
設計をテストとして文書化することで、開発者はそれがどう動くと想定されているかを正確かつ明快に理解しながらコーディングすることができる。これは、考えを洗練し、開発者がコンセプト統一性を持ってコーディングする助けとなる良い方法である。
「リーン ソフトウェア開発」
あるモデルが有用かどうかを判断する方法の一つは、そのモデルが最新に保たれているかどうかを観察することだ。モデルを最新に保って、使えるようにしておくことが重要であると信じている人がいるが、私たちはその逆だと思っている。モデルが有用でなくなれば、メンテナンスされなくなるはずだ。一時的に役立つモデルを作り、それが最終的に使われなくなるのはかまわない。しかし、ただそれがいい考えのように思えるからというだけで、モデルを作ってメンテナンスをするのは、ムダである。モデルが熱心に参照され、メンテナンスされていたら、有用なモデルを編み出したということがわかる。
「リーン ソフトウェア開発」
伝統的には、要求は文書化され、アナリストのチームに手渡されるものである。そして、分析を行い、その結果を設計者に手渡す。設計者はソフトウエアを設計し、その結果をプログラマに渡す。どのようなコードにするかについて、日々の決定を行うのはプログラマなのだ。彼らはシステムの統一性について、顧客がどう受け取っているのかを理解した段階から、ドキュメント2,3個分離れている。そのドキュメントを引き継ぐたびに、かなりの量の情報が失われたり、誤解されたりする。最初から理解されていなかった詳細部分のキーポイントや将来の機能については言うまでもない。
「リーン ソフトウェア開発」
チーフエンジニアの役割は、その車の設計が見えてきたら、最大の認知統一性を持たせられるようにトレードオフを判断できる環境を作ることなのだ。だから、チーフエンジニアは、エンジニアたちが多くのトレードオフと闘う中で、何に苦戦しているのかを理解しなくてはならない。そして、自分たちの決定がどのように製品の統一性に影響するかを、彼らが理解できるように手助けをするのだ。
「リーン ソフトウェア開発」
人は、自分が置かれた組織の期待にこたえるものだ。プロセスやドキュメント、計画の厳守に価値を置く組織では、ソフトウエア開発のリーダーは、多くは生まれてこないだろう。組織が自らの価値を定義すれば、その価値にあったものが手に入る。
「リーン ソフトウェア開発」
モチベーションをくじかせる、最も簡単な方法の一つは、アメリカ軍で「ゼロ欠陥精神（zero defects mentality）と呼ばれているものだ。ゼロ欠陥精神は、絶対にミスを許さない雰囲気のことである。つまり、どんな些細なことにでも完全性が求められる。軍隊では、ゼロ欠陥精神をリーダーシップの深刻な問題であると考えている。なぜなら、それが戦場での成功に必要な率先力をそこなうことになるからだ。
「リーン ソフトウェア開発」
私たちは、ある環境から別の環境へのプラクティスの移植は、間違いである場合が多いと、確信している。そうする代わりに、プラクティスの背後にある基本的な原則を理解し、それらの原則を、新しい環境に合わせた新しいプラクティスに置き換えなくてはならない。
「リーン ソフトウェア開発」
ワッツ・ハンフリーは、CMMの初期開発を先導した人物だ。彼は、訓練された、やる気のある人材がいなければ、ソフトウエア開発が成功することはない、と信じている。私たちはこの意見にまったく賛成だ。しかし、その「最も成功を収めやすい」というプラクティスには、敬意は払うが反対する。・・・私たちは、やる気に重要な要素は計測ではなく、権限委譲（empowerment）であると信じている。つまり、決定権を組織のできるだけ下位のレベルに移し、それと同時に、その人たちの聡明な決定能力を開発することだ。
「リーン ソフトウェア開発」
急な事態では、情報が指揮系統のチェーンを上がり、そして指示として下す余裕はない。そのため、現場での情報伝達とコミットメントの方法を、それにふさわしいものに作り変える必要がある。そのために重要な要素の一つは、スケジュールによって作業を進める（プッシュする）のではなく、顧客のニーズが作業を引っ張る（プルする）ことだ。
「リーン ソフトウェア開発」
賢明な決定を下せる専門知識を備えた人を育てる方が、人の代わりに考えてくれると称する意思決定プロセスを育てるよりも、ずっと重要なのだ。
「リーン ソフトウェア開発」
プログラミングは、金型の切削とよく似ている。リスクが高い場合が多く、ミスが大きなコストにつながる。そのため、開発が始まる前に要求を確立しておくシークエンシャル開発が、深刻なエラーを防ぐ方法だと一般には考えられている。シーケンシャル開発の問題は、設計者が「広さを優先した設計手法」ではなく、「深さを優先した設計手法」を取らざるをえないということだ。深さ優先の手法を採ると、高レベルの決定の結果が出る前に、それが依存する低レベルな決定を下さなくてはならなくなる。もっとも費用のかかるミスは、最初の時点で、重要なことを見落とすことによって生まれる。そのような大きなミスは、詳細に速く掘り下げすぎた場合に最もよく起きる。詳細なパスを確定してしまうと、後戻りができなくなるし、後戻りすべきだということにも気付きにくくなる。大きなミスを起こす可能性があるなら、全体を見わたし、詳細な決定は遅らせるべきだ。
「リーン ソフトウェア開発」
イテレーションは、実現可能な解決の一実証例としてとらえるべきであり、唯一の解決としてとらえるべきではない。早期のイテレーションでは、システムの残りの部分を、実現可能性のある多くの方法で実装できるように、幅広い余裕を残しておくべきだ。イテレーションが進み、さらに選択されていくにつれ、設計の余地は徐々にせばめられていくべきなのだ。
「リーン ソフトウェア開発」
スタンディッシュ・グループの研究によれば、典型的なシステムの機能のうち、45パーセントは一度も使われることがなく、19パーセントはほとんど使われることがないそうだ。プロジェクトが始まる時点で、顧客が自分の欲しいものを正確に知っていることはめったにない。そのため、彼らは必要かもしれない機能をすべて求める傾向にある。要求を出すチャンスが一度しかないと思えばなおさらだ。この方法をとると、私たちの経験上、プロジェクトの全体的なミッション以上にスコープを広げてしまう可能性が非常に高い。顧客にプライオリティが最も高い機能だけを要求させ、それをすばやく提供し、それから次にプライオリティの高い機能を要求させれば、重要機能のリストは短くなるはずだ。また、変化していく顧客の事情に対応することもできる。そのため、機能をプライオリティの高い順に並べ、上から順に手をつけていくのがいい。一般的に、この戦略を使えば、確保されたリソースがなくなるまでに、全体的なミッションを達成できるはずだ。
「リーン ソフトウェア開発」
ビジネス価値が最も高い機能を先に提供するため、最優先の機能から先に開発するべきだ。リスクの高いものは、後になってからではなく、早いうちから注意を向けておくべきだ。
「リーン ソフトウェア開発」
あらゆるアジャイルソフトウェア開発手法にも、あらゆる場面で適用するスタート地点がある。それは「イテレーション」だ。イテレーションは、ソフトウェアを設計し、プログラムし、テストし、統合し、提供するための、長さを固定した短いサイクルだ。製品開発でのプロトタイプと非常によく似ているが、イテレーションは最終的な製品の一部を、きちんと動作するように作りだすという点が違う。そのソフトウェアは、後のイテレーションで改善されることになるだろうが、最初からきちんと動作し、テストもされ、統合されてもいるのだ。イテレーションによって、シークエンシャルソフトウェア開発に比べてフィードバックの量が劇的に増加する。そして同時に、顧客やユーザーと開発者の間の、また、そのシステムに関心を持ついろいろな人たちの間のコミュニケーションが大幅に増加する。テスターは最初のイテレーションからプロジェクトの参加し、ハードウエアやソフトウエアの環境も早期に考慮される。設計の問題点は早期に見つかり。変更が入るごとに、変更に対する耐性がシステムに組み込まれていく。
「リーン ソフトウェア開発」
仕事をするのなら、それは、「直接顧客」のための仕事でなくてはならない。すなわち、だれかがどこかで、その仕事の成果を待ち望んでいる、という状況でなくてはならない。開発者は、直接顧客を知っているべきだし、その顧客が定期的なフィードバックを返せる方法を用意すべきである。問題が起きたら、最初にすべきことはフィードバックループがすべてうまくいっているかどうかを確認することだ。つまり、各自が自分の直接顧客がだれなのかを知っていることを確認する、ということだ。次にすべきことは、問題領域のフィードバックループを短くすることだ。
「リーン ソフトウェア開発」
リファクタリングをともなったイテレーション、つまり、システムを発展させながらの設計改善は、知識を獲得し、早く答えを見つけだし、統一性のあるシステムを作り出すための、最も効果的な方法の一つであるとわかっている。
「リーン ソフトウェア開発」
ソフトウェア開発の思考には二つの流派がある。一つは、開発者に、最初から確実に設計やコードを一つひとつ完璧にするように、と奨励する流派である。もう一つは、最初から設計やコードを確実に完璧にするよりも、小さく、迅速に試し、テストをし、失敗すれば正しくするというサイクルで進めた方がいい、という流派だ。前者の流派では、経験によって知識を得るのではなく、知識は熟考とレビューによって得られるものと信じている。最初から正しく進める前者の手法は、良構造問題に関してはうまく機能するだろう。しかし、試し、テストをし、直すという後者の手法が、悪構造問題には適している。
「リーン ソフトウェア開発」
どういうわけか、可変性は悪であるという考えがソフトウェア開発に入り込んでしまった。ソフトウェア開発では、可変性をおさえ、毎回繰り返し可能な成果を得るために、標準化されたプロセスを作りだそうとしてきた。しかし、開発は繰り返し可能な成果を生み出そうとはしていない。開発とは、それぞれの顧客の問題に適した解決を作りだすものなのだ。
「リーン ソフトウェア開発」
決定を遅らせることには価値がある。なぜなら、推測ではなく、事実にもとづいている方が、より的確な決定を下せるからだ。成長中の市場では、早期に確定するよりも、いろいろな設計オプションを選択可能にしておくことに価値がある。複雑なシステムを開発している場合に、決定を遅らせるためにキーとなる戦略は、システムに変更可能性を組み込むことだ。
「リーン ソフトウェア開発」
ムダとは、顧客が認める価値を、製品に付加しないもの、すべてのことだ。リーン思考では、ムダという概念を最大の問題としている。部品がちりの積もった棚に置かれたままになっていたら、それはムダだ。要求を集めた文書が、使われないまま埃をかぶっていたら、それはムダだ。製造工場が、すぐに必要となる以上の量を生産しているのなら、それはムダだ。開発者がすぐに必要となる以上の機能をコーディングしているのなら、それはムダだ。製造の過程で、製品をあちこち移動させるのはムダだ。製品開発において、あるグループから別のグループに開発を引き継ぐのはムダだ。理想は、顧客が欲しがっているものが何かを見つけだし、製造するか開発して、顧客が要求するそのものをただちに納品することだ。顧客のニーズをすぐに満たすのにじゃまとなるものはすべて、ムダなのだ。
「リーン ソフトウェア開発」
「原則」が、ある分野についての指針となる考えや洞察であるのに対し、「プラクティス」は、原則を実行するために、何をするか、である。原則は普遍的なものだが、それらが特定の環境にどう当てはまるのかが、わかりにくい場合もある。一方プラクティスは、何をすべきかについて明確なガイダンスを示してくれるが、それぞれの分野に適応させる必要がある。私たちは、「ベスト」プラクティスなどというものはない、と信じている。プラクティスは、コンテキストを考慮しなくてはならない。
「リーン ソフトウェア開発」
製造の最終段階での変更による莫大な損失の回避方法として、最初から設計に関して正しい決定を下し、それ以降、変更する必要をなくす、という方法がある。これがデトロイトの手法だ。トヨタやホンダは、設計に関する不適切な決定の損失を避けるのに別の方法を発見した。それは、「取り消しのきかない決定を最初にしないこと」だ。設計に関する決定をできるかぎり先延ばしにし、決定するときには、わかっている情報を総動員して、正しく決定する。この思考は、トヨタが開拓したジャストインタイム生産の背後にある、「顧客の注文を受けるまで、何を作るべきか決めてはいけない。注文を受けてから、できるだけすばやくそれを作れ」という思考に通じるものがある。
「リーン ソフトウェア開発」
メタファを使いあやまった場合にリスクがあることを承知で言えば、ソフトウェア開発は製造ではなく製品開発と似通っていると私たちは信じている。
「リーン ソフトウェア開発」
CMMやPMIを非難するわけではない。ただ、産業界でのリーン改革を経験してきたものから見れば、それらはソフトウェア開発にムダな要素を与えやすいように思える。ソフトウェア開発のパラダイムを、プロセスから人へ、ばらばらの個から集団へ、推測からデータにもとづいた決定へ、計画から学習へ、トレーサビリティからテスティングへ、コストとスケジュールの管理からビジネス価値の提供へと変えること
「リーン ソフトウェア開発」
