DBマガジン2010年3月号の特集２『基礎からの要件定義講座 - “聞く”と“伝える”をフル活用する』にPART2として『ヒアリングからプロトタイピングまで演習で学ぶ要件定義の実践』という記事を寄稿しました。
内容は若手メンバー（1年目、2年目）の3名を対象に行なった開発演習です。当初は技術習得を目的とした開発演習だったのですが、僕がファシリテーターをすることになったので目的を『「聴く力、考える力、伝える力」という3つの“力”の習得』として、要件定義から開発までの広い範囲を実習したものです。そのために次のコンセプトに従って演習を組み立てました。
答えはメンバー自身で出す
いわゆる開発演習だと要件定義書や仕様書ぐらいはありますが、今回はなし。「ユーザー役の社員」を用意し、要件は彼らに自由に出してもらいました。つまり、整理されていないし、技術的な可能性も検討されていないし、開発範囲も制限がない状態です。そこから「何を作るべきか」「なぜ作るべきか」を考えさせました。
間違っても良いからアウトプットを早く出す
考えるというのは、腕を組んでやることではなくて手を動かしてやることです。整理されていない情報を矛盾無く構成するのは地道な作業です。小さく成果物を出しながら、あーでもない、こーでもないという作業を繰り返し、段々と見えてくるモノ。そのためには「間違っているかどうか」を気にしないでアウトプットしていくことが大事です。
すぐに周りのフィードバックをもらう
3人寄れば文殊の知恵とはよく言ったもので1人でもんもんと考えていても良いものはできません。互いにアイデアを持ち寄り洗練させていけばいい。成果はチームで出すもの。1人では出来ないことでみんなでキチンと相談すればよりよい成果物に繋がります。
細かな内容は雑誌記事に譲るとして、その中で利用したテクニックを紹介しておきます。
・モデリングを利用したインタビュー（時系列分析から機能分析へ）
・パワーポイントによる提案（ビジョン＞課題＞戦略＞戦術の落とし込み）
・ペーパープロトタイピング
・KPTでの振り返り
特に活用したのは小さな付箋紙です。書いて、動かして、まとめて、というのに付箋紙は最高のツールです。PCの前にいるよりも机を囲んで全員で考えさせることを重視しました。それぞれの工程はそんなに突飛なことはしていません。むしろ、オードドックスと言えます。
大事なことは要件定義の手法やツールを知っていることではなく、ユーザーと、あるいはチーム内で深い対話をすることなのです。専門知識が足りなければ専門家を足せばよい。だけど、それだけでは解決にはなりません。チームとして力を発揮するのに必要なのは、やはりコミュニケーションなのです。
雑誌には載せなかった個人的な感想。僕は決まりきったコンテンツの演習だけを行なうことに疑問を感じています。手法やツールをなぞることは学校の勉強と変わらない。僕が大事にしたかったのはメンバーに「ゼロから何かを作りだし、それを実現していくシステム開発の醍醐味」を感じて欲かった。これを知ってしまうとソフトウェア開発の魅力は桁違いに高まります。
最後に謝辞。ユーザー役をやってくれたＫさん、Ｈさん、そしてメンバーを技術的に支えてくれたＮさんありがとう。あと、こんな実験的な演習にも関わらず成果を評価してくれた関係者各位にも感謝。記事に出来たのはタイミング良く長谷川さん（Starlight & Storm）に声をかけてもらったから。何よりも演習に参加して成果を残してくれた3人のメンバーに感謝です。あっという間に成長する君たちを見ていて、こちらが大いに刺激を受けたよ。今後のさらなる活躍を祈念しています。そのうち、がっつりとプロジェクトをやりましょう。
 | DB Magazine ( マガジン ) 2010年 03月号 [雑誌] 翔泳社 2010-01-23 by G-Tools |
