2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
リンクをコピー
記事をブックマーク
塚原彰仁氏:ここまでの話はどうでしょうか。「本当にそうなの?」「美化しすぎなんじゃない?」と、疑問に思った方もいらっしゃるかもしれません。というのも、スライドを作っていた私が「本当にこれでいいのか。これを紹介していいのか」と疑問に感じていました。
なので、あおごへいもちさん、Mitsuiさん、Hamadaさん、れぐるすさん、つざきさん5名のスクラムマスターに、実際にインタビューしました。私の経験だけでなく、この5名のスクラムマスターがどんな経験をして、今はどんなことを考えているのかを紹介できればと思っています。
まずは「スクラムマスターの経験は役に立っていますか?」です。「企画と開発チームとのコミュニケーションが増えたことで、双方のプロダクトへの理解度が上がりました」という意見をいただきました。
先ほど紹介したスクラムイベントの中で、企画チームのプランニングや、Sprint Reviewの中でコミュニケーションをする機会があるので、スクラムの前後ではコミュニケーションの量が増えたり、プロダクトへの理解度が上がることは確かにそうだなと思いました。
「プロダクトオーナーと話す機会が増えたことで、ビジネスへの関心が高まりました」。スクラムマスターはProduct Backlogを作成する時にサポートに入ったりすることで、プロダクトオーナーと話す機会がかなり増えると思います。
また、プロダクトオーナーはプロダクトの何を作るのか、なにしろユーザーにより近い目線でプロダクトを捉えているので、エンジニア同士の会話ではなかなか生まれない会話や気づき、学びがすごく多いなと私も感じました。
「チームがどうあるとよいかを話し合う時などに、スクラムの原則をベースに会話することができるようになる」。共通言語的なものができたということですね。確かに、ふりかえりの場で何について話せばいいのか、どういう状態になっていけばいいのかについては、チームで共通認識が取れているとすごくコミュニケーションが進みやすい。私もここはかなり助かっています。
次に「スクラムマスターで印象に残っている学びはありますか?」(という質問)に対して「理想的なチームの状態をスクラムマスターとしてイメージを持って、メンバーをどのようにサポートすべきか考え、行動するのは難しいですね」という意見をいただきました。
私も同じような悩みを抱えていて、チームを観察して違和感があったとしても、それをどうサポートするのかについて、けっこう迷ったりしました。スクラムマスターやマネジメントの立場ならではの経験や学びなのかなと思います。
「企画チームと一緒に考えてプロダクトを作ることで、仕様どおりにただ作っていくだけでは経験できない学びがありました」。やはりプロダクトオーナーとのコミュニケーションが増えるという意見があったとおり、企画と開発チームのプロダクト理解度が高まっていく過程で学びがあります。
それと、プロダクトに対する捉え方です。開発チームが捉えているエンドユーザーの解像度と、プロダクトオーナーが考えているエンドユーザーの解像度がだいぶ違ったりするので、そういうものがコミュニケーションの一つひとつによって、どんどん埋まっていく様子は開発者としてすごく楽しいです。
「エンジニアとしてもスクラムマスターで活きている学びはありますか?」と聞くと、「エンジニアリングに直接活きている感じはないが、エンジニアとして良かれと思って行動していたことが、プロダクトの価値を作るという意味ではそこまで機能していないものがあった」とお話されていました。
具体的には「理性主義で考えすぎることで動きが鈍くなる」「技術寄りのフレーズを使って、プロダクトオーナーがプランニングで置いてけぼりになる」ですね。
確かに、プランニング(の段階)で、エンジニア同士で「このタスクをどうやっていこうか」という話をすると、すごく詳細な設計仕様まで考えて話し込んでしまう。そうすると、ミーティングがすごく長くなってしまったり、プロダクトオーナーが聞いていても話についてこられなくなってしまいます。
スクラムは理性主義ではなく、逆に経験主義に重きを置いてやっていかないとわからないというスタンスで、すごくガチ打ちの見積り・スケジュールではなく、ざっくり見積りでもいいからやってみることを優先しています。
そうすると「スケジュールどおりの開発をしなくていいのか」という直感と反する動きになっちゃうんですが、短くスプリントを切っているので、大きなスケジュールの遅れになることはありません。
「逆に短くスプリントを切って失敗したとしても、その経験を基にすぐに適応できるから大丈夫だよね」となっています。
(次に)「ファシリテーリング、ティーチングなどは活きる機会があると思うし、これからのソフトスキルは流行り廃りがないのがいいですね」。そうですね。だけど技術的なものは流行り廃りが激しいので、それに比べると、それがかなりないのが1つの魅力かなと。
あとは「自分が受け持っているタスクの報告量と質を意識するようになりました。プロダクトオーナーや企画チームに伝わるようなコミュニケーションを大事にしています」という意見です。
エンジニア同士のコミュニケーションだと技術寄りの話をしても伝わりますが、PO(Product Owner)が入っているとなかなか伝わらないままコミュニケーションが進んでしまうことがあるので、ちゃんと伝わるコミュニケーションを大事にしていきたいですね。
最後に「自身のキャリアにおいてプラスになりましたか?」という質問に対してコメントをいただいています。「マネージャーって、何をする仕事なのか不明瞭だから、キャリアの選択肢に入れづらかったが、スクラムマスターの経験で少し見えたのと自身の向き不向きが判断できる」。
「スクラムマスターをやり始めてから、マネジメントの方向性もありだと思うようになりました。プロフェッショナルとして技術力を磨いていく人にも、スクラムマスターの経験、知識はプラスになるものがあると思います」と。
「厳密にエンジニアリングマネージャーとかになりたいのか?と言われるとそうじゃなくて、もう少しチームが良くまわるようにするところに作用したいなと考えると、スクラムマスター的なキャリアのほうが自分のやりたいことにあっているのではないかと考えている」。
「ファシリテーションなどソフトスキルが伸びました。また現時点の興味関心の傾向から、技術を磨いていくのが良さそうだと判断材料になっています」。
あとは「キャリアで悩んでいるなら、一度経験してみるのはプラスになると思います」。さらに「『プロダクトで価値提供する』ということは、プロフェッショナル。技術をどんどん突き詰める人でも、マネジメントを考える人でも、差はないと考えています。どちらも大切にしたい思想ですよね」という意見をいただきました。
いかがだったでしょうか。スクラムマスターをやってみたいかも、挑戦したいかもと思っている方はどうですかね? いますかね?(笑)。
これから挑戦される方にアドバイスをするとしたら、まずは『スクラムガイド』を読むことをおすすめしますが、けっこう抽象度が高くて難しいです。『SCRUM BOOT CAMP THE BOOK』という本はだいぶわかりやすいので、そちらを読んでみることもおすすめします。
スクラムを始めてみないことには何も始まらないので、チームに掛け合ってみること。最初にスクラムをやるとなったら、スクラムイベントはちゃんとやり切ることをおすすめしています。
あとは、相談できる人、例えばアジャイルコーチと呼ばれる人やスクラム経験の長い人、相談できる人が身近にいること。最初はだいぶ迷うと思うので、相談できる人を捕まえておくのがおすすめです。
必須ではありませんが、スクラムマスターを交代する仕組みを用意しておくのもいいと思います。スクラムマスターがキャリアの片道切符になってしまっては、なかなか「スクラムマスターをやってみよう」という気にはならないので、ちょっとだけ経験してみるというやり方もありなのかなと思っています。
大まかですが、弊社はこんな感じで始めていました。まずはスクラムマスターを任命してメンバーで『スクラムガイド』の読み合わせを実施します。あとはスクラムイベントのルールや完成定義です。タスクをどうやったら完成とみなすのか、スプリントを繰り返しながらメンバーで話し合って、細かいルールを決めていきました。
実際に、我々も外部のアジャイルコーチを招待していて、スクラムで迷うことや困ったことがあれば相談してサポートをしてもらいました。また、弊社はスクラムマスターを3ヶ月の交代制で回しています。かくいう私も2代目のスクラムマスターで、スクラムを経験しています。
スクラムを交代する仕組みをもう少し紹介すると、3ヶ月で専任スクラムマスターを任命しています。スクラムマスターは「君がやって」という名指しで決めるのではなく、アンケートで立候補するかたちになっています。
前任のスクラムマスターがしっかりサポートすることが大前提なので、3ヶ月という短い期間でも、ある程度スクラムマスターが自立してスクラムをグイグイ引っ張ってくれます。
何が良いかというと、チームにスクラムマスター(経験者)がどんどん増えていく仕組みなので、チームの安定感が増していきます。また、3ヶ月という期間なので「ちょっとやってみようかな」「興味あるな」という人でも取り組みやすい、ハードルが低いと思います。
最後にまとめです。「スクラムマスターの経験は役に立ちそう!」と言い切ってよろしいですかね。みなさん、どうでしょうか。ファシリテーションやチームビルディングなど、ソフトスキルが身に付くかなと思っています。ビジネスサイドへの関心や理解が深まる機会もあります。あとは、やはりキャリアを考える時の参考になるかなと思います。
スクラムマスターは、マネジメントに興味があるけれど、今のエンジニアの仕事とはちょっと距離があるものなので、それを考える時のキャリアのヒントになるのかなと思っています。
「おもしろそうかも」と、もしスクラムマスターをやる機会が巡ってきた時、このスライドを思い出して、挑戦してみようという気持ちになってもらえると幸いです。
私はMeetyなどをやっているので、スクラムで気になったこととか、今日の話の続きとか、もうちょっと詳しく聞きたい方はお気軽にお声がけください。もちろんTwitterのDMからも、ちょっと話を聞きたい方はご連絡やお声がけください。
スクラムマスター関連の話だけでなく、開発チームの仕事の仕方とか、「スクラムにおけるエンジニアの立ち振る舞いはどうやったらいいんですか」みたいな話でも、もちろん大丈夫です。
今回スライドを作成するにあたってご協力いただいたみなさん、本当にありがとうございました。良いスライドを作れました。
では、以上をもちまして発表を終了します。ありがとうございました。
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは