変化の激しい時代に対応すべく、アジャイル開発の代表的なフレームワーク「スクラム（scrum）」に関心を示し、導入する企業が増えつつある。
パナソニックグループの関係会社であるパナソニック システムデザイン株式会社もそのうちの一つ。
ソフトウェア開発からマネジメント、デザイン、コンサルティングと、DXを中心に事業領域を拡張し続けてきた。家電のIoT化が進むと共に、従来の開発手法に限界を感じるようになり、2021年4月よりスクラムの導入を開始した。
スクラム推進チームWUMPATSのマスコットキャラクター
実は10年前にもアジャイル導入を試みたが、当時はアジャイルの考え方が現場に浸透せず、導入に失敗した。社内には30年近くもウォーターフォール型開発に慣れ親しんだ開発者もいる。
導入から現在に至るまでには、越えるべき壁がいくつもあった。苦い経験を踏まえ、今回のスクラム導入ではScrum Inc. Japan （以下SIJ）によるサポートのもと、スクラム推進チーム・WUMPATS（ウンパツ）を設立。従来のウォーターフォール型開発からスムーズに考え方を移行するための体制を整えている。
SIJの伴走のもと、どのようにハードルを乗り越えたのだろうか。また、導入から2年が経過した現在、どういった効果を実感しているのだろうか。
WUMPATSのメンバーでありプロダクトオーナーの芳本孝史氏とスクラムマスターの川田純子氏、そしてSIJのアジャイルコーチを務める清水麻由氏を中心に話を伺った。
左から、SIJ清水麻由氏、パナソニック システムデザイン川田純子氏、芳本孝史氏
──スクラムを導入して約2年半、どういった効果を感じていますか？ まずはスクラムマスターの川田さんいかがでしょうか。
川田純子（以下、川田） 最も強く感じたのは「人の変化」です。
当初は各プロジェクトのメンバーとして参加している開発者も、受け身の姿勢が多かったんです。「言われたことをしっかりやる」というスタンスが浸透していて、スクラムの導入に関しても「なんでそんなことをやるの？」と消極的だった印象があります。
一日のはじめに、デイリースクラムという、ミーティングを毎朝行うところから始めるのですが、その時も皆さんの頭上に「？」が浮かんでいるような様子でした（笑）。
デイリースクラムとは、チーム内でゴール地点までの道のりを確認するための「昨日やったこと」「今日やるべきこと」「仕事の障害となっていること」の３つを共有するんです。
それでもデイリースクラムを繰り返すうちに少しずつ発言量が増えて。プロジェクトの進行に積極的になっていくのが伝わりました。
導入から3ヶ月で、発言量が10倍に増えたチームもあるんです。
──プロダクトオーナーの芳本さんは、どんな変化を感じていますか？
芳本孝史（以下、芳本） 川田が話した「人の変化」にもつながるんですが、実は人材育成が加速しました。従来のウォーターフォール型のプロジェクトでは、「データベース」「プログラミング」など、専門的なスキルを持った人をアサインし、役割を分担していました。
しかしスクラムではメンバーのスキル領域を決めず、お互いのタスクをフォローし合いながら開発を進めます。設計からプログラミング、テストまでを網羅できるような人材が求められるようになりました。
通常、技術者のスキルの底上げには時間がかかります。しかしスクラムチームでは、チームで仕事を達成することを目指すため、ペアプロやモブワークなどのプラクティスを駆使してスキルトランスファーを行います。それによって現場のメンバーも徐々にさまざまな種類のタスクを自然にこなせるようになりました。
スクラムが浸透することで、技術者を育成しやすい環境が生まれていると実感しています。
30年培ってきた考え方を抜本的にシフトすることの障壁
──パナソニック システムデザインのスクラム推進チームはどういう手順でスクラムを浸透させたのでしょうか。
川田 まずは2021年7月に、WUMPATSや当部門のメンバーを中心に他部門のメンバーも含めた社内の40名程度で、SIJさんの合同セミナーを受講することから始めました。
そのうえで「導入をリードする自分たちが腑に落ちなければ社内にも浸透させられない」と判断し、私を含むチームメンバー3人で、15分間のデイリースクラムを習慣化しました。
スクラムの考え方、適切にコーチングするための伝え方や表現のコツを身につけてから、初めて実案件のプロジェクトチームにWUMPATSメンバーが参加するようになりました。
──すんなりいきましたか？
川田 いくと思ったんですけどね（笑）。蓋を開けてみると想像以上に険しい道のりでした。
研修を受けたときの第一印象は、「参考書などを読めばスムーズに展開できそう」だったんです。でも頭で方法や意味を理解することと、実際に腹落ちしてできるようになるのにはギャップがありました。
私も含め、現場の開発者は30年近くもウォーターフォール型の開発に親しんできました。やっぱりそのときの常識や考え方が染み付いていて、根本的に発想を変えることは、1〜2日程度の研修では済まないんです。
そして、自分がようやく手応えをつかんでから受託のプロダクトではなく自社プロダクトでの運用を開始しました。実際に始めてみると実務にあたるメンバーに、デイリースクラムのイベントひとつとっても目的を理解してもらえず、「こんなに伝わらないのか」と絶句した記憶があります。
その間もアジャイルコーチであるSIJの清水さんに、コーチングの様子を観察・フィードバックいただきながら、徐々に経験値を積み上げていきました。
──現場の考え方を変化させていくために、どういったアクションを起こしましたか？
川田 基本的には各プロジェクトチームにべったりと伴走しつつ、スクラムイベント※ を繰り返すなかで理解してくれたところが大きかったです。「チームが自発的に動くようになるまでには辛抱が必要」ということも、実案件に関わる中で心得ました。
例えば、デイリースクラムを例に挙げると、まずはその場が機械的な報告にならないよう心がけました。
デイリースクラムは冒頭で述べた「3つの問い」をもとに進行します。「昨日やったこと」「今日やるべきこと」「仕事の障害となっていること」。
ただ、この質問フォーマットを意識しすぎてしまうと目的をつい忘れてしまうんです。
──目的ですか？
スクラムはフレームワークなので、その型だけをなぞっても目的を理解していないと意味のないイベントになってしまうんです。
何のためにこのイベントをやっているのか？をメンバーが理解できれば、そのためにこの場で何を発言すれば良いか、がわかります。そうなれば、そのチームは自律的にスクラムイベントを実施していけるようになるからです。
そしてそれをチームにコーチングしていくのがスクラムマスターの役割なんです。
その時にチームにどうコーチングしていくかに関しては、清水さんにもフィードバックをいただいた部分が大きくて。定点観測をいただきながら、依存しすぎない距離感で見守っていただけるのはありがたいなと感じています。
──SIJのアジャイルコーチである清水さんは、いわば、スクラムを現場に伝える川田さんを指導するわけですから、いわば先生の先生という立ち位置ですね。どのようなフィードバックをされたのでしょうか。
清水麻由（以下、清水） 「言われたことをやる」から「自分たちで考えて実行する」になってもらうことです。なので、みなさんから質問をされた時に、その答えをただ返すのではなく常に「なぜそれをやるか」を聞くようにしていました。
パナソニック システムデザインさんに限らず、日本の企業は「正しくやりたい」という気持ちがすごく強いんです。でも、「正しさ」は目的や、環境、時代によっても変わります。
もちろん「このやり方は合ってますか？」と聞かれて「正しいです」と答えるのは簡単ですがそれより「目的はなにか」を確認し、そのために何が正しいのか、と考えてもらう必要があります。すると、「言われたことをやる」が正しかったところから、自分自身の頭で考えて行動するに変化し、チームの自律性も生まれます。
特にパナソニック システムデザインさんの場合は、パナソニックグループとして長年の歴史や伝統があるからこそ、社内が「既存の正しさ」に過剰適応している一面もあるように感じました。しかし、スクラムを導入した目的は「既存の正しさ」の外にあります。
間違っている場合は「違います」と伝えつつ、あえて何が正解かを一緒に考えることで、我々のサポートがなくても自走できるようなコミュニケーションは意識していました。
川田 全員が同じゴールを向いて足並みを揃えられるよう、チームに伝える言い回しひとつにも注意しています。そのレベルにチームがなるには、自分で考えないと身につきづらいんです。
──芳本さんはいかがでしょう。導入するに当たってどんな課題がありましたか。
芳本 おっしゃるとおり、「既存の正しさ」の壁は、今現在も課題です。
パナソニックグループには「市場に出すものは完成されたものであるべき」というモノづくりに対する文化があると考えています。設計品質や実装品質、最終的なプロダクトの品質などを上流からきっちり管理しながら、工程ごとのチェックポイントを経て出荷するプロセスが根付いています。
一方でアジャイルの場合は「完成されたものよりも、早く市場で評価して早くアップデートする」ことが重要だというアプローチです。そうなると、社内の品質保証のプロセスから考え方を改める必要があります。
それは単に既存のルールに例外を設ければいいという無責任なことではありません。先ほど川田も「辛抱が必要」と言っていましたが、社会的責任を担保したうえで、今まで培ってきたノウハウを捨てるには、相当のエネルギーが必要です。
「パナソニックグループとしてどうあるべきか」を考え抜いて判断せねばなりませんでした。
そこでSIJさんのご協力を仰ぎながら、スクラムに対応した品質管理プロセスをまとめた「スクラムガイドブック」を作成。実際に品質部門のメンバーにも同席してもらい「スクラムの場合は“品質”をどう捉えるべきか」「どういった工程を加えるべきか」などの検討を重ねました。
このガイドブックを、3〜5年ほどの中長期的なスパンで、少しずつ浸透させていければと思っています。※ スクラムイベント：スクラムの要素として定義されているスクラムチームのメンバーが集まり実施する定期的な会議のような場。セレモニーとも呼ばれる
「モノづくり」の基本に立ち返るきっかけに
──スクラム導入に当たり、SIJに依頼した期待値はどのようなものだったのでしょうか。
芳本 一度アジャイルの導入で挫折を経験しているからこそ、しっかりと寄り添って、考え方を根本的に変えてもらえそうな企業にお願いできればと考えていました。
その上で、SIJさんはセミナーや資格所得の推進など、スクラムの支援活動を積極的にされている。我々も学ばせていただくことが多いと考え、ご相談をした次第です。
清水 ありがとうございます。
今回のご支援を実施する際、パナソニック システムデザインさんが「自走していける状態になること」が目指すゴールである、ということを初めに合意しました。これは、基本的な我々のスタンスで、どのお客様にもお伝えします。
そのために、初期の段階ではまず基本的な知識のインプットのための研修や、スクラムチームを初めて立ち上げるワークショップを実施するなど、我々コーチもしっかり入ってサポートする。
そしてスクラムマスターの方が、チームをコーチングできるようになっていくに従って、我々は少しずつフェイドアウトしてく、というやり方を行います。
ですが、スクラム運営の改善や推進活動に終わりはありません。
──SIJと共にスクラムを推進するなかで、印象的だったことを教えてください。
川田 私個人はコーチングのフィードバックをいただいた時のことを鮮明に覚えています。
当社は、主にパナソニックグループの多くの事業部からお仕事を発注いただき、モノづくりに臨んでいます。各プロジェクトのチームメンバーも、プロダクトオーナーは事業部で立て、開発者は当社からメンバーを揃える、という編成が中心です。
だからこそ開発者はプロダクトオーナーに「お伺いを立てる」というスタンスを切り離せなくて。私自身も、そういった社内の遠慮してしまう部分が、コーチングに現れてしまっていました。
すると、ある時、清水さんが、「プロダクトオーナーはお客さんじゃなくて同じチームの仲間ですよ」とズバッと指摘してくださって。そのアドバイス以降、チームメンバーをフラットにとらえる、ということを意識するようになりました。
──芳本さんはいかがでしょう。
芳本 私よりも現場のメンバーの声も聞いてみるといいかもしれないです。水﨑さん、ちょっといいですか。
水﨑知恵（以下、水﨑） はい。
──水﨑さんはスクラムを導入してみて、開発メンバーとしてどのような変化がありましたか？
水﨑 そうですね、シンプルに楽しいというか、「モノづくりに携わっている」という実感を得られたのは大きかったです。
ウォーターフォール型の開発では、上流から下流へと降りてくる指示に従うだけでした。でもスクラムだと、自分も「企画を考える側」、つまり上流の立場を経験できるようになり、プロジェクトを自分ごと化できるようになったんです。
従来は、納品後に「やっぱりこう作り変えて」と言われ、モチベーションが下がってしまうこともありました。しかしスクラムの場合、アップデートを重ねることが前提となります。短期間でちょっとずつ作るからこそ、大きな仕様変更が発生することもありません。
結果、修正指示に対する抵抗感がなくなり「そういう考え方もあったのか」と受け入れやすくなったことも、スクラムによる影響が大きいのかな、と感じています。
今まであまり企画サイドに対しアイディアを投げることもできなかったのですが、「こうした方がいいのでは」という提案もしやすくなりました。
──最後に、スクラムを社内に浸透させるうえで心得ておくべきことについて、アドバイスをいただければと思います。
芳本 私はプロダクトオーナーの立場として、エンドユーザーと対話することが重要だと感じました。
今まではエンドユーザーありき、というよりも「指示通りに作り、リリースしたら終わり」という空気がありました。しかし、本質的なモノづくりをするためには、やはり「出して終わり」じゃ意味がない、とスクラムを通して気づかされて。
必ずしも直接的にエンドユーザーの声に触れる必要はありません。
しかしレスポンスやフィードバックを吸い上げて、プロダクトへ反映することで、より良いモノづくりに取り組むことができる。スクラムは、モノづくりの基本的な考えに立ち返るきっかけになったと思います。
プランニングポーカーアプリのUI
その実践として、我々としてオリジナルのプランニングポーカーアプリを開発し、SIJさんのセミナーでもご利用いただきフィードバックによる改善を行っております。
川田 なぜ今までのやり方を変えてまでアジャイルに取り組みたいのか、その理由を忘れないことは重要だと思います。
これまでの方法でも開発を進めることはできるし、むしろ変えることの苦労も大きいです。私も最初はくじけそうになりましたし、いまだに一筋縄ではいかないところを感じています。
その上で「何を成し遂げたいのか」ということは見失わないこと。そしてその問いを自分自身だけではなく、チームメンバーにも投げかけ続けることが、スクラムを推進するうえで重要なポイントだと思います。
同社でスクラムの導入を見守るパナソニック システムデザイン株式会社 代表取締役常務・垂石淳平氏は、スクラムのもつ可能性について、次のように述べる。
垂石淳平 当社はこれまでもソフトウェア開発やマネジメントなどでクライアントに貢献してきましたが、今後も持続的に貢献し続けるためには、クライアントと一緒に事業課題について考え、事業成長に貢献していくこと、つまり「B to B」から「B for B」へと目的意識を変えていくことが重要です。
クライアントと伴走する役割を担いながら、課題を解決し、我々も成長していく。そのためには、スピード感を持ってプロダクトを柔軟にアップデートできるスクラムが必要不可欠な武器になる、と捉えています。
なお、WUMPATSチームのメンバーは大きく3つのミッションを掲げています。
一つはアジャイル開発プロジェクトを通し「『その先』を創る」という社の行動指針のもと、クライアントの事業に貢献すること。
二つ目は活動を通し、社内メンバー全体の人材育成にあたり、組織力の強化に貢献すること。
そして三つ目はプロジェクトで得た経験やスキルを活かし、パナソニックグループ以外のお客様にも貢献できるようになること です。
プロジェクトを通して自他の成長を促しながら、今後もより広範囲にチャレンジを続けていくことを期待しています。
