ＩＴ相談役を始めてますが、そこで話題にあがるのがスクラッチ開発におけるホームページ制作業者やシステム開発業者とのやり取りです。
発注者にとって、今どういう状況にあるのか、依頼した事が伝わってその通り仕上げてくれるのか、不安になっているようです。
ウェブサイトやシステムの受託開発は一点モノで他にはありません。
出来上がらないと分からないというものですから、不安になるのも無理はありません。
ですから業者はその不安を解消する事が本来やるべきことの１つですが、困ったことに開発者の多くは「言われたことを作る」事に意識がいきがち。発注者とコミュニケーションをとる事を優先してくれません。
一方の発注者、不安を解消するために何かしているのかというと、必ずしもそうではないようです。
理由は色々あるでしょうが、
「開発者の邪魔をしてはいけない」「何を聞けばよいか分からない」「確認する事が多くて確認する事すら忘れている」「本業で忙しい」といったことを理由にしている方も少なからずいらっしゃいます。
ここでは、発注者と業者、それぞれが気を付けなければいけない事をお伝えしていき、いかにして開発を成功させるか、という事を開発プロセスとコミュニケーションという観点からお伝えしたいと思います。
開発プロセスを端的に表現するとこうなります。
「どのようにウェブサイト制作やシステム開発を進めていくか、一連の作業手順やルール」
開発プロセスにはいくつか方法、種類がありますが、だいたいどの開発プロセスにおいても基本となる考え方があります。
こちらの図は、「ウォーターフォールモデル」と「Ｖ字モデル」の組み合わせでで開発プロセスを表現したものです。
ウォーターフォールモデルというのは、水が上から下に流れていくように、順々に段階を経て進む事です。しっかりやることをやってから進みますからやる事は明確ですが、後戻りが難しい手法です。
Ｖ字モデルというのは、開発がどんどん深く進んでいく事に対し、テストはそこからＶ字で戻り、開発工程で行ったレベルのことをテスト工程で行う流れです。
順々に工程を進めるウォーターフォールモデル＋レベルに応じたテストを行うＶ字モデル。
これが開発プロセスにおける基本的な考え方になりますから、まずはこれを理解しましょう。
なお、当方が監修した記事も参考になると思いますのでご紹介いたします。
> システム開発ライフサイクルとは？開発の流れや開発モデルなども紹介
合わせてご覧いただくと理解が深まると思います。
一番最初は左上のシステム企画（経営戦略からシステム化をしよう、というところ）から始まります。
実際には開発業者に依頼する部分は「要件定義」からとなりますので、システム企画について当記事では扱いませんが、興味ある方はＩＴ相談役にお問い合わせください。
システム開発は、左半分の開発工程から始まります。
一番上の要件定義から始まり、外部設計→内部設計→プログラミングと進みます。
続いて、右半分のテスト工程に入ります。
一番下の単体テストから始まり、結合テスト→システムテスト→運用テストの順に進み、OKなら開発は完了です。
各工程でどのようなことを行っていくのか、順に説明いたします。
要件定義では、システムで実現したい業務や機能、それらの範囲、性能やセキュリティーといった非機能要件、開発の流れ人員といった実行計画、をそれぞれ具体的に定めていきます。
発注側が望むもの、目標とするものを具体的にする工程です。
厳密には、要件定義の前に「要求定義」という発注者が行う工程もあるわけですが、よほどしっかりした発注者じゃない限りここは行われませんので、たいていは「要件定義」の中で業者がヒアリングをしながらまとめていく、という事をします。
この工程で出来上がるものは「要件定義書」です。
例えば「システム概要・システム化の景目的といった業務要件」「必要な機能・画面構成・帳票・連携といった機能要件」「性能・セキュリティー・データ保全・可用性など非機能要件」です。
システムがどのような見た目、操作、動きになり、どのような情報を出し入れするのか。システムの外側、つまり人や外部システムとの接点を設計します。
要件定義書で提示されたことを元に、実際にシステムを構築するために必要な仕様を定める事です。
この工程で出来上がるものは「外部設計書」です。
例えば「システム方式設計」「ソフトウェア構成」「ネットワーク構成」「ハードウェア構成」「画面遷移」「画面レイアウト」「帳票レイアウト」「項目定義」「テーブル・ファイル定義」「バッチ処理設計」「外部システム連携」などです。
外部設計書を基に、実際にシステムが動作するようシステム内部の動作を定義します。
主にプログラマーがその内容に従いプログラムできるようにするために用いられます。
この工程で出来上がるものは「内部設計書」です。
例えば「データベース物理設計」「データフロー」「クラス図」「モジュール構造」「シーケンス図」「アクティビティ」などです。
内部設計書の内容に従い、実際にプログラミングを行います。
この工程で出来上がるものは「プログラム」です。
プログラム単体で期待された通り動作しているかどうかテストします。
この工程で出来上がるものは、試験結果と修正された「プログラム」です。
※試験計画書も場合によってここで作ります（プログラミング時に作るのがベスト）
作ったプログラムを結合させて内部設計通りに動作するかをテストします。
この工程で出来上がるものは、試験結果と修正された「プログラム」や「結合に使った仕組み」（プログラム、各種スクリプト、ツールへの登録、など）です。
※試験計画書も場合によってここで作ります（内部設計時に作るのがベスト）
作ったシステムが外部設計通りに動作するか、システムの外から動作させ実際に動作するかテストします。
この工程で出来上がるものは、試験結果と構築・修正された「システム」です。
※試験計画書も場合によってここで作ります（外部設計時に作るのがベスト）
要件定義で定められた内容であるかどうか、実際の運用に沿った形でテストします。
この工程で出来上がるものは、試験結果と構築・修正された「システム」です。
※試験計画書も場合によってここで作ります（要件定義時に作るのがベスト）
通常は手戻りなく行くよう、各工程でそれぞれ成果物として作るものを作り、レビューを行い、完成してから次の工程に進みます。
しかしすべてが順調に行くわけではありません。
もし何かしらの問題が発生して前工程に戻る場合は、当然ですがその分時間と費用を要する事になります。誰がその費用を負担するかは別の話なのでここでは語りませんが、発注者、業者それぞれがリスクを負う事になるので、各工程をしっかり取り組む必要があります。
前工程に戻るリスクはそれだけではありません。
先に決めていた仕様を変える、という事ですから、その修正に伴う他への影響も考慮しなければいけません。
仮に１か所だけ仕様変更しようと思っても、影響調査の結果１００か所変更が必要でした、というのはままあります。それだけの余計な修正が増えるのです。
従いまして、手戻りをいかにして無くすか、発注者と業者それぞれの目線や立場で、「こうしたらこうなるだろう、だからOK/NGだ」というのを見極める必要があります。
続いて、発注者と業者でそれぞれどのように役割を分担するのが良いのか、説明をしていきます。
発注者は「要件定義」で要望を提示し、業者が理解出来るよう主体となって取り組みます。
業者は「要件定義書」を作るお手伝いをしながら（現実はほぼ業者が作ります）、さらにそれをシステムの仕様というかたちで外部設計を行います。
発注者はその外部設計を見てOKかNGかを出します。
内部設計、プログラミング以降は業者が主に行う部分なので、発注者はあまりそれを目にする事はしませんが、必要かつ著作権の譲渡がなされているのであれば開示することもします。
出来上がったシステムは、発注者がしっかりと検査（検収）し、要件定義書、外部設計書の内容通りであればOKを出し納品物として受領する、という流れになります。
再度開発プロセスのイメージを載せます。
ここで赤の矢印に注目してください。これは発注者と業者の接点を示しています。
上の役割分担でも書きましたが、開発プロセスで発注者と業者が関わる工程は「要件定義」「外部設計」、そしてそれに対応する「システムテスト」「運用テスト」です。
開発工程であれば、この工程で出来あがった「要件定義書」と「外部設計書」がお互いの意思疎通を確認するものになります。
ここで意思疎通して出来上がったものが続く内部設計、プログラミング、単体テスト、結合テスト、という工程を経て「システム」になるわけです。
つまり、どういうシステムに仕上がるかは、「要件定義」「外部設計」次第、という事です。
このプロセスをおろそかにするとまず失敗しますよ、という事は明確だと思います。
では、いかにして「要件定義」「外部設計」を行うのか、発注者の立場で何を気を付ければよいのか挙げていきます。
設計書を出さない業者は論外‥と言いたいところですが、費用の関係でここを削られる事もあります。
また、アジャイルなど開発手法によっては無い方が良い場合もあります。
そういった例外はさておき、基本は業者が設計書を作って提出するものです。
提出しない場合、作らない場合はその理由を明示すべきです。
とはいえ、これだと業者次第です。
業者に期待して「いつか出すだろう」と考えては危険です。
発注者は、設計書をはじめとした成果物に何があるのか、それを業者選定の段階で知る必要があります。受注してからでは遅いです。しっかりと把握しましょう。
私個人の意見としても、設計書を作る事は業者にとって最低限の責務だと思っています。
とはいえ、発注者はシステムの専門家ではありません。
設計書にはある程度専門的な記述がありますから、理解できない点があるのは致し方無い部分もあります。
とはいえ、もし本当に理解できないのであればそれはシステムを発注する立場としてはいかがなものでしょう？
外部設計のところでも説明したとおり「システムがどのような見た目、操作、動きになり、どのような情報を出し入れするのか。システムの外側、つまり人や外部システムとの接点を設計する」と記載した通り、システムと人をつなぐ部分ですから、全く理解できない話ではありません。理解しないままシステムを使おうとしても、システムを使いこなせるわけがありません。
発注者は理解する試みを放棄してはいけません。
設計書を作る業者も、発注者の責任にしてはダメです。
発注者が設計書を理解できないのえあれば、それは設計書がダメと思った方がよいです。
発注者の理解が足りないのではなく、設計者の表現力に問題がある、と解釈してください。
お互いが相手のせいにするのではなく、各々が何とかして相手に歩み寄ろうという姿勢を作る事が大切なのです。
「実際にシステムを使ってみないと判断できない」という意見は多いです。
設計しているエンジニア本人ですら実際に動く姿を１００％理解できているわけではありませんから、その意見は同意できます。同意は出来ますが、努力はしましょう。
現実問題、こうしたい、というヒアリングをしていきなり動くものを作れるほど、世の中うまくは出来ていませんから。
もっとも、これらの問題を解決すべく、ローコード、ノーコードといったツールも登場してきています。代表例はMicrosoft Excelですね。これは本当に素晴らしいツールで、ちょっとした計算やフォーム程度であれば考えながら作り上げる事ができます。
システムのイメージがつかめていない、実際にそうしたシステムを運用して業務に活かす事ができるかどうかわからないのであれば、ローコード・ノーコードツールから始めてみてはいかがでしょう？
何事もそうですが、いきなり大きなことにチャレンジするのは大きなリスクを伴います。
小さく始めれば、とるリスクも最小限に抑えられますから、失敗を気にしなくなります。
要件定義や設計を重ねるうちに全然違う方向に進んできた、という話もたまにあります。
要件定義や外部設計の効果は「見える化」です。
漠然と頭に描いていたものを文書化すると細かいところが見えてきますし、頭の中でもシステムの具体的なイメージができるようになります。
その結果「もっとこうした方がよいのでは？」と違う方法も思いついたりします。
それ自体は問題ないのですが、問題は当初の目的と変わってきたという事。
その場合は「原点に立ち返りましょう」です。
要件定義書で決める事の一つに「システム概要・システム化の景目的といった業務要件」があります。
そう、目的が定められていますから、ここを見て「こうした方がよいのでは？」に合致するかどうかを常に見るようにしましょう。
本業で忙しくて、業者から提出された設計書や出来上がったシステムを見る暇がない。
という事は正直よくあります。
もちろん本業にはしっかり取り組んでいただきたいのですが、その先を目指してのシステム開発のはずです。本業で得た貴重な利益、又は先行投資して得た資金を、無駄にしてはいけません。
もちろん発注者はそんな勿体ない事をしたいわけではないです。
恐らくですが、想像以上にシステム開発に掛ける時間が多かった、というのが本音ではないでしょうか。
でもここまでの内容を見て頂くと漠然とでも分かっていただけると思うのですが。
システム開発は業者任せではうまくいく可能性は低くなります。
システム規模が大きくなればなるほどです。
ですので、システム開発を発注される場合は、そこにかける時間を発注側で十分作っていただく必要があります。
出来れば１名専任を、そうでなくても本業との兼任でよいので業者と十分なコミュニケーションをとれて、設計や検収に十分な時間をとるだけの人を確保していただきたいです。
もしかするとこの１点に尽きるかもしれません。
今まで上で挙げてきたポイントは、結局は期待したシステムを作り上げる事に尽きるわけです。
ただ、自分ひとりで作り上げるものではなく、業者に依頼して作るものですから、いかにして希望を伝えるかが肝要です。
その為に必要なのは、分からない事を質問して理解し納得する、納得しなかったらお互い納得するまで相手に伝える、というコミュニケーションです。
そのようなコミュニケーションを阻害するのは、冒頭に書いた「開発者の邪魔をしてはいけない」「何を聞けばよいか分からない」「確認する事が多くて確認する事すら忘れている」「本業で忙しい」といった声なのです。
そこでこの記事では、先ず発注者が知るべきことをお伝えしました。
そのうえで積極的なコミュニケーションをとる、という事を推奨したいのです。
開発者の邪魔にはなりません。開発者も良いものを作りたい、という思いは同じなのですが「これが正しい」という指針を発注者が言わないと開発者の想像する「正しい」で動いてしまいます。
ですから、どんどん意見を言ってほしいというのが開発者の立場なのです。
「何を聞けばよいか分からない」も聞けばよいのです。普通の開発者であれば喜んで答えてくれます。
「確認する事が多くて確認する事すら忘れている」は、どのように課題を管理するか、という話です。これについては「プロジェクト管理」、という開発プロセスをいかに円滑に進めるか、という話になりますので、別の機会にお伝えしたいと思いますが、ここも要は質問をすることですね。
理想は自己解決ですが、その前提となるシステム開発に関するノウハウを得るのは大変です。
ここではそのエッセンスとして最低限必要な事をお伝えしておりますが、個々の課題を解決していくには「発注者の立場」でＩＴ開発のプロフェッショナルの力を借りると良いです。
この記事を書くきっかけも、元はといえばシステム開発やウェブサイト制作を発注している企業様からの相談事に応えるためです。
困る前にまず相談いただくことで、問題を防ぐことが出来るかもしれません。
「サブスクＩＴ相談役サービス」というサービスを行っています。
初回相談は無料ですので、お気軽にお問い合わせいただけたら幸いです。
理念
私たちが開発したシステムやサービスを通じ、物心両面から豊かになってもらう。そして人生を楽しんでもらう。そこに私たちが存在する理由があります。
日々新たな製品・サービスを開発・ご提供し、最後まで誠意をもって取り組んで成果を出す。
ご縁を頂いた方やその先の人達に安心と満足をご提供出来る様、誠心誠意取り組んで参ります。
