上流工程を担当する時に気になる事を5つ並べてみた

本稿について

本稿は ミライトデザイン Advent Calendar 2023 の25日目の記事とります。

筆者は会社の代表でもありつつエンジニアでもあるので、業務内容は経営・営業・人事・管理・開発みたいな色々ごちゃまぜミックスなわけですが、その中でも開発分野に関しも大きく二つにわけると、

1. クライアントのシステム開発に関するサポートをコンサルとして参加させて頂く
2. 上流工程の実務担当として要求・要件の整理や定義を行う
3. 社内のプロジェクトでリソースが足りない時に開発者としてプログラムを書く

みたいな事をしています。

本稿では、この中の特に2を行う際にどんな事を気にしているとか意識しているとかを雑多につらつらとメモ書きの様に書いてみたいと思います。ホントにメモ書きみたいなものなのであしからず。
なぜメモ書きなのかと言えばアドカレのネタが何も浮かばなかった案外そういう情報も役にたつかもしれないと思いついたからです。
とりとめなく思いつくままに並べているだけですが、よろしければ最後までお付き合いください

上流工程をやる際に考えている事を雑多に並べていくよ（なんとなく順番に）

上流工程とは主に要求定義や要件定義、外部設計などを指して使われる言葉になります。
経験上、上流工程を担当すると言っても案件やクライアントの規模や体制によって具体的にやる事はまちまちな事が多い印象なので、正式な言葉の定義とは別にコンテキストにより若干ニュアンスが異なる気がします。

1. 背景が気になる

ここで言う背景はシステム化対象となる業務やシステムの背景の事ではありません。それはそれでこの後出てきます。
ここで言う背景とは、「この仕事（依頼）がなぜ自分に回ってきたのか？」という背景です。
社内システム開発であれば若干違うかもしれませんが、お仕事として依頼を受けるにあたっていくつかのパターンがあります。

1. そもそも開発部門が無いクライアントのシステム開発を依頼された場合
2. SIやその他窓口会社などの元請け会社が存在し協力会社として参画する場合

1の場合は当然上流から下流までクライアント以外が行うので案件を受けた時点で必然的に上流工程を担当する事になります。
2の場合は二通りにさらにわかれます。元請け会社のリソースが足りないケースかスキルや知識が足りないケースです。
リソースが足りないとは、案件規模が大きい場合や他案件でリソースが埋まっている事を指し、スキルや知識が足りないとは、上流経験が不安な人員しかいないか、案件特有の専門知識が足りない時などでしょうか。

気になる理由

まず背景を考える理由はなぜかというと、仕事を請けるか請けないかの判断したいからです。
上記で言うと、経験や知識が足りない場合の解決策として自分に話が来た場合（これが一番多い）その課題に対して自分が解決できそうか否かを判断します。請けたは良いけど自分には無理だった、とならないようにしたいですしね。特に今回のやりたい事に専門的な知識が必要な場合はその範囲をカバーしていけるかを慎重に検討します。

2. 体制が気になる

次に考えるのは案件体制についてです。これは様々な意味合いを含んでいるのですが、思いつく事をあげると

• 自分がどういう役割で動く事を望まれているか
• クライアントや元請け会社はどの位協力的だろうか
• 計画の柔軟性はどのくらいありそうか
• 予算はどこから出ているか

柔軟性とは納期やスケジュールが固定されているかどうかやリリースの順番などを指し、予算については予算捻出の仕組みを指します。

気になる理由

わかり辛いので一つ一つ分解して説明すると、

• まず自分に求められている役割が気になる理由としては、期待値のすり合わせです。例えば上流をメインで取り仕切った方が良いのか、他の方のサポートをした方が良いのかなどや、その期待値がこの案件を請ける上で適切か、などを明確にしたいからです。ここの期待値が合っていないと後々めんどうな事になるケースが多いです。恐いよね。

• 関係会社がどのくらい協力的かを気にする理由は、これはまああまり説明は不要かもしれませんが、関わる全ての会社や人が同じ方向を向いていない案件はたいがい燃えます。種火で済むこともあれば業火になる事もあるでしょうが、とにかく燃えます。ストレスもMAXになります。また、もう一つの視点としては意思決定者との距離も含まれてきます。担当が協力的でも意思決定者までの情報伝達が遠い場合、思うように進められないことが多いからです。

• 柔軟性を気にする理由は、上流から参画する以上、要求や要件をこれから整理していくという事です。つまり開始前時点でガチガチな計画立てようがないはずです。ですが、様々な事情や理由でローンチや納期の時期が固定されていたりする事があるので、その辺の不確実性をどのくらい認識しているかが重要だと思うからです。

• 予算についてもかなり重要ですよね。主に二つの事を気にしています。一つは案件規模感と予算感に大きなギャップがないか。上流開始前の段階ではお互いに正確な規模感ははかれませんが、「XXXXという事をやりたいので社内でこのくらいの予算を確保しています」みたいな場合に桁がそもそも足りてなさそうな時とか。多少低い程度なら低予算なりにどうできるかを提案したりできるのでなんとでもなるのですが、そもそもイメージしている桁が1つも2つも違う事が案外あったりするんですよね。あと、スタートアップ企業などで調達資金のみが予算捻出元になる案件はあくまで個人的にはですがかなり慎重になります。自己資金で予算確保できない以上方向転換がいつ行われるかわからない時期なのでリスクが高いと判断します。

と、ここだけでも長くなってしまいましたが、仮に同じ規模、同じ難易度、同じ予算、だったとしても案件の進めやすさは体制によって大きく変わります。ここで俗にいう「嫌な匂い」がする案件は極力請けないようにしています。逃げるは恥だが役に立つ

3. 情報が気になる

次は情報です。ここで言う情報とは与件書やRFPといったようなこの案件で何をしたいのか。何が目的なのか、といった情報から始まり、新規構築なのかリプレイスなのか。リプレイスだとしたら現行システムの仕様書などはあるか、といった情報となります。また、この辺りでようやく案件背景なども気になりだします。なぜこの案件が必要なのか、なぜ今なのか、といった事です。

気になる理由

実際に案件が動き出すと、まずは要求整理や要件定義といった工程に入っていきます。
我々はシステム開発を生業にしているいわゆるので当然システムに関してはプロとなりますが、クライアントの業務などについては基本的に素人です。もちろんこれまでの経験で対象の業務知識を持ち合わせている事は多々ありますが、どこまで言っても実務として持ち合わせている知識ではなく、また仮に類似の経験を持っていたとしてもそれぞれ固有の事情というのが必ず存在するものです。それらを理解する足掛かりとなる情報がどのくらい揃っているのかは重要なポイントの一つになります。

4. ビジネスが気になる

システムは当然ながら作ることが目的ではありません。使う事が目的です。
これから開発するシステムが、

1. どういう目的で
2. どういうタイミングで
3. どういう流れで
4. どういう人たちにより

使われるのかが気になります。それはシステム化対象範囲にとどまらずビジネス全体の中でどのような位置に属しているかも含めて把握しておきたい事です。

気になる理由

初期の要求や与件は時によって既にHOW形式でまとめられている事があります。しかし、このシステムを通してどういう目的を果たしたいのか、ビジネスの流れはどう変わるのか、効率化とはどの数値に現れるべきなのか、などWHATを理解する事でより適切なHOWを提案できるかもしれません。システム開発のプロとして参画する以上、与えられたHOWが適切であるかどうかを精査する所から始めなくてはいけません。

5. 業務が気になる

ビジネスの概要を理解した上で、次は実際の業務が気になります。業務と書いてはいますが業務システム以外であればそれに類するものです。部署やチーム、担当者など利用する人たちや機会、フローなどを把握します。業務フロー図などがあればそれを確認させて頂いたり、無ければ作成から始めます。

気になる理由

一つ前の項目の続きですが、そのビジネスはどういう人たちがどのようなフローで扱うのか。それを知る事で実際に使う事を前提としたシステム開発ができます。全体像が大きければ大きい程この辺りの理解が重要になってきます。上流段階から利用シーンを具体的にイメージする事ができれば、ただ機能として正しい動きをするのではなく、役にたつシステムを作るヒントになります。

まとめ

いかがでしたでしょうか。普段気にしている事をふわっと5つ並べてみました。
今回とりあげた気になる事を踏まえて要求整理や要件定義を実際に進めていくイメージです。

ぶっちゃけ上流工程に入る前の案件を請けるかどうかの判断をする所からなので、上流工程の気になる事ではない気もしますが、まあその辺は雰囲気でよしなに脳内修正してください。

ただ、これだけは確信をもって言えるのが、上流工程が失敗するとその後の巻き返しはかなりの労力が必要となります。端的に言えばけっこうな確率で燃えます。
逆に、上流さえしっかりしておけば、多少計画にずれが生じてもいくらでもリカバリーできたりするもんです。

そんな大事な上流工程ですが、見て来た限りで言うといまいち漠然としており、あまつさえただドキュメントを作ることが目的となっていたりする事もあります。

ですが、開発チームがどれだけ作る力を持っていたとしても、何を作ればよいかがわからなければ物は作れません。また作れたとしてもそれが本当に必要なものでなければ結局は意味がありません。

繰り返しになりますが、システムは作る為にあるのではなく使う為にある事を忘れてはいけません。
クライアントにとって価値があり、また、開発者にとってより良い開発体験ができるように、本当に役に立つより良いシステム開発をしていきたいですね。

最後に

本稿で今年の ミライトデザイン Advent Calendar 2023 も最終回となります。
社員が企画してくれた会社アドカレも今年で3回目。記事を投稿してくれたミライトメンバーや社外のみなさん本当にありがとうございました。唯一穴をあけたり変わったりしてもらってる張本人の自分が言うのはかなり憚られますが、こうやって皆で発表の機会をもって取り組む事は凄く価値がある事だなぁと感じています。
来年もアドカレに挑戦すると思いますのでまた来年も皆さんご参加ください。
本当にありがとうございました！ではでは。