DX成功のカギは「エンジニアとの相互理解」- 上流工程を回すコツとは？

DX推進される企業様のご相談で増えてきたお悩みが、
「エンジニアとのコミュニケーション」です。

どんなに良いデジタル活用のアイディアでも、
実際に開発してくれるエンジニアに正しく伝わらなければ
プロジェクトを成功させる事は困難です。

具体的にはこういった問題が多いようです。

1. 外注ベンダーの納品物が当初のイメージと違った
2. どうやって要望を伝えれば良いのか分からない
3. エンジニアの言っている内容を理解できない

そこで本記事では、開発プロジェクトの流れに沿って
ビジネス・エンジニアが円滑にコミュニケーションする
相互理解のノウハウをお届けしていきます。

ビジネス・エンジニア間のコミュニケーションを理解するには、
まず開発プロジェクトの準備段階にあたる「上流工程」の把握が重要です。

上流工程の目的としては、
「企画するビジネス側」と「開発するエンジニア側」の共通認識を作る
ことを大前提に考えます。

そして、各関係者がバラバラに関わるのではなく、
ビジネス側はDXリーダーに当たるPM（プロジェクトマネージャー）が取りまとめ、
エンジニア側はSE（システムエンジニア）が取りまとめます。

上流工程は２つのフェーズに分ける事ができます。

ーーーーー
■要件定義：
プロジェクトのゴール設定、開発したいシステムの概要
（ビジネス側のDXリーダーが作成する）

■基本設計：
要件定義を実現するシステムはどんな風なのか、
画面構成・機能一覧など大まかな完成像をイメージできる資料
（エンジニアが作成する）
ーーーーー

しかし、2018年から続くAI・DXブーム以降、
上流工程をスキップして「とりあえずやってみよう！」の流れが強まりましたが
「プロジェクト成功率３０％未満」といった厳しい調査結果が出ています。

そこでセオリーに立ち返って、きちんと上流工程にあたる
「要件定義」「基本設計」に力を入れる企業が増えてきました。

要件定義のポイント

まず要件定義のポイントとしては、ビジネス側の要望である
「どんなシステムが欲しいのか？」をエンジニアに伝える事が最重要です。

そのためには、こういった問題背景が理解できる情報を盛り込みます。

1. プロジェクトの目的、解決したい課題
2. どんな機能が必要なのか？
3. いつ、誰が、何の目的でシステムを使うのか？

要件定義にもっとも多い失敗としては
「アイディア段階でエンジニアに丸投げ」してイメージと違うシステムが完成したり、
「要望をすべて記載」して予算オーバーするケースが挙げられます

基本設計のポイント

続いて基本設計のポイントとしては、
「エンジニアが何を作ろうとしているのか？」を理解する事が最重要です。

理由としては、どれだけ素晴らしい要件定義を作っても、
エンジニアが１００％正しく理解してくれる保証はないからです。

そこで、エンジニアがどれだけ要件定義を理解しているのか
正確に把握できる唯一の資料が基本設計です。

具体的には「画面設計」「機能設計」「データ設計」の３つを作ってもらい、
イメージした完成像と一致しているのか？をチェックします。

ここはシステム開発を企画した本人しかチェックできないため、
DXリーダーとしてプロジェクト成功のカギを握る重要なプロセスです。

そして、上流工程には沢山の山場があります。

それらの多くは「ビジネス側のDXリーダー」と「エンジニア」の立場の違いから来る
「良いシステムを判断する基準」の違いが原因にあります。

1. ビジネス目線の良いシステム：ユーザーにとって使いやすい
2. エンジニア目線の良いシステム：バグが起きない。メンテナンスしやすい

つまり、ビジネス目線で考えれば
ユーザーが喜ぶアイディアは開発中であっても盛り込みたいですし、

反対にエンジニア目線で考えれば、
開発中の追加・変更はバグの元になるので避けたいと感じるわけです。

こういった認識のズレを残したまま開発スタートしてしまうと、
後になって「言った言わないの問題」に発展してプロジェクトが円滑に進みません。

そのため、認識のズレを埋めるためのコミュニケーションが重要です。

ビジネス・エンジニア間の「共通目的」をつくる

ビジネス・エンジニア間の認識のズレを埋めるためには
両者が納得した「共通目的」を作る事がもっとも大切です。

つまり、「ユーザーにとっての使いやすさ, 課題の解決を優先したい」ビジネス意見と
「バグを少なく作りたい」エンジニア意見のバランスをどこに置くのか？を決めます。

その橋渡しとなる資料が要件定義・基本設計になってきます。

共通目的は「２W１H」のストーリーで書く

具体的にどうやって共通認識を作るのか、
そのポイントが「２W１H」のストーリーを描く事です。

まず、２Wに該当する要件定義としては
解決したい課題や目的など、開発プロジェクトの方向性を示すのが大事です。

結果として、無闇なシステム要件の追加・変更が起きないよう
ビジネス関係者の間でシステム完成イメージを明確に着地できます。

また逆に、エンジニア側と「解決すべき課題」を明確に共有できていれば
開発途中であっても「たしかに、この追加機能は必要だよね」といった具合に
きちんと根拠をもって追加・変更を相談できます。

そして、１Hに該当する基本設計としては、エンジニア側に
「どんなシステムを作るのか？」の完成イメージを描いてもらいます。

ここでは特に画面設計が重要です。
背景として、ビジネス側のDXリーダーはシステム企画に慣れてないケースが多く、
最初から１００％モレのない要件定義を作るのは困難です。

そこで、実際にユーザーが触るシステム画面を確認すれば
早い段階で要件の検討モレを発見する事ができます。

そのためには、最初の段階でエンジニア側に対して
「画面設計を見たタイミングで要件定義を再検討したい」旨を伝えておくと良いです。

以上がDX成功のカギである、
「エンジニアとの相互理解」をつくる上流工程のコツとなります。

まとめると、以下のようになります。

特に、ビジネス側のDXリーダーが「開発プロジェクトに慣れてない事」を
エンジニアにコミュニケーションしておき、事前に理解を得る事がとても大切です。

DXプロジェクトは誰もが最初は未経験なので、分からないのは当然です。
この記事が、そういった方々のお役に立つことを願っています。

以上、最後までお読みいただき誠にありがとうございました。