アル中プログラマの備忘録。もはやコーディングしてないけど。

酔いどれまさになう。プログラマとして就職し、システムエンジニア、プロジェクトマネージャーと立場を変えながら、システム開発に関わるとあるアル中の成長記録。

プロジェクトマネジメント

要件定義について思うこと、依頼主との関係性が一番大切で一番難しい

投稿日:2016年2月22日 更新日:

要求

要件定義

まさに要件を定義するのですが、実際には要求、要望など似た表現が微妙なニュアンスの違いで使い分けられていたり、その分け方も現場によってまちまちだったりして難しいです。
しかし、細かい差異を無視すれば依頼主と作り手が何を作るかを決める事です。

このときに気を付けないといけないなと思もってることを書こうと思います。

依頼主と作り手の要件の捉え方にはよくズレが生じるということ

依頼主の目的は、 何かを作ることではなくて「それを使って為す何か」であるのに対して、作り手はどうしても「どうやって作るか」に興味が向かいがちです。
また、両者には業務とシステムのそれぞれに関する知識に偏りがあるため、次のようなことが起きます。

  • 依頼主は簡単だと思っているが、実際にはとても大変な改修になる
  • 実際にはもっと簡単な方法で効率的なものを提供できるのだが、依頼主はそういった方法に思い至らず非効率な物を要求し、作り手も背景までは考えずに作ってしまい、なんとも言い難いものが出来上がる
  • 業務を少し変えることができれば不要になる機能があるのにお互いに気が付かない

よって依頼主の言うがままのものを作ると使い物にならないか、工数かけた割にはイケてないものが出来上がることが、よくあります。
それを避けるためには、「なぜそれが欲しいのか?」、「それを使ってやりたいことは何か?」 を確認する必要があります。

依頼主は成したい事の実現方法についてのネタが作り手より少ないことが多く、人は知ってる範囲でのお願いしかできないので、この部分は作り手が歩み寄るべきだと思います。
前に書いた通り、作り手はすぐ技術的な課題に思考が行きがちですが、「なぜ」の部分が分かれば作るもの(機能)は 別のものが良かったり、そもそも何かを作る必要すらないことに気付くことができます。
その上で、複数考えられる実現方法の候補について依頼主に説明するのが良いと思います。

作り手の説明はよく技術寄りになりすぎるということ

何がしたくて(何に困っていて)、それを成すにはどんな方法があるかまだ考えることができても、説明が上手くない場合もよくあります。
当然、単に楽したいわけではないですし、かと言って無駄な苦労はしたくないので、一押しの案は理にかなっているものを選んでいるはずですが、それの伝え方がいまいちなのです。
興味と同じで、つい説明のベースが技術的な難しさがどれくらいかになってしまいがちなのです。しかし、依頼主はそんなこと気にしていません。気にしているのはどれくらい早く(安く)できるのかどうかです。

ここを一生懸命説明するほど話が噛み合わず空回りすることが多いです。かと言って全く説明不要かと言えばそうではありません。「どうして大変か?」と「それを乗り越えてでもやる価値がある」または「そこまでする必要はない」と言うことを依頼主はの分かるレベル感で説明しないといけません。
例えば「テストが複雑で依頼主が思っているより大変です」で伝わることもあれば、「見た目はこの前のやつと同じですが、ここが違うため作り直す必要があります」であったり、ソースコード見せて説明する必要があったり、可能な限り依頼主のわかる言葉で根拠を伝える必要があります。

面倒に思えますが、ここに力を注ぐ方が効率的で、ここをサボると後で痛い目を見ることがあります。

ソフトウェアの見積もりはかなり曖昧だということ

様々な見積り手法があるものの、毎回作るものが違う以上、ある程度は過去の実績とカンに頼らざるを得ません。どれだけ見積もりの精度が上がっても、「想定外」が起きた時点ですぐ破綻してしまいます。

システム構築はときどき建築物に例えられますが、設計通りに作る(設計が間違っていたら欠陥)建物と違い、設計段階で全てを明らかにするのも厳しく、間違いの他にも途中で追加、削除、改変が起きます。しかも頻繁にです。
(家建ててる時にいきなり三階も追加とか、階段をエレベーターに変更とか言いませんが、ソフトウェアではよくあります。)

想定外が起きにくいようにするには、要件はできるだけ細くし、見積もりの単位を小さくするのが良いと思いますが、やり過ぎれば見積もりに係る工数ばかり増えてしまいます。

最初からごめんなさいできる環境も用意する努力が必要ということ

見積りは曖昧なままでは難しいため、意識してかせずかは問わず前提条件を設けていることが多く、この前提条件から外れるのが「想定外」です。
「想定外」が起きてから相談するとお互いにとってたいてい辛いことになります。
そのため、 最初から見積もり直しが必要になる可能性と思いつくその状況について話をし、可能な限り合意をとった方が良いです。

依頼主には責任逃れや言い訳に聞こえると思いますが、無責任に全部受けられて最後の最後でダメになるのと、怪しいタイミングで常にアラートが上がるのとでは依頼主にとっても後者の方が望ましいはずです。

一番大切なのはこういう話をできる環境を作ること

こういう話を依頼主と作り手が話せる環境を作ることが一番大切ですが、一番難しいです。
手も足も出ない現場も多いと思います。
これに関してはコツなどはありませんが、正直ベースで話をするようにしています。
期日絶対となればバッファーを隠して積むことになりますが、極力「こういう想定なら最短これぐらいで、ダメならごめんなさい。その時は説明と再計画させてください。」で話すようにしています。

たいていは欲しいものを聞いても収集がつかず、ないと困るものから始める必要があるということ

要件定義で対応する対象を絞る際に「今回はやらない」、「この順で機能追加する」というのを決めるとおもいます。
この基準になるのが「工数見積」と「優先度」だと思います。

しかしこれもなかなか難しいです。
依頼主に優先度付けを完全に任せると、「全て最優先」などということも起こります。
実際には最終的には必要だが今なくても困らない物も多く含まれています。

そのため、ヒアリングする時は「優先度は?」より「今ないと困るものは?」と聞くことが多いです。
そうしながら対応する順番を決めます。
優先度も付いていますが、この順番決めの対象にするかどうかぐらいにしか利用していません。
ときどき優先度が低くても一緒に対応すべきものが混ざっているので、それは適宜提案します。

これで全て最優先よりはよほど見通しが立てやすくなります。
あとは工数の許す範囲で順番に詰めて行き、着手したものはできるだけ最後まで割込みをさせずにやりきります。

仕方ない場合もありますが、割込みは大抵余計に工数がかかるため、その分全体が遅れることに了解を得られた場合だけリスケして対応することにしています。

本当の依頼主は誰か?を考える必要があること

依頼主と話をするのが大切ですが、その依頼主を間違えるとどうしようもありません。
基本的には目の前で要望を言っている人が直接の依頼主です。しかし本当の依頼主は別にいて、実際の利用者や、お金を払ってくれる人、承認を行う人であることもあります。
これを忘れていると現場ではOKが出ていて進めていたのに、最後に承認されず頓挫したり、作ったけど使われなかったり、他の何かと整合性が取れてなかったりなどが起きます。

最後に

言われたものを作るのは無難ですが、それでは楽しくないですし、せっかく作るのなら使ってもらえるもの、効果のあるもの、結果として誰かが楽に、幸せになれるものを作りたいです。

酔いどれまさになう。


-プロジェクトマネジメント

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

完了

プロジェクトマネージャーとしてのはじめてのプロジェクトを終えて

ふりかえり このブログのタイトルは「アル中プログラマの備忘録」ですが、プログラマではなくなってしまいました。仕事でソースコードを書くことは当分なさそうです。(アル中な部分はそのままですが) さて、プロ …

入り口

Developers Summit 2012に参加してきました

Developers Summit 2012 名称:Developers Summit 2012 (デブサミ2012) 会期:2012年2月16日(木)・17日(金) 会場:目黒雅叙園(東京・目黒) …

meeting

会議を効率的に進めるにはきちんと準備しよう

会議 必要だからやっている会議ではあるものの、多いときには一週間でいったい何時間費やしているのでしょうか? 1回の会議にしても、例えば5人で1時間行う場合、仮に一人月が80万円、労働時間が160時間/ …

カテゴリー