エンジニア3年目「はじめての上流工程をやり抜くための本」を要約してみた
生成AIやAIエージェントの活用が広がる昨今、
ビジネス課題の真の解決には最新技術の導入に加えて、それに伴う「人」の関わり方や体制そのものの見直しが不可欠なのではないのかなと疑問に思ったところから、
2008年に書かれている「はじめての上流工程をやり抜くための本」を、現代の視点から読み解くことで、時代を超えて大切なことを考えて紹介していきたいと思います🤲
(要約なので、ここは重要だなと感じたポイントに絞って本記事に記載します。)
また、エンジニア3年目である私自身の視点から、当時の書籍が示唆することと、現在の業務で直面する現実との「視点の差」を交えながら、上流工程について書けたらと思います。
概要
まず本書はSIerの立場で記載されていますが、私のようなSaaSのエンジニアが自社のビジネスサイドと連携し、要求整理や要件定義、基本設計を進める上でも大いに役立つ一冊だと感じました。
内容は、上流工程として「業界動向」「組織」「人」「予算・投資」といった多角的な視点からシステム開発を捉える重要性に焦点を当てています。具体的な実例を交えながら解説されているため、読者は高い視座と多角的な視点を得られると思います。
本書は全3章で構成されていますが、特に第2章が内容の大部分を占めています。
そのため、本記事では、本題への導入となる第1章と、詳細な考察が展開される第2章に焦点を当てて解説していきます✍️
第1章 上流工程とは
この章では、漠然と使われることの多い「上流工程」という言葉をシステム化する際に対象の業務の仕組みを正確に捉えるということの重要性をもとに、どのような構成要素からなるのかを示しています。
業務の仕組みを知る
「上流工程」を担う上で、私たちはコンピュータの有無にとらわれず、その業務の仕組みを捉える必要があります。
本書は、この点を非常に具体的な例で示しています。
例えば、創業100年を超える老舗の生命保険会社では、その歴史の半分以上を人が中心となってシステムを運営してきました。つまり、コンピュータがなかった時代から「保険会社というシステム」は運用され続けており、請求受付、審査、契約といった各「業務」が連携して会社のシステムを成り立たせていたのです。「翔泳社出版、2008年第1版 23ページ」
私たちがその中のある業務を自動化する際、単にその部分だけを見るのではなく、業務フローの前後にある審査や契約といった関連「業務」全体を知る必要があります。
さらに、既に自動化されている部分と、まだ手動で運用されている部分、それぞれの詳細を把握しなければ、真に価値のある提案も、最適な設計もできないと本書は強く訴えかけています。
この点は、私自身の経験からも痛感するところでした。
過去に業務の一部自動化タスクを担当した際、ヒアリングを進めるうちに、自動化対象の前後にある業務まで考慮する必要が生じ、後から追加対応が発生してしまうケースがありました。
また、深く知ってみるとそこにペインがあって手動ではそんな工夫がされていたのかと気付けることも多くあり、やっぱり業務フローや業務全体を適切に理解することなしに、質の高い提案は不可能であると感じます。
ITがあってこその提案を
本書が強調しているのは、無理にITを適用したり、既存業務の一部を単に機械化したりするだけのシステムでは意味がないという点です。これは、現在の生成AIやAIエージェントを導入する際にも、同じことが当てはまると私は考えます。
システムやデータがバラバラのままAIを取り入れても、その能力を最大限に引き出すのは難しい。
だからこそ、私たちは「システム=業務の仕組み全体」として捉える視点が不可欠であり、
上流工程では、個々の業務や機能に囚われず、組織全体を俯瞰し、ITがもたらす真の価値とは何かを見極めて取り組むことが求められています。
第2章 新事業を描け
この章では、顧客や業務依頼者からの指示された範囲内での業務遂行やシステム化対応に留まらない、より広い視野を持つことの重要性が示されています。私たちは、表面的な要望に応えるだけでなく、真に解決すべき潜在的な問題や課題を発見し、それに対する具体的な解決策を積極的に提案することの重要性を学びます。
「業界動向」を押さえる
本書では、IT業界の動向に留まらず、システムを導入するユーザーが属する業界の動向を、産業経済新聞などから継続的にキャッチアップすることの重要性が述べられています。この取り組みは、ユーザーに対して最適なアドバイスや提案を行う上で不可欠な要素となります。
これは、まさに他部門とのやり取りにおいても、将来持ちかけられるであろう悩み事を事前に想定し、それに対して的確に受け答えができるよう準備しておくという点で、重要なスキルであると感じます。単に言われたことをこなすだけでなく、ユーザーのビジネス環境全体を理解し、一歩先を行く提案を行うための、戦略的な情報収集とproactiveな姿勢が求められているのではないでしょうか。
「システム」を押さえる
本書では、システム開発における「システム」の概念を、単なる機能の集合体としてではなく、その本質を深く掘り下げて理解する重要性を強調しています。具体的には、以下の視点が示唆されています。
- 要件の進化を織り込む: 現時点での要望がすべてではないと想定し、将来的に「やはりここまでの対応が必要だった」と追加要件が発生することを見越した柔軟な設計思想を持つこと。
-
業務とシステムの相互作用を徹底的に分析する: 組織内の業務プロセスと、それを支えるコンピュータシステムの機能間でどのように情報が連携しているかを、詳細に洗い出す。
- このプロセスにおいては、一見すると非効率に見える手作業が「意図的に残されている(わざと)」ものなのか、あるいは「現状の制約上、避けられない(仕方なく)」ものなのかを正確に識別することが極めて重要です。この見極めこそが、真の課題解決に繋がります。
コミュニケーションの姿勢
初回のミーティングで一度は必ず質問をすることの重要性を示しています。
これは「分からないことは聞く」というパターンに一度乗ってしまえば、その後質問がしやすい雰囲気のまま進められ、そのスタートが早いほど聞けることが多くなるため効率的と述べています。
ただし、私はここで一点、注意が必要だと考えます。質の低い質問ばかりでは信頼を得られないため、先にも述べた使用システムや業務内容の事前準備と、質問の綿密な想定が不可欠であると捉えました。
対応の選択肢を増やす
上述のコミュニケーション姿勢にも通じますが、本書では、相談やタスクを受けた際に、現在の業務やシステム機能面で「工夫された点」や「苦労したポイント」を深く聞くことの重要性が述べられています。
これは、相手の努力や課題への理解を示すことで、信頼関係が構築され、今後もより幅広い相談が持ち込まれやすくなるという利点があるからです。結果として、私たちエンジニアが問題を解決するための選択肢を増やし、より本質的な改善提案へと繋げられる、というものです。単に表面的な要望を聞くだけではない、戦略的なコミュニケーションの重要性を示唆していると言えるでしょう。
対応するかの判断軸
対応の選択肢が増えるほど、どのようにタスクを処理していくかが課題となります。
本書では、その判断基準として以下の表を提示しています。
判断要素:複雑 | 判断要素:単純 | |
---|---|---|
電子データ化の価値:大 | △:無理に対応しない | ◎:確実に対応 |
電子データ化の価値:小 | ×:対応しない | ⚪︎:できるだけ対応 |
表中の「判断要素」とはインプットをアウトプットに変換するまでに考慮しなければならない条件などと記載がされています。
これは定量的に判断できる要素が揃っているかという意味かと思います。
ここで注意点が一つ述べられていて、システム開発をしていたらどんな人でも1度は経験があるかもしれないのですが、検討初期に判断要素を口頭で列挙された際には「なんとかなりそう」と思っても、進めてみたら要求自体に矛盾があるという場合です。
このように、往々にして後回しにされがちな具体的で詳細な判断要素、すなわち『細かい話』を早期に顕在化させること。これこそが、上流工程における成功の鍵であると本書は強く訴えかけています。
期待と効果と費用
まだ同じ第2章なのですが、ここからは「予算や投資」という視点からのシステム開発を捉えることについて書かれています。
「数字」を念頭に
日々のタスクに追われる中で、予算や投資といった「数字」を意識することは、私だけではない(そう願いたい)難しさがあると感じています。
しかし本書では、システム開発費用への投資額、運用開始後のランニングコストやユーザーの人件費まで含めて、「どれだけの利益を手元に残せるのか」を検討し、提案することが期待されていると述べられています。
駆け出しのエンジニアとしては、ついつい目の前のタスクで手一杯になり、「数字」を気にしながら業務を進めるのは難しいと感じてしまうのが正直なところです。それでも、自分が組織や企業の中で年間どれくらいの価値を生み出せているのかを把握することの重要性は、今回の読書を通じて改めて認識しました。
年に数時間でもこうした「数字」を意識して考えるエンジニアと、何も考えないエンジニアとでは、将来的に大きな差が生まれるのかなあと思ったり思わなかったりしました。
期待と効果と費用
上記「数字」を具体的にどのように考えるのかをここで記載します。
まず、システム開発にかかる初期(投資)費用と、その後のランニングコストを明確にします。
次に、これらのコストに対して、構築するシステムが何年利用可能で、どれほどの投資額を回収できるのかを試算します。
当然ながら、できるだけ早く投資を回収でき、かつ長期にわたって利用できるシステムこそが「良い案件」と評価されます。
それを計算するには「正味現在価値(NPV)」が取り入れられることがあるようなので以下に載せてみました。
なぜ「現在の価値」に直す必要があるの?
「現在の価値」の計算方法(割引という考え方)
具体例から見てみる「正味現在価値(NPV)の計算」
割引率を決める代表的な3つの考え方
「経費削減」ではなく「事業価値の創造」
本書では上流工程を担当する際に、決まりきった要件、方式、予算枠の中で決まりきったシステムを構築することは求められておらず、私たちは企業や組織が抱える問題や課題をどのようにして解くかが重要と示されています。
「経費削減」ではなく「事業価値の創造」に着目して発想し、提案内容を検討・精査することと述べられていて、生成AIやAIエージェントの動向が著しい現代だからこそ、このようなスキルや考え方はより必要なものになってきているのではないかなと思いました。
さらに、私たちが構築しようとしているものが、どのような方法でどれだけの価値を生み出すのか、そして『いくらかかるか』よりも『どれだけ儲かるのか』という尺度でその価値を考え、提案する重要性が高まっていると言えるのかなと思いました。
さいごに
ここまで、「はじめての上流工程をやり抜くための本」を現代の視点、特に生成AIやAIエージェントが活躍する今の時代における「人」と「業務の仕組み」の再定義という切り口で読み解いてきました。
2008年という時代に書かれた本書には、「業務の仕組みを知る」「予算や投資の視点を持つ」「業界動向を把握する」といった、エンジニアとして、ひいてはビジネスパーソンとして不変的に大切な原則が詰まっていることを改めて痛感しました。同時に、LLMなどが普及する今だからこそ、これらの原則をより深く、戦略的に活用することで、単なるシステム導入を超えた「事業価値の創造」に貢献できると強く感じています。
駆け出しエンジニアである私にとって、目の前のタスクに追われがちな日々の中でも、本書が示すような視座の高さや、数字、そして人や組織全体を意識することの重要性は計り知れません。年単位で考えれば、こうした視点を持つか持たないかで、エンジニアとしての成長曲線は大きく変わるはずです。
この考察が、皆さんの上流工程への理解を深め、日々の業務に新たな視点をもたらす一助となれば幸いです😇
※ご購入はこちらから
Discussion