パナソニック コネクトの技術研究開発本部は、サプライチェーン専門のITベンダーであるBlue Yonderとのジョイントソリューションチームを立ち上げ、オートノマスサプライチェーンの実現を目指している。同チームでマネージャーを務める森香織は、新たな企業との出会いと経験を経て、短期の開発と改善を繰り返して製品の完成度を徐々に上げる｢アジャイル開発｣の推進を始めた。
組織に新たな開発手法を取り入れるために、トライアンドエラーを繰り返しながら模索していたという当時を振り返りながら、どのようにこれまでの開発手法から脱却して、アジャイルに挑んだのか語ってもらった。
不確実性の高い時代だからこそ、｢お客さま志向｣の開発が必要
――まず、アジャイルに森さんが取り組むことになった経緯を教えてください。
森：パナソニック コネクトの研究開発（R＆D）部門には、大きく2つの役割があります。ひとつは｢現場プロセス事業に貢献する先進技術の研究開発｣。もうひとつは｢Blue Yonder並びにパナソニック コネクトの事業部門との、マーケット･お客さまからの逆算による新規事業･ソリューション創出｣。Blue Yonderとのジョイントソリューションチームに所属している私のミッションは、後者ですね。
私の部門では、Blue Yonderとともに仕事をするまでは基本的にウォーターフォール開発でした。例えばスマートフォンのアプリなどでは、すでにアジャイル開発がスタンダードです。ただ、私たちが主に携わってきた、大規模な組み込み系のシステムやソフトウェア開発においては、ハードウェア開発側や生産工程との緊密な連携が欠かせないことなどもあり、アジャイルの導入は進んでいなかったんです。
しかし、Blue Yonderの品質管理システムを見せていただいたら、私たちのこれまでのウォーターフォールの開発手法とはまるで違って衝撃を受けました。Blue Yonderと連携して、ソフトウェアビジネスへの変革を進めていくためにも、アジャイル開発を取り入れなければならないということで、挑戦が始まりました。当初は、とにかく新しい手法に慣れることに必死でしたね。
――ウォーターフォールとアジャイルでは、どのような違いがあるのでしょうか？
森：ウォーターフォールとアジャイルでは、同じソフトウェア開発のプロセスでもそのアプローチは全く異なります。ウォーターフォールは、要件定義に基づいて、一つ一つの工程を細かく確認しながら、段階的に進めていく開発プロセスです。
一方、アジャイルは｢その時点でできる限りのものをまずいち早くお客さまに提出して、フィードバックをもらって、修正して…｣というループを繰り返します。
ソフトウェアベースのソリューション事業においては、お客さまご自身も現場の課題解決にどのようなものが必要か明確に定義できていないことが多いです。だからこそ、｢agility（敏捷性）｣を持って、いただいたフィードバックを踏まえて、お客さまに提供できる価値を考えることがすごく大切です。そのための開発手法として、アジャイルは欠かせないものだと私は思っています。
――具体的にどのようなソリューション開発にアジャイルの手法を取り入れているんでしょうか？
森：最近の例でいえば、倉庫や物流拠点で使われるヤードマネジメントシステム（YMS）ですね。｢積荷を運搬するトラックが敷地内で無駄な移動をしたり、指定とは違う停車場に駐車したりすることで、タイムロスや冷凍品の劣化が発生している｣という相談をアメリカの物流会社からいただきました。その問題を解消するために、カメラでトラックの動線を検知したり、物体検知技術を応用したり……と、どんな技術がお客さまの課題解決につながるのか、アジャイルで探っているところです。
先日現場にカメラを設置したのですが、その際には画像認識技術の研究開発を行っているメンバーにも同行してもらい、お客さまからいただいたフィードバックをその後の研究開発に役立てています。不確実性が高く、現場に必要なソリューションを定義しづらい今の時代には、先進技術の研究開発においても、研究室内だけで行うのではなく、｢現場が求めるもの｣や｢お客さま価値｣を直接見て、その場でフィードバックをいただいて研究開発を進めることが、重要だと思います。
――持続的に顧客に価値を届けられる研究開発が重要だと。
森：そうですね。｢お客さま価値｣という意味では、短期間でプロダクトを作って、お客さまのフィードバックをもとにアップデートしていくアジャイルのプロセスは、お客さまにとっても良い開発手法だと思います。早く軌道修正ができるし、仮説検証の結果を見て、｢今作るべきものはこれではない｣となれば、その時点で改めて開発の方針を見直す…という決断もしやすいので、無駄な投資を生みにくいというメリットもあります。
そもそも、アジャイルという手法自体が、事前に全ての要件を定義するのではなく、｢お客さまにこういう価値を提供したい｣という目標を決めて、それに向けて、みんなで自発的に、作り方はもちろん、そもそも何を作るかから考える、というプロセスなんです。
失敗は、アジャイルにおいては｢失敗｣じゃなかった
――アジャイルを取り入れるまでのプロセスについて具体的に教えてください。
森：ネットや本で情報を集めたり、バーンダウンチャートという、プロジェクトの進捗状況をグラフ化したものを書いてみたり、文字通り一から勉強して、試しに4～5名の小さなチームを組んでまずは3か月間実践してみたのですが、当時は本当に大変でした。誰も正解がわからないなか、手探りで模索していた状況です。
やはり、一つひとつの工程を綿密にチェックしながら開発を進めていく、これまでのウォーターフォールの手法がすっかり染みついているので、2週間単位でスプリント（短距離走）を繰り返していくやり方に、最初は馴染めなかったんですね。今振り返ると、ウォーターフォールでやっていた2～3か月分の作業を、ただ2週間に縮めただけだけの、“なんちゃってアジャイル”でした。
――それは大変ですね。
森：メンバーみんなまじめだから、そのスケジュールでやりきっちゃうんです（笑）。早く課題を見つけて、早く解消していく、というアジャイルの考え方を知ってはいても、その本質を理解できていなかったんだと思います。
これまでの考え方を根底から変えないといけない、と気づくのに時間がかかりましたね。しかも、アジャイルは、最初から全ての要件とプロセスが明確に定義されているわけではないので、お客さまに具体的な成果物を事前に提示することが難しい開発手法でもあります。開発をスクラム（*アジャイル開発のフレームワークの一つ）にするだけではなくて、事業や組織の構造、予算の獲得方法も変えないといけません。
あまりにも大変なので、パナソニック コネクト内のアジャイル開発経験者に当時の状況を話して相談してみたら、｢すごいことやってますね……｣と半ば呆れ気味に驚かれたのを覚えています（笑）。そこから少しずつ軌道修正をして、外部のアジャイルのコーチにも入っていただいて、改めて学び直した次第です。違和感なく進められるようになるまで、2年はかかったと思います。やっぱりこれまでの開発から一新するには時間がかかるんですよね。現在はコーチングも終了して、より自分たちに適した独自の方法を試しているところです。
――森さんご自身にアジャイルの考えが身につくきっかけはあったのでしょうか？
森：具体的になにか大きなきっかけがあったというより、徐々に理解していった感じですね。つまるところ、アジャイルもフレームワークの一種。明確な“答え”はありません。｢こういう風にすると、うまくいきやすい｣というようなシンプルな原則（参考：アジャイルマニフェスト/12の原則）しかなくて、それをどう適用するかは、使う人たち次第です。
――答えがない、というと逆にどう動いていいかわからなくなってしまいそうです。
森：そうですよね。だから、私たちも最初は失敗しました。でも、失敗はアジャイルにおいては｢失敗｣ではない。例えば、お客さまに自分たちのプロダクトの価値を認めていただけなかったとしても、その結果がわかった、という価値がある。その結果を踏まえて、修正をすればお客さまの課題解決にも自然と近づく。トライアンドエラーを繰り返して、そのことに気づいたんです。
本を読んで理解したわけではなく、見よう見まねで実践して、その度にいろんな気づきを得て、それがいつの間にか自分たちのやり方になっていました。
｢お客さま視点｣で一丸となれる組織に
――アジャイルが定着したことによってもたらされた、チームの変化はありますか。
森：自分だけでなく、組織を見ても、2年間の積み重ねで考え方や動き方が確実に変わってきたと実感します。アジャイルを学んでいくなかで、｢自分たちで考えて、自分たちで動くこと｣がアジャイル実践の原則だと気づいて、みんな同じようにトライアンドエラーを繰り返して、成長していたんだと思います。
｢開発が楽しくなった｣というメンバーも多いですね。アジャイルが万能とは思いませんが、私は｢もうウォーターフォールには戻りたくない｣というのが正直な気持ちです。
ウォーターフォールはそのプロセス上、どうしても“進行は厳守、要件定義が絶対”というところがあって、それにストレスを感じる技術者もいると思います。しかも、1〜2年かけてようやく完成させても、結局、要件定義がお客さまが求めていたものと違ったために、“半分以上の機能がユーザーに使ってもらえない“なんてこともあります。
その点、アジャイルであれば、数週間に1回はお客さまから直接フィードバックをもらえますし、要件定義が違っていたら早期の軌道修正ができる。モチベーションも自然と上がりますし、目的を見失わずに開発ができます。
それもあってか、チームの日々の会話もこれまでは｢決められた仕様を作りきるためにあれをやらなきゃ｣というものだったのが、｢この機能ってお客さまに価値があるの？｣｢この作業ってコストだけがかからない？｣という顧客起点の会話に変わってきました。目標が明確だからチームもより一丸となったんだと思います。
――アジャイルの実践により、顧客に提供するソリューションにも良い影響が生まれてくると思いますか？
森：｢今直面している課題を解決するかもしれないアイディアを、短期間で試すことができる｣という｢早さ｣は、お客さまにとって大きなメリットでしょう。しかも、アジャイルならば、そのアイディアの仮説検証とアップデートを繰り返すことができるので、ウォーターフォールの開発で起こり得る｢数年待ったけど、期待外れのものだった……｣というリスクも少ないです。
｢お客様ご自身にも開発に積極的に関わっていただく必要がある｣｢アジャイル開発のプロセスに合わせた、柔軟な投資判断をする必要がある｣など制約はありますが、お客さまに価値を届ける、ということを最終目標において、開発に取り組んでいますので、うまくフレームワークが回れば、私たち開発側とお客さまの双方にとって無駄がない手法だと思います。
――最後に今後の目標について教えてください。
森：コネクト内でも、アジャイルに取り組んでいるチームは徐々に増えてきています。このまま他の部署も含む組織全体に、チームビルディングや進行のノウハウなどを共有しながら、アジャイルを普及させていきたいですね。
先ほども述べた｢自分たちで考えて、自分たちで動く｣という考え方やスピード感、メンバーとのコミュニケーションの取り方など、アジャイルには、さまざまな業務に取り入れられるエッセンスがたくさんあります。アジャイルのコーチからは、開発の手法はもちろんですが、チームビルディングやコーチングの方法も学びました。
アジャイルって、組織の中でアジャイルを教えられる人を育てないと、広がらないんです。お客さまに持続的な価値を提供するための取り組みとして、｢人を育てていくこと｣にも力を入れていきたいと考えています。
組織に新たな開発手法を取り入れるために、トライアンドエラーを繰り返しながら模索していたという当時を振り返りながら、どのようにこれまでの開発手法から脱却して、アジャイルに挑んだのか語ってもらった。
