2013年4月3日水曜日

トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッドをやってみて


今回開発しているTOCの新たなセールス&マーケティングコンサルティングプログラムとソフトウェアは、1年程度構想を行いコンサルティングプログラムのテキストを作って、それからソフトウェア開発を始めています。

今回のコンサルティングプログラムの開発は、議論の進め方が今まで通りだと完成しないと認識としていました。
コンサルティングプログラムの目的は「お客様の売上高を増加させる」と明確なのですが、それを実現する方法を考えるとなると、複雑でどのような因果関係があるのか把握するだけでも困難な問題です。
今までのコンサルティングプログラムや、沢山ある参考書籍、相当なコンサル経験と知識のある人、これらを集めて開発するにしても、議論の進め方を工夫しないと完成できそうにありません。
そこでリーン製品開発にあるLAMDAサイクルというものを使うことにしました。



LAMDAプロセスとは、車の開発が欧米と日本でかなり異なっている。日本は構想設計段階が長い。長い構想設計段階で何をしているのかの研究からアレンウォードがまとめた構想設計のやり方です。
基本的にはサイモンの意思決定モデルと同じで
「問題認識→代替案の探索→代替案のモデル製作とシミュレーション→結果の評価と選択→選択された案の実施」
このサイクルを繰り返し実施して設計案を固めていきます。



これを使った検討の流れは以下の通りで実施しました。

・わからない事とわかるための対策案を議論して表「LAMDAシート」を作成
・複数の対策案に関する検証を実施
・2週間に1回ミーティングを開き
・対策案で目的が達成できるのか報告とレビュー、
・案の絞り込みをおこない表を更新
このサイクルを繰り返していきます。

これにつかう表がLAMDAシートです。表の要素は


Look:達成すべき目的
Ask:目的達成を阻むわからない事(知識ギャップ)
Model:知識ギャップを解決するための複数対策案
Disucuss&Act:検討結果共有日と検証実施担当者

たいした表ではないのですが、この流れで実際にやってみると今までとは大きく異なる結果がでました。

LAMDAそれぞれ実施するときに注意したポイントと効果をまとめると

Look:達成すべき目的

ここでの目的は、要求仕様レベルの物ではなく、議論を整理するための大枠の要素レベルにする。
ここでの分類でもめないよう、参加者がある程度認める分類の仕方を事前に用意しておき議論時間の短縮をはかった。(今回はゴールドラット博士の決めている分類にした)

要求は実現手段の検討によって変化すると考え早期に固定しない方針とする。
早期に要求(目標スペック)を固定しようとすると、今できるレベルにしてしまうので凡庸な製品になる。これを避けるため大枠レベルから段階的に要求を具体化する方針にしておく。

Ask:目的達成を阻むわからない事(知識ギャップ)
複雑なテーマでは何がわからないのか分からない段階から議論を始めるのに、従来の方法では分からない事を発言できる時間帯がほとんどないし、分からないと言いにくい雰囲気がある。よってやや分かっているリーダーばかり発言して、その他の人はそもそも論以外何も発言できないという展開になる。そうするとリーダー一人で考えて、皆は指示を待つような形ができてしまい問題解決ができない。

LAMDAシートを使って話すと、まずは分からないことを列挙することから始めるので、全員堂々と質問でき発言数が多くなる。

誰かが分からない事でも、誰か答えられればその場で解決。この時点で知恵が共有される。誰にも答えられないことがあれば知識ギャップとして記録される。
(ある会社では3分以内に答えがでなければ知識ギャップとして記録するルールにしている。)


わからない事を記録することは典型的な失敗プロジェクトを防ぐ意味で有益。従来のやり方では納期のプレッシャーから、分からない事は置いておいて、分かっていることをまず実施して進捗しているように見せる。最後の方になって重大なわからない事が浮上してプロジェクトが立ち往生。プロジェクトは中止。という最悪のパターンががある。

アジャイル開発で進めてもこのリスクをさけられないが、LAMDAシートで構想設計していればこんな失敗をさけられる。

Model:知識ギャップを解決するための対策案を複数立案する

LAMDAシートでの対策案は、複数あげなければならない。
このことは、最適な案を言わないといけないプレッシャーがなくなるので、様々な人が思っている案を制限なく列挙できるメリットがある。

議論するのは対策案の検証方法が中心になる。○○という本に書いてあったとか、過去のプロジェクトで似たようなことをやったので調べてまとめればよさそうとか。

案の善し悪しについてこの場で議論しない。
わからないのに決めなければならないというムリなこと、不毛な議論を避けられる。

早期に決めなければならない方針を持つと、リスクの少ないありきたりな物で意思決定をせざるをえなくなる。
安全案とチャレンジ案を複数持って意思決定を遅らせることでリスクにチャレンジして画期的な案を発見できる可能性を高めることができる。


ここで、対策案が全くでてこないこともあるだろう。そういうときはまず誰かが実現可能な最低な案を発言してみる。「前のバージョンのままでいいんじゃない?」といった感じ。
そうすると、それは駄目だと、その案よりはましな案を皆が発言しだし、議論が活性化する。このようなやり方をマクドナルド理論とよんだりする。安全な雰囲気作りをして案が沢山出るよう場を作る事が重要だ。

Disucuss&Act:検討結果共有日と検証実施担当者

検証結果を共有する会議の日時は、一定間隔の日に固定しておく。(2週間ごとの金曜日等)
これにより見積もり不可能な代替案の検証期間について機械的に目標値をおく事ができるため会議時間を短縮できる。

会議での意思決定は複数案のうちどれを捨てるのか決め、一つにするのを出来るだけ遅らせる。対策案検証結果をみて自然に収束する事を狙う。

納期から逆算したデットラインに到達しているが収束しないものについてのみリーダーが一つに意思決定する。
このとき多くの場合、安全策を選択し、要求を低い方へ下げる事になる。
要求を引き下げても売れるのかどうかが判断基準になり、この意思決定が重大。

・上記の流れを繰り返して一つの設計案に収束させる。収束できたらプロジェクト計画を立案し開発をスタートさせる。

私が今やっているものの場合、上記のプロセスを実施し、案を収束させコンサルティングテキストが完成。テキストをインスペクションでレビューして、売れるのかどうかの検証を実施。ここまでで1年程度かけました。
それからソフトウェア開発をするかどうかビジネスモデルの検証、要求を絞り込みソフトウェアで実現する部分を特定、予算取りをして、それからソフトウェア開発が始まっています。そこからの開発はおおよそスクラムのやり方に沿っています。

以上のやり方が完璧だったとは全然思わないですし、もっと工夫できないのか考え中ですが、いきなりスクラムを使ってとりあえずソフトウェア開発を始めていたら不必要な物を開発してしまい、早期に開発中止になっていたでしょう。ITコンサルタントに要件定義してもらってウォータフォールで開発していたら多額の投資をして出来上がった時に使えないことが判明、会社が倒産するぐらいの問題になっていたでしょう。。

多くの企業で、要求・構想設計の探求段階は半年以上ありますが、プロセスが定義されておらず、マネジメントされていません。LAMDAのそれぞれを具体的にどのようにするかはまだまだ多くの議論が必要ですが、ヒット商品を作り出すため企画と開発が検討するやり方として可能性が大いにあると考えています。

2013年4月2日火曜日

アジャイル開発は全体スケジュールにコミットすべき



アジャイルソフトウェア開発について極端な議論をされています。極端に話すと議論がわかりやすい。議論を見ていると7つの理由のうち「全体スケジュールにコミットできない」「アーキテクチャ上の無駄が生じる」の2点が興味深い。「全体スケジュールにコミットできない」は自分の仕事にも絡むので書いてみます。

ちなみに、私はアジャイルのコンサルタントでもないので利害関係ありませんし、開発者ではなく企画の立場。できれば全てのソフトウェア開発がアジャイルソフトウェア開発でやった方が良いのではと思っています。

・全体スケジュール
スクラムでは直近の期間(スプリント)についてのみ計画する事になっており全体計画がありません。これについては確かに企画側は困ります。全体計画がなければ予算取りができませんし、変化に対して対処できません。

開発側からみて意味のある計画が作れないとか、後のことを考えてもしかたないというのは一理ありますが、企画側はあきらかに必要。
アジャイル開発のやり方として、「全体スケジュールは計画しなければならない」と明言してどのように計画すべきか議論した方がよいのではないでしょうか。
企画側が欲しい全体スケジュールは詳細なタスクではなく、最終成果物のスコープがどう変化するか。よって、どのイテレーションにどの機能が実装予定になっており、追加要求によって最終成果物がどのように変化するか大枠がみえれば十分です。

・コミットメントできない
全体スケジュールは作れば良いだけなのでいいのですが、全体スケジュールにコミットできるかどうかは厄介。
アジャイルソフトウェア開発では最終成果物についてコミットをおこないません。これは契約問題を含め大きなポイント。

「昔プログラマーはマジシャンと思われていた。動くソフトを作るだけで認められていた。しかしいまや普通の人。普通の人が約束を守らなければならないように、開発者も約束を守らなければならない」ケントベックが講演していた話しです。この発言からアジャイル開発は約束をしないというものではないでしょう。

問題はどうすれば約束を守られるのか。我々は誰も未来を正確に予測できません。よって計画に約束するためには必ずバッファが必要です。バッファはコスト・スコープ・時間といった形がありますが、いずれにしろバッファをもっていないと約束することは不可能です。
このことはアジャイル開発だろうがウォータフォールだろうが開発以外の業務であろうが同じです。

私のアジャイルソフトウェア開発の理解は「QCDにはコミットしなければならないが、スコープは柔軟に調整可能である。これを具体的に実現するための開発プロセス」であり、スコープにバッファをもたせる方法だと思っています。
このやり方は企画側からもメリットがあります。事前に全ての要求を洗い出すことは不可能ですから。

であれば
100機能開発する全体計画だが、70機能は必須で開発。30機能は変更可能なバッファスコープとする。
こういう全体計画すれば開発側も企画側もコミットはできるでしょう。バッファなんてお金の出元の方が認めてくれないと思うかもしれませんが、普通は大丈夫です。

以上の通りで「全体スケジュールにコミットできない」のでアジャイルが駄目なら、「バッファをもった全体計画を作る」という事で問題解決ではないでしょうか。

どのぐらいのバッファを、どのように誰が持つとバッファは最小化できるのか。こちらの議論が必要かと。