【インタビュー】部署の垣根を超えて対話し、組織全体にアジャイル文化やスクラムを広げる【スクラムマスター 後編】

プロダクトとの相性を鑑みて、あえてスクラム開発をやっていないチームもありますが、開発組織全体で見ると浸透度は高いです。スクラムマスターの資格保持者も年々増えていて、現時点で十数人。それまでにもチーム内でスクラム開発は取り入れていたけれど、より本格的にやっていきたいということで資格を取るケースもあります。

現状やっていないチームも、いったんは導入してみたけどあまりフィットせずに中止したケースや、一時は断念したけど、またトライしてみたいと私のところへ相談に来られるケースもあり、少なくとも前向きではあると思いますね。

そもそもの背景として、スクラム開発を導入する以前に、2018年あたりから開発を内製に切り替えていったというのが大きくて。それまでのニフティって、どちらかというとサービスのシステムは外部の開発会社の方に作っていただき、社内のエンジニアは仕様を決めたり、できあがったシステムのテストや調整だったりが主な役割でした。

私が入社したあたりから、少しずつ内製にシフトしていく動きが出てきた時に、開発方法そのものの見直しを迫られたんです。それまでのやり方は、最初に仕様をがっちり固めて外部パートナーに発注。ある程度の工期をかけてしっかり作り込んだものを最終的にこちらでテストするという、いわゆるウォーターフォール型の開発手法でした。ただ、内製でやるならスクラム開発のほうが、社内のエンジニア同士のコミュニケーションが増える利点をより活かせるのではないかと。

そうですね。それまでは「エンジニアは企画の人に言われたことをやればいい」というスタンスでしたが、途中で違うことを言われた時に困ることもありました。最初に仕様をガチガチに固めず、小分けで実装・開発・テストを回していくスクラム開発にシフトすることでそうしたストレスも減りましたし、エンジニアのマインドセットにも影響を与えたのではないかと思います。

私が入社した15〜16年前のニフティって、「振り返り」の文化がほぼなかったんです。せいぜい半年に一度の評価のタイミングで、それまでにやってきたことや成果を振り返るくらいで。

それがスクラムを導入して以降、早ければ1週間でプロジェクトを振り返る文化が色んなチームに根付いてきたと感じます。チーム単体のみならず開発組織全体としてもそうした動きがあり、それはスクラム文化が浸透してきたことも一因ではないかと。

現代のような変化が激しく複雑性の高い状況では、アジャイルな考え方が有効な場面が多いと感じています。その意味で、開発組織にスクラムが浸透してきたのは良い傾向ですが、それを真に効果的にするためには、プロダクトオーナーを輩出する企画側の深い理解が欠かせません。

単に開発側の働き方に企画側を従わせるのではなく、どうしたらスクラムのプロセスが有効なのかを一緒に考え、自分たちのプロダクトに対してアジャイルの原則と価値が機能するように落とし込んでいく必要があります。

そのあたりのはしご役は、企画側のプロダクトオーナーである私の役割だと思っています。

吉田が言うように、スクラム導入が開発側だけで先行している点は、課題だと感じています。前回も少し話しましたが、企画と開発のフロアが別々になっていて、物理的な距離があるのも一つの原因ではあると思うので、もっと対話の機会を増やしていきたいですね。（※）

私たちポイントチームの場合は、企画側に吉田がプロダクトオーナーとして立ってくれていることもありコミュニケーションは活発ですが、他チームでも企画と開発の垣根をなくしていくことが大事です。今は「同じプロダクトに関わる組織」というだけの関係であって、企画側と開発側が一枚岩で動けているケースはそう多くないと思いますので。それができるようになると、企画と開発がそれぞれ感じているプロダクトの課題を共有できて、「その課題に対処するためにはスクラムがいいよね」といった具合に、自然とスクラム開発を導入する方向に進んでいくのではないでしょうか。

私も開発側の人間なのでスクラム開発を当たり前のようにやっていますが、開発組織以外の、ニフティ全体で見るとまだまだ十分に浸透しているとは言えません。特にビジネスサイドでスクラムの知見を持った人って、現状は吉田さんくらいなのかなと思っています。とはいえ、こちらがいくら「企画側もスクラムをやりましょう」とか「プロダクトオーナーの資格を取ってください」と言ったところで、課題の本質が分からないまま導入してもあまり意味がない。

吉田さんがおっしゃったように、スクラムの意味やメリットを企画側にも納得してもらうことが重要です。そのためには、スクラム開発の本質や、開発側が感じている利点、ビジネス側がそれをやることでプロダクトやサービスにどんな影響があるかといったことを言語化して、丁寧に伝えていく必要がある。それはスクラムマスターである私の役割の一つだと思いますので、ボトムアップでじわじわと組織全体に浸透させていきたいですね。

まずは自分自身が、プロダクトマネジメントというものをより理解し、実践できるようにならなくてはいけないと考えています。また、自分一人だけではなく企画側も含めた組織全体として、ニフティにあるべきプロダクトマネジメントとは何なのか、どう進めていくべきかを考え、構築していく必要がある。

そのために、たとえば開発側、企画側の上長や同僚が参加するプロダクトマネジメントの勉強会などに自分も参加しているのですが、そういった場で何かしらの発信をして、プロダクトマネジメントやスクラムに関する知見を開発以外の部署にも広げていくような活動ができればと考えています。

先ほど話したことにも通じますが、開発内だけでなく会社の誰もが部署の垣根を超えて、自分の考えをシェアできるような場や文化を作りたいと思っています。たとえばニフティでは年2回、全社会議の場で経営陣から活動方針を伝えられるのですが、現状は一方通行というか「聞いて終わり」になってしまっているのが、もったいなく感じていて。

もっと現場の社員同士でディスカションして、「自分はこう受け取ったけど、あなたはどう思う？」といった話ができるといいのかなと。そうやって経営陣のメッセージに対する理解を深めた上で、「じゃあ自分は今期、こういう活動をしていきます」みたいなことまでシェアできると、組織全体が一枚岩になれるのではないかと思います。今はAIの活用が進み、業務時間が短縮できているので、そこで空いた時間は組織全体でもっと本質的な問いについて考えることに使いたいですよね。

チームや組織を変えるためには、まず個々のメンバーが自分自身の現状や課題に気づく必要があると考えています。自分がいま何に悩んでいるのか、何にチャレンジしたいのか、何が成長を阻んでいるのか。それが理解できて初めて、チームにも目を向けられるようになる。組織をより良い方向に変えていこうという思考が生まれる。メンバーそれぞれがチームの課題を言語化できるようになり、チーム全体にシェアされる。その結果、場合によっては課題解消のアプローチの一つとしてスクラムの導入へと至るかもしれません。

スクラムを単に形骸化したフレームワークに終わらせないためには、そうしたプロセスを踏んでいく必要があると考え、そのファーストステップとして2年前から社内コーチングを始めました。今は私だけでなく吉田と清水にもコーチングの研修を受けてもらっていて、チーム外活動としてコーチングを提供していこうと考えています。最終的にスクラムの導入というゴールに至らなかったとしても、一人ひとりが気づきを得ることで仕事へのモチベーションがアップし、組織全体の活性化にもつながっていくはずですから。