三菱電機が挑む、サイロ化解消への一歩。シミュレーション研修で体感した「BizDevOps」加速のカギ

フェニックスプロジェクト DevOpsシミュレーション研修

• BizDevOpsへの理解を体験を通じて深めるため
• 事業・工場・部門ごとのサイロ化による連携不足を解消するため
• 壁を取り払うことで結果が出るという成功体験を積むため

• BizDevOpsは順番に流れるフェーズではなく、一体で動くという本来のあり方への理解が深まった
• 普段とは異なる役割を担うことで、他の立場が何を必要としているかの気づきが得られた
• 目標管理を年一回ではなく、短いスパンで方向性を共有する形に見直す動きが始まった
• 面識のなかったメンバー同士に一体感が生まれ、研修後も自然と声をかけ合える関係性が築かれた

設計技術開発センターのアジャイル開発推進プロジェクトグループに所属しています。社内の各部門向けに、社内事情をふまえたアジャイル開発の伴走支援・コーチングを行うのが主な役割です。今回は研修プログラムの選定や推進も担当しました。

同じ設計技術開発センターで、オープンソース＆インナーソース共創推進部の部長を務めています。全社の開発リードタイム短縮化を目的に、社内外のナレッジ共有と活用を推進している、2025年4月に立ち上がったばかりの組織です。城戸さんのグループとも連携しながら進めています。

FA（ファクトリーオートメーション）領域のサービスビジネスを展開する事業部門に所属し、主に部門内におけるアジャイル開発の浸透・定着の支援を担っています。20年以上前からソフトウェアエンジニアとしてアジャイル開発に携わった経験をもとに、他部署へ知見を展開することもあります。

IoT・ライフソリューション新事業推進センターに所属していて、空調や住宅設備、家電などの製品をクラウドに接続するためのIoTアプリ開発を行っています。あわせてAI導入支援やCI/CD、DevOpsの推進にも関わっています。

私が入社した2024年当時、社内ですでにBizDevOpsという言葉は知られていました。しかしBizDevOpsは本来、一体で動くものなのに、順番に流れるフェーズとして切り分けられてしまっていて、従来型の分業構造と大きく変わらない運用になっていました。そのため、今はその誤解を解き、本来あるべきBizDevOpsの考え方に近づけていっている途中です。

全社レベルで見ると、事業・工場・部門ごとに閉じられた構造による連携不足が長年の課題でした。サイロ化を解消するために、全社的な共通課題としてきちんと連携しようとする流れはあるのですが、工場や事業分野ごとに課題の形がまったく異なり、進め方を決めるには難しさを感じています。

私が2025年8月に開催された本研修の無料体験会に参加して、ぜひ社内でも実施したいと提案しました。

最初はお互いの情報共有がままならずゲームがうまく進まないところから、参加者が自然と壁を取り払う工夫を始めていくのですが、壁を取り払ったからこそ結果が出るという成功体験ができるんですよね。それを自分たちの事業に置き換えて「実践してみよう」と思ってもらえる人が一人でも増えればと思い、管理職のメンバーを中心に今回の受講者を選定して、2026年2月に実施しました。

実は以前、半日版のワークショップに参加したことがあって、内容のベースとなった書籍も読んでいたのでフェニックスプロジェクトのことは知っていたんです。だから今回は、一緒に参加する社内のメンバーがどんな反応を示すのかという観察者的な視点でも興味を持って参加しました。

BizDevOpsの概念は理解していましたが、ワークショップという形でどう体験として伝えられるのかに興味がありました。参加してみたら、期待以上に面白くて学びのある一日でしたね。

私はアジャイル開発の担当歴もそれほど長くなく、一日まるごとロールプレイで進める形式は初めてでした。どのような体験になるんだろうという期待と、ちょっとした緊張感を持って参加しました。

私の本来の職務はエンジニアですが、研修ではあえてBiz側の役割を選びました。最初のラウンドでは、タスクや情報をまずBizからDevへ、そしてDevからOpsへと順番に受け渡していく流れになってしまい、チームがうまく連携できず、プロダクトのリリースもほとんどできませんでした。三菱電機の現場でも起きてしまう構造でもあり、「ああ、これか」と気づいた瞬間でもありました。

ところが、各ラウンドの振り返りで「どうすればもっとよくなるか」をチームで話し合い、出たアイデアを次のラウンドで実践していくうちに、タスクの流れがスムーズになり、スコアにも反映されていきました。意思決定をする立場や経営層は、細かい開発の中身をすべて把握している必要はないものの、全体の仕組みの中で何がボトルネックになっているのかは把握していないといけないと改めて感じました。全員で同じ方向を向いて動くことの重要性が、体験を通じて腑に落ちました。

外部環境に応じてBizが適切な情報を流すことの重要性が、体感でわかりました。全4回ある各ラウンドの終了時に結果が数字でフィードバックされるので「なんとか目標を達成したい」と、ゲーム性が自然に生まれるところも場が盛り上がる要因の一つになりましたね。

この感覚は、目標管理のあり方にも通じるものがあると感じます。年に一回目標を設定して終わりではなく、もっと短いスパンで見直していくことがモチベーションやパフォーマンスにつながるんだなと、管理職の視点でも改めて気づかされました。

私は運営側だったので外から見ていたのですが、参加者の中でも若手メンバーは最初遠慮がちに見えました。しかし、時間が経つにつれて、上着を脱いで汗をかきながら必死に議論するようになって、自然と一体感が生まれていましたね。体験型の研修だからこその行動変容だと感じました。

チームビルディングという側面でも効果が大きかったと感じます。面識がなかったメンバーも参加していましたが、研修が終わった後はかなり打ち解けた関係になっていたんです。研修後、廊下ですれ違った時に自然と声をかけるような関係性になれました。

「トラブルがあった際にみんなで一緒に乗り越えると絆が深まる」感覚ってありますよね。あれに近いものがあるのかなと思います。

まず、部署内のマネジメントのあり方を見直しているところです。目標設定を年一回行うだけでなく、今後は月次での目指す姿も打ち出し、伝えていきたいと考えています。フェニックスプロジェクトを通して、一体感やモチベーションというものは、短いスパンで方向性を共有していくことで作られていくんだと実感したからです。それと、研修を通じてチームビルディングの効果を非常に実感したので、部署内のメンバー同士でもこの体験を共有したいと思って再受講を検討しています。

研修を通じて、サイロ化は大なり小なりどの組織やチームにもあると改めて感じました。一つの組織の中にチームが分かれているため、みんな別々に同じような機能を作っていたという、いわゆる「車輪の再発明」のような非効率なことも起こってしまいがちです。そうした現実をふまえ、BizDevOpsを支援する立場として、「推進する」より前に、その組織が本当に何を必要としているかをもっと深く入り込んで観察して判断することが大事だと思いました。押しつけるのではなく、必要だと感じてもらえるような関わり方に変えていきたいという議論を、今組織の中で行っています。

新しいメンバーが増えてきている部署でもあるので、みんなが同じ方向を向いて動けるような土台を作っていきたいです。部のリズムづくりを着実に進めながら、研修で感じたチームビルディングの効果を新しいメンバーにも体験してほしいと思っています。

研修ではBiz側の役割を体験しましたが、普段の自分はDev・Ops側のエンジニアです。研修を通じて、ビジネス側の意思決定には現場のデータが不可欠だと実感したからこそ、今後はその橋渡しを自分たちから作っていきたいと考えています。具体的には、システムの稼働状況やサービスの利用データを可視化し、「現場で何が起きているのか」をビジネス部門がリアルタイムで把握できる環境を整えることです。チーム間の連携と優先順位の明確化を進めながら、開発・運用側からビジネス側への情報共有フローを仕組みとして定着させていきたいです。

一人でも多く、腹落ちできる人を増やしていくことですね。近道はないですが、フェニックスプロジェクトを受講して気づきを得た人が周りに学びと具体的な実践方法を伝えていく、その連鎖をつくっていきたいと思っています。

支援する側として、相手が本当に必要としているものを見極める目を磨いていきたいと思っています。必要に応じてアジャイルの手法やBizDevOpsの啓蒙・紹介を続けていきたいと思います。