【バックエンドエンジニア編】要件定義のやり直しを防ぐ! 開発を遅延させる「外部システム接続」の落とし穴と3つの回避策

はじめに

「エンジニア」とひと口に言っても、ソフトウェア、フロントエンド、サーバーなど、その役割によって現場で直面するトラブルはさまざまです。
本連載では、PMO(Project Management Office)として多くの現場を経験してきた甲州が、それぞれのエンジニアが抱える課題の回避策を深掘りしていきます。

一般的に「バックエンド」という用語は、インフラ系(サーバー、ネットワーク、データベース)を含めて使われることも多いですが、今回ではWebエンジニアにおけるバックエンド(アプリケーション領域)に限定し、インフラエンジニアについてはまた別の回で紹介します。

バックエンドで処理する内容は、アプリケーションやシステムによって大きく異なり、プロジェクトによってそのカバー範囲はさまざまです。

サーバーサイドのロジックやシステムのアルゴリズム部分を構築するのがメインとなりますが、それと同じくらい重要になるのが

• 「外部システムから受け取ったデータをどう処理するか」
• 「処理したデータを外部システムにどのように渡すか」

という領域です。

大規模なプロジェクトになれば「インターフェースチーム」という専門組織が組成されますが、中小規模のプロジェクトではバックエンドチームが外部との接続部分まで一括して担当することがほとんどです。

そこで今回は、この外部システムとの接続やシステム間の連携といった「インターフェース部分」に焦点を当て、よくある失敗事例とそれを未然に防ぐ回避術を紹介します。

失敗事例1：接続先ベンダーへの
「依頼内容」を詳細に合意していなかった

外部接続先に別ベンダーが入っており、発注企業を経由してインターフェース部分のカスタマイズを行う必要があるプロジェクトでの話です。

接続先ベンダーと協議を開始し、打ち合わせを何回か重ね、互いに何をすべきかは理解し合って詳細内容への落とし込みも完了していました。

ところが、それから1か月ほど経ち、進捗確認のために外部接続先ベンダーへ「その後の状況はいかがでしょうか？」と連絡したときに問題が発覚します。

という驚きの回答が返ってきたのです。

私たちのプロジェクト側では、既に作業依頼は完了しており、先方で改修作業が進んでいるものと思い込んでいました。しかし会議の議事録を振り返ってみると、仕様は決定したものの「次の一手(誰がいつまでに発注手続きを行うか)」への言及がなされておらず、打ち合わせを実施しただけで満足して終わっていたのです。

「すでに着手してくれているものと思っていました……」と後悔しても時間は戻りません。

急いで発注手続きに必要な情報を用意して対応を進めましたが、結果的に1か月のスケジュール遅延を招くことになりました。

失敗事例2：接続先が大小100システムに
およぶプロジェクト

バックエンドチームが外部接続先のとりまとめも兼務する体制のプロジェクトでした。

要件定義工程において「接続先の洗い出し」は完了していたため、チームは「設計工程に入ってから各接続先と個別のやりとりを開始すれば問題ない」と計画していました。自システムの改修は最小限に抑え、外部接続先側のカスタマイズに期待する方針をとったのです。

しかし設計工程に入り、各システムの管理部署や管轄ベンダーとのすり合わせを開始すると、想定外の回答が次々と返ってきました。

また、同じ会社内にある別部署との調整でも、以下のような声が上がりました。

• 「現在使用している社内ツールは、過去にシステムに詳しい人が野良で作ったものをそのまま使っているので、改修は不可能です(そもそも仕様が分かる人がおらず、作った人は既に退職しています)」
• 「改修するのは良いですが、そのための費用はどこから出るんでしょうか？」
• 「今回のプロジェクトによって仕事の手順が変わるのは迷惑です」

話が順調に進んでいた接続先の中からも、調査を進めるうちに複雑な要件がいくつも浮上し、外部接続先同士の横串の調整が必要な内容まで発覚しました。複数の接続先と同時に話を進めていくうちに、問題は雪だるま式に大きくなっていったのです。

場当たり的な対応を中断し、一度状況を整理したところ、要件定義工程での洗い出しが表面的な一面に留まっており、現状調査(リサーチ)がほとんどできていないことが分かりました。

結果として「要件定義からやり直し」というレベルの致命的な手戻りが発生し、バックエンドチームのタスクは3〜4か月の遅延。総合テストへの合流が不可能となり、プロジェクト全体がリリース延期という結末を迎えることになりました。

PMOの視点で手戻りを防ぐ！
インターフェース管理3つの対策

前述の失敗事例を読んで、

「見積もりが甘かった。次からもっとバッファを取る」
「相手先の対応が悪いからどうしようもなかった」

と思っていませんか？ プロジェクトの振り返りではこのような対策や感想があげられることが多いです。

私の感覚では、バッファをいくらとっても同じ結果になったし、相手先の対応が悪いのも自分たちが原因ということが言えるプロジェクトがほとんどです。つまり、自分たちの対応を見直すことでいくらでも先程の失敗は回避できると考えます。

そして、これらの失敗例は、失敗例として振り返ってみれば「もっとこうしておけばよかった」ということが出てきますが、実際にプロジェクトを進めている当事者でも、その最中はほとんどの人が、こうなるとは思っていません。

実際に、私が要件定義やプロジェクト計画段階で何度忠告してもリーダーは聞く耳を持たないことも多くあります。聞く耳を持たないリーダーは、問題が起きてから対応することになります。

プロジェクト全体に影響を与えるほどの失敗はないかもしれませんが、この記事を読んでいるリーダーの皆様にも思い当たるフシがあれば、ぜひ自分事として活かしていただけると嬉しいです。

前述の内容と同じ失敗を繰り返さないために以下の3つの対策を紹介します。

事前調査の重要性を理解し
接続先一覧と詳細を把握すること

顧客から提示された説明資料や設計書だけを信じるのではなく、システムのログなどから実際の通信先を洗い出し、インターフェース一覧を作成するなどの網羅的な一覧を作成しましょう。

一覧が作成されたら、1社1社ヒアリングや打ち合わせを実施する前に「プロジェクトやシステムに関する情報共有と現状調査のお願い」と題して、プロジェクトの説明資料や質問票などを送付し、必要情報を収集しましょう。

当然ですが、自身の判断でいきなり連絡するのではなく、事前に説明する場や状況確認などの打ち合わせ設定が必要なケースもあるので、そのあたりも含めてお客様やPMと相談しながら進めましょう。

対応方針をあらかじめ定めてから詳細な調査に入る

ひと口に外部接続先と言っても様々です。自社の他部署(自分たちでシステムを持っている場合と外部に委託している場合)、外部システムベンダー、SaaSシステム、パッケージシステム、運用ベンダーなど、洗いだすとオーナーや管理主体がさまざまあります。

自プロジェクトで取り扱うシステムにもよりますが、接続先との対応方針を決めるときに「ヒアリングや調査してから対応を決める」という進め方ではなく、「自プロジェクトの方針を決定してから調査に入る」という流れを作りましょう。

「調査してみないと分からない」は詳細の技術的な内容に関してはその通りだと思いますが、計画段階や調査段階では、

という大まかな対応方針と理想の流れと、ダメだったときの流れの想定をしておきましょう。

対象となる接続先の把握とプロジェクトにおいて
実施すべきことが全体俯瞰できる管理表を用意する

外部接続先が少ない場合や、会社がいくつかに分かれていて個別に対応しなければならない場合は、それぞれの管理表や対応記録などを作成しがちです。手間はかかるかもしれませんが、全体が俯瞰できるプロジェクト用の管理表を作成することをおすすめします。

「考えるべき接続先はどのくらいあるのか？」という一覧に対して「特定の接続先はどこまで話が進んでいるのか？」というステータス、現在の検討状況や関連資料、仕様決定の成果物などの管理や調整すべき相手の連絡先窓口など、関連すべき情報を一元管理して、プロジェクトとしてやるべきことがどこまで進んでいるかを可視化できる管理表を作成しましょう。

そうすることで、問題に早く気づくことができ、対処も早くなります。中にはシステム対応が不要になったり、調査した結果全く対応が不要と分かるケースも出てくるので、その管理もできるようになります。

また、複数名で分担して作業をする場合に進捗確認や状況確認が容易になります。この管理票はPMやお客様への報告へも活用でき、報告資料を都度作る必要もなくなります。

おわりに

カバー領域が多いバックエンドエンジニアこそ、マネジメント視点を取り入れて自チームだけでなく外部もコントロールしてプロジェクトを進めましょう。

外部関係者が多いがゆえに「相手に振り回されて仕様変更が多くて困る」というトラブルは、多くの開発現場に存在します。しかし、今回紹介した回避策を取り入れることで、これまで後手に回っていた対応を先手必勝の形に変え、自分たちのペースでコントロールできるようになります。

特にバックエンドエンジニアは、外部接続先との調整やロジックの決定において仕様の荒波を最もダイレクトに受けるポジションです。だからこそ、コードを書く技術だけでなく、プロジェクト全体をハンドリングする「マネジメント視点」を取り入れることが最大の防御であり最大の武器になります。

バックエンドエンジニアの仕事は一見地味で、ユーザーからは見えないため、その苦労が周囲に理解されにくい大変な役割かもしれません。しかし、システムの骨組みを支え、外部とシステムを繋ぐハブ(架け橋)として機能できるのは、あなたたちバックエンドエンジニアだけです。

ぜひ今回のマネジメント視点を日々の業務に役立て、自チームだけでなくプロジェクト全体をコントロールする強力なリードエンジニアへとステップアップしていってください。