スクラムから学ぶチームコミュニケーション―――――仕事のすれ違いを「ただ、話す」で解決していく、クラスメソッド小峰健範さんインタビュー
Amazon AWSの技術支援を中心とした事業を行い、様々な技術情報の発信でも有名な株式会社クラスメソッド。
今回はCX事業本部Delivery部でデザイナーのマネージャーをしている小峰さんに、ミドルマネージャーとしてのコミュニケーションスタイルやチーム内スクラムの事例についてお聞きしました。
記事中に専門的な用語なども出てきますが、そこを読み飛ばしながらでも読んでいただければ、チームが活発になるヒントや仕事におけるコミュニケーションの勘所がつかめる内容になっていると思います。
どうぞ最後までお読みいただけましたら幸いです。
【クラスメソッド株式会社 CX事業本部 Delivery部 マネージャー】小峰 健範
Webデザイナーから転職し、ゲームプラットフォームの開発ディレクターを担当していた際にScrum Alliance CSPO®を取得。現在はクラスメソッドCX事業本部Delivery部内にてデザインチームのマネージャーを担当し、スクラムマスターを兼任。
【Agendインタビュアー】フジイユウジ
Agend編集長。2011年バンダースナッチを創業。
様々な事業の経営やグロースに携わる中で意思決定のための会議や組織論、チームコミュニケーションに強い興味を持ち、Agendの運営を開始。
様々なタスクをこなすチーム。
小峰さん、今日はよろしくお願いします。
まずは簡単に自己紹介をしていただけますか？
クラスメソッド株式会社の小峰です、よろしくお願いします。
クラスメソッドはAWSの導入支援で知られているんですが、僕はCX事業本部Delivery部という100名超の部門で、顧客と伴走しての開発や、開発支援などをしています。
有名な事例としては、
スターバックスコーヒーのスマホアプリ開発・運用があります。
おお、あのモバイルオーダーができるスタバのアプリ。
あれクラスメソッドさんが開発されていたんですね。めっちゃ使ってます！
その中に10人くらいのデザインチームがあって、僕はそこでデザイナーのマネジメントをして、チームのスクラムマスターもしています。
主な業務はクライアントのいる開発なので、各プロジェクトにデザイナーをアサインしていくんですが、それと同時にクラスメソッド社内のクリエイティブ業務の多くもこのチームでやっています。
クラスメソッドさんはDevelopersIOでの情報発信で有名ですが、そういった社内業務のクリエイティブも小峰さんとデザインチームの仕事なんですね。
今年コーポレートロゴをリニューアルしたんですが、そういったクラスメソッドとしてのクリエイティブは私たちのデザインチームが担当することが多いです。
営業資料のデザインもやりますし。
お客様のいる受託開発のプロジェクトにデザイナーをアサインしながら、社内から依頼されるタスクにも対応するため、デザインチーム内でスクラムをやっている感じです。
毎日たった15分のデイリースクラムが、コミュニケーションを変えた。
もともと前職でスクラムマスターをはじめたんですが、クラスメソッドに入社した後にデザイナーと話していて「アジャイルやスクラムのことは知識としては知っているし、プロジェクトのスプリントに参加したこともあるけれど、しっかり理解はしていない」という話が出てきたんですね。
じゃあデザインチーム内でもスクラムやってみよう、ということになりました。
スクラムとは:
アジャイルのひとつで、複雑な問題に対応する適応型のフレームワーク。
複雑な問題に対応するための作業を並べ → 一定期間(スプリント)ごとの作業を選択・実施 → 結果を検査し、次のスプリントに向けての調整を繰り返す。
スクラムガイドには「スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。」と書かれている。
スクラムやってる人たちの中でも「デザイナーをスクラムに入れるか問題」みたいな議論がたまにありますよね。
開発エンジニアだけでスクラムやって、デザイナーはスクラム外で作業をしてエンジニアを待たせてるみたいなプロセスだと、どうしてもムダな手戻りが発生したり、それぞれの領域での調整作業が大きくなったりします。
デザイナーとエンジニアが一緒にスクラムに参加したり、理解を深めたりしているだけでも、かなりより良い仕事ができると思います。
デザイナーのチームで日常的にスクラムやってて慣れているなら、プロジェクトに入ったときも良い動きしてくれそう。
デザインチーム内のスクラムを始めるまで、メンバー個々が自分のタスクを把握していて、誰が何をやっているかデザインチーム全体の見通した情報共有があまりできていなかったんですよ。
なるほど？
それって、他のメンバーが何やってるか知らなくても困ってなかったんですよね。
デザインチームでスクラムをはじめてみて、どう変わりました？
毎日15分のデイリースクラムをやったのが、すごく良い効果を生んだんですよ。
誰が何やってるのかがチーム内で共有されたら「あの仕事やってるの？」とデイリースクラムが終わった後にチームメンバー間で技術や知見を交換するような会話が生まれたり。
スクラムやる前もサポートしあうことはしていたと思うんですが、何をサポートして欲しいか、サポートできるか見えるようになったら、ぜんぜん動きが変わりましたね。
メンバー同士でのコミュニケーション総量はかなり増えたんじゃないかな。
デイリースクラムだけでそんなに劇的な効果が(笑)
クラスメソッドさんは元から社員同士がサポートしあうような文化があったんでしょうね。そこにデイリースクラムでチーム内に流通する情報をドカッと増やした感じなんだろうなって思いました。
デイリースクラムとは:
“スクラムチームの開発者のための15分のイベントである”
“スプリントゴールの進捗に焦点をあて、これからの1⽇の作業の実⾏可能な計画を作成する限り、必要な構造とやり⽅を選択できる。これは集中を⽣み出し、⾃⼰管理を促進する。 デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする”
(スクラムガイドより引用)
デイリーでちゃんと情報共有できているから、余計なミーティングも減ったんですよ。
逆に、今まで見えていなかった課題が話し合われるミーティングが増えたりした面もありますが、全体としては良い傾向だと思います。
毎日の15分を増やしたことで、チーム内に流通する情報量が増えて、全体の会議の質や量が適正になっていくやつですね。
理想的だ。
一般的なスクラムと変えている点
最初は多かったデイリースクラムで話すことも、いまは情報の密度を維持しながらトピックの数は減っていって、短い時間でちゃんと情報共有できている雰囲気ができましたね。
レビューとかレトロスペクティブもやってるんですよね？
(※スプリントごとの成果確認、スプリントを振り返って次のスプリントに向けての動きを検討すること)
はい。 レビューとレトロスペクティブがとても良い機会になっていて、他のメンバーの仕事についての考え方を知ったり、自分に関係ない業務のレビューもデザイナー間の知識や技術の交換をする場になっています。
プロジェクト管理や進捗確認としてではない、日常的なチームコミュニケーションとしてのスクラム、めっちゃ良いですねー。
スクラム導入以前は、社内調査で「ナレッジ化・共有ができていない」という課題があがっていたんですけど、最近はそれが課題として挙がらなくなりました。
これはおそらく、レビューやレトロスペクティブの効果だと思うんですよね。
よくあるプロジェクト管理やソフトウェア開発でのスクラムとはちょっと違いますよね？
デザイナーがアサインされているプロジェクトチームごとでプロジェクト個別のタスク管理はされているので、誰がどんな仕事をしているか分かるだけにして、タスクの二重管理はしないようにしていますね。
カッチリはやっているわけではないですが、大規模スクラムを模しているという感じで。
社内からの依頼やチーム内業務と、プロジェクトアサインで粒度は合わせずに管理してる感じなんですね。スプリントレビューもやっているとのことでしたけど、各スプリントでやるタスクの見積もりとかどうしてるんですか？
「ここまでぐらいに終わらせたいよね〜」という完了見込みの日付だけ見て、コミットメントをガチガチにしないように意識している感じで、ここではストーリーポイント(タスクの難易度や規模を相対的に見積する手法)は使っていないです。
アサインされているプロジェクトは1タスクのように扱って、分割したりはしていません。
あくまでチームメンバーが全体を見通すためにやっているので、参加しているプロジェクトの扱いは割り切って、次のスプリントにも残り続けるっていうイレギュラーなものとして定義しています。
おー、メイン業務と社内タスクを同時並行でやってると上手く管理しきれないチームが多いと思うけど、これは良いかもしれない。
マネージャーだけじゃなく、チームメンバーみんなで全体を見渡したコミュニケーションとれるのがすごく良いし、僕もマネしてやってみたいなー
スクラムやアジャイルの思想が、歩み寄りや対話を生み出している。
次に、スクラムやアジャイルの考え方が、小峰さんのマネジメントスタイルや仕事のコミュニケーションに影響してる点を詳しくお聞きしたいです。
僕自身もスクラムでなんでも解決する、とは思っていたわけではないんですが、CSPO®を受講した際に講師から、
「スクラムも含む、すべてのフレームワークや型がそのままソリューションになることはないから、相手の課題を聞くことから始める」
って言われたんですね。
スクラムを上手く組織に導入していくやり方がないかを質問したんですよ。
そのときに「まずは何が課題と感じているか、経営陣とか事業責任者とか、現場の人たちに話を聞く」って言われたんですね。
そうじゃないと、スクラムを持ち込んでも押し売りにしかならない。ソリューションにならない、と。
それが強く小峰さんのマネジメントやコミュニケーションスタイルに影響したっていうの、めちゃくちゃ良い話ですね。
会議や調整の場を用意するんじゃなく、誰かと何か調整が必要そうだって思った時、ちょっとしたことでも何か解決しなきゃいけないって思ったら、ただ対話をしに行く。
スクラムに限らず、複数の人が関わるなら密接に対話や理解をして進めることが何よりも優先される、という姿勢を教えてもらいました。
以前からそういうことを大切にしていたつもりでしたけれど、明文化されているのを見て「これだったんだ」と確信を得たというか。
なるほど。「ただ、話す」って行動をとるのは意外と難しいですよね。
席を立ってサッと行くとか、リモートならすぐに通話しようって言うとか、言葉にするのは簡単だけど、みんななかなか実行できない。
昨日の夜も、上司やその上にあたる人とSlackで盛り上がったんで、「この後、ちょっと3人でいいっすか」って口頭で話したんですよ。
すぐ話して、パッと方針をそろえて。
おお、上司からすると、部下のミドルマネージャーからちょっと時間取ってくださいって言われたら嬉しいですよね。
ちゃんとコミュニケーションしたいって姿勢を持ってもらえてるなって実感できるだろうし。
「ただ、話す」を実行するだけで、歩み寄ることになるんだなあ。
チーム内でもデイリースクラムとかで気になったことがあったら、できるだけすぐに話しに行くようにしています。
これだけで解決できることがものすごくたくさんあるので、「ただ、話す」という考え方は本当に大事だなと思います。
なるほど。
課題や問題になるより前に、芽が出た時点くらいで「ただ、話す」ことができれば、予防できるというか。
早い段階で「ただ、話す」ことで、すり合わせができるんですよ。
例えば、決済画面をどうするかという話があったとして、デザイナーはユーザー行動を分析したいから分析ツールのコードを入れたいけれど、エンジニアとしてはセキュリティの観点から決済関係には外部のコードを入れたくない……といったお互いの専門領域とか立場の違いで意見が割れるってあるじゃないですか。
そういった場合でも、内容が固まってないうちに話すことで、お互いの専門性や役割を理解しあって解決に向かいやすいんですよね。
内容が固まってから話すと対立っぽい感じになったりするので。
「ただ、話す」ってシンプルなのに最強に効果あってめちゃくちゃ良いんですが、話すだけでは話が噛み合わない場合も多そうな気がするんですよね。
こちらが課題を感じて話しに行っても、相手が「いや、だいじょうぶ。いけるっしょ」って軽くとらえているとか。
ありますね。
例えば技術力のあるエンジニアが「品質」の観点で新人が書いたコードを書き換えちゃったときに「人材育成」の観点でそれは良くないことだと伝えても、前提が「品質」だと会話にならないじゃないですか。
もちろん「人材育成」のために「品質」がダメになって良いわけはないけど、どちらも重要なことなのだから、すり合わせが必要なんですよね。
うんうん。
前提になっていることや優先すべき点が立場によって違う。
そこで、お互いの立場や重要視することの違いを話して、理解し合うわけですよね。
場合によっては向こうが折れてくれるかもしれないし、こっちが折れざるを得ない状況にもなるかもしれない。
対立するんじゃなく、お互いの立場や重要視すべきことを理解しあえるように伝える。
これが答えなのは分かるんですけど、めちゃくちゃ難しいですよね。
事象 → 課題 → 原因 → 施策 → 効果 に分類した「問題解決の5階層」というのがあって、下の階層で認識がそろっていないと、上の階層では意見や認識がすり合うことはないというものです。
こちらが「課題があるんです」って言っても、知っている「事象・事実」なんかの前提がズレていたら相手は「大丈夫っすよ」って答えを出しちゃう。
だから、まずは事象・事実のすり合わせ、次に課題のすり合わせ、というようにお互いの前提をそろえますね。
それは本当にそうだなあ。
問題や対立になる前に話す。
お互いが歩み寄って理解するために、前提をそろえる。
スクラムやアジャイルをただのプロジェクト管理の手段として学んだのではなく、「ただ、話す」ことや「お互いの前提をすり合わせる」という仕事のスタイルにできたのはとても良かったと思います。
これまでやってきたこととつながって、自分の中の理解が深まった感じがしますね。
まとめ: チームコミュニケーションは「ただ、話す」からはじまる
現役のミドルマネージャーがどのようなコミュニケーションの工夫をしているか、実践的でデザイナーのチームでなくても役に立つお話だったのではないかと思います。
■ チーム外の業務(プロジェクト)にチームメンバーをアサインするような仕事でも、メイン業務と社内(チーム内)業務を含めた見通しが効くようにしたことでコミュニケーションが活発になり、サポートやチームワークが生まれた。
■ アジャイルやスクラムの基本である対話を大切にして、「ただ話す」を素早く、日常的に実践している。
■どんなに良い方法でも押し付けではソリューションにはならない。「問題解決の5階層」を下からそろえて話し合っている。
小峰さんのロジカルかつ人の気持ちや話し合いを大切にするスタンスに学べることが沢山ありました。
小峰健範 | DevelopersIO
クラスメソッド採用サイト
（企画・編集：フジイユウジ ／ 取材・文・撮影：奥川 隼彦）取材:2023年9月
