社内の知見共有を目的に運用されてきたインナーメディア「BApedia」。そのリニューアルプロジェクトを、Business Architects（ビジネス・アーキテクツ、以下BA）の若手メンバーが主導しました。

「職種を越えてナレッジを共有できる場」を目指し、計画書づくりから要件定義、CMS移行、デザインまでの全工程に挑戦。数々の課題に直面しながらも、自ら考え、行動し、壁を乗り越えていきます。

本記事（前編）では、「BApedia」プロジェクトの上流工程を担当した3名のメンバーに焦点を当てます。今回のプロジェクトでは、佐藤がプロジェクトマネージャー、廣川がディレクター、内藤がアカウントプランナーを担当。
それぞれの立場から語られるリアルな悩みと学びを通じて、BAならではの「伴走力」の原点を探ります。

BAの「伴走力」はどう生まれる？

• 【前編】社内ナレッジベース刷新の上流工程に挑む若手たちの試行錯誤（本記事）
• 【後編】デザインとシステムを担う現場の奮闘

職種を越えてナレッジを共有するための「BApedia」

そもそも「BApedia」とはどんなメディアなのでしょうか？

佐藤：BA社内でWebの知識や業務ノウハウを共有するインナー向けのメディアです。全社員へアカウント発行し、ログインすれば誰でも投稿可能になっています。

リニューアル前は、主にフロントエンド主導のナレッジ共有やコミュニケーションを目的としたサイトでしたが、このリニューアルを機に、エンジニア・デザイナー・ディレクター・セールス・コーポレート部門など、職種を越えて知識が共有ができるよう再設計することにしました。

具体的にどのような箇所をリニューアルすることになったのでしょうか？

佐藤：大きな変更としては、CMSの移行です。前身のサイトではWordPressで運用していましたが、今回の刷新で「PowerCMS X クラウド」へ移行しました。

今回、PowerCMS X クラウドを選んだ理由は大きく2つあります。まず1つ目は、お客さまに薦めるためにより深くこのCMSを理解することです。そして2つ目は、既存の運営サイトでも同CMSを導入しているため、プラットフォームを統一して知見を蓄積・展開しやすくすることです。

また、CMSの移行に伴い、トップのデザイン変更や記事テンプレートの調整など、細かい部分もリニューアルしています。

今回のプロジェクトは、なぜ若手中心で任されたのでしょうか？

廣川：さきほどのCMS移行の話にもつながりますが、BA社内ではPowerCMS X クラウド案件の対応が特定のメンバーに集中しており、対応の幅を広げにくい状況でした。そのような背景から、若手を主軸に据えてPowerCMS X クラウド関連の知見の底上げを図ることになりました。

PowerCMS X クラウドは幅広い企業で導入しやすく、お客さまへの提案機会も多いCMSです。だからこそ、属人化させずBAとしての対応力を補強し、若手のスキルを向上させる意味合いが大きかったですね。

プロジェクト計画書づくりで直面する最初の壁

最初の難所は「プロジェクト計画書」だったと伺いました。

佐藤：はい。目的の設定とスコープの言語化に苦労しました。私自身、これまでの案件では資料を「読む側」だったので、「書く側」は初でした。どこまでを成果物に含め、どこからを除外するのか。定義が曖昧だと、WBSも見積もりも曖昧なまま進んでしまう。

今回は社内向けなので、事業部長の小山さんがクライアント役でしたが、「公開＝ゴール」という短絡的な捉え方を最初に崩してもらったのが大きかったです。

なぜ「公開＝ゴール」ではないのでしょうか？

佐藤：もちろんサイト公開は最終成果ですが、そこに至るまでに要件定義書、設計ドキュメント、運用マニュアルなどの中間成果があります。序盤のフィードバックで「成果物リストを先に出そう」と言われハッとしました。

それを踏まえて、「やることとやらないこと」を明記してスコープの骨子を作る。その枠が固まると、ようやく見積もりとWBSが引ける。順序の学びが大きかったです。

中間の成果物が見えるとプロジェクトの解像度が上がりますね。では、プロジェクトのアカウントプランナーとして「クライアント役」との合意形成はどう進めましたか？

内藤：定例会議が行われる前段におけるネゴシエーションを意識しました。打ち合わせをする前にクライアントに対して、アジェンダに齟齬がないかや進行中に出てきた課題を先に共有しました。

その際に、自分たちの大枠の方向性が間違っていないかを確認し、よりクリティカルな議論を定例でできるよう心がけました。

当初は、相談というよりも「回答待ち」になりかけたのですが、「自分たちの仮説を持って臨むこと」を徹底してから、チームとしても意思決定が明確になりました。

要件定義書づくりで味わった試行錯誤

続いて要件定義についても伺います。「実装したいこと」と「工数・納期」との両立で工夫した部分はどんなことでしょうか？

廣川：プロジェクト開始当初の想定では「UX・機能追加」まで一気にやる構想でしたが、まずはサイトローンチまでの期限を優先しました。

この判断は自分たちだけの決定ではなく、クライアント役との合意形成を最優先しました。その際、「納期を最優先にすると何が外れるか」などを、事前のネゴシエーションや定例時のヒアリングで擦り合わせしていきました。

今回のフェーズ1では、PowerCMS X クラウドへの移行を主軸に据えました。今後のフェーズ2として、「社内アンケートによる機能ニーズの把握」なども検討しています。

佐藤：要件定義書については、BAで標準化しているテンプレートを使用しましたが、その当てはめにも苦労しました。というのも、要件定義書は、機能要件・非機能要件・リソース・リスク・マイルストーンなどさまざまな要素を含んでいます。

そのため、用語の定義から理解し直し、今回の「BApedia」にとっての意味を自分たちの言葉で書く必要がありました。そういった部分でエンジニア・デザイナーへの依頼自体の要件化にも時間がかかりました。

プロジェクト計画書・要件定義書で定めた内容を「WBS」へ反映する際、どのような部分が難しかったですか？

佐藤：成果物を起点にタスクを分解する視点が十分にもてておらず、初期段階では大枠の整理にとどまっていました。特に、エンジニア・デザイナーの領域は把握できていない部分が多く、同プロジェクトのエンジニア・デザイナーのメンバーに粒度を補完してもらい作っていきました。

また、WBSを引いた瞬間、「意外と余白がない」という危機感が生まれました。本来は計画書作成と同時並行で進めるべきだったと反省しました。
この過程を通じて、「成果物から逆算して考えること」の重要性を実感するとともに、計画と実行を同時に走らせる難しさと大切さを学びました。

内藤：このプロジェクトは若手中心ということもあり、社内テンプレートや知見についてを把握できていない部分もありました。今後のプロジェクト進行では、他のベテランメンバーのやり方や社内テンプレートを聞いて、BA全社的なノウハウを踏襲しながら円滑に進めていきたいですね。

「BApedia」プロジェクトを通して得た学び

皆さんは、BAに中途採用で入社していますが、今回のプロジェクトで前職での経験が役立った場面はありましたか？

佐藤：以前、接客販売の仕事をしていたので、「相手が何を求めているのかを察して、順番を考えて提案する意識」が自然と身についていたと思います。今回のプロジェクトでも、プロジェクトマネージャーとしてその感覚が活かせました。

廣川：自分は自動車営業をしていたのですが、そこで学んだのは「相手の状況を見て需要を読む姿勢」です。

お客さまが直接は言葉にしないニュアンスや背景をくみ取る力は、要件定義や合意形成の場面でもとても役立つと感じました。

内藤：私は保育・福祉系の営業を経験してきました。その際に鍛えられたのが、「傾聴」です。相手の話をしっかり聞きながら、自分のペースを崩さず対応する。

社内外の交渉や合意形成の場面でも、冷静にやり取りできたのはその経験のおかげです。あとは「揺さぶられないメンタル」も活きたと思います。

今回の「BApedia」プロジェクトで得た学びは何ですか？

佐藤：成果物から逆算して正確にタスクを洗い出す必要性を痛感しました。特にスケジュールを考えるうえでは、見えにくい工数を多めに見積もり、計画時点から盛り込むことが不可欠です。見積もりと実績を照らし合わせることで、精度を高めていきたいです。

また、お客さまがWebの専門家でない場合は、「やりたいこと」を要件に落とし込むために、業界用語の説明や「やらないこと・できないこと」を丁寧に伝える必要があると感じました。

廣川：CMS移行に必要な作業を理解できたのは大きな学びでした。今後のスケジュール作成やタスクの洗い出しの際に役立てられると思います。加えて、進捗確認は定例外でも適宜行う仕組みが必要だと実感しました。

良かった点としては、事前に代替案を検討できたことです。スコープを決定する際に「できること」「できないこと」を的確に伝え、できない場合でも代替案を出す。今後、新たな案件に参加する時も、そのような意識でお客さまとの合意形成を進めていこうと思います。

また、このプロジェクトで作成したドキュメントや知見を、他の案件でも進行の指針として活かしていきたいです。スケジュール作成の精度を高めることが次の目標です。

内藤：限られた時間とリソースの中で「何を優先し、何を後回しにするか」を決める難しさを感じました。工数を見誤ればプロジェクト全体が崩れるため、優先順位を見極める判断力をもっと磨く必要があります。

社内案件だからこそ許容された工数増加も、実際のお客さまがいる案件では通用しません。信頼を得るために、工数算出やリソース配分を軽視せず、限られた条件下で正しい判断ができるように成長していきたいです。

「型」を作る経験が、伴走力を育てる

前編の締めくくりとして、クライアント役を務めた小山に、本プロジェクト（上流工程）の取り組みと成果について振り返りをお願いしました。

「今回のプロジェクトでは、メンバーが自分たちの力で再現性のある「型」を作り上げたことが、一番の成果だと思います。

『成果物から逆算して考える力』や、『見えにくい工数をきちんと計画に落とし込む姿勢』、『スコープと合意形成を丁寧に積み上げる姿勢』。

どれもプロジェクトを進めるうえで欠かせない力ですが、実際の案件で試行錯誤しながら学ばせることは難しく、座学やOJTだけでは習得しにくい領域です。

それぞれが前職で培った経験を持ち寄り、チームとして補い合いながら成長していく姿はとても頼もしく、思わず自分がお客さま役であることを忘れそうになりました。

今回の取り組みで得たものは、きっと今後お客さまと向き合うときの大きな支えになると思います」（小山）

初期の計画書や要件定義は、多くの企業のWeb担当者がつまずきやすい領域です。今回のプロジェクトで若手メンバーが身につけた“型”は、まさにそこを一緒に整理し、合意形成まで伴走するための基盤。この経験で培った「伴走力」は、今後のプロジェクトでお客さまと共に課題を解き、成果を最大化するための確かな力となっていきます。

育成と実務を往還しながら成長を続ける、そんなBAの姿勢がこのプロジェクトにも表れていました。
続く後編では、デザインやCMS構築といった実装フェーズに焦点を当てます。上流で定めた計画や要件が、どのように具体的なアウトプットへとつながっていったのか。その奮闘と工夫を追いかけていきます。