無料ブログはココログ

« 2013年12月 | トップページ | 2014年2月 »

標準化のトレードオフ その4 - 慣性の法則 -

ソフトウェアプロセスが、計算機上のソフトウェア(プログラム)と最も異なるのは、実行するのは人間であるという点です。

プログラムを変更すれば、すぐに動作が変わります。しかし、人間が実行するプロセスは定義を変更しても、正しく動作するとは限りません。

これは、人間はミスをするだけでなく、経験によって学習するので、以下のような特徴があるからです。

  • 経験していない事は上手にできない
  • 慣れたことに最適化されて考えなくなる
  • しばらくやっていなかったり、条件が変わるとできなくなる

このように経験によって、慣性の法則とでもいうべき物が存在します。「本当にアジャイル開発がしたかったら会社を移った方が早い」と言われる方がおられますが、慣性の法則を考えると確かにそういう考え方も一理あります。

そうは言っても、アジャイル開発に限らず組織にとって必要な技術なら、導入しないといけません。そこで、以下のような方法が考えられます。

トレーニング:実践する事で経験を積む事ができます。アジャイル開発の様な繰り返しは、経験を積む上で効果的でしょう。

継続的な改善:ルールが読まれるのは慣れる迄ですし、繰り返しているうちに失敗も慣れてしまいます。KPTによるふりかえりの様に、継続的に改善を考える事が大切です。

形式知の共有:ワークショップは効果的ですが、広がりが限定され、実践し続けないとできなくなります。理論やノウハウを形式知化して共有する事が必要です。

ここで大切なのは、最後の形式知化の共有です。SECIモデルのように、暗黙知を伝達が容易な形式知に変換して、形式知の組み合わせや編集によって体系化して新しい知識を生み出すことが必要です。

そうでなければ、改善を繰り返しても思いつきの繰り返しになるからです。技術を積み上げ可能にしなければ未来は切り開けません。

形式知化は特定の個人や組織ではなかなかうまくいかないでしょう。その事象が組織固有の問題か一般的な問題なのかの区別が難しく、関連する技術の体系化も困難だからです。

技術者に社外勉強会と言う場が必要なように、組織の発展にも社外勉強会などの外部との技術的なつながりを持ち、ソフトウェアエンジニアリングすることが必要なのです。

このエントリーをはてなブックマークに追加


標準化のトレードオフ その3 - 応用のできない習熟 -

デスマーチは嫌だ!幸せに暮らしたい。みんな、そう思っていたはずです。

ソフトウェア開発がうまくいかないのはプロセスが悪いからで、より良いプロセスで開発すればうまくいくはずだ。そのはずでした。

確かに最初はうまくいきました。確認作業の漏れがなくなり、ソフトウェアの品質は向上しました。

プロセスの標準化はトレーニングにも有効でした。いつ、どのような事をすれば良いかが明確になるので、経験者だけでなく、初心者にも勉強になりました。

しかし、その確認方法には問題がありました。チェックできるのはプロダクトとプロセスの実施で、なぜそのプロセスが必要であるかの理解度ではなかったからです。

このため、問題が発生する度にチェックする項目が増えて、どんどん管理的・義務的になりました。そして開発者は、なぜそれが必要かを考えなくなりました。

その結果、応用のできない習熟がすすみました。それまで大規模開発でうまくやっていたリーダーが小規模開発プロジェクトを任されると、ボロボロなことが多く発生しました。

その多くは、納期のプレッシャーに負けて必要な管理をスキップしていたからでした。大切な作業だからと理解して実施していたのではなく、チェックされるから作業していたのでしょう。

プロセスの標準化は必要なプロセスを実施することを目的にしていましたが、それは人を思考停止させ、無能化してしまいました。標準プロセスに習熟したはずが、応用のできない習熟だったのです。

そんな人も同じ職場でいたなら、幸せだったかもしれません。しかし、世の中は常に変化していますので、やり方も常に工夫しないといけません。

ソフトウェア開発には、プロセスの正しい理解必要です。考えなくて良いプロセスには、トレードオフが存在するのです。

このエントリーをはてなブックマークに追加

標準化のトレードオフ その2 - 本当に狼男ですか? -

「ソフトウェア開発に銀の弾丸はない」といいますが、ソフトウェアプロセス成熟度の改善の序文には

  「ソフトウェア危機」は死んだ!

と書かれています。でも、ソフトウェア開発の混乱はなくなっていません。銀の弾丸を見つけたはずなのに、うまくいかないのはなぜでしょうか?

そういえば、ソフトウェア開発を熊とのワルツに例える本もありました。

銀の弾丸は昔の狼男には効果があっても、いつのまにか狼男が耐性を身につけたのかもしれません。もしかすると国防総省には狼男が居たかもしれませんが、一般向けのソフトウェア市場に居たのはドラキュラで、少しでも早く仕様を陽のあたるところに出すべきだったのかもしれません。

でもドラキュラも銀の弾丸を撃たれれば、死にはしなくても少し弱まります。方向性が定まらずにプロジェクトが混乱している時は、誰か声の大きい人が方針を決めるだけで、混乱が解消するからです。

同じように暗がりから迫る狼男に、光を当てれば少しはひるむでしょう。やり方が決まれば、あとは工夫で乗り切れるかもしれません。

プロジェクトにはゴールがあり、同じ開発はありません。しかも最近は開発期間が短くなっています。なんとなく開発がうまくいって、それに開発者が慣れてしまえば、その方法を悪くいう人は少ないでしょう。

では、ソフトウェア開発の問題は何で、どの開発法が良いのでしょう?

昔は簡単でした。とにかく動く事。信頼性が低くて動かないシステムが多かったので、バグが少ない事が第一でした。

そして、その次は生産性でした。実装方法が限られていましたので、1ヶ月に何行を開発できるかで生産性が測れましたので、同じ信頼性なら生産性の高い方が良かったでしょう。

今はどうなんでしょう?その方法が良いと言える条件は何でしょうか?

不具合の現象が問題だったのか?生産性が問題だったのか?必要な時にリリースできないのが問題だったのか?世の中の変化にあわせられない事が問題だったのか?開発者が苦しんでいたのが問題だったのか?それはプロジェクトによって異なります。

ソフトウェアプロセスはソフトウェアと似ています。問題が明確なら正しい答えを出せますが、問題が曖昧なら動いたように見えていても、後から問題が発覚するかもしれません。

また、ソフトウェアがレガシー化するように、人には慣性力があります。慣れている方向には簡単に動きますが、方向を変えるのは大変です。

ソフトウェアの様に様々な制約の中で良い方法を選ばないといけません。制約を考慮して、より良い実現方法を考えます

様々な方法の理解が欠かせませんし、プロジェクトの問題を見極める事も必要です。様々な方法のトレードオフを考えて、問題を解決しないといけないのです。

このエントリーをはてなブックマークに追加


標準化のトレードオフ その1 - 標準化のパターン -

今週は忘れ物を2回もしてしまいました。1回は家族がケータイを別の場所に移動させたからで、もう1回はいつもと違うタイミングでネクタイを締めようとしたからです。

いつもと違う状況で失敗すると言うのは誰でも経験があると思いますが、これは習慣という形でプロセスが標準化されているからだと思います。

標準化のパターン

今回の経験から、プロセスの標準化をパターン化すると以下のようになります。

(1) タスクをまとめる

出かける際に持ち出す物の置き場所を決める事で、作業を効率よくできますし、確認が容易ですので抜けを防ぐ事ができます。また、特別に持っていく物があれば、前日に同じところにおいておく事で、忘れずに持っていく事ができます。

(2) 手順を決める

準備に習熟していると、朝起きてから短時間で用意することができます。部屋のレイアウトや準備のし易さなどを考慮して手順を決めておけば、徐々にスピードアップできますし、家を出てから髭のそり忘れに気付くということもありません。

(3) チェック

忘れ物の原因の一つは、チェックの手順がなかったことです。出かける際の忘れ物は誰もがするらしく「はとがまめくてぱ」なんて言葉があるくらいです。出かける際のチェック対象を決めておけば忘れなくなるでしょう。

(4) 予備

忘れ物を2回しましたが、ネクタイを忘れた際はそのまま出勤して職場に置いてあるネクタイを締めました。予備を用意すると言うのはかなり有効で、割り箸なども予備があると安心です。外部調達でも予備の代わりになるので、職場の近所にコンビニがあるからと割り切れば、チェックの手順をかなり減らす事ができます。

標準化されていない場合

初めての顧客などの場合は、このような標準化がない状態になりがちです。まるで引っ越し後の初めての出勤のように、バタバタしてしまいます。

標準化は混乱を避けるために有効で、予備の確保という一種のフロントローディング([#Agile] アジャイル開発はフロントローディング)によって、チェックの作業を減らす事も可能です。

標準化のトレードオフ

標準化は効率化と作業品質の確保に有効で、混乱を避けて他の事に力を割けるようにします。習熟することで、その場その場で考えなくても良いようになるからです。

しかし、それは思考停止でもあります。習熟すればするほど、効率化すればするほど、今回の忘れ物の様に想定外の事象に弱くなります。

標準化して現状に満足するだけではなくて、常に考えることが大切なのでしょう。SECIモデル([#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 -)の繰り返しによって、改善のイノベーションが生まれるのだと思います。

おわりに

忘れ物からプロセスの標準化を考えました。上に挙げた4つのパターンは、それぞれ、アジャイル(壁を打ち破れ! - アジャイル開発とスクラムを読んで -)、リーン([#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み -)、プロセス監査、CPPM(オプションを維持するためのアソビ - CCPMのバッファを考える -)に相当するものです。

それぞれに良さがあり、その良さは特長であると共に弱点でもあります。これまで開発法が語られるとき、良さやノウハウが語られますが、その背景にある弱点はあまり語られなかったと思います。

ここに挙げた標準化のパターンとトレードオフを起点に、これらの開発法とチケット駆動開発の特長と弱点について考えてみたいと思います。

このエントリーをはてなブックマークに追加


ベストなセカンドベスト

次善の策というとうまくいかなくて代替案を提示しているように聞こえますが、最善にこだわりすぎる方がうまくいきません。

以前、「向上しようと思ったら、愚かな自分を受け入れろ #dvsumi」に書いたように、人工知能やそれから派生したゲームは最適解を得る事が難しい問題の存在が明らかになる事で発展しました。

計算機が速くなっても、ボードゲームの次の一手を見つける際に全ての組合せを短時間で求める事はできません。ある程度の先読みと何らかの戦略によって次の一手を決めざるを得ません。最適でないからこそ、工夫が生まれます。

ソフトウェア開発も同じです。ガチガチのウォーターフォール開発で、全ての可能性をあらかじめ検討し、段階的に詳細化することは非常に困難です。

ゲームなどの場合にはグリーディアルゴリズム(欲張り法:Algorithms with Python)があり、身近なところで良さそうな決定をします。ナップザックに大きなものから詰めるとそれなりにうまく詰める事ができるイメージ([#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~)です。

アジャイル開発は、セカンドベストだと思います。何かをあきらめているからこそ、それなりにうまくいく方法です。過大な理想を追い求めないからこそ成功する方法だと思います。

その過大な理想は達成が難しいもので、単純な設計法でバベルの塔を目指すような理想の実現には非人間的な苦痛が求められました。そこで出てきたセカンドベストがアジャイル開発でした。

しかし、いざアジャイル開発を導入しようとすると、個々のプラクティスの導入はうまくいくものの、開発そのものをアジャイル開発に移行するには様々な制約が邪魔をします。

つまり、ベストなセカンドベストと思えたアジャイル開発も、理想であって現実には難しい問題が存在します。

ここで、ある事に気付きました。人工知能が理想は難しいことを明確にして、セカンドベストを求める事でブレークスルーができたように、アジャイル開発も難しい現実を明らかにして、セカンドベストを求めれば良いのではないか、という事です。

新しいヒントを得たように思いました。

プロセスのムダを取る3つの方法

前の記事(救いにならないアジャイル、救いになるアジャイル)で「プロセスのムダ取りをしないプロセス改善はありえません」と書いたので、プロセスのムダをなくす方法をまとめておきます。

作業のムダを取る

作業のムダが生まれるのは、必要のない作業をするからです。
リーンの引き取り([#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み -)のように必要に応じて実施することで、ムダがなくなります。まずは、その作業がなぜ必要か、何時までに必要か、を明確にします。

メトリクスもGQMのようにゴールがあるから収集するのですから([#TiDD] チケット駆動開発はプロセスを軽量化する)必要のないメトリクスを収集する必要はありません。

計画のムダを取る

計画する際に生まれるムダは「ついで」(序で)です。冷蔵庫で人参が干涸びるのは、たくさん買った方が安いからとまとめ買いするからです。余った人参はシチューをすればさばけるかもしれませんが、余分に作った機能をムダにしないようにプロセスを変える事はないでしょう。

アジャイル開発のYAGNI(You Aren't Going to Need It:今必要のあることだけをやれ)という考え方に従えば、計画のムダをなくせるでしょう(アジャイル開発の生産性の高さを考える)。

時間のムダを取る

意外としている人が少ないのは、逆線表です。多くの方が計画を前から引こうとしますが、後ろから計画を立てていくとムダが無くせます。

その理由の一つは、上に書いた引き取り的な仕組みでムダな作業が省けます(アジャイルとプルシステム)。

もう一つはスケジュールの平準化と最適化です。瓶に粒状のものを入れるとき、トントンとすると、粒が詰まってより多く入れる事ができます。もし、粒に大小があるなら、ナップザック問題の様に大きな粒から入れるとうまくいきます([#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~)。

ソフトウェア開発では一般に下流ほど工数の変動が少なく、工夫が難しくなります。そこで下流から線を引くと隙間なくスケジュールできまし、避けられない現実も明確になります。

ありがちな失敗パターンは、ウォーターフォールの典型的な計画を立てる事です。少人数で始めると増員時の負担によるムダが大きくなりますし、ついつい後工程で人を増やせば何とかなるだろうと思ってしまい、ズルズルと計画が遅れがちです。

予算取り時は残業なしで見積もったはずが、実施時にはどう考えても無理な状況もあり得ます。その際に後ろから線を引いて考えると、厳しい現実も平準化でき、チームで戦う事ができます(元気が出るチケット駆動開発 - 補完型TiDDの経験 - @XP祭り関西2010)。

おわりに

ムダなプロセスを生む人に悪気はありません。その人の思う普通を実践しているだけです。でも、プロジェクトによって開発対象やメンバー、スケージュールなど、様々な制約が異なるので、普通のプロジェクトはめったにありません。

まずは、プロセスがどのような構造になっているか、なぜ、その作業が必要なのか、きちんと理解してください。その上で、プロジェクトの様々な制約にあわせられたとき、ムダのないプロセスが実現できると思います。

なお、ムダはなくすことと、乾いた雑巾を絞る事は違います(リーンを考える - 無駄と必要なアソビ -)。 リスクの低減に必要なアソビはきちんと確保して、より良いプロセスを実現してください(オプションを維持するためのアソビ - CCPMのバッファを考える -)。

このエントリーをはてなブックマークに追加


救いにならないアジャイル、救いになるアジャイル

渡辺幸三さんのブログ記事「仕様書プログラミング」とその運命が興味深いです。概ね同意ですが、アジャイル開発を実践されている方と同じ価値観だという印象を持ちました。

「仕様書プログラミング」とその運命のアジャイル開発に関する部分を要約すると

  • コンピュータが人々の仕事を奪い続けてきたことは広く知られた事実である。
  • 機械的で退屈なプログラミングがコンピュータによる自動処理に置き換えられ、良くも悪くも創造性が求められるプログラミングしか残らなくなる。
  • 仕様書プログラミングには仕様書の不備の補完という創造性があるが、多すぎる不備へのイライラ感か、厳密すぎる事に対するウンザリ感しかない
  • しかし、アジャイル開発は救いにならない。仕様書をはじめとする包括的ドキュメントは決定的に重要だからだ

アジャイルソフトウェア開発宣言

たしかにアジャイルソフトウェア開発宣言には

「包括的なドキュメントよりも動くソフトウェアを」

とあります。しかし、その下には、

「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」

とされていて、包括的ドキュメントの価値を認めるもののコードはもっと大切だよね。と言っています。

  • 標準プロセスや契約にあるからと、必要以上のドキュメントを書いてはいけない
  • ドキュメントに縛られて、動く使えるソフトウェアが提供できなくては意味がない

という意味だと思います。実際、アジャイル開発をされている方でも必要なドキュメントは書かれますし、システム間連携などで開発に必要ならプログラミングの前に書かれます。

つまり、包括的なドキュメントがすべて必要なドキュメントなら、ドキュメントは否定されないということです。

問題は従来法にもアジャイル開発にも極端な人がいて、現実的でないことを強制や主張する事ではないでしょうか?

プロセスのムダ取りをしないプロセス改善はありえませんし、コミュニケーションの手段として必要な文書を否定するアジャイル開発もあり得ないでしょう。

救いになるアジャイル

アジャイル開発が救いになるのは、その仕組みで創造性を強化する場合です。つまり、アジャイルソフトウェア宣言にあるように

  • メンバーとの継続的なコミュニケーションが必要
  • 確認しながら開発を繰り返さないといけない
  • 顧客やメンバーなどの継続的なコミュニケーションが必要
  • 変化が激しい

つまり、全てをあらかじめ決めるよりも、部分的にでも動く事で顧客あるいは仕様決定に役に立つ場合です。「アジャイルと規律」のように対象のシステムによっていずれか、あるいは切り分けて用いるものだと思います。

仕様書駆動の向いている基幹系システムや組み込み系はこれからも必要ですし、アジャイル開発に向いているサービス系システムもこれからドンドン増えるでしょう。

これらは独立している場合もあるでしょうし、組合せられることも増えるでしょう。それぞれの良さを学んで、良いプロセスを実現していきたいと思います。

仕様書はモデル

渡辺さんのアジャイル開発に対する批判は、仕様書駆動=ウォーターフォールというステレオタイプな視点で見ると、誤解してしまうかもしれません。

渡邊さんの記事の主張は「プログラミングによる合理化は止まらない」から、コードに引きずられないで、モデルで創造性を発揮しなさい(「データモデルなきアジャイル」の危うさ)、という事だと思います。

渡邊さんは「仕様書で「動的制御」される業務システム」の開発環境XEAD Driverを公開されています。DOAで有名なジェームス・マーチンのInformation Engineeringや後のRapid Application Developmentの流れを汲むもので、データモデルからプログラムを生成すると理解しています。若い人にはMDA(モデル駆動型アーキテクチャ)からの説明(「モデル」としての仕様書:渡辺さんのブログ)が理解し易いかもしれません。

渡邊さんの言われている仕様書はXEAD Driverの入力となるモデル(「モデル」としての仕様書:渡辺さんのブログ)だと思います。管理や配布の目的のために体裁を整えられる事はあると思いますが、読まれる事のないムダな情報を先に書けという事ではないと思います。

モデルという開発言語

モデルを書いて実行できるなら、それは開発言語です。実装優先時の考慮点 その3 - 言語と環境の選択 -で書いた言語と環境の選択肢の一つです。

コンパイラやインタプリタを作るとき、構文解析/字句解析にyacc/lexを使います。この際にyaccやlexの入力はBNFに相当する言語仕様と処理のプログラムです。この入力はXEAD Driverの様に図的ではありませんが、仕組みとしては良く似ています。

現在ほどフレームワークが普及していないころ、プログラム量を減らそうと、yacc/lexやシェルスクリプトを活用していました。XEAD Driverを見ていると、いつの間にか紺屋の白袴のように開発を効率化するためのプログラミングが少なくなっている事に気付きます。

渡邊さんの言われるように、これからは開発者に創造性の発揮が求められます。開発環境の整備はもちろんのこと、DevOpsの視点でツールの利用や構築も創造性を発揮する方法の一つではないでしょうか?

おわりに

対立をあおって書いても面白かったかもしれませんが、10年以上経つのに違いばかりを議論しても発展しないと思い、「同じことを言ってませんか?」という問いかけをしてみました。

みんなムダな事はしたくないし、開発を効率化したい。渡辺さんが書かれているように( アジャイル手法は分野毎に違っていい)、色々な技術がある中で状況に合わせてどのような開発を行うべきか、プロセスを選択的なタスクの集合として洗練していきたいと思います。

このエントリーをはてなブックマークに追加


[#TiDD] ソフトウェア開発と時間 - 時の記念日特集寄稿コラム -

2011年に寄稿したコラムが出てきました。これは情報処理学会誌である情報処理(Vol.52 No.6)で「時の記念日」にあわせた特集「時間とコンピュータ」に掲載されたものです。現場ではない人を意識したチケット駆動開発の説明文はあまりないので、公開します。


実装優先時の考慮点 その5 - ドキュメントを優先すべき時 -

実装を優先してプロジェクトを進める場合でも、先にドキュメントを作った方が良い時があります。

  • 変更が多いとき

実装を優先するのは、より早くフィードバックを得るためです。アーキテクチャの検討が必要な時などは、ドキュメントの方が大胆に変更できるでしょう。

  • ドキュメントの方が軽量なとき

変更量は小さくても方向性が決まらない間は、ユーザインタフェースなどでもドキュメントの方が簡単な場合があります。きちんとしたドキュメントではあまり軽量化できないので、レイアウトをツールやホワイトボードで描くなどします。

  • コミュニケーションが容易なとき

ユーザインタフェースを伴わない場合は、コードよりも図の方が理解が容易な場合があります。理解してもらわないとフィードバックが得られないので、必要なドキュメンテーションをします。

軽量なドキュメンテーションは、実装優先でなくても活躍します。ホワイトボードにシーケンス図を書いてそのコピーを元に開発を進めた事もありますし、多くの業務アプリでも手書きのラフなモデリングは利用されています。

アジャイル1次ブームの不思議な話

2000年に始まったアジャイル1次ブームでは、ドキュメントは書かないという不思議な話を聞く事がありました。しかし、XPにはトラッカーという記録の担当者があるほか、必要なドキュメントは作成されます。

当時はCMMの守破離の第1段階であるレベル3を達成しようと、多くの企業が標準化に躍起になっている時代でした。以前からライト・オンリー・ドキュメントと言われるほどムダの多いドキュメントが、スリム化されないままにより厳格に標準化されたので、反発もあったのでしょう。

もちろん、分かりやすいコードは大切ですし、しっかりした基盤上の小規模な開発や、スタイルの確立した優秀なプログラマであれば、ドキュメントなしに開発する事も可能かもしれません。しかし、上に挙げたようにドキュメントの方が有利な場面もあります。

プロジェクトはバランス

プロジェクトで大切なのは、ムダなくゴールに向かう事です。業務や組織で異なる様々な制約を考慮して、合理的な判断をする事です。

たとえば、開発が一旦終了して継続的に開発(保守)が行われない事がわかっている場合には、早めにドキュメントを用意するでしょう。これは顧客のためだけではなく、開発者が未来の自分のために書くものです。いつでもだれでも対応できるように、理解に必要なポイントをまとめておきます。

チケット駆動開発の導入も同じです。情報共有や過去の履歴の活用など多くのメリットがありますが、合理的な理由がなければプロジェクトに導入してはいけません。

ソフトウェア開発はプロジェクトのゴールに向けて、ムダの少ないバランスを追求するものです。プロジェクトにまつわる様々な制約を踏まえて、より合理的な方法を実践します。

どのようなタイミングで、どのようなドキュメントを作成するか、それも大切なバランスの一つだと思います。

IMPACT MAPPING - 戦略を共有する言葉 -

ソフトウェアは多くの利害関係者間のコミュニケーションから生まれる。コミュニケーションには言葉が用いられるので、どのような言葉を用いるかでソフトウェア開発の成否が決まる。

従来の方法

実装優先で作れば良いと思われる方もおられるかもしれない。しかし、この本のまえがきにこうある。

「動くソフトウェア」はユーザーストーリを確認する事はできても、問題の発見と選択には大して役に立たない。

実装やその前段階のモデリングは戦略の合意が得られた後のイメージ共有には有効だが、戦略を決めるには重すぎる。必要以上の情報が含まれているからだ。

そこで、従来は用語の統一がおこなわれてきた。構造化分析/設計に始まるデータディクショナリや、DDDのユビキタス言語がそれにあたる。

用語を統一する中でターゲットとするビジネス戦略(WHY)と対象ユーザ(WHO)が共有され、モデルや実装を通じて何を(WHAT)どのように(HOW)作るかが明確になってくる。

指示型コントロールから適応型コントロールへ

一見、正しそうに見える従来のやり方だが、大きな問題がある。ビジネス戦略(WHY)と対象ユーザ(WHO)がすでに明らかでないとうまくいかないからだ。まえがきにはこのように書かれている。

私達は、考え方の大きな転換点に差し掛かっている。(中略)プッシュ型では、人々はやる事を指示される。プル型では、問題や機会を与えられて、部門を超えたチームがその理解と解決に取り組むのだ。 (中略)内発的動機は、自律性、成長、そして目的によってドライブされる。

つまり、ゴールの設定からチームで取り組み、WHY、WHO、HOW、WHATを整理するのである。

効率的な情報共有

では、コミュニケーションに用いられる言葉はどのような構造が良いか?できる人の知識は構造化されているのだから、何らかの構造に整理した方が良いだろう。

従来はスクラムのバックログのように優先順位付きのリストや、派生開発(XDDP)のWhat、Where、Howを示す変更要求仕様書、トレーサビリティ・マトリクス、変更設計書などの表がある。

IMPACT MAPPINGでは、より効率の良いマインドマップの木構造を応用し、中心からWHY、WHO、HOW、WHATを割り当てている(翻訳者のお一人である平鍋さんの記事に詳しく説明されている)。木構造なので構造の見直しが局所化され、アルファ・ベータ法(リンク先はwikipedia)のようにあまり重要でないツリーを対象外にする事も容易である。

本の内容

ここまで、引用部分を除いて私の理解を説明した。せっかくなので内容にも触れておこう。

この本では、上に述べたようなインパクトマップそのものの説明よりもどのように書くか、そして犯し易い間利害について多くのページが割かれている。

準備のステップとしては、本当のゴールを見つける、適切な測定値を定義する、最初のマイルストーンを計画する、チェック、が説明されている。マップを描くステップとしては、骨組みを描く、代替案を見つける、主な有線事項を特定する、「稼ぐ」か「学ぶ」、チェック、が説明されている。

そして、測定値をマップ内に表示する、何度もやっては繰り返す、定期的な計測とチェック、で一連のプロセスが説明されている。これらは、非常にシンプルに説明されており、方法論というよりも手法に対するノウハウ集となっている。

本のデザイン

私とあきぴーさんとの共著チケット駆動開発も手法に対するノウハウ集で、80年代の書籍のような難解さを覚悟して、多様な内容を詰め込んだ。

しかしこの本の場合は、まるで児童書の様にシンプルで明快なデザインでエッセンスだけに絞る方法を選んでいる。図とタイトルをスライドに貼付ければそのまま発表に用いることができるくらいに練られている。

著者や翻訳者らはこのデザインを非常に大切にしているのだろう。適切な訳注は本の後半にまとめられ、全体のデザインを壊さないように工夫されている。

この本にはスキャンタイプの電子版がある。デザインを大切にしているので、それ以外の方法はなかったのだろう。しかし、2段組みの構成中にぶち抜きの図があるので、7-8インチ程度のタブレットでは少しつらいかもしれない。(私には少し字が小さかったが)通常本か、大きめのタブレットの利用をお勧めする。

おわりに

書店で手に取ってシンプルなデザインに、購入をためらう方もおられるだろう。イントロダクションにこう書かれている。

私の狙いは、この手法と関連するアイデアへの関心を喚起し、コミュニティを刺激する事だ。そのため、この本は意図的に短くつくり、すばやく読めるクイックリファレンスとして身近に置けるようにした。

背景に思想を持つ方法論とちがってこの本のように、ある方法のノウハウを集めた本は読み手を選ぶ。人によって価値を感じるところが異なるからである。しかし、それは読み手の成長に応じて、新たな発見があるという事だと思う。

すでにできあがった組織の中では、本書の方法を導入する事は簡単ではないかもしれない。しかし、ビジネスとソフトウェアの関係を考える際に、本書は非常に刺激となるだろう。そのような読者には、この本の薄さが大きなメリットになる。

少なくとも私は、この本に大きな刺激を受けてこの記事を書いた。知識が整理され、また一つ抜けていたピースが埋まったように思った。

このエントリーをはてなブックマークに追加


« 2013年12月 | トップページ | 2014年2月 »