――R&D部門の業務内容を教えてください。
増田：三菱電機の中にある多岐にわたる事業部門を横断し、最先端技術の研究開発に取り組んでいます。
このチームが担当する領域は幅広く、昨年度は特に発電系、自動車、宇宙関連といった多様な部署からの研究依頼を受けています。
研究領域としてはLinuxや組み込みシステム、特に非常に小さい基盤で動作するソフトウェアの開発を主要なミッションとしています。社内の各事業部門から寄せられる製品開発におけるOSや低レベルソフトウェアの課題解決を支援するだけでなく、自身で調査したOSS（オープンソースソフトウェア）や先進技術の適用を提案し、そのプロトタイプ開発も手がけています。
――どのようなチーム構成で業務にあたっていたのでしょうか？
増田：今日お話しさせていただくのは昨年度の取り組みで、当時は4人の研究者と1人の外部エンジニアからなる計5名体制のチームで進めていました。全員が組み込みソフトウェアの研究を専門としており、私はチームリーダーとして5人のメンバーを統括していました。
――その中で感じていた課題は何でしょうか？
増田：大きく三つの課題を感じていました。一つ目はプロジェクトの期間の問題です。我々は社内の製品開発拠点(社内用語で場所と呼びます)と連携した研究を行い、個々の研究テーマを研究依頼と呼んでいます。研究依頼は基本的に一年単位で進行しており、年度の始めに依頼を受け、年度末に成果を出す形が一般的です。具体的な納期が指定される場合もありましたが、特に指定がなければ年度末の完了を目指すことが多かったです。そのため年度の初めに一年間を通してのスケジュールを引かれる、という点で途中で状況が変化しても柔軟な対応が難しいと感じていました。
二つ目は案件同士の独立性です。我々は複数の場所の研究依頼に取り組みます。そのため技術領域が同じだけで事業は全く異なることが多いです。また、我々の部署の研究テーマでは研究依頼の規模が小さいことが多く、一人の担当者が複数の場所の研究依頼を掛け持ちすることがよくあります。そのため、案件同士でスケジュールの融通をきかせることは難しく、同時並行で研究することが多かったです。
三つ目は業務の属人性です。我々は個人単位での案件管理が中心でした。各研究者が1人または2人で複数の研究依頼を受け持ち、それぞれの専門分野において個人のペースでスケジュールを立て、作業を進めることが多かったです。チーム内で情報共有はしても連携は少なく、自分に関係のない案件では他のメンバーの報告が「身に入らない」と感じることもありました。各研究者が独立して専門性の高い領域を担っていたため、属人性が高く、担当者が育児休業取得や人事異動などで離れる際、後任への引き継ぎや初動に時間がかかり、業務の継続性が課題となっていました。
チームリーダーがすべての案件を把握し、メンバーへのアドバイスを行う役割を担っていましたが、各メンバーが抱えるタスクリストを個人で管理していたため、メンバー間での情報共有が進みにくく、案件の透明性が低い状態だった点も、課題として認識していました。
矢吹：私も「チームとして協力して進めていきたい」という思いは持っていたものの、各研究者の専門性が深いため、「他のメンバーの得意な領域の仕事を自分がそのまま担当することは難しい」という考えでした。また、リーダーの増田さん以外のメンバーにどこまで助けを求めて良いのかも不明瞭で、結果的に相互協力が難しいと感じていました。
――増田さんはそのような課題を感じていた状態でScrum Inc.認定スクラムマスター研修を受講されたと思います。研修で印象的だったのはどのような点でしょうか？
増田：私は、上司とは以前から、研究というものは最初からゴールが見えているわけではなく、まさにアジャイルの考え方と親和性が高いのではないかとよく議論していたんです。食わず嫌いせずに一度ちゃんと学んでみよう、という気持ちで参加しました。
研修で特に印象的だったのは、やはり「改善のループを回していく」という考え方でした。研修の中で、実際に紙で飛行機を作って飛ばし、その結果を計測してフィードバックし、折り方を変えていくというワークがありました。「改善こそがスクラムなんだな」というのを強く感じました。「入念に計画するよりも、短くサイクルを回して早く失敗して次の成功につなげる」というスクラムの教えは、まさに研究の進め方と同じです。
この研修を通して腹落ち感があったのは、スクラムイベントの「意義」を教えてもらえたことです。これまでは、スクラムイベントの「進め方」はなんとなく知っていても、「何のためにこのイベントがあるのか」という「意義」までは理解できていませんでした。研修で説明を受け、一つ一つ埋まっていくようなイメージでした。例えばデイリースクラムは「毎朝（進捗を）フォローされるのか」と正直悪いイメージを持っていましたが、困ったことを共有する開発者のためのイベントであることが分かり、やるべきイベントだと納得しました。
仮説を立てて試してみて、結果を可視化して次に繋げるという研究のやり方と、アジャイルは本当に同じだと実感しました。
――研修の学び中で、実際の業務に活用したいと思えたポイントはどんなものがありましたか？
増田：「T型人材」としてチームで力を合わせるということを実践したいと思いました。私たちのチームの研究依頼は、一つ一つが小さい案件になりがちで、一人または二人で担当することが多かったので、これをスクラムに当てはめるのは難しいと感じていたんです。でも、研修を通して、「プロダクトが小さいのなら、それらをまとめてしまえばいい」という発想に至りました。複数の研究依頼を「エピック」のように捉えて一つにまとめることで、小さな案件でもスクラムを適用できるのではないかと思ったんです。これは、必ずしも大きなプロダクトがなくても、スクラムの考え方や「改善のループ」を外さなければ、部分的にでも取り入れて良い効果があると確信できたことでもありますね。
――実際にチームで実践するにあたって困難なポイントがあったのではないかと思います。リーダーの増田さん、メンバーの矢吹さんそれぞれの視点でどのように感じていたのかを聞かせてください。
増田：チームメンバーへの導入時には、まず「スクラム的な運用をしたいので、全案件みんなで協力してやっていきたい」という方針を伝えました。メンバーの不安を払拭するため、「目的と効果」を明確に説明し、説得用の資料も作成しました。例えばデイリースクラムについては、スクラムマスター研修で学んだように「開発者のためのイベント」であり、マイクロマネジメントのためではないなど、実施する意義について繰り返し伝えました。最初のころはデイリースクラムの冒頭で毎回その宣言をしていました。
実際の導入では、まず全ての研究案件をAzure DevOps (Microsoft DevOps) に載せて可視化し、スクラム型で管理できる基盤を整えました。イベントの開催時間についても、子育て世代のメンバーが多かったことから、教科書通りの朝ではなく、デイリースクラムを昼にやるなど調整しました。また、当初は教科書通りに各イベントを一通り実施し、最初の3ヶ月間をトライアル期間と設定したんです。3ヶ月後に四半期のレトロスペクティブを行い、継続するか元に戻すかをチームで決めることにしました。この「お試し期間」の設定は、メンバーが安心して取り組めるようにするための配慮でした。
矢吹：私は、増田さんからスクラム導入の提案を受けた際、製作所から研究所に戻ってきたタイミングで、新しい仕事と新しい管理方法が同時に始まったため、最初は正直いっぱいいっぱいな気持ちでした。スクラムの目的や効果は理解できたのですが、実際にやってみると本当にできるのか、みんなが大変な思いをするんじゃないかという不安を抱えていました。
そんな中、増田さんが設定してくれた3ヶ月間のトライアル期間や、疑問に思ったことをすぐにディスカッションできる環境、そしてチームで話し合い、フィードバックする機会が設けられていたことで、徐々に変化に適応していきました。
当初は、スクラムを導入することで抱える案件の数が増え、多様な知識が必要になるという大変さも感じていましたが、最終的にはとても納得感高くチーム向けの運営方針が出来上がってきたと感じています。
3ヶ月のトライアル期間が終わった際には、チーム全体で「このままやめたくはない」という意見で一致しました。これは、スクラム導入によって具体的な良い変化を実感できたためです。
以前は一人で悩む時間が多かったのですが、デイリースクラムなどで困っていることを話したり、新しい発見を共有したりする機会が増え、「話したら解決にみんなで考えてもらって解決に向かえる」という感覚になりました。また、案件の状況や業務内容がチーム全体で共有されたことで透明性が上がり、これにより業務の属人性や特定の人への依存性が下がったと感じています。
さらに、外部エンジニアのメンバーも含め、作業の背景知識を共有しやすくなったことで、自発的に「次こういうことやった方がいいんですよね」といった提案が飛び交うようになり、意識も変わったという実感があります。実際に情報をオープンにしていくことで、「逆に仕事が進めやすくなる」という実感が得られました。スプリントごとのレトロスペクティブを通じて、自分たちのやり方を常に「より良くしていけた」という「改善していく実感」があり、それが「心地よさ」につながっています。
――まさに増田さんが研修で感じた「改善していく良さ」を感じられていたのですね。一方で、導入時や導入してみて感じられた課題はどんなものがあったでしょうか？
増田：異なる事業を担当している複数の場所がステークホルダーであり、それぞれが異なる優先度を持っているため、全体を通した案件の優先順位付けが難しかった点です。そのため、チームが一つのバックログアイテムに集中して取り組む「スウォーミング」が難しかったと感じています。これは依頼元（場所）との調整が十分ではなかった反省点だと振り返っています。
矢吹：私も同じく優先順位の決定が難しかったと感じています。また、タスクが多かったことや、年間を通して先々の計画があまり決まっていない研究の性質上、期日だったりその先々の計画デリバリープランとかを立てることがうまくできませんでした。しかし、これらの課題に対しては、案件によってスプリントの幅を変えるなど、引き続き改善に取り組んでいます。
例えば、成果が出にくい案件はスプリントを1ヶ月にするなど、仕事の種類に応じて柔軟に対応しています。
――チームとしては常に改善中だと思いますが、今後はどのような点に注力したいとお考えでしょうか？
増田：私が今後さらに取り組んでみたいと考えているのは、まずスクラムやアジャイルの考え方を研究所全体に広げ、定着させることです。私は今年(2025年)の4月からマネージャになったため、昨年度私が担当していたスクラムチームはすでに次のチームリーダーに引き継ぎましたが、彼らはこれまでのやり方をさらに改善し、より良い取り組みを進めてくれています。私のグループにはもう一つ別のチームがあり、そちらでもデイリーでの打ち合わせを始めるなど、スクラム的な運用を徐々に取り入れています。この考えは、だんだんとスクラムを実践することが当たり前、つまりスタンダードになってきているという実感があるからです。
また、若手社員へのスクラムの展開にも力を入れたいと考えています。現在、若手研究者たちが「ロボコン」（ETロボコン）というコンテストに取り組んでいるのですが、私の方からスクラムでやってみてはどうかと提案したところ、彼らは自発的にその手法を取り入れてくれました。ロボコンのように最初から明確なゴールが見えていない研究開発においては、仮説を立てて試作・実験し、結果を計測して改善していくというアジャイルの手法が非常に親和性が高いと強く確信しています。
これまでの経験を通じて、たとえ小さな研究であっても、部分的にスクラムの考え方を取り入れることで良い効果が得られると確信できるようになりました。今後は、そのような部分的なスクラム導入の推進も行っていきたいです。
そして、研究成果を受け取ってくれる事業部門(製作所)側の人々にもスクラムの考え方をより深く理解してもらうことが非常に重要だと感じています。短いサイクルでフィードバックをもらう場を設け、密なディスカッションを通じて連携を深めていくことで、お互いにメリットを感じ、より効率的に仕事を進められるようになると考えております。
最終的には、研究所がより高い顧客価値を創出できるよう、「早く変化のサイクルを回せる組織になる」という意識を私たち自身が持ち、その実現に向けて貢献していきたいと強く思っています。
――最後に、これからスクラムに取り組もうと考えている方へアドバイスいただけますでしょうか？
増田：私たちが実践してきたのは、教科書通りの「ちゃんとしたスクラム」ではなかったと思います。しかし、最も重要だと感じているのは、「アジャイルの価値基準」やその「考え方」です。特に、「改善のループを回していく」という点が非常に大切です。この核となる考え方を外さずに実践していけば、たとえ完璧なスクラムでなくても、様々な仕事に応用でき、多くの良い効果が得られるはずです。
最初は「スクラムは難しい」と感じるかもしれませんが、ぜひ一度チャレンジしてみてほしいと思います。完璧な計画や成果を最初から目指すのではなく、仮説を立てて試行し、それに対してチームで振り返りを行い、評価し、次に何をすべきかを繰り返していくこと。これは研究開発だけでなく、どんな仕事においても改善していくために非常に重要なことだと強く感じています。
