小学生の頃、ガンダムが流行っていました。
見た目のカッコよさに加えて、細かいパーツを一つ一つ自分の手で組み上げていくことに惹かれて、ガンダムのプラモデル、通称ガンプラをいくつか作った記憶があります。
最初は手でパーツをもぎ取ったせいで美しく出来ず、次はニッパーとヤスリを買って挑んだものの完成後に色を塗ったために綺麗に仕上がらず、最後は色を塗ってから組み立てたのですが、手先の器用さと色塗りのセンスが足りず、ガンプラの箱に描かれている魅力的な姿とはほど遠い出来上がりにがっかりしたことを思い出します。
ガンプラのパッケージは、躍動感を感じる姿とカラーリングでとても格好良く、完成形をイメージしやすいように描かれています。作る際にパーツの組み方がわからず困ったり、色選びで迷ったりしたら、パッケージを見て確認していました。

さて、システム開発プロジェクトが炎上する要因の第三弾は、全体像です。
システム開発も、機能やプログラムという部品を組み合わせて完成させていきます。
プロジェクトに途中参画して、システム全体図がなかったり、機能一覧が陳腐化していたり、一覧と設計書が紐づいていなかったりすると愕然とします。ガンプラを作ろうとしても、箱も説明書もなければ、何を作るのか、どのように作ればよいか分かりません。システム開発において危険なのは、進捗遅延やバグの多さよりもシステム全体像が整理されていないことです。

システム全体を示すドキュメントとは

プラモデルに限らず家具でも何でも組み立て式のものには説明書が付いていて、その説明書は、完成図、部品一覧、組み立て手順の3つで構成されています。
システム開発で考えると、完成図はシステム全体図、部品一覧が機能一覧、組み立て手順は設計書に該当します。このうち完成イメージを示すシステム全体図と部品一覧に当たる機能一覧がシステム全体を示すドキュメントです。
組み立て式の家具でも説明書が分かりにくいと作るのが難しく、部品が足りなければイライラした気持ちになるのと同様に、システム開発でも、全体図が雑に描かれていたり機能一覧に漏れがあったりしたら、うまく作ることは困難です。

・システム全体図
完成イメージなので、全ての部品が漏れなく表現されていなくても構いませんが、コンポーネントがいくつあって、接続する周辺システムは何かなど構成要素と繋がりがわかることが重要です。そして、これはプラモデルのパッケージと同じように分かりやすく素敵に描かれていることが大切です。

・機能一覧
例えば、組み立て式の収納家具の部品一覧には、棚板、脚、ネジなどと部品が分類されています。その分類毎に棚板であれば天板、中板、底板、側板、脚であれば前脚、後ろ脚、キャスターなど、ネジも種類によって分けられ一覧化されています。
システム開発でも同様に、機能を画面、バッチ、IF、帳票などと分類して一覧化することが大切です。

なお基本設計書は、機能一覧の一機能に対してひとつ作成しますが、機能と設計書との紐付けが分からないと、機能一覧の意味が薄れてしまいます。基本設計書は、一つの機能をどう作るかを定義するものであり、機能の組み立て手順のようなものです。

なぜ、システム全体ドキュメントが重要か

システム全体を示すドキュメントがないことは論外です。
説明書がない中でモノ作りを進めていくことは、もはや芸術家の世界であり、これでうまくいくなら、それはアートです。
基本設計書が一つの機能について書かれるものなので、その元となる機能一覧は、基本設計の前工程であるシステム化要件定義で完成していないといけません。箱も説明書も部品一覧もないプラモデルの部品だけをもらっても完成させることが難しいのと同じように、システム開発の基本設計に入ってもシステム全体図と機能一覧がなければ炎上必至です。
逆に言うと、システム全体図と機能一覧さえあれば、多少スケジュールが雑でも管理プロセスが甘くてもモノ作りには入れます。

・機能一覧がない
部品一覧がないと、部品が足りるかわかりません。部品が足りないことに気が付くのは、組み立てていく途中です。システム開発では、結合テストや総合テストというプロジェクトの中盤以降の工程で気が付くことになるため、そのタイミングから部品を作りだしたら、納期に間に合わない可能性が高いです。

・システム全体図がない
完成図がなければ、積み木のようなもので、とりあえず部品は用意されているが、どういう姿で完成するかは人によって変わってしまいます。開発者の完成イメージの違いは必ず障害となって現れます。

炎上する理由のひとつに漏れがあります。システム全体図と機能一覧は、この漏れを排除することにも役立ちます。
機能一覧にIF機能があれば、システム全体図にも関連システムとの接続の線が引いてあるはずです。このように2つを照らし合わせることで漏れのチェックが出来るので、この2つのドキュメントはセットものと考えるべきです。これらは最後までずっと見られるドキュメントのため、常に最新化と整合性の確認が必要です。

システム全体図と機能一覧は、誰が作るべきか

システム全体図と機能一覧を誰が作るか、作れるかは、プロジェクトの成否に関わる重要な問題です。建築士と木工職人のスキルが違うように、システム開発でも全体設計と機能設計ではスキルが異なります。一機能の設計はSEあるいは開発者でも良いですが、システム全体の設計書となるシステム全体図と機能一覧は、プロジェクト責任者であるPMが作るべきだと考えます。
誰が見ても同じ完成形をイメージできるシステム全体図であるべきで、見る人によって解釈が変わったり、誤解を生んだりするようでは良くありません。分かりやすく素敵なシステム全体図を作れないということは完成形をイメージできていないということであり、そんな人にPMは務まりません。

複数製品をブレンドしたシステムの難しさ

ERPなどパッケージ製品は、完成形をイメージしやすく、機能も用意されているため、システム全体ドキュメントの重要性はそれほど高くありません。
ただし、複数の製品を組み合わせた構成とする場合には注意が必要です。
例えば、椅子を作る場合、木だけの椅子と脚が金属で座面が木で背もたれがレザーの椅子とでは、難易度が大きく異なります。木製の椅子は、木工職人だけで作れますが、異素材ミックスとなる後者の椅子では、木工職人の他に、金属加工職人やレザー加工技術者、さらにそれらを結合する接着技術に、それぞれの材料に合った塗装技術も必要となり、想定外の問題や脆さが発生することがあります。
システムでも同様で、いわゆるブレンデッドシステムと言われる複数の製品を組み合わせて全体を構成する場合には、連携部分や性能面でネガが出る可能性があるため、リスクを把握する意味でもシステム全体図と機能一覧が重要となります。

多少余談になりますが、パッケージ製品だけでなく、OSや開発言語、ミドルウェアも種類が多くなれば、それだけ必要な技術の種類が増えます。
技術の幅が広がると、それだけエンジニアも必要となるため、体制のレバレッジが効かせ辛くまってしまい、効率的な推進が難しくなります。本番化以降の運用を考えても、運用メンバーを多く抱えられる大規模システムなら良いですが、小規模な運用だと多様な技術を扱えるマルチスキルなエンジニアの確保が難しくなります。
結果として、運用費用が高くなるか、問題発生時に技術が足りずに解決まで長引くか、仮にマルチスキルのエンジニアを育てたとしても離脱リスクを抱えたまま運用し続けることになります。パッケージ製品を導入することはカスタムメイドに比べて簡単かもしれませんが、複数の製品や技術を組み合わせたシステムにはネガティブな要素があることを理解しておく必要はあります。

炎上診断チェックリスト（③全体像）

③－1．システム全体図
・システム全体図が作成されているか
・システム全体図の所在が全プロジェクトメンバーに認識されているか
③－2．システム全体図の各要素
・システム全体図に記載されている要素（システムかサーバーか、IFか疎通か、製品かモジュールか等）が統一されているか
③－3．一覧とのリファレンス
・システム全体図に記載されている要素が各一覧（機能一覧、ユーザー一覧、関連システム一覧、IF一覧、データエンティティ一覧）とリファレンスが取られているか
③－4．データフロー図
・データの流れを1枚で示したドキュメントが作成されているか（システム全体図上に示すことも可）
・移行データの有無が明示されているか

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！