システム発注先との良好なコミュニケーションのために知っておきたい開発の流れとは

複数グラフのテキストを見ながらパソコン操作する人

更新日:2017年09月27日 | 公開日:2016年07月18日

この記事ではシステム開発の発注が初めて、もしくはあまり詳しくないという担当者の方のために、システム開発会社とのコミュニケーションをどうやって良好に保ったら良いかのノウハウを提供しています。

システム開発の発注の経験があったり、よりシステム開発会社との連携を密接に構築したいという方は、ぜひ「システム開発成功のポイントは発注者がシステム設計の最小限の理解を持つことだ!」もご参照ください。


1.既存の業務プロセスの問題を明らかにしてシステムを設計する

テキスト上でディスカッションするミニチュアの社員

このプロセスは開発側で「要件定義」と呼ばれます。
要件定義とは、開発側がクライアント側に何を作成することを求められているかを明らかにしてドキュメント化する作業になります。

ここでの主役は、発注先(開発会社)ではなくむしろ発注元(クライアント)です。
開発会社はシステム化の対象業務に含まれる業務機能を洗い出し、その業務機能同士の関連を「DFD(業務機能関連図)」や「業務フロー図」などに落とし込みますが、業務内容を正確に漏れなく伝える責任はクライアント側にあるからです。

業務フロー図の作成は、社内業務プロセスの改善などでも作成することが必要になる内部情報の整理作業でもありますので、ここで作り方のコツを整理しておきましょう。

【業務フローを作るためのコツ】
1. 何をきっかけにアクションが発生するのか開始条件を明確化する

まず最初に、該当業務がどんなアクションで引き起こされるのかに着目して整理しましょう。
例)
・クライアントから連絡が入る
・新規の注文メールが届く
・システムから緊急のアラートが届く
・月末を迎える/月初を迎える/週末を迎える/月曜日を迎える
などです

2. 流れを時系列に沿って明確化する

最初のアクションからのおおまかな流れを箇条書きにします。
例)
・クライアントから連絡が入る⇒担当者をピックアップする⇒担当者に要件をつなぐ
・新規の注文メールが届く⇒在庫を確認する⇒商品発想の手配をする
・システムから緊急のアラートが届く⇒アラート個所を確認する
・月末を迎える/月初を迎える/週末を迎える/月曜日を迎える⇒ルーティング作業にかかる
などです

3. 条件分岐を明確に記述する

業務の流れが分岐する場合は、その条件を明確にして複数のシナリオを作ります。
例)
・クライアントから連絡が入る⇒担当者をピックアップする⇒担当者に要件をつなぐ
・クライアントから連絡が入る⇒即答する

・新規の注文メールが届く⇒在庫を確認する⇒商品発想の手配をする
・新規の注文メールが届く⇒在庫を確認する⇒在庫がなければ確保の発注をする

・システムから緊急のアラートが届く⇒アラート個所を確認する
・システムから緊急のアラートが届く⇒担当外ならシステム管理者に連絡する

・月末を迎える/月初を迎える/週末を迎える/月曜日を迎える⇒ルーティング作業にかかる
・月末を迎える/月初を迎える/週末を迎える/月曜日を迎える⇒イレギュラー案件が発生した場合は緊急対処する

などです。

2.問題解決に役立つコンピュータシステムを共同チームで作る

右手を差し出す男性

このプロセスは開発側で「実装」と呼ばれます。

実装のプロセスに入ると、クライアントは待つだけかというと、決してそんなことはありません。
確かに以前は「ウォーターフォール型」といって開発工程をいくつかのフェーズ(局面)に分割し、前フェーズの成果物を次のフェーズに設計通り引き継ぎ、滝が上から下へと流れ落ちるように開発していくという手法が一般的でした。
この手法の場合には、業務プロセスを洗い出して開発側に伝えた後は、クライアントは製品が完成するのを待つだけというスタイルが普通でした。

しかし現在の開発手法はかなり変わってきています。
現在主流の開発手法は「アジャイル型」といって、顧客を巻き込みながらチームを組んでソフトウェアを完成させていきます。

この方法では、下記の流れに沿って開発を進めます。

1. クライアント側と開発側が少数精鋭の共同チームを作ります
2. だいたい2週間程度でできると思われる範囲に開発プロセスを区切ります
3. クライアントと開発側が共同でその範囲の要求の決定、実装、テスト、修正、リリースを行います
4. 改善点を次の工程にフィードバックします

この1~4の作業を繰り返すことで、市場環境の変化の早いWebシステムやアプリ開発などを成功させることができます。
いったん設計が決まった後、顧客が何も口を挟まない古いタイプの開発スタイルでは、市場の変化に迅速についていくことが困難だからです。

3.実際にシステムを導入して業務を改善していく

ノートパソコンやタブレット、地球儀、コーヒーカップ

このプロセスは開発側で「テスト」と呼ばれます。

システムを納品するにあたっては、最終的に各種テストを行います。
旧来はテストの分類として下記のような項目が上げられることが一般的でした。

■ 単体テスト
■ 結合テスト
■ 総合テスト、システムテスト
■ ユーザーテスト、運用テスト

このうち、「単体テスト」「結合テスト」「総合テスト、システムテスト」は開発側が行うもので、ユーザーが関わるテストは最後の「ユーザーテスト、運用テスト」になります。

アジャイル型で開発している場合には、途中途中でクライアント側も「単体テスト」「結合テスト」「総合テスト、システムテスト」に参加しているので、実質テストに関しても、クライアント側がすべてタッチしていることになります。

アジャイル型での「ユーザーテスト、運用テスト」はこれまでの確認という意味合いが強いので、「頼んだものとまったく違ったものが出来上がった!」などの大きなネガティブサプライズはほとんどありません。
しかし、開発任せにしていた場合にはこういう悲劇的な結末も起こりえますし、実際、大手企業同士でも大規模な訴訟問題に発展したりするケースも起こっています。

【まとめ】良好なコミュニケーションはシステム開発を進める上で重要です

開発者任せにしないで良好なコミュニケーションをとりつつシステム開発を進めることが、現在の開発スタイルの主流になっています。

日本最大級の発注業者比較サイト『アイミツ』ではシステム構築に関する専門知識を持ったコンシェルジュが、信頼のおける業者を完全無料で紹介することができます。

まずはお気軽にお問い合わせください。
すぐれたコンシェルジュが、あなたの会社に合った企業選びを全力でお手伝いさせていただきます。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
3万社以上が利用している無料の相談サービスです。

コンシェルジュ