仕様策定についての考察
弊社で新規機能の開発が行われていた際に以下のような問題が発生していた。
- デザイナーとエンジニアチームで仕様についての理解、認識がズレていた。
- デザイナーがビジネスチームに仕様を共有するフロー上、誤った認識で顧客に共有されていた。
1点目については、技術的に不明瞭な段階で、現時点で可能そうな仕様が共有された。 その後エンジニアチームで技術的に明確になった時点で当初共有されていた仕様ではなく、理想的な仕様で実装されていたものの、デザイナーチームには共有されていなかった。
2点目は1点目の認識の差異が原因となり、ビジネスチームに伝えた仕様と実際の仕様が異なっていたため、顧客に改めて最新の仕様を共有しなければいけない必要が生じた。
今回の背景としてはタスクフォースチームで緊急度が高く、納期が存在していたため発生したと思われるが、有事に限らず普段の開発フローにおいても明確化されたワークフローや意思決定プロセスを定義しておくことで、仕様の策定から実装、運用までの流れを加速させ、より密なコミュニケーションが可能になると考える。
そこでいくつか思考実験を行ってみる。
登場人物の紹介
- ビジネスチーム(顧客との対話、ビジネス影響の判断、機能の提案等を行う)
- デザインチーム(UI・UXの設計、機能の提案等を行う)
- エンジニアチーム(機能実装、障害対応、保守運用、機能の提案等を行う)
ある機能を開発するとき、上記の3チームが直接的に関わる。 そこには知識の壁が存在し、相互理解ができない可能性があると考える。(例: デザイナーはHTTPの仕組みを理解していない。)
そこでお互いの代表者がそれぞれ歩み寄り、両者の同意が得られるレベルまで仕様について議論する必要がある。
ビジネス上のインパクトが納得できる機能か? ユーザー体験やペルソナで想定されるストーリーは十分に納得ができるか? エンジニアリングにおいても十分に調査でき、実現可能性に見通しが立っているか?
代表者は各領域のエキスパートであり、この開発において最重要責任者であると考える。 例えば、当初の調査で十分だと思われていた要件定義が、実装段階において不十分であると分かった場合には、急ぎ3者を含んだ仕様策定会議を開き、修正を行う義務を持つ。
しかしながら上記の仕様策定において、いくつか課題がある。
外から見ればエンジニアは1チームのように見えるが、技術領域で分割すると大まかには以下の様に分けられる。
ここでは更に知識の壁が発生し、インフラストラクチャ、バックエンド、フロントエンドの順に壁が厚くなる。
エンジニアリング領域毎に、事業影響が異なるため、安易にリーダーを選出できない課題がある。
フロントエンドのエンジニアがインフラストラクチャやバックエンドの領域に関する仕様については基本的に責任を負える立場にないといった具合だ。
隅に追いやられたような形のフロントエンド領域だが、デザイン領域の意思決定にはフロントエンドのエキスパートがいなくてはならない明確な理由が存在する。
それは実装可能性の可否と、変更コストの判断である。デザイナーチームはプランを彼らにレビューしてもらうことで、そのプランが提案可能かどうかが判断できるようになる。
そこで、仕様策定におけるデザイン領域の決定は、フロントエンドとデザイナーのエキスパートの2名で意思決定を行うようにする。
このような関係性がインフラストラクチャとバックエンド領域でも起こり得る。
実現したい仕様によってはインフラストラクチャに影響を与え、その結果バックエンド(またフロントエンド)はその影響を踏まえた上での設計が必要となる。
インフラストラクチャへの影響は必ず起こるわけではないため、必要だと判断したときのみ仕様策定に関わってもらうようにするのが良いだろう。
今までの考察をまとめると下図のような関係になる。
フロントエンドはバックエンドとインフラストラクチャと完全に切り離すことができないため、デザイナーチームとの連携などやや関係するチームが多いものの、見た目や挙動の変更に大きなコストがかからないよう、基盤周りは整備しておきたい。
バックエンドとインフラストラクチャのリーダーは常に密なコミュニケーションを心がけ、インフラストラクチャのリーダーが仕様策定に参加しない場合においても、バックエンドにどのような変更が行われるのかは常に情報が更新されるようにしておくのが好ましい。
今回の登場人物にはいわゆるプロジェクトマネージャーといった人物は存在していない。今の予想では時間軸と意思決定プロセスの担保を行うことが考えられる。時間軸はいわゆる納期や回転率をマネジメントし、意思決定プロセスの担保は、結果的には正しい情報を元に関係者が動ける状態を維持する責務を指す。