こんにちは、QAコンサルタントのヤマダです。 「いい感じのシステム、よろしく！」 エンジニアやプロダクトマネージャーの皆さん、顧客からこんな風に、フワッとした要望を受けて困った経験はありませんか？ 良かれと思って作ったのに「なんか違うんだよな…」と言われてしまったり。 こうした悲しいすれ違いを防ぎ、顧客の真のニーズを引き出してプロジェクトを成功に導くための強力な武器が、ビジネスアナリシスの知識体系 BABOK® (Business Analysis Body of Knowledge) です。 今回は、このBABOKの考え方を使い、ある飲食店の「漠然とした想い」を具体的なシステム要求に落とし込んでいくプロセスを、ケーススタディ形式でご紹介します。 BABOKとPMBOK：プロジェクト成功の両輪 BABOK（バボックと読みます）は、ビジネスアナリシスの専門機関であるIIBA®が策定した、ベストプラクティスを体系的にまとめた「知識の地図」のようなものです。 この話をすると、プロジェクトマネジメントの知識体系である PMBOK® (Project Management Body of Knowledge) とどう違うのか、という質問をよく受けます。この二つの違いを理解することは、プロジェクト全体を成功させる上で非常に重要です。 一言で言うと、その目的が異なります。 BABOK® (ビジネスアナリシス) PMBOK® (プロジェクトマネジメント) 目的 正しいプロダクトを作る (Do the right thing ) プロダクトを正しく作る (Do the thing right ) 焦点 What (何を作るか), Why (なぜ作るか) How (どう作るか), When (いつまでに) 役割 ビジネスニーズの発見、要求の定義 計画の立案、リソース・進捗の管理 BABOKが「そもそも何を作るべきか？」という上流工程を担う のに対し、 PMBOKは「作ると決まったものを、いかに計画通りに完成させるか？」という実行工程を担います。 例えるなら、BABOKが「目的地（＝ビジネスゴール）を定め、そこへ至るための航海図を描く」役割、PMBOKは「その航海図に基づき、船（＝プロジェクト）を安全かつ効率的に運航する航海術」と言えるでしょう。 両者は対立するものではなく、プロジェクトという船を成功に導くための「両輪」なのです。ビジネスアナリストとプロジェクトマネージャーが協力し合うことで、初めて「価値あるものを、計画通りに」届けることができます。 ちなみに、BABOKにはその知識レベルを証明する国際資格として、 CBAP® (Certified Business Analysis Professional) など、実務経験に応じた認定資格制度（ECBA , CCBA®, CBAP®）もあります。 さて、今回のケーススタディでは、特にBABOKが担う 「何を作るべきか」を定義する部分 に焦点を当てて見ていきましょう。 ケーススタディ：あるレストランオーナーの悩み クライアント: 地域で人気のイタリアンレストランのオーナー 相談内容: 「最近『ネットで注文や予約できないの？』ってよく聞かれるんだ。電話対応も大変だし、テイクアウトも強化したい。ついでに人気メニューも分析できたら最高だね。」 さあ、この「想い」をBABOKの6つのステップで具体化していきます。 実践！BABOK流・要求具体化の6ステップ Step 1: 計画とモニタリング (どう進めるか決める) いきなり機能の話をするのではなく、まずプロジェクトの進め方を決めます。 やること: 関係者は誰か、どうやって情報を共有するか、どんな進め方をするかを計画します。 具体例: 関係者: オーナー、ホール・キッチンスタッフ、常連客など 進め方: 週1でオーナーと会議。簡単な試作品を触ってもらいながら進める（アジャイル的アプローチ）。 情報共有: 議事録や資料はGoogle Driveで共有する。 Step 2: 引き出しとコラボレーション (本音と課題を聞き出す) 関係者から、言葉の裏にある本音や現状の課題を引き出します。 やること: インタビューや業務観察を通じて、関係者のニーズや問題点を深く理解します。 具体例: スタッフに現状の電話予約業務の課題（聞き間違い、予約の重複など）をヒアリング。 店舗のピークタイムの様子を観察し、業務のボトルネックを発見する。 ヒアリング結果を簡単な図や文章にまとめ、「こういうことで合ってますか？」と認識を合わせる。 Step 3: 戦略アナリシス (ビジネスの「なぜ」を掘り下げる) ここは、プロジェクトの心臓部とも言える非常に重要なステップです。単に現状の課題を洗い出すだけでなく、 「そもそも、このプロジェクトを通じてビジネスとして何を達成したいのか？」という根本的な問い（ビジネスニーズ） を定義します。 このステップを飛ばすと、いくら高機能なシステムを作っても「で、結局ビジネスの何が良くなったんだっけ？」という状態に陥りがちです。戦略アナリシスでは、主に以下の4つの視点で考えます。 現状の分析 (Analyze Current State): 我々は今どこにいるのか？ なぜ変化が必要なのか？ 将来状態の定義 (Define Future State): どこへ向かいたいのか？ 成功した状態とはどんな状態か？ リスクのアセスメント (Assess Risks): その道のりにどんな障害物（不確実性）があるか？ 変革戦略の定義 (Define Change Strategy): どうやってゴールまでたどり着くか？ 最適なルートは？ これらを踏まえた上で、今回のレストランのケースでは以下のように考えます。 具体例: 現状(As-Is): 電話対応に追われ、機会損失や顧客満足度の低下が起きている。売上データが属人的で活用できていない。 将来状態(To-Be): オンラインチャネルからの売上が30%向上し、スタッフはより付加価値の高い接客に集中できている。データに基づいたメニュー開発が可能になっている。 リスク: スタッフがシステムを使いこなせない。導入コストが想定以上にかかる。 変革戦略: まずはリスクの少ないテイクアウト機能からスモールスタートし、スタッフと顧客の反応を見ながら予約機能などを段階的に導入する。 Step 4: 要求アナリシスとデザイン定義 (アイデアを設計図にする) 理想の姿を実現するための具体的な機能（＝要求）を洗い出し、設計に落とし込みます。 やること: 要求を機能（例: 決済機能）と非機能（例: 使いやすさ）に分類し、システムの画面イメージなどを作成します。 具体例: 機能要求: メニュー表示、オンライン決済、予約カレンダー 非機能要求: スマホで使いやすいデザイン、3秒以内の画面表示 手書きのラフな画面イメージ（ワイヤーフレーム）を描いて、オーナーと「こんな感じですか？」とすり合わせる。 Step 5: 要求ライフサイクル・マネジメント (変化に強く、ブレない軸を持つ) プロジェクトを進める中で発生する要求の変更や追加に、うまく対処します。 やること: 機能に優先順位をつけ、追加要望が出た際の影響を評価し、対応を判断します。 具体例: 優先順位付け: 「オンライン決済」は必須（Must）、「クーポン機能」はできれば（Could）のように整理する。 変更管理: 「デリバリー機能も欲しい」という追加要望に対し、開発期間とコストへの影響を提示し、導入するかどうかをオーナーと合意する。 Step 6: ソリューション評価 (作って終わりじゃない、価値を測る) 完成したシステムが、本当に当初の目的を果たしているかを確認します。 やること: システム導入後の効果をデータで測定し、さらなる改善点を見つけます。 具体例: 導入前に立てた目標（KPI）である「電話対応時間を50%削減」「オンライン売上30%UP」を達成できたか計測する。 「メニューの更新が少し面倒」といったスタッフからの意見を収集し、次の改善アクション（例: 管理画面の改修）を提案する。 まとめ いかがでしたか？ BABOKのフレームワークに沿って進めることで、オーナーの 「いい感じにしたい」 という漠然とした想いが、 何を: テイクアウトと予約のオンラインシステム なぜ: 業務効率化と売上向上のため どうなれば成功か: オンライン売上30%UP といった、 誰が見ても明確で、測定可能なゴールを持つプロジェクト に変わりました。 日々の開発業務で「これ、何のために作ってるんだっけ？」と感じたとき、この6つのステップを少しだけ意識してみてはいかがでしょうか。きっと、あなたのプロジェクトを成功に導くヒントが見つかるはずです。 The post 脱・伝言ゲーム！BABOKの知識で顧客の想いをカタチにする方法【飲食店のDX事例】 first appeared on Sqripts .

こんにちは、iOSエンジニアのyamakenです。2026年4月12日（日）から14日（火）の3日間にわたり開催された、try! Swift Tokyo 2026に、LINEヤフー株式会社はGOLDス...

はじめに セーフィー株式会社 開発本部エンジニアリングオフィスの山崎（@ymzaki_m4）です！ 今年も26新卒エンジニア11名が仲間に加わり、全体研修を経て4月20日から開発本部での研修がスタートしました！ エンジニア研修といえば、言語の仕様やフレームワークの使い方、インフラ構成といった「技術（ハードスキル）」が主役になりがちです。しかし、セーフィーの開発組織が大切にしているのは、技術を使いこなす前の土台となる「人」「チーム」「プロセス」のあり方です。なぜなら、プロフェッショナルとしての仕事は「個人戦」ではなく「チーム戦」だからです。 今回は、研修の冒頭2日間でおこなわれた、組織