一昔前ならシステム構築の手間って膨大な時間と労力をつぎ込んで作るものってイメージがありました。
例えちょっとした機能変更でさえも、開発側の担当者は「それは多くの機能に影響を与えるからかなり時間がかかる」とか何かと理由を付けて拒む姿勢もよく見かけました。
まぁ、これは担当者が面倒くさがっていたり、品質や納期の観点からこの時期にその要求を受け入れるリスクを嫌っていってたのかもしれません。
しかし、今ではその労力というのはだいぶ軽減されてきています。
もちろん要件の規模によりますけど、その一部の機能を構築するのにも昔に比べたらはるかに楽になっているでしょう。
技術の標準化や多様なライブラリ、ネット上に発信される多くのノウハウ、IDEなど開発環境の進化などその理由は多々ありますが、そういった開発コストの低下の中で思うのは、システムを構築する手間っていうのはもはや構築をする側より仕様を決める側の方が大きく、ボトルネックってむしろ提案側になってしまっているのではないかと感じたりもします。
開発プロセスとボトルネックが発生する場所の変化
この話はもちろん「一般的な」って枕詞が付くので、世の中にない先進的なサービスを作ろうとした場合は、その限りではありません。
まぁ、世の中にない先進的なサービスってのは多くは、それを生み出す技術が根幹にあったりして、そういうのって提案側と構築側が一緒になってたりもするのですが、ボトルネックが発生する場所としては同じかもしれませんけど。
要は、こういった問題を解決するためのサービスを提供し、その仕様としてこういうシステムを作りたいってのがあった場合に、その要求を取りまとめる側の方が今や多くの時間がかかったりします。
これは、別に今に始まったことではありません。
ただ、昔のようにウォータフォールモデルのシステム開発手法を主としていた頃には、要件定義に多くの時間を割くものの、それが終わってしまえば後は製作をスケジュールどおりに進めていくというスタイルのため、要件定義の遅れは製作全体がシフトするということで済みましたが（プロジェクトとしては済みませんけど）、今や製作にかかる時間が短縮され、機能構築をスパイラルに進めていくようなやり方を取ることが多くなってきた中で、要求が出てこないというのは、個々の製作が始まっているため、問題が大きくなりがちです。
機能ごとに要件決めとその構築を短い期間でまわしていくことになると、そのイテレーションの中では、都度提案側から要求を貰うことになりますが、提案側から出てくる要求というのは、構築期間より長く時間がかかることが多くあります。
元々、要件定義自体は開発プロセスに関わらず多くの時間が費やされます。
要求そのものを取りまとめることになるので当然なのですが、開発プロセスの変化に要求をまとめるプロセスが追いつけてない事は多いのではないでしょうか。
この要求をまとめるプロセスというのは、業務プロセスをモデル化するということもそうですし、具体的にITを頼って何をしたいのかという目的設定もそうですし、じゃあそのシステムっていうのはどういったもので、誰がどんなシーンで利用するものなのかっていうのもそうです。
業務プロセスをモデル化するってのは、過大や要求からシステム部門が作業を請け負うことも出来るでしょうが、もっと根本的な目的設定とかどんなシステムやサービスを作りたいのかってイメージが頭の中に思い描けてなかったりするのは、開発プロセス上では結構大きな問題だったりします。
提案要求をまとめるときに気をつけたいこと
IT自体がコモディティ化した今は、それを取り扱う人は専門家だけではありません。
人事や総務などの管理部門にいる人や、そのサービスを望んでいるが技術には全く詳しくないという人まで、「こういったものを作りたい」という漠然としたイメージしか持ってない人が提案側のメンバーとして入っています。
提案書の中には、たどたどしい感じで画面設計や状態遷移や機能要件などが盛り込まれていますが、実際それを具体的に頭の中でイメージできているのは、あまりいないのではないでしょうか。
要は、実際に動かしてみないとわからない、という人が多いということです。
あとは、体制の話で「取り合えずチームで検討します」と言って決定までに1週間かかるとか。
こういった状況に追い込まれないためにも、提案側との要件決めには幾つか留意しておくことがあります。
・ 何を解決したい（作りたい）のかということを双方ちゃんと理解する
提案側から出された要求書は大体システムありきで書かれていて、それがなんの役に立つのかってことが頭の中から飛んでたりもします。
一昔前なら開発側で偏った思考によって起きる問題が今や提案側で起きてたりもします。
・ 最低限作りたいものは何なのかを理解しておく
提案側は、色んな機能を詰め込みたがりますが、それによって何時までもリリースできないプロジェクトを続けたり、時間がかかることで当初の目的がずれてくることもあるので、最低限何を実現してそのためにどんな機能が必要なのかをちゃんとヒアリングしておいた方がよいです。
もしそれが出来たなら、その時点で一旦リリースしてしまうということで、運用を開始することで得るものも数多くあったりします。
・ 提案された設計はゼロベースで考え直す
一旦向こうから提案された画面イメージとかは忘れて考え直すのも視野に入れてた方が良かったりします。
目的設定がずれていたら、何も解決しないシステムを作るだけになってしまいますので。
・ 共有イメージを持っておく
今や似たようなサービスというのは数多く存在するので、事前に「このサイトみたいなレイアウトですかね？」とか、この機能というのは「このサイトのこの部分のようなイメージですか？」ってことを共有しておくと楽になります。
・ なるべく早く動くものを共有しておく
提案側にある漠然としたイメージをより具体化するためにも、早めに動くものを見せておいた方がよいでしょう。
これは、裏側が張りぼての機能がない状態でも問題ありません。
気にされるのはだいたい画面上のUIであり、裏側の状態遷移やロジックというのは気にされません。（というか「そこは良いようにやってよ」ってまかせっきりになってたりもしますので）
・ 決定権を持つ人を巻き込んでおく
ボトルネックになるのが偉い人へのお伺いだったりするので、予めそういった決定権を持つ人も巻き込んでシステムレビューを進めた方が話が早かったりします。
仕様の決定、製作、確認（確定）と製作の過程で間に2つの確認事項が含まれるのでそれに割かれる時間というのは馬鹿になりません。
・ システム構築には時間がかかるという概念を払拭しておく
もちろん、全体を通しては長い時間がかかるプロジェクトにはなりますけど、先に書いたように機能一つ一つにかかる時間はそれほど多くはなくなってきています。
ボトルネックが提案側に移ってきているので、さっさと作って見せたところで仕様確認に時間がかかり、先に進めなくなる事態に陥ることも多々あります。
ある程度の目処を早めに伝え、提案側にタスク期限を明確にしておくことでボトルネックの解消につなげることもできるかもしれません。
まとめ
開発の主導者が変遷していく中で、それに適した開発プロセスというものも求められてきていますし、問題が発生するポイントも変化してきています。
サービスの構築は、システム担当者だけでということも行かない時代になってきていますし、それは別に面倒なことが増えたというよりは、より多くの可能性を広げているとも捉えられます。
ただ、構築が楽になったとは言っても話が二転三転されたりすると、納期だけでなく開発側にも大きなストレスとなりますので、提案側と構築側のギャップを埋めてうまく進めていく仕組みづくりというものにも気を使わないといけないと感じたりします。