イメージできないものは手に入らない

ITコーディネータの吉田聖書よしだみふみです。

久しぶりにシステム開発(調達)に関する話題です。
皆さんが外部のシステム会社に委託をする時、
適切な形で要求・要件を提示できているでしょうか。

ご一緒に考えてみましょう。

私がこの業界に関わり始めた頃から、
丸投げのシステム開発というものを目にしてきました。
おそらくそれ以前からもあったでしょうし、
もちろん今でも見受けられます。

丸投げというのは少々表現が粗いですが、
発注者が開発者に求めるアウトプットに対して、
提供するインプット情報が不当に小さい案件…
とでもしておきましょうか。

不当というのも表現が粗いですね。
インプットが小さくても、
それで間に合うようなケースもありますし、
ここでは、システムが構築できない、
あるいは構築に着手できない程度の…
としておきましょう。

そんなもの、
開発者が発注者の意図を組んで構築するものだ
…と思われましたか?

確かに、システム開発に
そういった側面があるのは事実ですが、
その「程度」については
作業範囲をどのように定義するか
によって変わってきますので、
一方的に決めつけるものではありません。

少なくとも、開発者が見て
明らかに情報が不足しているという状態で
ゴリ押しで進めてはいけません。
開発者も、そのような丸投げの状態で
安易に開発を請け負ってはいけません。

理想は、発注者が、
開発者の業務が滞りなく行えるようなレベルの
情報を提供することです。
主に「何がしたいんだっけ?」の部分を要求、
「どうして欲しいんだっけ?」の部分を要件、
と呼んだりしています。

しかし、中小企業など、
発注側の人的資源が不充分なケースでは、
外部のコンサルタントを投入して要件を定義したり、
要件定義が出来る開発者(開発会社)に
その段階から支援してもらうという方法が取られます。
それはそれでおかしい事ではありません。

ここで重要なのは、
要件定義の部分を支援してもらう時、
あくまでも作業の主体は
発注者であるということです。

ここを履き違えると問題となります。

支援を受ける・受けないは別として、
システムの質のベースラインを決めるのは
発注者のイメージの質です。
明瞭で具体的なイメージを描くのは
開発者ではなく、発注者の責任なのです。

誰に支援してもらおうとも、
要件定義の成果物(結果)は
発注者のイメージより勝ることはありません。
勝ることがあるように見えるとしたら
それは支援によって、発注者のイメージが
より鮮明になったということです。

もし支援を受けていても
イメージを鮮明にする努力を
発注者が怠ったとすれば
成果物もそれなりのものとなります。

尚、余談ですが、
以前に比べて最近では
「利用者側の協力義務」を問う
裁判事例も増えてきました。
要は、外部に丸投げするとしても、
発注者の最低限の責務として
開発者に協力することが求められているのです。

詳しく知りたい方は
細川義洋氏が執筆されている
@ITの記事をご覧ください。
「訴えてやる!」の前に読む IT訴訟 徹底解説

この連載が書籍にもなっているようです。


関連記事

プロマネの右腕

クロスイデアでは、新サービス・新ビジネスの 立上げや計画を中心に
プロジェクトマネジメントの支援を行っています。

新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html

YouTubeにて動画配信中!

プロジェクトマネジメントのノウハウを
YouTubeで配信しています。
ブログと併せてご活用ください。

Comments are closed.