“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。
「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。
第7回のテーマは「開発者」です。後編では、立場や役割の壁を越えて「協働」するために必要な体制やメンタリティ、コミュニケーションのあり方についてお話します。
前編はこちら
![中村洋](https://redjourney.jp/wp-content/uploads/2024/03/image-7.png)
中村 洋 Yoh Nakamura
株式会社レッドジャーニー
CSP-SM(認定プロフェッショナルスクラムマスター)・CSPO(認定プロダクトオーナー)
様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
※発表資料 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。
![新井剛](https://redjourney.jp/wp-content/uploads/2024/03/image-3.png)
新井 剛 Takeshi Arai
株式会社レッドジャーニー 取締役COO
CSP(認定スクラムプロフェッショナル)、CSM(認定スクラムマスター)、CSPO(認定プロダクトオーナー)
プログラマー、プロダクトマネージャー、プロジェクトマネージャー、アプリケーション開発、ミドルエンジン開発、エンジニアリング部門長など様々な現場を経て、全社組織のカイゼンやエバンジェリストとして活躍。現在はDX支援、アジャイル推進支援、CoE支援、アジャイルコーチ、カイゼンファシリテーター、ワークショップ等で組織開発に従事。勉強会コミュニティ運営、イベント講演も多数あり。
Codezine Academy ScrumBootCamp Premium、機能するチームを作るためのカイゼン・ジャーニー、今からはじめるDX時代のアジャイル超入門 講師
著書「カイゼン・ジャーニー」、「ここはウォーターフォール市、アジャイル町」、「いちばんやさしいアジャイル開発の教本」、「WEB+DB PRESS Vol.111 見える化大作戦特集」
スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ(2020年版)という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。
「開発者」について、スクラムガイドにはこのように解説されています。
開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。
開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。
出典:スクラムガイド
- スプリントの計画(スプリントバックログ)を作成する。
- 完成の定義を忠実に守ることにより品質を作り込む。
- スプリントゴールに向けて毎日計画を適応させる。
- 専門家としてお互いに責任を持つ。
…とはいえ、実際の現場ではガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけば良いでしょうか。
外部の力を借りるって、どうすればいいの?
新井:
チームが取り組むプロジェクトにどんな技術や経験が必要か、開発者たちは分かっていることが多いと思います。
自分たちに足りないものがあるなら、社内外にアプローチ先を見つけておいて必要なときは借りられるといいですね。
中村:
「自分が頑張ればなんとかなる」っていうマインドになることもあります。
無理なものは無理だし、実際に今ないものは仕方がないんです。外部の有識者を招いてもいいし、社外が難しければ社内でもいいから力を借りればいいと思います。
特に昨今はリモートワークが定着してきて、スポットで力を借りやすくなっていると思うんです。
外の力を借りることって大事なことなのに、慣れていないチームが多いなと感じます。
新井:
何とかしなくちゃいけないと思い込みすぎちゃったり、特に契約の問題なんかは経験がないと遠く感じたりするのかもしれませんね。
顧客への価値提供やプロダクトゴールの実現といった目的のためには、いろんな選択肢を広げなくてはいけません。
中村:
私たちは仕事柄いろんなチームとの協働の経験がありますが、そもそも誰を呼べばいいのか? どう声をかけたらいいのか? 契約はどうするのか? 全然わからないという方もいますよね。
新井:
そういうことを知っている人がチーム内にいるといいですね。
中村:
自分たちだけで何とかしようとして、疲れ果ててやめてしまうケースも時々見かけます。
何か困っていることがあるなら声をかけてほしいですし、気軽に声をかけられるようになると、思った以上に応えてくれる人がいます。
特にアジャイル界隈にいる人はそういう人が多いはずです。私自身も、もちろんレッドジャーニーとしても、困ったときはお力になりたいと思っています。
参加者コメント:
外部の方をコーチとして招くのは良いと思いますが、外部の方に作業を依頼するようになってしまうと、そもそもチームの定義から違ってきてしまうような気がします。
中村:
コメントありがとうございます。
あくまでも「チームにスキルをトランスファーする」という文脈で来てもらうのはどうでしょうか。
一時的に発生する作業なら「一時的なパワー」として作業を依頼するのもいいですよね。
新井:
チーム内に全部揃っていてどんどん成長していけたら理想的ですが、そうとは限りませんから、どうしていくのかを考えながら最終的にベストに近づいていけたらいいんじゃないでしょうか。
Message from coaches
- チームにスキルが全部揃っているとは限らない。外部のコーチや専門家の力を借りて、スキルをトランスファーしてもらったり一時的なパワーとして使わせてもらったりしながら、チームの成長を目指そう。
- どんな技術や経験が必要か、開発者たちは分かるはず。社内外にアプローチ先を見つけておいて、必要に応じて力を借りよう。
- 「がんばればなんとかなる」というマインドは手放そう。ないものは仕方がないし、無理なものは無理。顧客への価値提供やプロダクトゴールの実現のために選択肢を広げよう。
- リモートワークの定着により、スポットでも力を借りやすくなっている。不慣れを理由に二の足を踏むのはもったいない。気軽に声をかけてみよう。
「完成の定義」を見直すタイミングは?
中村:
スクラムガイドには、「開発者は常に次の結果に責任を持つ。(中略)完成の定義を忠実に守ることにより品質を作り込む。」とあります。
実際のところ、皆さん「完成の定義」をどれくらい意識しているでしょうか?
受け入れ条件ではなく内部品質の話として、どうなれば自信をもって完成と言えるのか? 明確になっていないことが多い気がします。
新井:
スプリントレビューで、スプリントゴールが達成できなかったり、タスクが終わらなかったり、不具合が発生したりしたときは、完成の定義をアップデートしていきたいですよね。
中村:
チームのペースやルールがまだできていない段階では、プロダクトバックログアイテムごとに完成の定義のチェックをするようにタスクとして置いておくのもおすすめです。細かいチェック項目がすべてクリアになれば完成の定義を満たしているということになります。
新井:
なるほど。いい作戦ですね。ちょっと面倒かもしれませんが、習慣化していくといいかもしれません。
特に、立ち上がったばかりのチームでは丁寧に見ていくと良さそうです。
中村:
少なくともレトロスペクティブのタイミングで、完成の定義と照らし合わせて、自分たちの状況や足した方が良いもの、逆にもう要らないものはないかを考えながらアップデートしていけるといいと思います。
新井:
トラブルが起きた時は、スクラムマスターから「完成の定義を見直してみよう」と促してもいいかもしれません。
中村:
チームが自発的に気づけるようになるとベターですね。
Message from coaches
- 完成の定義は明確にしておきたい。スプリントレビューやレトロスペクティブのタイミングで見直しアップデートしよう。
- 立ち上がったばかりのチームでは、特に丁寧に見ていこう。完成の定義のチェック項目をタスクとして置いておくのもおすすめ。
- うまくいかないときは完成の定義を見直してみよう。スクラムマスターが促したり、チームが自発的に気づけるようになるとより理想的。
それぞれが個別に仕事をしながら「協働」するにはどうすればいい?
新井:
そもそもチームで働くということに納得していない、コミットしていないメンバーもいたりすると、「一人でやった方が早い」っていう状況に陥りがちですよね。
そういう場合は、お互いにとってのメリットを握った上でどうするか話をしていけるといいですね。
中村:
「一人でやった方が早い」って本当に思っているとしたら、根本的な価値観のすり合わせからスタートする必要がありそうです。
アジャイルの大前提にある「やってみないと分からない」「学習していくことで可能性を広げていく」っていう状況からは、だいぶ遠いところにいると思います。
新井:
一人でやり切ったとしても、結局手戻りが発生したり、後になって分かることが出てきたりしますよね。
個人の解釈には限界があって、実際にはニーズと違うものができあがることもある。
自分とは違う解釈を得られて初めてお客様がほしいものを作りあげていくことができると思います。
中村:
協働の大事なポイントは、違う解釈や反対意見を入れられるかどうかです。
協働の良さを最大限引き出すためにも、違う解釈や反対意見を得る機会を逃してはもったいないですね。
新井:
受け入れ条件って活字で表現されてはいますが、理解や解釈には幅があります。
解釈の多様性があれば、プロダクトオーナーやお客様が求めていたものと違うものができあがっちゃうような事態も、ある程度は事前に防げるのではないでしょうか。
Message from coaches
- 協働の大事なポイントは、自分とは違う解釈や反対意見を入れられるかどうか。それらを得られる機会を逃さないようにしよう。
- 解釈の多様性が広がれば、お客様が本当に求めているものとプロダクトゴールとのギャップを減らすことができる。
- アジャイルの大前提は、「やってみないと分からない」「学習していくことで可能性を広げていく」という価値観。「一人でやった方が早い」と思うときや、チームで働くことにコミットしていないメンバーがいるときは、根本的な価値観のすり合わせから始めよう。