top of page
失敗しないシステム開発の発注方法

依頼する内容を明確化することでトラブルを回避する

フォーマットにこだわる必要は無く詳細が提示できれば良い

アジャイル開発の解釈ですれ違いを避ける

依頼の明確化を考えてみた

 

「依頼する作業の明確化」をひとことで語るのは難しいと思います。

​そこで作業の明確化について詳細を記載してみました。費用に直結することになりますので発注者目線と受注者目線でわかりやすく書いています。

01

作業工程を理解する

03

追加費用を出さないために

02

アジャイル開発の勘違い

04

発注内容を明確化する

​発注前にだいじな2つのこと

01 作業工程を理解する

システム開発にはそれぞれフェーズが存在しており、フェーズごとに作業を進めることでトラブルを回避しながら開発期間に間に合うように開発を行います。そこでまず作業行為を書き出してみました。

​多少の前後はあるにせよおおまかな流れさえ理解していれば問題ありません。

01.

企画

​基本的に自社で行う作業です。構築するシステムが何のためにどのような機能をもって誰が使うかなどを洗い出します。

この時点で概算予算を決める場合もあります。

成果物​:

03.

外部設計(上流工程)

要件定義に沿って各機能をどのように実現するかを決めます。

見た目を決める作業で使い勝手に直結する作業です。

​自社で作成する場合もあれば、開発会社と一緒に作り上げることもあります。

成果物:画面構成(遷移)図、基本設計書

05.

構築/開発

上流工程で確定した仕様を実現させるため、決められた開発言語に沿ってプログラミング作業を行います。

​実現に関して仕様変更などが発生する場合もあります。

成果物:ソースコード

07.

結合テスト/総合テスト

全体を通してシステムが正常に稼働するかを確認するフェーズとなります。

​既存システムの改修などでは結合テストは自社で行う場合もあります。

成果物:結合テスト仕様書、エビデンス

02.

要件定義 (上流工程)

必要な機能を1つ1つ書き出し、ワークフローなどを決める作業となります。システムに詳しくない方でも作成することが出来ますから自社で行うことで工数を少なくすることが出来ます。

成果物:要件定義書

04.

内部設計(上流工程)

プログラムに関する設計となりますのでエンジニアが作成します。

システム開発会社がプログラム構築をするための設計書と考えてください。

業務システム部が自社で作成する場合もあります。

成果物:詳細設計書

06.

単体テスト

作成したプログラムが要件通りに稼働するかを確認するテストとなります。

​テスト仕様書を作成しチェック漏れが無いか確認しエビデンス(証跡)を残すところまでが一般的な作業です。

成果物:単体テスト仕様書、エビデンス

08.

リリース

発注者の最終検品作業が行われて問題ナシと判断されると、リリース予定日にあわせてシステムがリリースされます。

​納品書により作業が完了します。

成果物​:納品書

開発規模が300万円を超えるようなシステム開発ではこのような流れで開発工程がすすんでいきます。

ただし、100万円以下の構築や改修などの場合は成果物がソースコードだけの場合もあります。

​一概にシステム開発といってもその進め方は千差万別なところが担当者泣かせでもある所以です。

02 アジャイル開発の勘違い

 

昨今、「アジャイル開発」という言葉が大流行です。

しかしそれに伴うトラブルもまた大きな問題になっていると思っています。

​そもそもアジャイル開発とは何でしょうか?ちょっと説明してみます。

【アジャイル開発とは】

一般的に以下の流れを開発パートごとに繰り返して1つのシステムを組み上げていく手法です。

仕様→設計→構築→テスト

​1つ1つ順序立てて組み立てていく手法に対して機能ごとに上記を繰り返しながら構築することで仕様変更に俊敏に対応できるメリットがあり最終的に開発期間が短くなる(費用も安く抑えられる)開発手法

ただし、理想通りにうまくいったケースを私は知りません。なぜなら仕様変更に発注者側とシステム開発会社側で認識が合っていないことがほとんどだからです。

ここをしっかりと理解することでトラブル無く開発を進めることが出来ると思っています。

​以下に発注者側とシステム開発会社側での認識のズレを書き出してみました。

発注者目線

【1】各部署から、仕様書を確認後、機能追加の話が来るので開発会社にそのまま伝える。

【2】開発進捗から「それならこうしたい」をそのまま開発会社にぶつけてしまう。

【3】作ってる最中なら仕様変更も問題ないという認識で動いてしまう。

​【4】仕様変更が繰り返されても開発期間は長期化させない。

​【総括】

​アジャイルの本質は構築するシステムの要件が、しっかりと決まっていることが大前提です。

その上で各機能におけるちょっとした仕様変更という意味だと認識しています。

あれもこれも!だと工期だけが延びてしまい結果として開発期間が長期化した上、工数がかさんでしまい予算オーバーになってしまう危険性があります。

開発会社目線

【1】設計仕様が変更になるので要見積もりで再設計が必要となる。

【2】追加については理解しているが工期が延びてしまうので納期修正と再見積もり依頼が必要となる。

【3】変更内容と納期を考えれば増員の必要があり見積もりの再提出となる。

​【4】開発期間の延長とそれに伴うリソース確保による再見積もり。

【総括】

​作っている最中に変更することは全体仕様が確定していて工期、見積もりに影響ない範囲においてが大前提です。

工期や仕様自体に大きな変更がある場合は当初の見積もりでは対応できなくなってしまいます。

​当初受けた案件と仕様が変わってしまうのであれば再見積もりを出さざるを得ない。

03 追加費用をださないために

システム開発で一番トラブルになる点と言えばやはり追加費用の問題でしょう。

アジャイル開発が一般化すればするほどこの問題は頻発すると思っています。

その理由は前述した発注者側と開発会社側のスタンスの違いにあるからです。

ウォーターフォール型の開発では追加費用に関して大きなトラブルは発生しません。

なぜなら、最初に仕様を100%確定させるまで何度も揉みこむことで発注者側も開発会社側も認識が合っているからです。

アジャイルが一般化し、設計→構築→テストを繰り返した結果、開発時間が延びてしまい追加費用の嵐になってしまうことは絶対に避けたいところです。

成果物担保の無い契約形態で発注した場合によく起こる問題です。

ラボ型のオフショア開発は低コストを実現するにはとても良い手法です。

ただし残念ながらきれいにまとめられるだけの知識と経験が無ければ難しいのが実情だと思っています。

まず追加費用を出さないためにすべきことから説明します。​


確定した仕様は変更しない

時間の経過とともにいろんな担当者の目が入ることで仕様を変更したくなるのはシステム開発では当たり前のことです。

・何度も仕様書を見返していたら足りないものが見つかった

・意見の洗い出しが充分ではないため、後からあれもこれもといった意見が出てしまった

・時間の経過とともに、もっと良い方法があるんじゃないのか?といった気持になってしまった

・上司から驚くような仕様変更案が飛び出した

この辺りは発注者側で私が何度も経験したことで、追加費用にダイレクトに響くことが多かったので苦い思いとして記憶しています。

そこで担当者さんには是非、頭の片隅に置いておいていただきたいことがあります。

・外部設計はじっくりと作り込んだと思っても数日から3日間ほど寝かして改めて見返してみる。

・構築/開発が始まった後の機能変更、追加などについては事前に社内で追加見積になる可能性を協議し、その上で開発会社に確認を取る。

・バージョン1、バージョン2の概念を持つ。刈り取れなかった機能については仕様書にまとめてバージョン2として開発に区切りをつける。

はい、、、正直に言えば上司や関係部署に理解を得るのは難しいです。でも仕様変更や工期延長による追加費用の発生を防ぐことを何よりの命題として考えるならば必要なことです。

頭の中にあるだけで動き方が変わるのがポイントです。

そして、開発会社は常に工数で稼働していることを認識することが大切です。

開発会社側のスタンスを理解することで追加費用のトラブルは最小限に抑えることが出来ます。

そのような中が私が一番、気にしていたことがあります。最後にその一文を書いておきます。

アジャイルであろうと確定した設計はいじらない。

​04 発注内容を明確化する

発注内容を明確にすることは開発期間、見積もりに大きな影響を与えるので担当者として最大限考慮しなければならない点です。

発注内容を明確化するために気にすべきは以下だと思ってます。

■上流工程は自社で行うのか開発会社に頼むのか

​■外部設計はできるだけ細かく仕様を決めドキュメントにする

​■設計書としてではなくイメージ図でもよいので資料をつくる

■上流工程は自社で行うのか開発会社に頼むのか

 

要件定義と外部設計については自社で作成できるのであれば自社で作成しましょう。

特に300万以下の開発規模であれば要件定義もそこまで難しくは無く、外部設計(基本設計)もそれほど難しくはありません。

すこしとがった言い方をするならば、このくらいの規模であればエンジニアでなくとも設計書は書けます。

これまでに数例ほどシステム開発の現場に入ったことがあるならば充分に対応可能です。

その手間を惜しまなければ費用はその分、安く抑えることが出来ます。

ネットで調べれば基本設計の書き方や画面構成図(遷移図)などはテンプレートが落ちていたりしますからそこに書き込んでいけばよいのです。

発注する工程を明確にすることで開発会社の担当者さんも作業要件を把握できますから相見積もりの精度が高まります。

■外部設計はできるだけ細かく仕様を決めドキュメントにする

 

外部設計は慣れないと四苦八苦すると思いますがシンプルに考えればOKです。

大切なことはできるだけ細かく仕様を決めて言葉と図でドキュメントをまとめることが大切です。

言葉だけでは伝わりにくい部分は画面構成図や遷移図としてまとめることで目で見て理解してもらうことでイメージが伝わります。

正直なところめんどくさいですが、これがとても大事なことです。

例えば業務システムで名前の記入方法を考えてみてください。

名前の記入欄はテキストで入力するようにしますが予想変換などの機能を付けたいのであれば、その旨を記載します。(例:tanakaとうつとtanaka@example.comと予想変換してくれる)

または、決められた人だけであれば呼び出し範囲をグループ化し、プルダウン形式で呼び出すこともできます。もちろんフリーで記入するだけの方式でも良いと思います。

呼び出しをするのであれば従業員データが格納されているシステムと連動させる必要がありますから、システムの仕様を伝えなければなりません。(AzureActiveDirectoryのセキュリティグループと連携等)

名前に関する機能1つでもしっかりと説明しないといろんな仮説がでてしまい見解のズレが生じます。

しかし、言葉と図を作ることでかんたんに理解共有ができます。

そこで機能に対して体系立って考えてみると良いです。

・デーベースと連携させて従業員名簿を呼び出す

・予測変換機能で頭文字を入力することで格納されているデータを照合させる

​こうして1つ1つの機能をどのように実現するのかを考えて言葉にすることで開発会社が考えなければならない時間を少なくすることができますし、スムーズに内部設計に入ることが出来ます。

■設計書としてではなくイメージ図でもよいので資料をつくる

 

上流から開発会社と一緒にプロジェクトを遂行する場合でもやはり発注側でしっかりとしたイメージ図やかんたんな仕様まとめのドキュメントは作っておくべきです。

たとえば見た目についてはある程度、社内会議などでまとまっていると思います。

既存のシステムの改修であれば、使い勝手などや追加機能などから画面をどのように変更するかなど資料作りをしていると思います。

その資料などをもとに画面のイメージ図や1つ1つの機能がどのような見え方や動き方をするのかなどを書き出すだけで理解度が上がります。

たとえばお問合せフォームを作成すると仮定した場合ですが以下2つでどちらが開発会社にとって理解が早いかを考えてみましょう、かなりざっくりしてますが・・・

 1:お問合せフォームの作成。必要情報を入力したのち確認画面から送信するとサンクスページになる

 2:お問合せフォームの作成内容:フォーム、確認画面、サンクスページ、サンクスメール

   フォーム必要情報は以下

    名前(必須):テキスト最大100文字まで

    フリガナ:テキスト最大100文字まで

    電話番号(必須):「-」なしで受付、「-」がある場合はエラー

    メールアドレス(必須):「@」が無い場合はエラー

    問合せ内容(必須):5つの問合せをマルチチェックボックスで表示

    お問い合わせ詳細:テキストで最大1000文字

   サンクスメール送信者アドレスは「yyyy@example.com

   件名は「お問合せを受領しました┃〇〇〇

   言語:PHP

​   デザイン:弊社提供

かんたんな図があればなお良いと思います。

​結論になりますが、設計書というかしこまったドキュメントではなくてもイメージ図と作るべき機能の詳細を書いただけのエクセルで良いのでできるだけ細かく作ることが大切です。

bottom of page