TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

事業・業務・システムの3階層で要件を捉える

TRACERYプロダクトマネージャーの haru です。

要件定義では、事業要件、業務要件、システム要件の3層に要件を階層化し、事業戦略から業務運営、システム構築に至るまで整合性を保つことが不可欠です。

本記事では、事業要件、業務要件、システム要件の概要と、それらの整合性がもたらす効果について解説します。

事業、業務、システムの関係

組織の目的を実現するためには、事業、業務、システムがそれぞれの役割を果たし、連携する必要があります。以下に、それぞれの概要を示します。

  • 事業 組織が社会的または組織的な目的を達成するために継続的に行う活動全体
    • ECモール事業、資産運用事業、フードデリバリー事業など
  • 業務 事業を実現するために必要な現場での作業、オペレーション、運用
    • 商品販売、営業、マーケティング、商品管理、物流、カスタマーサポートなど
  • システム 業務を効率的かつ円滑に進めるためのITシステム*1
    • 商品販売システム、顧客管理システム、請求・売上管理システムなど

たとえば、国内でECサイトを通じて商品を販売していた企業が、海外市場への拡大を目指して越境EC事業を開始するとします。

この「事業」を成功させるためには、各国での適切な商品調達先を選定し、在庫を効率的に管理し、顧客に確実に商品を届けるための物流体制を整えることが必要です。これが、事業を支えるための具体的な「業務」の内容となります。

さらに、これらの「業務」を円滑に進めるためには、各国の在庫状況や物流の進捗をリアルタイムで把握し、柔軟に管理できる「システム」を導入することが重要です。

たとえば、在庫管理システムによって需給変動に対応した最適な在庫配置が可能になり、物流システムにより配送状況の一元管理が実現します。これにより、事業全体の効率化が進み、顧客へのサービス品質も向上します。

このように、事業・業務・システムが連携することで、越境EC事業の持続的な成長を支える基盤が形成されます。

事業、業務、システムの関係

上記の例のように、事業、業務、システムは、それぞれが目的達成に向けて、目的と手段の関係で連携しています。

事業は、組織が目的を達成するための活動全体を指し、その目的に沿って具体的な業務が現場で展開されます。

そして、これらの業務を支え、効率化と精度向上を図るための基盤として、システムが不可欠な役割を果たします。

事業要件、業務要件、システム要件の関係

事業、業務、システムが効果的に機能するために定義されるのが、『事業要件』『業務要件』『システム要件』です。以下にそれぞれの概要を示します。

  • 事業要件 事業で目指す目的のために、実現すべきと合意した事項
  • 業務要件 事業要件を達成するために、各業務プロセスで具体的に実現すべきと合意した事項
  • システム要件 業務要件を満たすために必要なシステムの機能、性能、運用条件などを定義し、実現すべきと合意した事項

たとえば、組織全体の目的として「スピーディーな意思決定」をするために「経営と現場の一体化」を実現することが事業部門の事業要件として掲げられたとします(下図)。

事業要件、業務要件、システム要件の関係

この事業要件を実現するために、物流部門では業務要件として「リアルタイムの在庫管理」を設定し、システム要件として「入出庫の自動ログ記録」を行う仕組みの構築を決定しました。これにより、常に正確な在庫状況を把握でき、経営判断を迅速に行うための基盤が整います。

また、営業部門では業務要件として「売上データの全社共有」、システム要件として「売上ダッシュボード」を開発することを決定しました。これにより、全社を横断した売上データの共有と分析が容易になり、経営と現場の連携が強化されます。

このように、各部門が事業要件に基づいた業務要件とシステム要件を設定し、具体的に業務を構築することで、組織全体として「スピーディーな意思決定」という目的に近づくことができます。

事業、業務、システムが有機的に連携することで、組織全体の目的を一貫性を持って効果的に達成できるようになります。

最後に

本記事では、事業要件、業務要件、システム要件の階層構造において整合性を保ち、事業・業務・システムが有機的に連携する重要性について解説しました。

事業・業務・システムが有機的に連携することで、事業目標から現場業務、システム構築までが一貫性をもって効果的に運営され、組織全体の成果に結びつきます。

そして、事業要件や業務要件に即したシステム要件を見極めることで、システムが組織の価値創出に貢献することが可能になります。

要件定義を行う際には、システム要件だけでなく、その背景にある業務要件や事業要件にも注目し、全体を俯瞰して確認しましょう。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:ここでのシステムは狭義の「システム」を表す。広義、狭義のシステムの定義についてはシステム開発におけるシステムとは何かを参照のこと。

「ビジネス+IT」に要件定義のインタビュー記事が掲載されました

TRACERYプロダクトマネージャーの haru です。

ビジネス+IT*1様にシステム開発の要件定義に関するインタビューを受け、その内容が前編・後編の2部構成で記事として公開されました。

www.sbbit.jp

www.sbbit.jp

インタビューの背景と目的

DX*2の進展により、企業は単なるデジタル化にとどまらず、事業活動全体をデジタル技術で変革しようとしています。これに伴い、システム開発は高度化・複雑化する一方、要件定義の不備が原因でプロジェクトが失敗するケースが増えています*3。さらに、アジャイル開発の普及により、「要件定義を省略してもよいのではないか」「実装してから直せばよいのではないか」といった意見も見受けられるようになりました。

そのような状況の中、ビジネス+ITの井内亨様から、私がWeb上に公開している資料*4をご覧いただいたことをきっかけに、システム開発の要件定義をテーマにインタビューのご依頼をいただきました。

記事の内容

記事は前編と後編に分かれており、目次は以下のとおりです。

前編

  • そもそも要件定義とは?
  • 再注目される「要件定義の重要性」
  • 修正コスト200倍…? 要件定義の失敗が招く「悲惨な末路」
  • 要件定義が失敗する「3つの原因」
  • 要件定義の「成功ポイント5点」
  • 要件定義を超・効率化させる「MVP開発」とは

後編

  • 「要件定義を無くす」ことは可能か?
  • 要件定義“不要論”を招く「アジャイル開発への誤解」
  • 「要件定義を無くす」と何が起きる?
  • 要件定義に必須の「3つのスキル」をチームで補え

詳細については、記事をご参照ください。

NewsPicks

NewsPicksでも取り上げられていました。コメントが参考になります。


今後も、トレラボを通じて要件定義を中心としたシステム開発のノウハウをわかりやすくお届けします。

「読者登録」をしていただくと、新着記事をいち早くチェックできるほか、最新の情報をキャッチできますので、ぜひご登録ください。また、X でも更新情報を発信していますので、フォローしていただければとおもいます。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:SBクリエイティブ株式会社が運営する、ITと経営の融合をテーマとしたメディア

*2:Digital Transformation(デジタルトランスフォーメーション)。企業が外部エコシステム(顧客、市場)の劇的な変化に対応しつつ、内部エコシステム(組織、文化、従業員)の変革を牽引しながら、第3のプラットフォーム(クラウド、モビリティ、ビッグデータ/アナリティクス、ソーシャル技術)を利用して、新しい製品やサービス、新しいビジネスモデルを通して、ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上の優位性を確立すること。

*3:日経XTechの調査では、開発プロジェクトの失敗理由の1位が「要件定義」であった。IPAの調査でも同様の結果が出ている(「ユーザのための要件定義ガイド第2版」P.23参照)。また、ビズリーチ社の2022、2023年のレジュメ検索トレンドでは、「要件定義」が上位に入っている。その背景には、DXを推進する中で要件定義が思うように進まず、要件定義のスキルを持つ人材が強く求められている現状がある。詳細は、トレラボ記事の要件定義の難しさの「開発プロジェクトが失敗する一番の理由と世の中で求められている人材」を参照のこと

*4:要件定義とはそもそも何か

重要なツールとして進化した、区切られた文脈〜「ドメイン駆動設計をはじめよう」翻訳者・レビュアー対談その4

TRACERYプロダクトマネージャーの haru です。

2024年8月29日(木)に開催された勉強会「BPStudy#204〜ドメイン駆動設計をはじめよう」では、書籍ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法(以降、LDDD*1)の翻訳者とレビュアーをお招きし、パネルディスカッションを実施しました。その時の様子をお伝えします。翻訳者とレビュアーの見解を通じて、書籍をより深く理解し、実践に役立つヒントを得られるでしょう。

パネルディスカッション参加者
  • パネラー
    • 増田 亨(ますだ とおる) 氏(翻訳者:以下、増田)
    • 綿引 琢磨(わたびき たくま) 氏(翻訳者:以下、綿引)
    • 佐藤 匡剛(さとう ただよし) 氏(レビュアー:以下、匡剛)
  • モデレータ
    • haru(本記事の執筆者)

区切られた文脈の設計のコツ

同じ言葉の一貫性に注目することで、その言葉が通用するもっとも広い範囲を特定できます。(p.44)

業務領域は「発見」であり、区切られた文脈は「設計」です。(p.49)

3章 事業活動の複雑さに立ち向かうより

haru:「区切られた文脈は設計なので、開発チームが決めて良い」と書籍には書かれています。業務領域と区切られた文脈の関係はどのように考えればよいでしょうか。区切られた文脈を設計するコツや考え方について教えてください。

匡剛:3章「事業活動の複雑さに立ち向かう」の「業務領域」、「区切られた文脈」、「同じ言葉」の3つの関係を理解することが、ドメイン駆動設計そのものを理解するうえで重要ですし、その点で3章をしっかり読み込むことが大事ですね。

区切られた文脈の設計の考え方として、3章で言われているのは「区切られた文脈の最大サイズの範囲を同じ言葉に注目することで発見できますよ」ということです。区切られた文脈の範囲をそれ以上大きくすると「同じ言葉」が破綻するような場合は、区切られた文脈の範囲をそれ以上大きくできませんということです。そして、それは開発チームの裁量で決定してよいということです。

さらに言っているのは、「区切られた文脈」は、チームのオーナーシップと関係していて、複数のチームで1つの「区切られた文脈」を担当してはいけないということです。チームの構成と「区切られた文脈」が対応しているという関係です。チーム設計、組織設計の話になります。一方で業務領域は、事業、業務そのものの中で決まっているもので、エンジニアがどうこうできるものではなく既にあるものという意味で「発見」なんですよね。どの業務領域をどのように分担するかを決めていくと、自然と「業務領域」と「区切られた文脈」の設計が決まってくると思います。

ドメイン駆動設計の重要なツールとして進化した「区切られた文脈」

増田:3章は明快に書かれていて参考になりますよね。匡剛さんの仰ったとおり、「区切られた文脈」は「同じ言葉」が通じる範囲であり、チームの単位であり、モデルの一貫性が維持できる範囲である、ということがくり返し説明されています。

同じ業務領域でも、担当者から見えるモデルと、管理者から見えるモデルは当然違っていて、別のアプリケーションになる可能性が充分あります。管理者用のアプリケーションをつくるチームと、担当者用のアプリケーションをつくるチームが別々に「区切られた文脈」で1つの「業務領域」を担当するということが可能性としてはあるわけです。

言葉が違って、チームが違って、モデルも違う。何のために区切るのかという「Why」と、何を手がかりとして区切るのかを考えるときに、「同じ言葉」「チーム」「モデル」で区切るんですよ、という「How」が、3章で説明されています。

逆に業務が複雑ではなくて、一貫性を持って取り扱えるのであれば、文脈を区切る必要は無いわけですね。なぜ文脈を区切るのかといえば、2つのチームが1つの文脈をごちゃごちゃやりだしたら混乱しますよねとか、同じ言葉が異なる意味になったら混乱するよねとか、ということです。

文脈の区切り方について、特に私が一番感銘を受けたのが「それ以上、範囲を大きくしたら破綻してしまうという範囲でまず区切って、知識が深まってきたら複雑さも見えてくるから、そこで必要だったらさらに区切っていきましょう」という段階的な文脈の区切り方の話が、非常に参考になりました。

haru:時間軸で考えるアプローチについては、LDDDの他の部分でもさまざまに述べられていますね。例えば、第10章「設計の経験則」や付録A「ドメイン駆動設計の実践:事例研究」などです。

増田:マイクロサービスの区切り方(14章「マイクロサービス」)もですね。「(以降、エヴァンス本*2)が出版された時代(2003年)から進んで、「区切られた文脈」は、もっと重要なツールとして、進化したというイメージがあります。

haru:第4章「区切られた文脈どうしの連係」では、区切られた文脈同士をどのように連係させるかについて、いくつかの図を用いて説明されています。

増田:第3章「事業活動の複雑さに立ち向かう」や第4章「区切られた文脈どうしの連係」では、従来のドメイン駆動設計の書籍では、説明が曖昧であったり、効果についての記述がなかった点が、LDDDでは明確かつ具体的に説明されています。

haru:区切られた文脈の設計がうまくいかないと、ドメイン駆動設計による開発も危なくなります。土台となる戦略的設計を開発チームのメンバーが理解して初めて、成功の可能性が高まると思います。

綿引:マイクロサービスであるかどうかに関わらず、「区切られた文脈」はソフトウェアのリリースやデプロイの単位と重なるという側面があります。

haru:一枚岩のシステムでは、あるチームがソフトウェアの最新版をデプロイすると、他のチームのソフトウェアにも影響を及ぼすリスクが高まりますからね。

増田「1つのチームが複数の文脈を扱っている場合、区切りがぼやけることがあるので注意が必要」とLDDDに書かれていて、これは重要だと思いました。文脈を区切ったつもりでも、複数の文脈を同じチームが担当すると、境界線が曖昧になり、次第に混ざってしまうことがあります。1つのチームが区切られた文脈を担当する際には、意識的に境界を明確にするように心がけるべきだと書かれていて、なるほどと感じました。

haru:そこは、区切られた文脈についての正しい理解と、明確に分けるという意志がないと、次第に混ざってしまう力が働きますね。

増田:よしなにつなげてしまうというかね。

綿引:これでいけるじゃんみたいな。

haru:その逆のアンチパターンとして「分散した泥団子*3」というのも書かれていますよね(14章「マイクロサービス」)

増田:本当に実践的ですよね。

訳者とレビュアーから最後にひとこと

haru:あっという間に終わりの時間になりました。みなさん最後にひとことずつ頂けますか。

増田:このメンバーで話せて楽しかったです。気づきがありました。綿引さんに(イベントの第2部で「ドメイン駆動設計のコミュニティで現在活発なコミュニティが無さそう」と)煽られた*4ので、勉強会の方も考えて企画したいと思います。輪読会するとか。コミュニティ重要ですね。

綿引:増田さんが書籍についてはしっかり説明してくれる*5とおもったんで、私はLTライクに話しました*6

haru:綿引さんの話は、久々に「エンジニアとは」というテーマで良い話を聞いたなと思いました。

綿引:今回の翻訳は、良い機会をいただけたなという感想です。翻訳後にイベントを開催してもらったりもですね。また機会があればいろいろやってみたいとおもいます。

haru:BPStudyも2回目の登壇ありがとうございます。

匡剛:出版されてから訳者のお2人と話す機会がなかったので良かったなと思います。

haruXでの方が活発なんですかね(笑)

増田:打ち上げもやりましょう(笑)

匡剛:この書籍は戦略的設計のところから入っているので、区切られた文脈やその関係などについて、ネット上などで議論されると良いかなと思っています。

haru:本日は登壇いただきありがとうございました。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:原書のタイトルは "Learning Domain-Driven Design"

*2:エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう。ドメイン駆動設計の原典として広く認知されている。

*3:文脈を小さく区切りすぎてしまい、保守や開発のコストしにくくなる現象

*4:イベントの第2部の登壇資料:ドメイン駆動設計を実践するために必要なもの

*5:イベントの第2部の登壇資料:『ドメイン駆動設計をはじめよう』中核の業務領域

*6:イベントの第2部の登壇資料:ドメイン駆動設計を実践するために必要なもの

要件定義の重要ポイント〜要望・要求・要件を見極める

TRACERYプロダクトマネージャーのharuです。

システム開発チームのメンバーとして、ユーザーから「この機能が欲しい」と依頼されたとき、どのように対応しますか。

このような場合に役立つのが、依頼された内容を要望、要求、要件に明確に分類する考え方です。

本記事では、依頼された内容を要望、要求、要件に分類し、要件を導き出す方法について説明します。

要件定義の目的とゴールについては、以下の記事を参照してください。

tracery.jp

要望、要求、要件の3段階で考える

開発の依頼内容は、以下のように要望、要求、要件の3つに分けて考えると整理しやすくなります。

要望、要求、要件の3段階で整理する

要望

要望は、クライアントやステークホルダーからの初期の希望やアイデアです。ニーズともいいます。この段階では、技術的な制約を考えずに、望むことを自由に出してもらいます。例えば、「アプリの使い勝手を改善してほしい」という抽象的な内容の場合もありますし、「月次売上データをグラフで出力したい」という具体的な内容の場合もあります。

要求

要望を取捨選択し、整理、構造化したものが要求です。例えば、「ユーザーが少ないクリックで購入できるようにしたい」という具体的な内容です。

要件

最終的に、要求を取捨選択し、実現対象として合意したものが要件となります。クライアントやステークホルダー全員が同じ理解を持つことが重要です。要件は明確で実現可能でなければなりません。例えば、「ナビゲーションメニューを再設計し、3回以内のクリックでユーザーが購入できるようにする」といった具体的な内容が望ましいです。

要望、要求、要件の3つの段階を経ることで、ユーザーのニーズへの解像度を高め、費用対効果の高いシステム開発が可能になります。

要望、要求、要件の例

要望、要求、要件の具体的な内容について例をもとに説明します。

システム開発全体との関係を示すために、後述の図内では、Why、What、How、Makeとのマッピングも記載しています。

  • Why 『なぜそのシステムを作るのか』という目的
  • What 『何を作るのか』
  • How 『どのように作るのか』
  • Make『実際に作る』

詳細は以下の記事を参照してください。

tracery.jp

要望の発生

現場担当者から「月次売上データをグラフで出力したい」という話を聞いたとします。この時点では開発するかどうかは決まっていません。開発者は「要望」としてリストアップしておきます。

要望の発生

要望をうけてすぐに開発するリスク

要望に対してすぐに設計や実装に取り掛かるのは、適切ではありません。

まず、グラフを画面上に出力することが本当に費用対効果が高いかを検討する必要があります。実際、グラフの実装には多くの開発工数がかかり、後になって「工数が掛かりすぎた」となることがよくあります。

また、現場担当者の要望をそのまま実現しても、担当者の誤解により、開発した機能が事業やユーザーの価値につながらず「結局使われなかった」となってしまうこともあります。要望の本質を理解し、必要性を慎重に検討することが重要です。

要望をうけてすぐに開発するリスク

背景、目的の確認

要望を聞いたら、まず、要望の背景や目的を確認します。

月次売上のグラフを「いつ」「誰が」「何のために」「どれくらい」使うのかなど*1を、現場担当者に詳細にヒアリングします。これらのことを「ユースケース(システムの使用事例)」といいます。

具体的な機能の要望を受け取ったら「ユースケースはなにか」と考える習慣を持つとよいでしょう。

確認したところ、月に一度、経営者に売上を報告する際に月次売上のグラフが必要であることがわかりました。

さらに、売上報告の目的を尋ねると、会社では経営層と現場の認識の乖離が問題となっており、「経営と現場の一体化」を進めるための取り組みの一環であり、実現できればスピーディーな意思決定ができるという価値が生まれることがわかりました。

ユースケースを確認した後は、さらに深堀りして「その機能によって解決される問題や生まれる価値はなにか」を考えるとよいでしょう。

背景、目的の確認

目的を実現するための手段の再検討(要求の完成)

目的が明らかになったら、その目的を実現するための手段をあらためて検討します。

グラフを画面に出力することでも目的は果たせますが、月に一度の出力頻度であれば、より低コストで実現できるCSVを画面から出力する機能を開発し、Excelでグラフを作成するという案が浮上しました。

要求とは要望を取捨選択し、整理、構造化したものと説明しましたが、この段階で、下図のとおり、要求は構造化された状態(階層構造)になります。

目的を実現するための手段の再検討(要求の完成)

要件の検討(要求から要件へ)

開発者は、月次売上をCSVで出力することが最も費用対効果が高いと結論づけ、この方法を提案することにしました。

この提案に基づき、月次売上のCSV出力に必要な要件を現場担当者と相談しながら以下のように検討しました。

機能要件

  • CSVに出力する項目は何か?(例:売上日、商品名、数量、売上金額)
  • どのような抽出条件が必要か?(例:期間指定、商品カテゴリ別、店舗別)

非機能要件

  • 出力までの時間
    • 数秒以内での出力完了が必要かどうか
      • 現場担当者に確認したところ、数秒以内での出力は必須ではないことがわかった。データ抽出処理の時間を試算した結果、数分かかる見込みのため、画面を非同期化し、出力完了時に通知を受け取ってダウンロードできることとした。
  • 出力データのセキュリティ
    • アクセス権限の制御
      • 機能を使えるのは「管理者」のみ
    • データの暗号化
      • HTTPSによる暗号化

要件の検討(要求から要件へ)

要件の合意

開発者、現場担当者、現場責任者などのステークホルダーと協議し、今回は月次売上をCSVで出力することで合意しました。将来的には画面上でグラフを表示する計画もあり、この要求は今後の検討課題として残すことにしました。

要件は、要求をさらに取捨選択し、実現対象として合意したものと上述しましたが、合意した時点で、要求は要件になったといえます。

要件の合意

要件から、設計、実装へ

明確になった要件をもとに工数見積もりをし、スケジュールやコストをステークホルダーと合意したら設計を始めます。設計では、具体的な画面設計やデータ設計などを行います。設計が完了したらプログラムの実装に入ります。

これらの検討結果を経て、ユーザーの要望に基づき、費用対効果の高い開発を行うことが可能になります。

工数見積りやコスト、スケジュールなどの話は、別記事で説明します。

要件から、設計、実装へ

最後に

開発の依頼内容を要望、要求、要件の3段階に分けて整理する考え方について説明しました。

アジャイル開発宣言*2の4つの価値のひとつに、「契約交渉よりも顧客との協調を(Customer collaboration over contract negotiation)」があります。

開発者は依頼された内容をそのまま開発するのではなく、依頼者と開発者が協調して実現したい価値や目的を確認し、要件を明確にすることが重要です。

こうすることで、不要な機能の開発を避け、優先度の高い要件に集中し、結果として必要な価値をユーザーにスピーディーに提供することが可能になります。

次の記事では、事業要件、業務要件、システム要件の3層に要件を階層化して捉える考え方について説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:5W2Hなどという「When(いつ)」「Where(どこで)」「Who(だれが)」「What(なにを)」「Why(なぜ)」「How(どのように)」「How Much(いくらで)」の頭文字をとったもの

*2:日本語訳:https://agilemanifesto.org/iso/ja/manifesto.html

要件定義の難しさ

TRACERYプロダクトマネージャーの haru です。

システム開発は、企画、要件定義、設計、実装、テストというプロセスに大きく分けることができます。

開発者にとって、設計、実装、テストは仕事内容をイメージしやすい領域です。

ビジネスに近い立場の人々は、企画段階での企画書作成などを具体的にイメージできるでしょう。

しかし、要件定義に関しては、何をすべきか不明瞭でイメージしにくいという人も多いかもしれません。

この記事では、システム開発における要件定義の位置づけ、そして要件定義が難しい理由について説明します。

開発プロジェクトが失敗する一番の理由と世の中で求められている人材

システム開発が失敗する一番の理由を知っていますか?

日経クロステック、日経ビジネスが開発プロジェクトの失敗理由を調査した結果をみてみます。

日経XTechの調査結果
日経ビジネスの調査結果

上記は2017年、2018年に行われた調査結果ですが、いずれも『要件定義』に関する理由が1位です。

また、ビズリーチが発表した、『レジュメ検索・検索トレンド』の検索キーワード1位は『開発要件定義』でした。(2022年) 翌2023年の結果でも、要件定義は8位にランクインしています。

2022年レジュメ検索トレンド
2023年レジュメ検索トレンド

これらの調査結果をみると、要件定義が原因でシステム開発がうまくいかないことが多く、その結果として要件定義ができる人材が企業で求められているということが見えてきます。

要件定義は誰が何をするのか

システム開発のプロセス

システム開発の4プロセス

システム開発のプロセスは、上の図のように4つのプロセスに分けられます(ここでは「作る」ことにフォーカスし、テストは除いています)。

  • 企画 『なぜそのシステムを作るのか』という目的(Why)
  • 要件定義 『何を作るのか』(What)
  • 設計 『どのようにシステム・ソフトウェアを作るのか』(How)
  • 実装『実際に作る』(Make)

4つのプロセスは『レストランでの食事』に例えられる

レストランの例え

4つのプロセスを身近な例として、『レストランでの食事』に例えてみます。

まず『企画』は、食事のプランニングです。

何のために(Why)レストランで食事をするのでしょうか?親交を深めるためなのか、誰かの誕生日のお祝いなのか、理由は様々ですが、『仲良くなる』『お祝いをする』といった目的があると思います。ここまでが企画の部分です。

食事の目的が決まったら、何の料理を食べるのか、を考えます。ここが『要件定義』にあたります。

友達の誕生日を祝うため(企画)、友達の好物であるハンバーグを食べに(要件定義)、いろんな種類のハンバーグを頼めるお店に行こう(要件定義)、といったイメージです。

ここまでが、お客さんが担当する部分です。

続いて、お客さんからの注文(要件)を元に、レストラン側が料理をどのように作るのかを考えます。『設計』に当たる部分です。

どのように(How)、焼くのか煮込むのか、ドリアに乗せるのか、チーズを入れるのか、お客さんからの注文(要件定義)を元にどんな風に調理をするのかを決めていきます。

そうした調理方法(設計)を元に料理をつくります(実装)。

料理に例に説明しましたが、一連のプロセスは、「料理を注文する側」のお客さんと「料理を作る側」のお店側に分けられます。

ビジネス側と開発側の境界線

これはシステム開発も同じです。『企画』と『要件定義』、そして『設計』と『実装』とに分けられます。ただし「ビジネス側」「開発側」はロール(役割)と捉えてください。ビジネス側が開発の仕事を担当することもありますし、開発側がビジネスに携わることもあります。ここが料理とは異なる点です。

ビジネスを『事業』と『業務』に分けて理解する

ビジネスは事業と業務で構成される

ビジネスは『事業』と『業務』に分けて考えられます。

『事業』とは組織が社会的または組織的な目的を達成するために行う継続的な活動の全体を総称したものです。『業務』とは、事業を実現するために行う現場の仕事、オペレーションや運用を指します。

例えば「全世界に商品を販売したい」という目的をもった越境EC事業*1があるとします。

『事業』を実現するためには、商品をどこから仕入れるのか、商品の在庫管理はどうするのか。顧客に商品を届けるための物流などを考える必要があります。これらが『業務』です。この『業務』を行うためにはどのようなITのシステムが必要なのかを最終的に定義するまでが要件定義です。

要件定義の難しさ

要件定義における専門性の谷

要件定義における専門性の谷

ここまで説明してきたように、事業・業務を行う『ビジネス側』の役割(ロール)をもった人が要件定義を行います。

ここで問題になるのが、一般的にビジネス側の人は、ITシステムそのものへの知識やシステム開発プロジェクトの経験が少ないということです。

そのため、事業や業務に必要なITシステムがどのようなものなのかを定義することが難しくなります。

一方で、開発側の人も一般的にビジネスの知識や経験が少ないため、事業や業務に関して定義することが難しくなります。

ここが要件定義の難しさであり、要件定義のおける専門性の谷といえるでしょう。

この専門性の谷のために、冒頭で示したように多くのシステム開発が要件定義を理由として失敗していると考えられます。

この専門性の谷を渡るためには、ビジネス側と開発側の協力が特に必要になってきます。

そして、要件定義を推進し、様々なニーズを取りまとめられる人が世の中で求められている人材です。

要件定義ではビジネスと開発の協力が特に必要. Photo by Unsplash Antonio Janeski

まとめ

本記事では以下のことを説明しました。

  • システム開発が失敗する一番の理由と世の中で求められている人材
  • システム開発全体において要件定義は誰が何をするのか
  • 要件定義の難しさ(専門性の谷)

要件定義における専門性の谷を乗り越えるための『要件定義に必要なスキル』については以下の記事で説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:インターネットを利用して異なる国や地域にある顧客に商品やサービスを販売するオンラインビジネスの形態。このビジネスモデルでは、企業は国境を越えて製品を提供することで、より広範な市場へアクセスし、多様な顧客層にリーチすることが可能になる。

要件定義に求められるスキルとは

TRACERYプロダクトマネージャーの haru です。

要件定義の難しさ - TRACERY Lab.(トレラボ)では、要件定義がなぜ難しいのか、という説明をしました。

今回の記事は、要件定義を成功させるために必要なスキルと、そのスキルの身につけ方について説明します。

要件定義に求められる3つのスキル

『要件定義』に求められるスキルは、以下の3つです。

  • ニーズをまとめるスキル
  • 開発から運用までをイメージするスキル
  • 全体を捉えるスキル

それぞれのスキルについて説明します。

ニーズをまとめるスキル

さまざまな要望を取りまとめ、導くスキル

システムにはさまざまなステークホルダー(利害関係者)が関わり、それぞれがシステムに対して要望を持っています。

例えば、経営者はシステムの活用によって売上が上がるか、費用が下がるか、従業員の満足度が上がるかなど、経営的な側面から要望を出します。

業務担当者は、業務で成果が上がることや効率化を求める要望を持っています。

顧客は、自分の仕事の成果が上がるか、やりたいことができるかという要望を持っています。

開発担当者は、日々開発がしやすいか、保守がしやすいかといった要望を持っています。

現実的にはこれらの要望に全て応えることはできません。

あるステークホルダーの要望を満たすと、他のステークホルダーにマイナスの影響が生じることもあります。

これらのさまざまな要望をヒアリングし、文書化、モデリング、プロトタイピングなどを行うことで認識をすり合わせていきます。

そして、要望を取捨選択し、要件としてまとめ、最終的にステークホルダー間で合意を形成する必要があります。

このように、要件定義を行うためには、多種多様でばらばらな要望を整理し、要件の合意に導く力が求められます。

開発から運用までをイメージするスキル

開発から運用までをイメージするスキル
 

要件定義をする際には、開発工程から完成、運用までを一貫してイメージするスキルが必要です。

このスキルや知識は2つから成り立っています。

1つは、開発のインプットにどのような情報が必要かを理解していることです。

要件定義でまとめた要件(上図の青)は開発プロセス(上図の緑:設計、実装、テスト)のインプットになります。

たとえば、設計と実装は要件定義の情報を基に進められ、テストでは要件を基にシナリオテストなどのテストケースが作成されます。

そのため、どのような情報が開発プロセス(設計、実装、テスト)にとって必要十分かを把握することが求められます。

そうでないと、開発中に何度も要件の確認が必要となり、手戻りやタイムラグが発生し、開発の遅延につながる可能性があります。

2つは、要件を実現するためにどれくらいの工数がかかるかをイメージすることです。

開発の設計プロセスでは、画面設計やシステムの背後にあるアーキテクチャ、データベースの設計が行われます。

定義された要件を満たすために無理な設計になったり、必要以上の実装工数がかかると、工数増加や他のトラブルにつながることがあります。

そのため、要件定義の段階で、要件定義者はその要件を満たす画面や背後の仕組みがどのようなものになるかをイメージし、工数的にも妥当な設計や実装ができるような要件を定義する必要があります。

要件定義担当者が十分にイメージできない場合は、開発者と協力し、設計や実装にとって妥当な要件かどうかを確認しながら進めると良いでしょう。

エコシステム全体を捉えるスキル

エコシステム全体を捉えるスキル

要件定義に必要なスキルの3つ目はシステムだけではなくエコシステムを含めた全体を捉えるスキルです。ここでいうエコシステムはビジネスの流れ(人、物、金、情報の循環)を表します。

ビジネスの観点から業務に必要なシステムの要件定義を進める中で、エコシステムにも目を向ける必要があります。

事業に関連する業務が全て自社で完結するわけではありません。

たとえば、物流については専門の会社に依頼する方がよいかもしれません。倉庫での管理については、倉庫を借り、管理をする人員を専門事業を行っている会社から雇うか、自社で確保するかを選ぶ必要があります。

このような観点から、自社内だけではなくエコシステム全体を考慮し、必要か不必要かを選択する必要があります。

外部の力を借りることが費用対効果に優れている場合、独自のシステムを新たに開発する必要はありません。

自社だけでなく、人、物、金、情報がスムーズに循環し、時間が経つにつれて発展していくエコシステムを持つことが良いビジネスだと言えます。

事業およびエコシステム全体を捉えた上で、必要なシステムやその中のソフトウェアを考慮し、要件定義を行います。

システムの外側を意識しないと、事業を実現するためのシステムにはなりにくいと言えます。

必要なスキルを身に着けるために『型』を学ぶ

要件定義に必要なスキルはどのように身につけるのでしょうか。

それは、要件定義の『型』を学び、身につけることです。

ここでいう要件定義の『型』とは、広く深い思考を促す手法や思考プロセスのこととします。

要件定義の『型』

要件定義で必要なスキルとして、①ニーズをまとめるスキル、②開発から運用までをイメージするスキル、③全体を捉えるスキルがあると、説明しました。

たとえば、要件定義手法のRDRA *1にならうと、これらを高めるための手助けをしてくれます。

詳しくは、今後書いていく別の記事で説明していきたいと思います。

『型』に倣い、身につけることのメリットは、考えることが減ること

『型』に倣い、身につけることのメリット

要件定義を進めるにあたって、「ニーズをどのようにまとめるか?」「開発から運用までをどうイメージしながら進めるか?」「全体をどのように捉えるか?」など、進め方を自分で考えるとすると、相当な時間がかかります。

その方法が適切であればまだしも、誤っていれば余計なコストが発生します。

本当に必要なのは、具体的な要件定義の進め方ではなく、成果物(何を作るかを示すもの)とステークホルダーの合意です。

「型」に倣い、それを身につけることで、要件定義の結果として必要なものを作り出すことに集中できます。

『型』は万能ではない

ここで注意してほしいのは、「型」が万能ではないということです。

「型」はスキルを高めるための方向づけを提供しますが、価値あるものを創出できるかどうかは最終的に関わる人々の力量に依存します。

また、「型」はシンプルさを追求するために、本当に必要ではないものを削除しスコープ外とすることが多いです。そのため、他の方法で補う必要がある場合もあります。

まとめ

要件定義に必要なスキルとして、以下の3つを挙げました。

  • ニーズをまとめるスキル
  • 開発から運用までをイメージするスキル
  • 全体を捉えるスキル

これらの「型」を学び、倣うことで、これらのスキルは向上し、要件定義の結果として望むもの、つまり要件定義の成果物(何を作るかを示したもの)の創出とステークホルダーの合意を形成することを効果的に進められます。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:Relationship Driven Requirement Analysis:ラドラ。モデルベースの要件定義手法。アイコン同士を線でつないだシンプルなモデルによって業務とシステムの構成要素の関係(Relationship)を構造化し、要件をかたちにしていく