SmartHR Tech Blog

SmartHR 開発者ブログ

組織全体がアジャイルになっていくには 〜アジャイル推進室連載企画第2弾〜

こんにちは。プロダクトエンジニア兼アジャイル推進室メンバーの長田(shooen)です。 今回はアジャイル推進室連載企画第2弾として、SmartHRにアジャイルコーチとして参画いただいている豊田さんのインタビュー記事をお届けします。 開発の現場に限らず組織全体がアジャイルになっていく上での困難や必要なチャレンジについて、参考にしたりヒントを得たりしてもらえたらと思います。

豊田 聡

2020年9月にSmartHRへジョイン。開発組織におけるスクラム/LeSSの導入支援をはじめ、ピープルマネジメントや組織開発の支援、組織全体のマネジメント力向上施策などに力を入れている。

直近3年間のSmartHRの変化

豊田 聡さんの写真
豊田 聡さん。趣味は筋トレ。スクワットとデッドリフト100kg上げている。

長田: まず豊田さんがジョインした頃のSmartHRの印象を教えてください。

豊田: 会社の7つのバリューが特にいいなと思いました。アジャイルとの親和性が高い内容。開発組織だけのものではなく会社全体で掲げられているので、開発以外の組織も巻き込みやすいと思いました。考えた人天才かよって(笑)。

長田: それからもうすぐで3年が経過しようとしていますが、これまでを振り返って実際どうでしたか。何か変わってきたことはありますか?

豊田: ジョインして最初の1年半ほどは開発組織だけを見ていました。当時は形はスクラムになっているけど、うまく使い切れていないという状態でした。ただ、正しくプラクティスをやっていこうという姿勢はみんな持っていて、フィードバックすればすぐに適応しようとする感じでした。

なので気をつけていたことは「なぜそれをやるのか」というのをみんなに理解してもらいながら進めることでした。早く正しいものを小さく世に出して仮説検証を回していくことに意識を持ってもらうように話をしていきました。

長田: やり方よりも目的を理解してもらうことを意識していたのですね。

豊田: 今はネットや書籍で調べればやり方はいくらでも出てきますしね。自分からやり方について言及することは、ほぼなかったと思います。みんなが自ら調べていろいろやろうとするときに、目的は何だったか、そこからズレていないかを改めて認識してもらうように働きかけていました。

長田: 実際そのような関わりをしてきて、開発組織はどう変わっていきましたか?

豊田: 良くなっていったと思います。早く世に出すにはどうしたらいいのかを考えるようになったり、「ここから先は自分の仕事ではない」みたいな話を聞かなくなったし、「より創発的になっていくにはどうしたらいいんだろう」みたいなことを話す人もいる。プロダクト全体のことを考えて話す人が増えたと思います。 あと、チームにもよりますが、スクラムチーム外の方、経営やビジネスサイドの方たちと積極的に関わろうというチームが増えてきていると思います。

長田: そういったことが増えてくると、どのような良いことに繋がりますか?

豊田: 目の前でやっていることを疑えるようになると思います。本当にこれを作っていていいのか、今これが本当に大事なのかとか。チームの中での会話も、決まったことを早く終わらせることではなく、そもそもこれで大丈夫か、何を優先するべきかみたいな話ができるようになっていて、チームに良い影響が出ていると思います。

長田: そのあたりチームによって差があるとのことですが、どういった要因でそのような差が生まれるのでしょうか?

豊田: 会社が大きくなってきていて、歴史がある会社はある程度やり方が固まってベストな状態になっていると思われがち。でも実はそんなことはない。 会社が大きくなってきたフェーズで新しく入ってきた人は、これまでのコンテキストがわからないのでちょっとおとなしめになってしまうというのはあると思います。昔からいる人がちゃんとコンテキストを伝えることが必要だと思うのですが、そういう人たちはコンテキストを知った上で今の状態が当たり前になっているので、決して今がベストな状態ではないことを新しく入ってきた人たちに伝えなければならないことに気づきにくい。カルチャーを伝えていくということが必要なんだと思います。

長田: 2年前の記事(あれから半年。アジャイルコーチに聞く SmartHR の現在地とこれから)で今後気をつけるべきこととしてまさに今の話をされていましたが、実際にチームによって少しずつ差が出てきてるということなんですね。

tech.smarthr.jp

開発組織だけでなく組織全体へ

長田: 最近はプロダクトサイドだけでなくビジネスサイドやバックオフィスの部署やメンバーとも関わっていますが、具体的にどのようなことをしているのですか?

豊田: 一言でいうといろいろな相談に乗っている感じです。プロダクトサイドのときとの大きな違いは「プロセス」についてこれまで触れる機会のなかった人に対して話をするという点。プロダクトサイドの現場では認知されているけど、その他の組織にはまだ認知されていない観点を知ってもらうような話をしています。

長田: 「プロセス」というのは仕事の進め方ということですか?

豊田: ですです。よくあるのは「会議に時間をかけてはいけない」とか「会議や相談するときは整理したものを持っていかなければならない」と思っているケースで、そうなっていると創発性が失われていくんですよね。参加者は案を聞いて問題なければそれで終わり、みたいな。でもそれって非同期でもよくて、同期的にやるなら参加者から意見を募って一度発散したほうが良いですよね。

このように、組織ごとにある暗黙の常識みたいなものをアップデートするというか、新しい視点を知ってもらう感じですね。発散したら良くないみたいなイメージを持っている人もいて、わざと発散させる考え方もありますよということを伝えたりしています。なのでプロセスだけでなく「組織運営」や「組織の作り方」みたいなものも含んでいますね。

長田: 他にはどのような相談に乗ることが多いですか?

豊田: あとはピープルマネジメントに関する相談が多いです。現在マネージャーやチーフ向けに1on1講座をやっていますが、そこでインプットしたものを実際の現場に落とし込むのをサポートしているイメージです。人によって難しい相手や苦手な相手がいると思いますが、そういった相手とどう接したらいいのか、1on1講座の内容を相談者とその相手に合わせて具体的なアクションに落とし込むのを一緒に考えたりしています。

これも職種によって違いがあって、例えばチーフとメンバーの1on1でだけ相談して、メンバー同士ではあまり相談しないみたいなケースもあったりします。メンバー同士で相談して学び合っていければチーフのコストは減りますが、そのようなカルチャーがない場合、1on1の場でひたすらチーフが教えるみたいなことになっていたりします。そういうときは「それってチームで振り返ってもっと良くすることはできませんか?」みたいな提案をしたりもしています。そしてその際はアジャイルに関する言葉はできるだけ使わずに、相手の言葉を使って話をしつつ、アジャイルな状態に近づけることを意識しています。

長田: それは「アジャイルな組織」ということのインプットをせずに少しずつアジャイルな状態に向けていく感じですか?

豊田: いきなりインプットすると「全く現実味がない」となりそうな人にはそうしています。アジャイルに興味関心がある人だと普通にインプットをします。そこは相手に合わせています。

「効率」に2つの概念があることを認知する

長田: ここまでいくつか話に出てきていますが、ビジネスサイドやバックオフィスと関わる中で、プロダクトサイドでの関わり方との違いみたいなものはありますか?

豊田: 一番大きな違いはチームで仕事をするという感覚が薄い部署が結構あるところですかね。 個別の事象に対する相談はあるんですが、「チームワーク」や「振り返って良くしていく」というような相談が少ない印象があります。そこのノウハウが身につくと大きな効果が現れるんじゃないかなと思います。

長田: そのような違いはどういった要因で生まれるのでしょうか。

豊田: これまでに積み重ねてきた結果から暗黙の価値観ができているのだと思います。さっき話した「会議に時間をかけてはいけない」みたいな。それは誰も明言したりはしないのですが、暗黙的にそのような価値観がある気がします。それ故にリソース効率に振っていて「個人で動いたほうが早い」という理解になっているのではないでしょうか。実際、プロダクトサイドで初めてフロー効率の話をしたときも混乱したと思うのですが、そもそもその2つの概念(リソース効率とフロー効率)があることを認知しておらず、「効率がいい」イコール「誰か一人が集中して何かをすること」だと認識されているんじゃないかなと思います。

長田: 豊田さんがフロー効率を広める前のプロダクトサイドも同じ状態だった気がします。一人でコードを書くほうが、ペアプロやモブプロよりも効率がいいという暗黙的な価値観があったように。リソース効率しか認知していないとそうなるのも頷けますね。

今SmartHRが身をおいている不確実性の高い領域におけるソフトウェア開発ではフロー効率が有用だということはプロダクトサイドに広まってきましたが、ビジネスサイドやバックオフィスでもフロー効率が適している領域なのかというとどうなんでしょうか。

豊田: 目指したいゴール次第だと思います。フロー効率という言葉が正しいかわかりませんが、個人戦よりはチーム戦のほうがうまくいくと思います。 今は社内で車輪の再発明がたくさん起きていると感じてますね。どこかでは解決済みの課題が、他の場所ではそれを知らずにすごく苦労しているというのが多い印象です。

今それで一番大きな課題になっているのは「マネジメント力」だと思います。プロダクトサイドは定例MTGでマネジメントに関するノウハウの共有や悩みの相談だったり、マネージャー・チーフの役割の整理などが比較的されている方だと思いますが、そういったことがされずマネジメントへの期待値も揃っていないところもあるのが現状です。そのような状況だと足並みを揃えて物事を進める以前の問題になってしまいます。

グループの垣根を越えてマネジメント間でのノウハウが共有されていれば、解決できることはたくさんあると思います。 実際、マネージャーになった人がマネジメントについて勉強していくのって、今はリソース効率で進めている人がほとんどだと思います。マネージャー全体のコミュニティがあったら「なるほど、そうやってるんだ」みたいにすぐに解決できることがありそうなのに。

会社をひとつの生物として考える

豊田 聡さんの写真

長田: 豊田さんはその「マネジメント力」の課題に対してどういったアプローチで解決していこうと考えているのでしょうか?

豊田: 基本的には相談してくれた方ベースで動いていきます。ただ、それだけではどうも解決できそうにない場合は、解決できそうな人を巻き込みます。それがチーフの悩みであればマネージャーを巻き込む。マネージャーでも解決できないならVPを巻き込む。結局私自身では解決はできないんです。まずはその方たちが解決できる環境を整えるところを手伝うみたいな感じです。

あとこれは現在進行中ですが、「マネジメント力強化」の取り組みはわりと全社標準みたいなものにできそうだと考えています。その中にはスクラムマスター的な要素も含まれているので、これまでの経験を活かした上で、全社に適応できるものを作っていくチャレンジになっていると思います。

長田: 今「マネジメント力強化」に取り組んでいく狙いを教えてもらってもいいですか?

豊田: 組織のミドル層にあたるマネージャーって会社をうまく機能させるのにめちゃくちゃ大事なんです。マネージャーは大抵いくつかのチームを持っていると思います。会社をひとつの大きな生物だとすると、一つ一つのチームは目だったり耳だったり足だったり。それがひとつの生物としてうまく動こうとすると、それらの間で情報を伝える神経がないといけない。つまり、それぞれのチームの間で情報を伝える役が必要。その役割はマネージャーが握っています。 マネージャーが仕組みを作るか、マネージャー自身が伝えるか。いずれにせよそれが機能していないと、見ている方向と動いている方向が異なるみたいな状態になってしまう。

組織が大きくなってきた今、実際そういう状況が起こりかけていると感じているので、そこの最低限を揃えたいというのが直近の目標です。

複数あるプロダクトチームと他のチームを繋ぎたい。距離はあるかもしれないが、そこをうまく繋げることで組織全体のアジリティが上がると考えているので、一見アジャイルと関係ないようですが、会社をひとつの大きな生物として考えそれをうまく機能させることはアジャイルな状態を目指していると言えると思います。

組織全体がアジャイルになると何が起こるのか

長田: ビジネスサイドやバックオフィスがアジャイルになってくるとプロダクトサイドや会社にとってどのような強みが生まれるのでしょうか?

豊田: ビジネスサイドとプロダクトサイドは直結するので話しやすいのですが、一旦あえてバックオフィスの方から話してみましょう(笑)。

例えば何かのルールをバックオフィスの部署が考えるとき、アジャイルな感じで進めるか、ウォーターフォールな感じで進めるか選べるかもしれませんよね。もちろん社内のルールにもさまざまな背景があって、法律で決められているようなものはアジャイルに進めるのは難しいかもしれません。逆に、これまでに前例のないようなもの、不確実性が高いものも中にはあると思います。

最終的には組織全体に影響するようなルールを変えたいというときに、すべて完璧に考えて検証し、どの組織に当てはめても大丈夫というレベルまで確認を終わらせてからそのルールを適応するという方法もあれば、特定のエリアだけで試してみようと、小さく始めてアップデートしていく選択肢も考えられると思います。アジャイルを知っているとそういう選択肢も取れますよね。不確実性の高いものなら、結果的にはそちらの方が早く最適解に到達できるかもしれません。

長田: なるほど。確かに社内のルールってそんな簡単に変えられなさそうというイメージはありますが、よく考えるとそれってプロダクトにも同じことが言えるのかもって聞いてて思いました。簡単に変えられなさそうと思っていたプロダクトをアジャイルに変えていくことができるのなら、同様に社内のルールもアジャイルに変えていくことは可能なのかもしれない、ということですね。

豊田: そうです。結局早くリリースして検証したほうが良いものもあるかもしれないと思いますね。もちろん給与とかそういったところは難しいと思いますが(笑)。という感じでプロダクトサイド以外の人もアジャイルを知っていると良いことがありそうだなと感じています。

ビジネスサイドに関して言うと、ビジネスサイドの方は基本的にお客さまに近いじゃないですか。そこと距離を縮めることは開発にとって創発的な効果があると思います。 Tierによって傾向が違うとかそういうのが肌感でわかっていると思うので。その人達がどうやって開発が進められているかを知っていると、意見を誰にどのように言えば良いかを整理しやすいですし、開発側も誰に意見をもらいに行けば良いのかを考えやすい。お互いに関わりやすくなると思います。

例えばスプリントレビューにセールスの方が見に来てくれるとか。まず顔を知ってるって状態になるじゃないですか。「いつでも意見を言いに来てくれていいですよー」と言っても顔を知らないところへ行くのってなかなかハードルが高いですよね。特に1000人規模になってくるとなおさら。中には行ける人もいると思いますが、それはその人がすごいのであって(笑)。となったときに毎週スプリントレビューで顔を合わせている関係になると意見も言いやすいですよね。

長田: 先ほど創発的になりやすいとありましたが、「今、創発的だよね」って気づかないこともよくある気がしていて、どうやったらそこを意識したり気づけたりするのでしょうか?

豊田: 創発的な効果が出るのって確率は低いとは思うんですが、そういうものが生まれた瞬間に初めてこれって大事だったんだなと理解できる気がします。創発をまだ体験していない方に理解してもらうのは、確かになかなか難しいですね(笑)。

つい先日社内の飲み会で、ビジネスサイドの人と人事の人が初めて話したというシーンがありました。人事の人が持っていたスキルがビジネスサイドの人の悩みに使えるものだったので、その後、人事の人が壁打ち相手になって新たな取り組みが始まりそうなんですよね。これって偶発的なコミュニケーションがなかったら生まれなかったものなんですよね。 先ほどの通り、創発を体験したことがない人にとっては創発をイメージしづらいと思うので、このような創発的な出来事を共有していくことも大事だと思います。

プロダクトサイドができることは

長田: ビジネスサイドやバックオフィスもアジャイルになっていくために、プロダクトサイドができることはどのようなことがあるでしょうか。

豊田: 「チームで何かをする」というのを広めるのが大事なのではと思います。AさんとBさんが一緒に動いたら、別々でやるよりもすごいものができた、早く終わったとか。

長田: アジャイル推進室はそういったところにも関与していけると良さそうですね。1スクラムチームができることはありますか?たとえばスプリントレビューに招待するとか。

豊田: それ良いと思います。他にはお互いの仕事のことを聞きに行くとか、チームが担当しているプロダクトについてお客さまからどういうコメントや要望をいただいているのか聞いてみるとか。 まずはビジネスサイドとの距離を縮めていってほしいなと思いますね。それにはやはり作っているプロダクトの話をするのがやりやすいんじゃないかと。

長田: つい最近自分のいるチームでスプリントレビューをもっと良くできないかということでいろいろ意見を出しあっていたんですが、その中に「そういえばステークホルダーの人たちと飲み会とかしてないよね?一緒にカシュ(社内のフリードリンクを飲みながらコミュニケーション取ること)するだけでもスプリントレビューでもっと話しやすくなるのでは?」という議論がありました。

豊田: 「この前飲んだAさんだ!」と認識するだけで話しやすさが変わってきますよね。特に普段リモートの場合、一度オフラインで会っておくと全然違うと思います。 他にも、プロダクトに対するFBについてより詳しく聞いていく、深ぼっていくということも大事だと思います。FBをそのまま受け取ったり、「それはアジャイルじゃないんだよなぁ」とかで終わるのではなく、なぜお客さまはそれを気にするのか、その意見の元となるつらみはどういったものなのかみたいなところまで聞いていけると良いですよね。

そのためには「見えてるものが違う」ということを理解することが大事だと思います。「あの人はわかってない」ではなく「あの人には違うものが見えている」という思考で、それを詳しく聞いていく。 痛い話を笑いながらできるスキルって大事なんですよね。痛い話というのは「この機能、お客さまの評判悪いんですよね」というような話。「お、それどういうことか詳しく教えてよ」って気分を害さずに聞けるというのは大事なスキルなんです。そこで「チームは大変な思いして作ったのに...」って言い出しちゃうと、もう話が進まなくなってしまいますし、今後FBも出しにくくなっちゃいますよね。

長田: プロダクトサイドとビジネスサイドがうまく連携して創発的なアイデアを生んだりアクションを起こして、一方だけでは出せないような成果を継続的に出していける組織になりたいですね。

Join us

以上、アジャイル推進室連載企画第2弾でした。会社全体がアジャイルな組織になっていくにあたってのSmartHRにおける課題やこれからのチャレンジなど、少し具体的にイメージできたでしょうか?

プロダクト開発も組織の改善もまだまだやることはたくさんあります! 少しでも弊社に興味を持っていただけたら、カジュアル面談からでも大歓迎ですのでぜひご応募してください!

hello-world.smarthr.co.jp