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インチ程度のタブレットでは少しつらいかもしれない。(私には少し字が小さかったが)通常本か、大きめのタブレットの利用をお勧めする。
おわりに
書店で手に取ってシンプルなデザインに、購入をためらう方もおられるだろう。イントロダクションにこう書かれている。
私の狙いは、この手法と関連するアイデアへの関心を喚起し、コミュニティを刺激する事だ。そのため、この本は意図的に短くつくり、すばやく読めるクイックリファレンスとして身近に置けるようにした。
背景に思想を持つ方法論とちがってこの本のように、ある方法のノウハウを集めた本は読み手を選ぶ。人によって価値を感じるところが異なるからである。しかし、それは読み手の成長に応じて、新たな発見があるという事だと思う。
すでにできあがった組織の中では、本書の方法を導入する事は簡単ではないかもしれない。しかし、ビジネスとソフトウェアの関係を考える際に、本書は非常に刺激となるだろう。そのような読者には、この本の薄さが大きなメリットになる。
少なくとも私は、この本に大きな刺激を受けてこの記事を書いた。知識が整理され、また一つ抜けていたピースが埋まったように思った。
« いびつにとんがれ! - スーパーニッチの人生戦略 - | トップページ | 実装優先時の考慮点 その5 - ドキュメントを優先すべき時 - »
「書籍・雑誌」カテゴリの記事
- Visual IoT 開発ツール Node-RED が盛り上がってきた - 新刊2冊 -(2017.10.14)
- 決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -(2017.10.07)
- [#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!(2016.09.14)
- Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール(日経BPムック)(2015.05.17)
- [#Redmine #TiDD] 日経SYSTEMSにRedmineの紹介記事を寄稿しました(2014.10.13)
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
« いびつにとんがれ! - スーパーニッチの人生戦略 - | トップページ | 実装優先時の考慮点 その5 - ドキュメントを優先すべき時 - »
コメント