仕様の決まらない開発をどうすべきか考える

プログラム開発業務をやっていると、最初から仕様が全く決まっておらず、やりたいことだけがフワッとしてあって、なかなか開発作業が進まない事があります。 仕様が決まらない原因の一つに仕様を決めるべき人がプロジェクトメンバー内にいない（厳密にいうと自覚がない）場合が多く、そのシワ寄せは開発員に向けられることが非常に多いのです。 開発員は、「言えば作ってくれる」と思われている風潮に苛立っているエンジニアも多いのですが、果たしてこうした開発プロジェクトはどのように乗り越えるのがベストなのかを考えてみましょう。

仕様はどうやって決まるのか？

そもそも、カッチリした仕様が最初から存在する開発に僕は個人的に出会ったことがありません。 （自分が携わったことが無いというだけです） 大手会社の開発に参加したことがある人であれば、非常に明確に仕様が決まっている事も多いかと思います。 ベンチャー企業において、特に新規開発を行う場合に、誰がどのように仕様を決めればいいかという問題もあります。 一般的に言えば、「ウォーターフォール開発」をする場合は、事前にしっかり仕様を決めて設計書を作っておく必要がありますが、多くの企業が「アジャイル開発」を行う必要があるという事も理解できます。 ウォーターフォール開発とアジャイル開発のどっちがいいかという議論はこの場では行いませんが、そもそもどちらに関しても、きちんと仕様を決めることは開発がスムーズに進むかどうかの分かれ道になります。 仕様を決めてもらうまで開発作業が進めないエンジニアよりは、仕様を決めて行くことができるエンジニアの方が誰もがハッピーになることが理解できれば、やはりここは、決まっていない仕様は開発サイドで決めて行くことが重要だと考えられます。 「仕様待ち」と待ち受け状態で踏ん反り返っているエンジニアは、ある意味仕事をしていない状態とも思えるので、こうしたエンジニアのいるプロジェクトは進行が遅くなる事は言うまでもないでしょう。

仕様の決まっていない開発のほうがやりやすい？

開発の種類にもよりますが、僕が個人的には仕様のかっちり決まっている開発よりは、仕様が決まっていない開発の方がはるかに開発効率が良いと言う経験上の感覚があります。 もちろん、ショートプロジェクトなどでは、仕様が決まっていた方が、即座に開発作業を終えることができるのですが、腰を据えて行う新規開発やデモやモックアップの開発（研究開発）などは、仕様が決まっていると、その仕様に対しての問題点検証などの作業を行わなければならないこともあり、非効率な場合の方が多いのです。 とある、モバイルWEBページの構築を請け負った時に、膨大なレギュレーションを最初に読破してそれに沿ったコーディングルールから、各種決め事、細かな表示規則なども含めて、非常に細かく記載されている仕様設計書をどっさりページ数あり、取り掛かるまでに数日有した上、仕様に問題がある場合に仕様変更を待たなければいけないという現場がありました。 こうした仕様を最初に切るタイプのプロジェクトリーダーは頭の固い系の人が多く、なかなか仕様変更をするという思考に至りません。 問題点をきちんと目で見て触れる状態にして初めて問題である事を認識する為、2週間ほどで終わるはずのプロジェクトが結局2ヶ月ぐらいかかったという経験もあります。 世の中には完璧な仕様書などはきっと存在することはなく、それを柔軟に変更してきちんとゴールにたどり着けることが、開発の何よりも目的であることを再認識させてくれました。

最終的に仕様が決まらない時の開発員のすべき事

仕様は開発員が決めて行く開発がいいと言う風に書きましたが、プロジェクトリーダーに仕様を決めてもらう必要はあるので、どうしてもUI/UXの話では、「あれがいい、これがいい」という話で時間を費やしてしまいがちです。 デザインコンペにおける３パターンの必要性と同じで、開発仕様に関しても２〜３パターンの仕様提案は必要な作業なのかもしれません。 これは、仕様を決める上で重要な要素で、１つの仕様に対しての「良い悪い」という判断よりは、要素の違う複数案で選択する方が人ははるかに想像力を持った判断ができるという心理学もあります。 これは、１方向での思考よりはベクトルの違う思考性から選択することで、洗濯後の納得感が増すという効果もあるためオススメです。 ただ、選択肢は多くなりすぎると人は拒否安納を示し始めるので、提案数は３パターンが適正なのだそうです。 そもそも開発受託を行なっている会社に開発を依頼された場合は、依頼する会社は開発業務に疎い為、プロにお願いしてくるケースがほとんどなのですが、こうした人に開発仕様を決めることはまず不可能でしょう。 どんだけ待っても仕様書などは出てこない現状に気付き、開発側からそうした作業も含めた開発を請け負うのが当たり前なのですが、どうやらこうした当たり前の作業も進められない開発員も少なくないようです。 これまで大手企業の開発員で作業をしてきたという人が、ある時フリーランスとして独立した際に、こういう待ち受け状態のエンジニアになってしまうことが多いようです。 何も染まっていないプロジェクトを自分色に染めて、それを成功させることができるエンジニアって素敵じゃないですか？