ポスト

「ビジネスアナリシス」とは、『IIBA®のBABOK®ガイド』の定義によると「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動」です。ITの分野では「上流工程」にあたり、ビジネス戦略とITをつなぎ要件定義を作成し、ITシステムができることだけではなく、きちんと業務システムとして稼働させ、想定した価値を実現できているかの評価まで行うことが仕事になります。

国際的かつ中立的立場でビジネスアナリシスの啓発を行う非営利団体IIBAの理事として9年にわたり活動している当社の濱井和夫さんに、IIBAでの活動や業務への活用についてお話を伺いました。

IIBA参画のきっかけ

NTTドコモソリューションズ
濱井和夫

私はプロジェクトマネージャ（PM）やプロジェクトマネジメントオフィス（PMO）*1として、さまざまなプロジェクトに携わってきました。

現場の当事者として、また全体を俯瞰できる立場として何度か問題プロジェクトに携わる中で、その原因の多くが上流工程にあると感じていました。根本的な原因が上流工程で埋め込まれてしまうと、現場でPMがどれだけ努力しても解決が難しいケースが多く、こうした状況にどう対応すべきか常に考えていました。ちょうどその頃、ビジネスアナリシスの知識体系ガイドである書籍BABOK*2 のv2が発刊（2009年）され「これからはビジネスアナリシスが大切だ」と日本でも話題になりました。

それ以来、関連するセミナーや勉強会に時折顔を出すようになりました。2014年に公開されたBABOK v3のドラフトはv2から大きな変化がありました。その内容を理解するために有志で企画された勉強会に参加したことが、IIBAの参画のきっかけとなりました。v2では単一プロジェクトの成功をめざした上流工程（要件定義）が中心の内容でしたが、v3ではプロジェクト開始前に「なぜそれをやるのか」「何をめざすのか」を分析することから始まり、プロジェクト完了後に実施する「価値が実現されたか」のフィードバックまでスコープが拡大されたことで、経営戦略や価値創出に直結する内容へと進化しました。この勉強会をきっかけに「顧客や組織にとって真に意味のある価値は何か？」という問いを常に持ち、「顧客視点」で「本質をとらえる」ことを学びはじめました。また、BABOK v3のドラフト（もちろん英語）の勉強会の中で、単に単語を文法に従って日本語に置き換えるだけでなく、欧米文化の思想的背景を理解して変換しなければガイドの本質を正しく日本に伝えることができないという、翻訳の奥深さも実感しました。また、新しいことを広めるための必要性、その価値も認識しました。BABOK v3の翻訳メンバーには加わりませんでしたが、その活動を通じて理事会に参加しないかとお誘いを受けました。

*1 PMO（Project Management Office）：社内横断的に複数のプロジェクトを支援する組織。PMの補佐、プロジェクト管理の標準化などの役割をもつ。
*2 BABOK（Business Analysis Body of Knowledge）：IIBA（International Institute of Business Analysis）が策定したビジネスアナリシスに関する知識・技法・ベストプラクティスを体系化したガイド。要求定義、分析、設計、評価などのプロセスを6つの知識領域として整理し、国際的な標準となっている。

IIBAの活動（教育・翻訳・出版）～日本語で伝える意味～

書籍『BABOKガイド・アジャイル拡張版 v2』『ビジネスデータアナリティクス・ガイド v1』

理事就任後は、勉強会や教育プログラムの企画、IIBA日本支部での各種ガイドの翻訳プロジェクトにも積極的に関わり、メンバーとして参加するとともに有識者を巻き込む活動も行いました。アジャイル拡張版の翻訳時には、アジャイル開発の業界の有識者にレビューを依頼しました。また、ビジネスデータアナリティクスガイド翻訳の際には、当社内の有識者にボランティアで協力を募りました。日本でも「ビジネスアナリシス」という言葉を使わずに、実際に正しいビジネスアナリシス活動を行っている人、独自に有効な手法を考案している企業や個人はいます。

しかし、日本はこうした活動や手法を体系化することがあまり得意ではなく、欧米から新しいものがはいってくると盲目的に飛びつき、自分たちの良い部分を手放してしまう傾向があるように感じています。そこで、体系化されたガイド類を日本語化し、まずは基本としての型（本質）を正しく理解する人が増えることが重要だと考えています。そのうえで、自分たちの実践について、「どこが正しいのか」、「どこが不足しているのか」、「より良くできているのはどこか」を正しく判断し、さまざまな環境における課題に対して柔軟に対応できる人が増えるとよいと思っています。

ビジネスアナリシスの知見をPM/PMO業務へ活かす

現在、私はPMOとして、社内組織を横断し、クオリティゲート（ソフトウェア開発の各工程で行うプロジェクト品質管理の仕組み）の審査、プロジェクト支援、PM育成を行っています。ビジネスアナリシス活動で培った「本質の理解」や「顧客視点」は、業務のさまざまな場面で活かされています。
各クオリティゲートでの評価では、定量的な指標だけでなく、定性的な観点や根本原因の追究を重視し、形式にとらわれず本質を見極める姿勢を大切にしています。
例えばエラー密度、バグ密度の指標値をもとに「ストライクゾーン分析で、真ん中のエリアに入っているので品質は問題ありません」と報告された場合でも、「そもそもの指標値自体が妥当か？」、「件数だけではなく試験観点は適切か？」、「検出された故障の真因は何か？」など考慮しなければ実際には問題が残っている状態かもしれません。定量評価はあくまでも結果の数字で統計的な傾向を確認するものであり、定性評価と組み合わせて初めて意味を持ちます。前段階である開発プロセス定義や試験計画策定の段階から、品質を作り込むことが重要です。本質を理解した上で仕組み作りを考えることで、コンテキストが変わったときにもその状況に応じた最適な方法を選択できるようになると思います。
品質管理の審査や、プロジェクト支援においても形式的なコメントにとどまらず、「なぜ？」を常に問いかけることを意識しています。また、この「なぜ？」は開発プロジェクトの視点だけではなく、顧客を含めたプロジェクト全体の視点で本当に正しいことかを問うようにしています。

PMだからといって決められた仕様を「正しく作る」だけではなく、「正しいもの」を顧客と共感し、それを「正しく作る」ことが私のポリシーです。決める人・作る人という役割分担ではなく、一緒に考えて一緒に作り出していくことを大切にしています。その認識でビジネスアナリシスをファウンデーションスキル（土台となるスキル）に位置付けており、匠Method*3やシンプル要件定義のRDRA*4等の導入推進活動を行っています。

*3 匠Method：ビジネスや業務などの関係者における価値を明確化し、全体像を表現することで、対象とするスコープや要件について関係者と意思統一を図ることができる匠BusinessPlace社によって提唱されている手法です。
*4 RDRA（Relationship Driven Requirement Analysis）：ビジネス価値や、外部環境から、システム要求される仕様までの関係性を、図で分かりやすく表現し、関係者間で合意しやすくする要件定義手法。「RDRA」は、株式会社バリューソース社が提唱するモデルベースの要件定義手法です。

人とのつながりが、組織を変える力になる

社外での活動を通じて、当社が多数のステークホルダーと調整しながら大規模なシステム開発を完遂できるところは改めて大きな強みと認識しました。また、プロジェクトマネジメント（PM）力や技術力に優れた方も多いと感じています。一方で、品質を守るためのルールや仕組みがしっかりしているがゆえに、それをすぐに変えるのは難しいと感じる面もあります。しかし、そうした会社が変わることで業界全体に良い影響を与えることができるのではないかと考えます。
当社はNTTドコモグループとなり、今後は「どうつくるか？」から「（価値創造のために）何が必要か？」を一緒に議論しながら新しいサービスを生み出していくことがますます増えていきます。社内にとどまらず、どんどん外へ出て、多様な人と議論し学ぶという経験を重ねることが重要だと感じています。

私自身も、以前は「遠い存在」と感じていたアジャイル開発の第一人者の方などと勉強会や懇親会で話す中で、実際には同じような考え方をもつことがわかり、業界や世界を見ても共通する感覚があることに気づき、自分の中の壁が取り払われ、視野が広がるといった経験がありました。また、社外に出た人が戻って一緒に仕事をするなど、新たなつながりや学びが生まれることも大切です。いろいろな価値観を知って、そのうえで同じ思いで集まることでもっと強い組織になると考えています。

要件定義領域における生成AI活用の可能性と今後の展望

今後にむけては、システム開発の上流工程である要件定義領域における生成AIの活用推進にも取り組んでいます。システム開発ライフサイクル全体を見渡すと、コーディングなど生成AIによって効率化が進む領域が増えていますが、その中でも特に人間の介在が不可欠なのが、ビジネスアナリシスや要件定義の領域です。IIBA本部主催の年次グローバルイベントであるBBC*5でも、「ビジネスアナリシス領域でも情報の入手・整理・成果物作成に生成AI活用が当たり前の時代となり、最終的な戦略、思い、情熱に基づく判断にこそ、これまで以上にビジネスアナリストの価値発揮が求められている」という論調です。

NTTドコモグループとして市場から求められるスピード感でサービスを提供していくためにも、これまで以上に戦略的に生成AIを活用していくことが必要だと感じています。育成は一朝一夕にはできませんが、価値駆動で物事を考え、顧客との会話から整合性を持って要件定義を行うといったビジネスアナリシスの考え方は、土台となるスキルとして不可欠です。

少し前の話になりますが、私が入社直後に関わったDIPS（電電公社の汎用コンピュータ）*6の、数十年前に作成されたと思われるソフトウェア開発標準をひさしぶりに見返す機会がありました。なにげなくひらいてみると最初のページに「ソフトウェア開発の目的は顧客の事業価値の実現」といった意味のことが記されていました。コンピューターシステムを作りそれを動かすものにした当初も「お客さまのビジネスや世のために役立つものを作りたい」というところから始まっていたこと、時代は変わってもめざすべき本質は変わらないことを改めて感じました。

今後も、これまで積み重ねてきた知識を結晶化させ、「本質の理解」や「顧客視点」といったビジネスアナリシスの価値をさらに広め、現場での実践を通じてお客さまのビジネス価値創造に貢献していきたいと考えています。

*5 BBC（Building Business Capabilities）：IIBAが主催する世界中のビジネスアナリストが一堂に集結するイベント。
*6 DIPS（Dendenkosha Information Processing System）は、NTT（日本電信電話公社）が1970年代から1980年代にかけて開発したメインフレームコンピュータ。データ通信サービスや社内情報処理システムに広く用いられた。

濱井　和夫
NTTドコモソリューションズ株式会社
技術革新本部、ビジネストランスフォーメーション事業本部、エンタープライズソリューション事業本部、ビリングプラットフォーム部、NTT IT戦略事業本部、地域事業本部
PMO担当統括課長

2025年6月発行「Business Architecture: Collecting, Connecting, and Correcting the Dots」（日本語タイトル：「ビジネスアーキテクチャ: ビジネスを構成する点を集め、つなぎ、正す」）翻訳にも携わりました。

DX（デジタルトランスフォーメーション）という言葉が注目されるようになってからしばらく経ちますが、日本では組織や事業を横断したトランスフォーメーションの成功事例はそれほど多くはありません。その背景には、取り組みの早い段階でプロジェクトやプロダクトといった限定的なスコープに分断され、そこにのみフォーカスされる傾向があることが挙げられます。その結果、企業全体を俯瞰する視点でデザインする明確な機会や手法が、社内に十分に定着していないことが根本原因ではないでしょうか。新しい戦略やビジネスシナリオが、企業のビジネス構造や業務構造、さらにデジタル・ITシステムの構造にどのような影響を与え、将来のあるべき姿にどう再構成されるべきか――これらをプロジェクト開始前に検討する必要があります。そのためには、全体的な視点からビジネスや企業の各構成要素と相互関係を迅速にデザインできるマインドと手法を身につけることが不可欠です。こうした考え方や手法を、著者の豊富なコンサルティング経験を踏まえわかりやすくまとめたものが本書です。広い視座や多角的な視点を与えてくれる一冊ですので、ぜひ一読をお勧めします。