登壇者の自己紹介とアジェンダの紹介
島崎純一氏：よろしくお願いいたします。本日は、Agile Center of Excellenceの必要性を考えるといったところから、自身のアジャイルを再構築するというお話をいたします。
お話の前に、本セッションの注意点を共有させていただきたいなと思います。
本セッションは、Agile Center of Excellenceをキーワードにお話ししますが、A-CoEの成功例ではなくて、そのお話に至るまで、自分のアジャイルを企画の観点から見直したというセッションです。
本日のスピーカーの紹介といったところで、私、島崎純一と申します。今、プロダクトマネージャーを主軸に活躍しています。スクラムマスターやアジャイルコーチといったところは、社内的に少しやっているというレベルです。
なので、本日のお話はどちらかというとプロダクトマネージャーや企画というところでお話しすることが多くなるかなと思います。
今回のキーワードをあらためて出しています。
本セッションの流れですね。弊社における課題から、A-CoEのお話、自身のリビルドというところのお話、そしてA-CoEで動いてみたというお話、こちらでやっていきたいと思っています。
アジャイルを“早く進む解決策”みたいに思っていないですか？
みなさん、組織内でアジャイルをどういうふうに認識されていますかね？ うちの会社もいろいろあるのですが、例えばアジャイルを“早く進む解決策”みたいに思われていませんか？ みなさんのところだと、「そんなことはないよ」かもしれませんが。
よくあると言うとアレかもしれませんが、ありそうな誤認識といったところで、「新しく企画を始めたい、早くリリースしたいんだよね」という要望を受ける。開発側が、「その企画、実際に動くとなると工数かかりますよ」と。「そうなの？ アジャイルとかスクラムだったらすぐできるんでしょ？」、なんかこんな感じで（リリースが）早くなるみたいに思われちゃうパターンですね。
うちの周りでもあるかなと思ったのでちょっと聞いてみました。「アジャイルをやりたいんですよ」「スクラムやっています、うまくいっていないんですけどね」、こういうふうに、実際にやってみたい、やっているという話もあれば、やはり、「えっ、アジャイル？ 早くできるんでしょ？」、こういう方もいらっしゃるわけです。
中には、ある程度アジャイルというものを理解されているのか、「顧客ヒアリングは重要だよね。ヒアリングしたものをベースに優先度を切り替えてやっているよ」みたいなお話があったり、アジャイルソフトウェア開発宣言の中の、この価値をなんとなく理解されている人もいます。
ただ、人によってこの理解の度合いの差が大きいのが現状かなと、聞いて思いました。
スクラム開発というワードが出たので、せっかくなのでスクラム開発しているメンバーにも聞いてみました。ちょっと衝撃を受けるような内容もあるんですけど（笑）、「POが誰なのかがわかりません」「誰が優先順位を決めているんですかね？」と。「うまくいっている気がしない」……まぁ、うまくいっている気がしないは、よく聞くかなというところですかね。
あとは、やはりちょっとずれていたりします。「スクラムは、要件が決まっていない開発ですよね」と。うーん、ちょっと違うな、というところですね。誤ったスクラム開発が導入されていて、やはり困る開発者もいることを感じました。
ここにはやはり課題がありそうだと（思いました）。個人的には、ここの課題をしっかり解いていって、アジャイルな考えを戦略の1つとして増やしていきたいなと。やはりサービスを届けるといったところになってくるかなと思うので、より確かな価値を届けることを、私はやっていきたいなとに思いました。
スクラムをやりたいとか、アジャイルな文化でしっかりやっていくんだみたいなお話はいったんさておきですね。
なぜ人によってアジャイルの知識に差があるのか？
といったところで、先ほどの課題を少し深堀ってみて、そこからなにかできないかを考えてみます。
先ほどの2つの課題ですね。まずは、人によってアジャイルの知識が異なる。先ほどお伝えしたところになりますが、気になったキーワードは、「人によって差が大きい」というところです。
なんで人によって差があるんでしょうか？ ちょっとそこに関して深堀ってみました。関係者の視座から、どのように感じているかをまとめてみました。
事業部の責任者からすると、やはり社会貢献したいですと。社会貢献した上で、ビジネスを成功させて、会社の成長につなげたいと考えています。
ただ、実際にそれをやっていくための企画に関しては、成功率がやはり低いですよねと。成功率を上げるためになにかしらやっていかなきゃいけないよというので、アジャイルを少し理解されている状況です。
次ですね。プロダクトの責任者です。ここの方々は、プロダクトの売上を上げるために方針を決めて、企画としてどんどん進めていきたいと考えています。
企画を成功させるために、戦略としてアジャイルというものがあると理解はしていますが、弊社の場合、そこの進め方がまったくわからないという状況でした。
PMメンバー、こちらはどちらかというと、責任者の下で実際に企画を回していく方々ですね。戦略に幅といったものはありません。営業やCSから圧力もあって、より完璧な企画として物を作っていくという行動に移りがちです。
営業、CSのみなさんといったところでいきますと、そもそもものづくりという認識が薄いかたちでした。
組織内でアジャイルの理解を促進することが大事
今回、私がまず注目したのがここの2つです。やはり戦略に幅を持たせて、より確かな価値提供というところだと、プロダクト責任者、PMメンバーに対して、しっかりとここらへんを解決するためにアジャイルを教育していく必要はあるかなと思いました。
ただ、これだけを解決すればいいのかというと、実はそうでもないなとも思っています。
例えば、ものづくりですね、進めていく中で、あまり例は良くないのですが、アジャイル、スクラムでやっていく中で、まずはこういったところからやってみますという企画の考えからスタートして。
ただ、これをやっていこうとすると、CS、営業のみなさんとかからすると、「それだとぜんぜん足りないよ。お客さんの要望、足りていないよ」と。「安全性低いし、なんなら疲れないようにしてほしいし、もっと言えば空飛べたほうがいいし」。とんでもない要望も飛んでくるわけですね。
企画としては、本当に必要なものを捉えてやっていかないと失敗してしまうというおそれがあるのに、「この要望を受けきれん」というところで認識齟齬が起きるというかたちですね。
なので、責任者、PMメンバーに対してだけではなく、やはり事業部、会社全体で、共通認識を設ける必要があるなと思っています。
これらをまとめると、プロダクト責任者、PMに対して戦略の幅を持たせるために、組織内でアジャイルの理解を促進する必要があるというのが、1つ見えてきた答えになります。
スクラム開発を間違ってしまう大きな要因2つ
もう1つ、誤ったスクラムの導入。「なんでスクラム開発を誤ってしまったんでしょうか？」というところを少し深堀ってみました。
いくつか要因はあるとは思いますが、今回は大きそうな2つを持ってきています。
1つ目は、サービスが大きくなってしまったとか、組織が大きくなったとか、サービス自体がモノリシックでなかなか純粋なスクラム開発の適用が難しい、みたいなお話ですね。
2つ目、スクラム開発の知識が少ない状態で、断片的にやり方だけ持ってきてしまっているパターン。これらを行ってしまっているので、間違ったスクラム開発になってしまっているというところですね。
1つ目に関して、もう少しお伝えしていきます。ここに関して、やはり弊社でも何名かでスクラム開発の適用を考えます。ちょっと申し訳ないのですが、私たちも、モノリシックなサービス、巨大な組織といったところに対しての適用方法が見当たっていないのが現状です。
逆に考えれば、スクラム開発をやっていこうっていうので、ここに適用するとなると逆に混乱するので、今は適用すべきタイミングではないと捉えております。
一方で、スクラム開発の知識が少ないというお話ですね。こちらに関しては、みなさんはこの場などで話を聞いている中で、アジャイルやスクラムの知識を蓄えていると思いますが、私も同様で、このようなかたちで理解を深めてもらうという活動をしていくことは可能だなと思います。
先ほどの課題に対して、どんなことをやっていこうかというところをまとめています。アジャイルの知識が異なるというものに関しては、戦略の幅を持たせるためにアジャイルの理解を促進していきましょう。誤ったスクラム導入に関しても、スクラム開発の知識を理解していただきましょう。
つまり、アジャイルの知見、スクラムの知見を広める役割がいるだけで、多少なりとも課題解決していきそうだなというところにたどり着きました。
（次回へつづく）
