2013/01/24★システム構築の最初にして最大の難関システム構築をする際の要件定義は難しい。一度決めたはずの要件が、プロジェクトが進むに従って何度も変更される。設計書も書きなおし、プログラムも書きなおし、テストもやり直し、マニュアルも書きなおし・・。気づくのが下流工程になればなるほど、被害は大きくなる。これほど重要な要件定義なのだが、実はシステム構築においては凄く中途半端な位置付けだ。「とは言っても、システムのプロじゃないんだから、ユーザーが正確で網羅的な要件定義は出来ない」という現実論がある。その2つの見解のハザマに落っこちて、ただでさえ難しい要件定義が、ますます困難なものになっている。「これが出来るシステムであるべき」ということである。その要件がどうやって実装されているのかは、要件とは関係がない。それは設計の世界の話だ。大事なところなので、住宅建築に例えてみよう。設計:・キッチンは2階に・トイレは階段の下、階段3つ降りた所に作る・階段の上に、常時開けておける小さい窓を作るこう整理して書くと当たり前に見えるのだが、要件は家に住む人にしか言えない要望だ。トイレが2つあることが書斎よりも重要、という人も中にはいるだろうし、どっちが正しいという話ではない。設計はどちらかと言うと、その道のプロの領域だ。キッチンを2階に設置することで、水回りの配管にどのような配慮が必要なのか・・といったことは専門家でなければ分からない。それらを全て踏まえた上で、ベストな配置を選びとる時に中途半端に素人が口を出すと、かえって悪くなることのほうが多い。家を建てる時になればつい「キッチンは2階にあるのがいいな」と言ってしまうものだけれども。聖書に「カエサルのものはカエサルに。神のものは神に」という言葉がある。本来の持ち主に返せ、という程度の意味だと思う。同じ言い回しで表現すれば、こうなる。「要件はお金を払うユーザーが。業務担当者はシステムがどの様に実装されるかにアレコレ思い巡らすよりもまず、「自分が手に入れたいもの」を明確に表現することに全力を注いだほうがいい。僕は家を建てたことがあるが、最初はこんな間取りがいいかな・・と小学生の落書きみたいなものを書いていた。あまりに発想が貧困なので、すぐに馬鹿馬鹿しくなった。ド素人の自分が下手に考えて、設計する人にとって「制約」みたいなものになってしまうのは良くない。それよりも「要件=こんな家だったら嬉しいな」を色々な方法で設計者に伝えるのが、ユーザーである僕の仕事だ、と思い直した。・自分たちがどんな人間か・何が好きで何が嫌いか・どんな生活をしているか・家に何を望むか。・欲しい家をCDアルバムに例えると?服に例えると?人に例えると?「カエサルのものはカエサルに。★だが、要件定義はプロが仕切るべき要件を話すのは、ユーザーにしか出来ない。ユーザーは業務のプロであって、要件定義のプロではない。世間でよくやられている様に「要件定義書はユーザーさんが書いて下さい。僕らシステム開発者はその通りに作りますから」は、無理な注文となる。要件はユーザーにしか話せないが、話を引き出すのは要件定義というプロセスのプロが責任を持つべきだ。ユーザーが要件を正しく定義するための工夫は沢山ある。ベストプラクティスアプローチ。僕らケンブリッジは過去プロジェクトの蓄積として、各業務に必要であろう要件のリストを持っている。人事業務で言えば、400行くらいになる。それをベースにすれば、ゼロからお客さんが全て語るよりもずっと早くて網羅的な洗い出しが出来る。業務フローアプローチ。将来業務フローを定義しながら、そこで使うシステム機能を一つ一つ明確にしていく。時間がかかるが、仕事とシステムの噛み合わせがとても良くなる。他にも挙げていけばキリがないが、どちらにせよ「ユーザーの要件を引き出す責任」はその道のプロであるシステム開発者が持ったほうが、結果として上手くいく。少なくとも「ユーザーさんが要件を出してくれないから、スケジュールが遅れまくりだよ」とか愚痴を言うよりは、僕は自ら責任持ってリードする方を選びたい。「要件を出し切ることに責任を感じるかどうか?」で、プロフェッショナルなシステム開発者と、言われたことをやるだけの作業者に二分できるとさえ、思っている。逆に言えば、「それはお客様のご判断ですから」と慇懃に言って判断を丸投げするシステム開発者があまりに多い事に憤りを感じる。コンサルタントを名乗っていても、そんな感じの人もいますからね。★ユーザーが語った要件が誤っている?さらに言えば、プロジェクトの最初の頃にユーザーさんが「これがほしい」と言ったことが本当に正しいとも限らない。要件定義以降のフェーズでしつこくしつこく、それが正しいかを確認していく作業も、プロであるシステム開発者がリードすべきだ。ほとんどのユーザーは要件定義がそれほど難しい事を知らないし、要件が誤っている時に対応しなければならないのは開発者の側だからだ。僕らがやる場合は、プロトタイプを作って業務のシミュレーションをやることで、問題点を山ほど洗い出す。問題が沢山出れば当然ウンザリするが、後の工程になって表面化するよりは100倍マシだ。いう事をきちんとやらないで、「ユーザーさんが要件を変えるのが悪い」と言うのはプロ失格だと思う。長くなったので業務シミュレーションの話は、いずれまた気が向いた時に。08:53そんなやり方で要件定義全てうまくいくと本気で思ってるなら大間違い。11:22デスマ経験者さん、こんにちは。考えさせられるコメントです。要件定義ってとても難しいので、僕もいつも完璧にできるわけじゃないけれど、どうにかこうにかやっているし、プロジェクト全体としては上手く行っている。そのベースには、この記事で書いたことがあると思っている。(あくまでベースの1つでしかないが)うまくいくケースとうまくいかないケースの分岐点はどこにあるのだろうか?決定的なことが1つあるのではなく、いくつかの重要項目の組み合わせで決まるのだろうか?もちろんプロジェクトをやっていると政治的な問題や、既存システムの呪い的なものに苦労することもあるけれども、それは少し別な話だと思うので、そのうち書いてみたい。一言で言うと「そんなの考慮するのやめましょうよ」と言えるだけの場作り関係づくりを事前にどれだけ出来るかの勝負だと思いますね。10:33ちょうど昨年実施したプロジェクトの振り返りをしており、ブログを読んで共感しました。パッケージを使うケースの要件定義の場合、システム開発者が要件を引出す重要性が増すと考えています。(要件を一部我慢すればパッケージをより有効活用できるなど情報の非対称性がより大きいため)ですが、昨年のプロジェクトではシステム開発者が要件定義を軽視する傾向がありました。してから請負」という契約も一因かと思います。「要件定義はユーザーメインの仕事」と考え、その際は放置した要件が開発時に「この要件はパッケージの制約上実現できません」となり、そこから再度要件を検討しながら開発という様相を呈してしまいました。「お互いに苦労するので会社は別ですが、立場は置いておいて議論しましょうよ」と言える関係になることがプロジェクトには必要なのだと反省しています。17:47ちょうすけさん、こんにちは。僕がこの記事を書いたのは、やっぱりこう考えているシステム開発者が多いからです。要件定義ってそもそもかなり難しいので、そんなこと言っている場合じゃなくて、まさに>立場は置いておいて議論しましょうよこういうノリで取り組まないと全く上手くいかないんですよね。何度も失敗しているんだから気づいてよ・・とは思います。「要件を引き出すことはシステム開発者の責任である」ということを明確にしてしまうと、後の工程で仕様変更が発生した時に「ユーザーさんがこういったんだから、1字でも変わるなら追加料金いただきます」って言い難くなるんですよね。その辺の防衛上の理由が大きい気がします。克ケンブリッジ・テクノロジー・パートナーズのコンサルタントファシリテーションを使ってプロジェクトを成功させるのが得意。「うまくいかないのはあいつのせいだ」のメリットあるいはデメリット人生を決めた空白の半年、あるいは人生への期待値オフィスを気合い入れて作ってどうなったか?あるいは僕らなりの働き方改革1冊目の本が出てから人生変わった話。「規律を守るのが日本組織の強み」は嘘。「飛び越し報告」がタブーな組織の末路は壊死。カネカの件と僕の23年前の採用活動。Agents」が公開されました。「自立だ~」「成長だ~」だけだと疲れてしまう。今までの入れ歯よりもふた周り以上も小さい入れ歯を作ったら、話が出来るようになった症例これから必要な人材は「全体最適化」を考えられる人だ!オルタナティブ・ブログは、専門スタッフにより、企画・構成されています。入力頂いた内容は、アイティメディアの他、オルタナティブ・ブログ、及び本記事執筆会社に提供されます。利用規約プライバシーポリシーお問い合わせアイティメディアからのお知らせプレスリリースメールサービスRSSTwitterITmediaはアイティメディア株式会社の登録商標です。