こんにちは。ウェブサービス本部の河野です。

ディレクターの業務の重要なものの一つに、仕様をまとめたりドキュメントを作る業務があります。限られた時間の中でシステムを開発しなければならない際に、どのようなドキュメントをどこまで作成するか悩むことも多いかと思います。

そこで今回はディレクターがドキュメントを作成する際の心がけやポイントについて考えてみたいと思います。

wireframe
(photo: Wireframes by INPIVIC)

1.ドキュメントを作ることが目的とならないようにする


当たり前のことですが、一番重要なのは進めているシステム開発が納期通りに不具合なくリリースできることです。仕様をメンバーに理解してもらうことが第一で、その手段としてドキュメントがあるという優先度を間違えないようにしましょう。

きちんとしたドキュメントの作成には時間が掛かり、変更時の更新にも同じく時間がかかります。また、更新をせず情報が古いままの場合、開発メンバーがそれを最新バージョンと勘違いするトラブルのリスクが出てきます。

スピード感が求められる開発の場合には、プロジェクトに関わるメンバーと常にコミュニケーションを取れるようにして、ドキュメントは必要最低限にとどめ、口頭やテキストチャットを多く使って進める方が無駄がなく良い場合もあります。

コミュニケーションの方法と特徴を以下の図にまとめてみました。口頭・チャット/ドキュメントの特徴を踏まえて、適切に使い分けましょう。

document_01_new

それでは、具体的にドキュメントにするかしないかの判断はどうしたらいいでしょうか。あくまでケースバイケースですが、以下の2つの軸で考えるようにしています。

共有したい情報の賞味期限 → 変更がない内容であるほど、ドキュメントにしておく価値が高まります
共有したい人数 → 多いほどリアルタイムコミュニケーションが難しくなってきますので、ドキュメントの方がいいでしょう

それでは、以下では実際にドキュメントを作る際のポイントを記していきます。

2.企画や要件の共有に重点をおく


企画から実装の手前までの開発工程を以下に抽出しました。

ecae2d0edb1fc505c255372d8c6ecfda

前半の企画、要件定義が「何を実現するか」のフェーズで、後半の設計でそれを「どのように実現するか」というフェーズになります。

仕様書を作る際に、ついわかりやすい画面遷移やUIなどユーザーの見た目の部分を先に進めてしまいがちですが、前半の企画や要件こそ一番重要なところです。

そして企画やコンセプトはサービスの根幹でもあり、ころころと変わるものではありません。サービス内容は営業/法務/経理/広報/CS(カスタマーサポート)/開発/デザイン/運用など様々な部門への共有が必要になる部分ですので、一番ドキュメント化しておいた方がいい部分だと思います。ターゲットや提供する機能、訴求などそのサイトやサービスで実現したいことを明文化しましょう。

3.想定しているシナリオ以外に目を向ける



典型的で望ましいシナリオを正常系というのに対して、それ以外の部分は準正常系や異常系と言われます。システムはあらゆる状況やパターンに対しても細かく動作を規定する必要がありますので、そのパターンとしては正常系よりもそれ以外の方が多いです。

また、その動作でシステムの質は左右されます。そこを意識して洗い出しておかないと、対応するエンジニアの負担が大きくなってしまいます。

例えば、
・ユーザーにして欲しくない操作をされたり
・予想以上のデータが送られてきたり
・想定していない順番での要求がきたり
・通信が途中で途絶えてしまったり
・連携先のシステムが応答しなかったり、または想定外のデータが返ってきたり
などです。

その部分についても予め、企画に沿った形で原則や方針を明確にしておいた方がスムーズに開発が進みます。また、実際問題として異常系の挙動は、想定外だけに最初から洗い出すのが難しい部分です。エンジニアと企画目的や方針がきちんと共有されていれば、エンジニア自身でもどのように処理すべきか判断できます。

2にも関連した話ですが、そのためにもサイトの企画・目的を最初にきちんと共有することが大切だと思います。

4.非機能要件に目を向ける



要件のうち、機能面以外のもの全般を非機能要件といいます。例えば、性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれます。機能と違って利用するユーザー側や画面などからは見えてきませんので、洗い出しにくい部分です。こちらも仕様書を作るにあたって見落とされがちなので、意識しましょう。

非機能要件で明確にしておきたい例を2つあげます。

1. 利用者数、アクセス数
規模やスケールによって、システムの作り方はかなり違ってきます。
・最初は少ない利用者でも、その後の伸びによっては、スケールする可能性がある場合
・普段はほとんどアクセスがないが、イベントなどで突発的に大量アクセスが来る場合
システムやサーバーはピークアクセスに耐えられるように設計/準備しておく必要がありますので、突発的にアクセスが集中するような事態が想定される場合は、 きちんとエンジニアに共有した方がよいでしょう。

2. データのリアルタイム性
アクセス数は同じであっても、提供するデータのリアルタイム性によってサーバーやシステムに求められる要求は全く違います。例えば、ランキングなどは定期バッチ集計にしても問題ない場合が多いですが、株価の場合はほぼリアルタイムでなければ意味がなかったりします。システムのリソースは有限ですので、利用シーンに合わせ最適化しておくべきです。

こちらに関連して弊社のインフラエンジニアが書いたとても良いエントリーがあるので、以下にご紹介します。

▼ディレクターやエンジニアが運用エンジニアにインフラの相談をする際に持って来て欲しい5つのこと
http://blog.nomadscafe.jp/2011/07/for-efficient-use-of-resources.html

最後に


仕様書というと非常に分厚く整備された文書を想像しがちですが、1つの図やデザイン、また1行の文であっても相手に伝われば全く構わないと思っています。

また、要件を漏れなく書くことは、非常に難しいことです。ドキュメントはあくまで共有するための手段ですので、作成に時間を掛けすぎず、打ち合わせ時の説明を支援するぐらいの位置づけでいるのがいいと思います。

そして、1度書いて終わりではなく、最初は粗くなってしまっても、よりメンバー間での理解を深めるために、内容の精度を上げていくことの方が大切だと思います。

NHN Japanでは、きれいなワイヤーフレームが書けるドキュメント作成も含めてサービス開発に最適なコミュニケーションができるディレクターを募集しております。