仕様を決める経験値

仕事で新商品開発の作業をしていると、側でアイデアや方向性などを考える立場の人が、

「この商品の良いところと、あの商品の良いところだけをくっ付けて、新しい商品を作って・・・」

という依頼を次から次へと投げてくるケースが非常に多い。 新商品を作っているのだから当たり前である。 そして、アイデア出しの段階では、このぐらいのブレスト内容で十分だ。 だが、実際に開発が開始してある段階にこのレベルの要望を出していると、非常によろしくない。どちらかと言うと完成後に事故る確率が高い。

イノベーションは技術が先行するもの

ただ、現実として、技術がわからない人は、細かな仕組みの指示が初回から出来ない。 もちろん、基盤の選定も何の言語を使っていいかという事も出来ない。 ウォーターフォールであるならば、上記のような理由から上流工程において設計を行う人は絶対にエンジニアスキルを有していないといけないということになる。

イノベーションを大切にする為に

円滑な開発進行を考慮しつつ、要望を満たすために、以下のような工程管理を行う必要がある。

1. 機能一覧のドキュメントを作って 2. 画面遷移図を起こして 3. 簡単なモックアップを作って 4. 依頼主に確認してもらう

スピード重視の場合は、いきなり3番から行う事も少なくないが、1番の前に、研究開発が入る事も少なくない。 実は商品としては、この研究開発の部分が技術的には革新的なので技術イノベーティブ要素は、ここに集約されることになる。 でも、この商品全体が革新的な場合もあるので、売れるポイントなどを、ドキュメントでコンセプト図としておく方が、チームプレイとしては望ましい。 実際に開発に入る時に、確認パーツの仕様を、プログラマーが切って作っていくことが多いのだが、この細かな仕様を切るという作業が、非常に商品の価値を高めていることに気がついた。

実際に開発に入る時に

確認パーツの仕様を、プログラマーが作っていくことが多いのだが、この細かな仕様を切るという作業が、非常に商品の価値を高めていることに気がついた。 いわゆる、骨ですね。 この骨格が、商品全体のフォルムになり、しっかりしているほど、安定するわけです。

全体開発を見据える俯瞰思考

開発全体の骨格という物をちゃんと見えていない開発は意外と少なくないです。 コーディングしている開発者が、自分はどんなパーツを作っているか分からなかったり、 裏方のシステム構築をしている人が、そもそもの完成イメージが共有されていないというチームは意外とありがちです。 チームプレイを重要視する組織はサービスにおいても、その後の組織拡大においても、良い成績を発揮できるという事は誰が考えても分かりやすくて明確なのに、自裁の会社内組織はそうなっていない事が多いようです。 こうしたチーム俯瞰と同じく、商品開発全体も俯瞰してみて、「実際に使用するユーザー」「サポートをするメンバー」「バージョンアップのフェイズマップ」「競合他社ウォッチ」などをもれなく行えることが仕様策定において非常に重要という事ですね。 こうしたことを考えると、開発作業もお作法が大事という時代が到来しているのではないでしょうか？