アート・オブ・プロジェクトマネジメント (その三) / Scott Berkun

前回のエントリから、三回目。今回はちょっと少なく、第六章のみです。

第六章「アイデアを得た後にすること」
システムを作ることになり、どのような問題があるかをリストアップしたならば、次はその問題をどうやってクリアするのか。という点について述べられているのがこの章です。
大体において、システム開発やWebデザイン、もしくは何らかのプロダクトなどに携わってこの手の問題に係わる人ならばわかることですが、ここが難しい。行きつ戻りつ、時にはその問題そのものの存在する疑うハメにもなりかねません。

この章でも、印象的な言葉が引用されています。
「そこには莫大な量の試行錯誤が存在している。・・・観察と理論を行きつ戻りつすることになるのだ。理論を知らずして何を探すかを知ることはできず、事実を観察せずして理論を確認することはできないのだ。(後略)」ジョシュア・レダバーグ･･･ノーベル賞受賞者1958年(p135)

筆者はこういった設計におけるチェックポイントをあげていますが、なるほど納得するべき点が多い。問題点をクリアするべくビジョンとコンセプトを明確にして、プロトタイプを作成。3つ→2つ→1つと設計の選択肢を絞り込んで、最後に仕様書を書く。という点があります。自分の場合、頭でぐるぐると考えて、1つの選択肢だけで作りこんでしまう傾向が強いため、どうしても次善の策、というのが浮かばないことが多いのです。もっと積極的にプロトタイプ(もしくはその明確なイメージ図)を作る必要があると感じますね。

筆者はここで、アイデアを纏める方法としてKJ法Wikipedia)を紹介しています。またプロトタイプの重要性も強く述べていますが、当然といえば当然です。
プロトタイプですが、目に見えるインターフェイスまわりから、その背後で動くロジックまで様々なケースが考えられます。しかし、形に見えることで、作り手は問題のブレイクダウンを行い、解決方法を導き(時に新たな問題を引き起こし)、スタートに向けての足がかりを掴むわけです。プロトタイプが出来上がると「これで完成？」とか「これしか出来ないの？」とか無知なことをいう人もいるわけですが(恥ずかしいところ、自分が言われた口です)、有り難味を知らない人の言葉としかいいようがありません。
まぁ、とはいえ、いきなりVBなどでインターフェイスをしこしこと作る必要もないのです。ちょっと要らない紙をもってきて、四角を書いてから、ダイアログボックスとかぐらい手で書けるでしょう？　そこからスタートしましょう。頭の中のイメージを紙に書いて、コピックでも使って色を塗りましょう。自分の場合、インターフェイスを考える場合、紙からスタートするようにこころがけています。

建築設計に携わる方が、新築依頼の方に模型を見せるように、車のデザインを行うチームが木型でボディのモックアップを作るように、システムだってプロトタイプが必要なのですから。

さて、ここで第一部は終了。プロジェクトマネジメントとは何か、から、PMにおける要求の定義からす毛ジュール、そして問題解決の第一歩であるアイデアの取りまとめまでをここでは書いていましたね。
チェックポイントが数多くあるので、これを抜き出してもいいかもしれません。

ちなみに本章の脚注には、「UIインターフェイスの技芸」というわけで作者サイトのエッセイが紹介されています。ちょっと英文なのがアレですが(w　読んでみようかと思うわけでブックマークしてみました。はい。

で、来週からは第二部がはじまります。次は「スキル」という名がついているように、PMにおける数々のテクニックが紹介される形となるのでしょう。ではでは。