この記事は私が数年間アサインされていた、とあるモダナイズプロジェクトでの苦い経験とその教訓をまとめたものです。
以下のような案件に参画される可能性のある方が対象読者です。
1.基幹業務システムリニューアルなどの大型モダナイズ案件
2.ウォーターフォール開発(アジャイル開発ではあてはまらない部分があるかもしれません)
3.プロジェクトの予算制約が厳しい案件
では始めます。
私が参画した開発案件の概要
基幹システムのリニューアルプロジェクトに参画しました。
元々10数年使用しているシステムであり、ハードウェアやソフトウェアのサポート期間が終了しており、システムごとリニューアルしようという経緯から立ち上がったプロジェクトでした。また、現行業務では効率化できていない部分がありそれを解消することも目的の一つでした。
【代表的な使用技術】Java/SpringBoot/PostgreSQL/GitHub/
結果どうなったか
製造工程・結合テスト工程で当初の計画を大幅に見直さざるを得ない状況になりました。
製造工程、結合テスト工程に当初想定していた期間よりも非常に長い時間をかけてしまいました。
学び
このプロジェクトに参画した学びを2点書きます。
学び①業務フローを必ず作成し、それをメンバーやお客様と共有すること
1つ目ですが、業務フローの作成と共有を徹底すべきだったということです。
業務フローとは、業務の流れや手順を図形と矢印で視覚的に表現したもので、業務プロセスを「見える化」し、関係者間で全体像を共有するために作成されます。
☆業務フローの例(お客様の問い合わせ～受注～制作～納品まで)
私が参画したプロジェクトでは、この業務フローを企画の段階で作成したもののほぼブラッシュアップ・共有されることなくディレクトリの奥深くに眠ってしまっていたという状況でした。。。
企画の段階・要件定義の段階から業務フローを作成し、作成した業務フローを道標にどのような新しい業務フローにするべきか、どのような要件・設計とするべきかを開発メンバーやお客様としっかりと議論していく必要がありました。
業務フローの作成が重要な理由は以下の2点です。
- 理由①要件定義工程においてお客様と開発メンバーの業務認識の齟齬を防ぐため
要件定義工程ではお客様の要望から何を要件と見なすか、どこまでを開発案件の対象スコープとするかを関係者間で議論していくことになるかと思います。ウォータフォール開発では要件定義工程が唯一お客様と会話・議論できるタイミングであり(後工程でもお客様と話はできると思いますが、要件定義ほどではないでしょう)、ここを過ぎた状態の要件の変更、ミスは手戻りになってしまいます。故に正しく要件を定義できるかどうかがシステム開発プロジェクトの成功を握っていると言っても過言ではないです。世の中の炎上しているシステム開発プロジェクトの99%は要件定義工程に問題があるからだと私は考えます。
もし要件定義において開発メンバーが思い浮かべている業務の流れとお客様が思い浮かべている業務の流れが異なった状態で要件を決めてしまうと高い確率で後工程に影響が出ます。(実際に私が参画したプロジェクトも製造工程以降での手戻りやミスが非常に多かったです)基幹業務システムの開発の目的が現行業務の改善である以上、業務フローの作成はこの認識の相違という問題を一定解決します。
正しい業務フローの作成・共有が現行業務のお客様との認識の相違を防ぎ、それが要件定義工程の成功に関わり、引いてはそれが開発プロジェクトの成功に関わってくるのです。
- 理由②手戻りした場合の迅速な復帰を可能にするため
先述したように、開発プロジェクトの成功の鍵は正しい業務フローを作成し、関係者間で共有することですが、とはいえミスも出てくるでしょう。例え小さいシステム改修プロジェクトであっても手戻りはするものだと思います。実はこの時も業務フローが重要な役割を果たします。
例えば、テスト工程で要件定義からやり直さなくてはならないミスが発覚したとします。この時にも業務フローを確認することが重要です。要件定義からやり直さなくてはならなくなった→業務フロー上では変更箇所はどの部分に当たる？影響範囲はどこ？他システム連携の際の影響は？など、業務フローの作成がこれらを分かりやすく構造的に把握することに役立つのです。そうすると設計→製造→テストまでスムーズに流れるでしょう。一方で業務フローを作成・共有できていない場合は対応が場当たり的になりがちです。影響範囲の特定がうまくいかずに対応に時間がかかりすぎるなどの問題点が出てくるでしょう。
ウォータフォール開発においては工程の手戻りは基本的にNGですが、仮に手戻りしたとしても早めに戻ってくることができれば傷は浅く済みます。業務フローの作成・共有は手戻りからの迅速な復帰を可能にします。
以上、基幹業務システム開発における業務フロー図の作成の重要性について書いていきましたが、もう一点。
より解像度高くお客様業務を把握するという意味でエンジニア自身が是非現場にも行ってみて下さい。 業務フローを作成してから現場に行ってみると現場に対する理解度が進み、改善提案などもかなりしやすいかと思います。私も現場には行ったことはありますが、オフィスで仕事をしているだけでは分からないことが学べました。現場の状況によって訪問できるかどうかは変わると思いますが、現場を訪れることで新たな発見があるでしょう。
現場を知っているエンジニアほど強いエンジニアはいないと思います。
最後に業務フローに関する参考書籍を紹介します。
業務フロー図の書き方の書籍としてはこの書籍が良かったです。
また、ビジネスプロセス全体に対する理解・改善という意味ではこの書籍も良かったです。
学び②なるべく出社すること
私が参画したプロジェクトの上流工程(要件定義・設計)では多くのメンバーがテレワークを中心とした働き方(週1~2回程度の出社)をしていました。これは明確にミスだったと考えています。予算が潤沢にないモダナイズ開発においてはなるべく出社を中心とした働き方で開発をすべきです。理由を2点あげます。
- 理由①コミュニケーションスピードの向上
例えば私がここまで書いた上の文章↑はざっと20分程度の時間がかかりましたが、同じ内容を会話すると何分くらいでできるでしょうか？だいたい20~30秒くらいではないでしょうか？たった一つのトピックで60倍もの生産性の差(1200秒と20秒)が生まれるのです。これが積もり積もると信じられないほどの差になることは火を見るよりも明らかでしょう。お客様を交えた緊急時の要件の変更であればなおさらそうです。出社かテレワークかの議論はよくなされているかと思いますが、やはりオンラインではオフラインでのコミュニケーションのスピードには勝てないのです。
予算制約が厳しい(=スケジュールが厳しい)モダナイズ開発においては、メンバーができる限り物理的に一つの場所に集まりスピードが担保されたコミュニケーションを行うことこそが成功の鍵であると考えます。
- 理由②士気の向上
士気の向上というメリットも見逃せません。
テレワークをしている方はプライベート空間を兼ねているか仕事専用の空間であるかに関わらずご自身が用意した環境でメンバーと離れた空間で仕事をしていると思いますが、士気を上げるのは非常に難しいのではないでしょうか？プライベートの空間と仕事の空間が同一である場合はなおさらです。定量的なデータや理屈とかではないのですが、1ヶ所に集まって仕事をすることにより引き出されるパワーは信じられないものがあります。 実際私が参画したプロジェクトも製造工程の途中からメンバー全員出社中心の働き方に切り替わりましたが、モメンタムの高まりをかなり感じました。
大型プロジェクトではここが勝負所だというタイミングがきっとどこかで訪れるかと思います。その時だけでも物理的な空間を共にしているかどうかで結果は一気に変わってくるでしょう。
まとめ
まとめます。基幹業務システムの開発に最も必要なことは下記の2点です。
①業務フロー図の作成
理由1.要件定義工程の成功のため
理由2.ミスによる手戻りからの迅速な復帰を可能にするため
※そしてエンジニア自身が現場に赴き、一次情報を得るとよりよい
②なるべく出社すること
理由1.コミュニケーションスピードの担保のため
理由2.士気の向上のため
以上です。
この記事が皆さんの開発プロジェクトの成功に寄与することを祈っています。
株式会社TRAILBLAZER（トレブレ）様のコーポレートサイトは下記になります。
https://www.trail-blazer.co.jp/
株式会社TRAILBLAZER（トレブレ）様の採用サイトは下記になります。
https://recruit.trail-blazer.co.jp
JR西日本様のコーポレートサイトは下記になります。
https://www.westjr.co.jp/