テックタッチではエンジニアが仕様書を作成

テックタッチでは仕様書のことを Product Wiki と呼んでいて社内で使っている Notion 上に記述しています。ここではユーザ目線で対象にしている機能がどのような期待結果をもたらすかについて記述していてエンジニア目線の内部の仕組みなどには触れません。入力項目を確定できない条件やエラーとなる条件なども説明しています。

テックタッチでは、開発している機能にもよりますが多くの場合エンジニア自身で Product Wiki (仕様書)をまとめることを実践しています。

エンジニア自身で仕様をまとめることで以下のメリットがあります。

課題を再認識することで、解決策の解像度が上がった状態で開発に取り組める
仕様をまとめることで、ユーザがその機能を使った際の体験を考えることに繋がる
後工程の設計や実装のことも考慮することで、ソフトウェアエンジニア力が鍛えられる

デメリットとしては、BizチームやPO(プロダクトオーナー)・デザイナーとの調整もエンジニアが進める必要があるという点が考えられますが、成熟したスクラムチームでのスプリントレビューなどでもらったフィードバックを元に改善する立ち回りと大きく変わらないと考えています。

一方で不確実性が大きいタスクについては、事前にPO中心に課題のヒアリングや解決策のブラッシュアップを通すことで、明確になった課題とある程度合意の取れた解決策を開発チームへの開発要望として受け渡しています。

仕様書を開発の中心に置くべき理由

テックタッチのアウトプットの流れは以下のようになっています。開発の流れ

仕様書が開発の中心になっていない開発というのは、開発する機能のUIデザインとタスクのチケットはあるが、機能全体の期待動作がまとめられていないような状態を想定しています。

仕様書 (Product Wiki)が開発の中心になっていることで以下のようなメリットがあると考えます。

開発内容の合意をするための資料として仕様書を使うことで、機能の価値の核となる部分や優先順位を判断できる
仕様がなければ何が正しいのか設計や実装レビューで判断できない
仕様書があればQA担当のメンバーにテスト設計書を作成してもらい、仕様の抜け漏れがチェックできる

Web系の開発だからといって要件定義・設計・実装・テストといったプロセスを省いていいというわけではなく、それぞれ重要な理由があって繋がりがあると考えます。

仕様をまとめる上で気をつけていること

課題・背景を理解する

今開発している機能は誰の何の課題を解決したいものなのか、背景・課題を深く理解しようとすることが重要です。社内ではBizチームの中でも特にユーザと話す機会の多いCSのメンバーにヒアリングを行う、顧客要望のあった機能ならどんなことをやりたいか直接意見を聞く場を設けてもらうといったことをやっています。

連絡係にならない

PO、デザイナー、CSといった他のメンバーの意見をまとめて判断を委ねるだけの仕事にしないことが重要です。開発者として自分の意思を持ってどうすべきか考えることを意識しましょう。ユーザのため、現状のアーキテクチャを考慮して、プロダクトが目指すビジョンを考慮して、など様々な観点から自分で判断する訓練になります。