1. 仕様書とは？
仕様書とは、ソフトウェアやアプリケーションの開発を行う際に必要となる、エンジニアへ示す説明書のことです。エンジニアは仕様書をもとに開発を進めていくため、システム開発には欠かせません。仕様書についての詳細を解説していきます。
1-1. どのような事を書くのか
仕様書には完成形となるものを記載します。例えば、「どのような機能を持たせるのか」「タップやクリックなどの操作で動きはどうなるのか」「アプリやホームページであればページ遷移の流れ」など必要となるものをすべて記載します。
そしてシステム開発の目的や、開発に至るまでの背景、いつまでに完成させるかの納期、どれくらいの予算を想定しているかなどを記載します。
1-2. いつ誰が作成するのか
仕様書は、基本的には開発を依頼した側である発注者が作成します。開発の依頼を受けた受注者がその仕様書をもとに内容などをヒアリングし、こまかなシステムの仕様や納期、予算などについて擦り合わせをしていくのです。
そのため発注する前段階で仕様書の作成をスタートし、社内で決定した要件を記載します。
誰が作成するのかという点に関しては会社によっても異なりますが、企画者やプロジェクトマネージャー、ディレクターが作成していくことが多いです。場合によっては、開発者側も仕様書の作成に加わるケースもあります。
1-3. 仕様書の必要理由とは
仕様書はプロジェクトの核になる存在です。仕様書をもとにプロジェクトの責任者であるプロジェクトマネージャーや、エンジニアが開発を進行していきます。
口頭だけの開発依頼では、発注者と開発者での乖離がでてくる可能性があるため、プロジェクトの成功は難しいでしょう。最悪の場合、予定していた仕様とはかけ離れた物が出来上がってしまい、プロジェクトが頓挫するということが発生してしまいます。
1-4. 設計書との違い
仕様書は完成形のあるべき姿を記した資料であるのに対して、設計書は開発の過程を記したものです。仕様書に記されている条件や内容を実現するために、どのような技術を使うのか、データベースの設計や外部システムの連携など詳細な方法について記載します。
専門的な知識を要するためエンジニアが作成することも多くあります。発注者側に専門知識のあるエンジニアがいない場合は、開発者側のエンジニアが作成しますが、発注者側も設計書の内容を把握して、仕様書の内容がきちんと反映されているか確認する必要があります。
2. オフショア開発の仕様書の書き方と注意点
仕様書には注意すべき書き方があります。オフショア開発ではコミュニケーションが難点という問題もあるため、より一層わかりやすい仕様書の存在が不可欠となります。仕様書の書き方において、注意すべき点を解説します。
2-1. 言葉の壁を意識する
オフショア開発には、大きな壁として言葉の違いがあります。日本人同士であれば、不明瞭な点があってもある程度は考慮してもらえるかもしれませんが、言葉の違う者同士となれば通用しません。
言葉の違いも文化も異なります。少しの表現の違いが大きな認識のずれを招く可能性があるため、5W1Hを意識し明確な内容にしましょう。
2-2. 漏れなく要件事項を書く
仕様書でエンジニアに「どのようにしてほしいのか」を明確に伝えることが大切です。仕様書の内容が不明瞭である場合には、中途半端な物が出来上がってしまうこと、機能が実装できないということが生じてしまいます。
その場合には、想定していた開発スケジュールに遅れが生じ、遅延した分の人件費なども大幅に増加してしまいます。不明瞭な仕様書は、開発において失敗を引き起こす大きな一因となります。
2-3. 図を使用した説明書にする
仕様書には、図を用いるのが効果的です。仕様書の内容がいくら正確であったとしても、理解するまでに時間がかかるとそれだけ工数も必要になり、開発者側の認識のずれも生じやすいです。
イメージやニュアンスは、人によって認識に微妙な差異があることが多く、それが仕様の理解のずれとなります。誰が見ても分かりやすい仕様書には、必ず図を用いて説明がなされています。
画面のレイアウト図や、遷移図など視覚的な情報が効果的です。完成形のイメージを図で共有できれば、意思や認識のずれをなくすことができます。
2-4. 仕様のポイントを細かく明記する
仕様書に、こだわりや重要なポイントを細かく明記することも必要です。開発者側は要点をつかみやすく、イメージを掘り下げて発注者側の意図や要求を理解しやすくなります。
理解が深まる利点として、開発段階で何かトラブルがあっても、最善の解決策を見出しやすくなります。柔軟に対応ができるため、結果的にスムーズな開発が可能になります。
2-5. 開発の目的を具体化する
仕様書には開発の目的も明記します。例えば、「ターゲット層である30代女性の利用者を増やしたい」「操作方法を分かりやすくしたい」など、現状の問題点や目標などを明記します。
開発者側も目的を理解することで、どのようなシステムを導入すればよいか、どこまでの開発が可能か、納期や予算の妥当性を明確に検討できるポイントとなります。双方のより深まった議論が可能になるのです。
2-6. 仕様の最終確認を入念にする
仕様書には誤りのないことが大前提です。オフショア開発の場合、もしも仕様書に変更が発生してしまうと、修正した内容を共有するためには難点があります。
言語の違いにより仕様書を翻訳する必要がある、時差があるため連絡の手間がかかる、曖昧な仕様書のままプロジェクトを進行し都度、仕様変更を行っていると大幅な納期遅延やコストオーバーを発生させる可能性があります。
また、仕様書の内容を変更した場合は、指示内容が伝わっているかのチェックも重要となります。また、仕様書の確認にはチェック体制を設けるなど、時間をかけて入念に行いましょう。
2-7. 依頼方法に注意する
仕様書の作成依頼は、発注者側が完成形を明確に想定していることが重要です。開発側の方が知見があるために全てをお任せで依頼してしまうケースがありますが、これではプロジェクトの背景や目的が共有され辛く、本当に良いものができる可能性が低くなります。
また発注者側が自身で、あるいは社内で完成形を明確化できていないために、完成品に対してイメージが違うということにつながりかねません。全てを丸投げする方法ではなく、発注者側が完成形を明確化させる必要があります。
3. オフショア開発の仕様書を書く際のポイント
オフショア開発において仕様書に関わるリスクは、上記の注意点を守ればある程度のリスクを回避できます。しかし想定外の問題も生じる可能性があるため、抑えておきたいポイントもあわせて解説します。
3-1. 技術者の認識不足に注意する
開発の成功には、開発者側がどれだけ仕様書を理解できているかが重要です。仕様書の完成度がいくら高くても、エンジニアやプログラマーが仕様書の内容を十分に理解できていないと意味がありません。
発注者側は、開発側がどのようなフローで作業工程を行い、どのように作業を分担しているかなど開発先のスタイルを把握しておくことも重要です。特に大きなプロジェクトで人材が多数必要な場合、エンジニアやプログラマーの入れ替わりが激しいことも珍しいことではありません。
そのような状況の場合、各々でプロジェクトへの認識や理解に差が生じる事が考えられます。仕様変更時やプロジェクト開始直後は特にコミュニケーションを密に行うことが重要となります。
3-2. 問題が起きた場合には原点回帰する
プロジェクトを進行しているとさまざまな問題に直面します。様々なリスクを想定しておくことが大切ですが、想定以上の問題が起こってしまうこともあります。納期に間に合わせるため、機能を削減しリリースを図ろうと考えるケースもあるかもしれません。
プロジェクトの目的はユーザーに対して機能を満たした物を提供することなのか、納期を優先することなのかを見極めなければなりません。問題が起きた場合には、原点に戻りベストな対策を考えましょう。
4. まとめ
仕様書とは、システム開発を行う上で必要となる説明書のことです。優良な仕様書には漏れがなく、誰が見ても分かりやすさがあります。
仕様書は、オフショア開発に限らずプロジェクト成功の鍵ですが、オフショア開発ならではのポイントもあります。
まずは仕様書をしっかりと理解してもらえる体制であるか見極めることが大切です。また、トラブル発生時にはそのプロジェクトの目的を見失わないような対策を行うことが大切です。
「オルグローラボ」では、ベトナムでのオフショア開発事業を行っています。オフショア開発では人件費のコストカットばかりに注目されがちですが、満足のいく成果物を仕上げられるスキルも求められます。
オルグローラボは、ベトナム現地の大学や企業とのパイプを活かした人材確保と、実践的なジョブトレーニングを行っており、高いコストパフォーマンスでのオフショア開発が実現できます。
