「一人でやった方が早い」から「協働」へ、チームが変わるためのポイントとは？ ─ ”とはいえ”シリーズ #7「開発者編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第7回のテーマは「開発者」です。後編では、立場や役割の壁を越えて「協働」するために必要な体制やメンタリティ、コミュニケーションのあり方についてお話します。

前編はこちら

機能横断型のスクラムチームって、どうすれば実現できる？ ─ ”とはいえ”シリーズ #7「開発者編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

外部の力を借りるって、どうすればいいの？

新井：
チームが取り組むプロジェクトにどんな技術や経験が必要か、開発者たちは分かっていることが多いと思います。

自分たちに足りないものがあるなら、社内外にアプローチ先を見つけておいて必要なときは借りられるといいですね。

中村：
「自分が頑張ればなんとかなる」っていうマインドになることもあります。
無理なものは無理だし、実際に今ないものは仕方がないんです。外部の有識者を招いてもいいし、社外が難しければ社内でもいいから力を借りればいいと思います。

特に昨今はリモートワークが定着してきて、スポットで力を借りやすくなっていると思うんです。
外の力を借りることって大事なことなのに、慣れていないチームが多いなと感じます。

新井：
何とかしなくちゃいけないと思い込みすぎちゃったり、特に契約の問題なんかは経験がないと遠く感じたりするのかもしれませんね。

顧客への価値提供やプロダクトゴールの実現といった目的のためには、いろんな選択肢を広げなくてはいけません。

中村：
私たちは仕事柄いろんなチームとの協働の経験がありますが、そもそも誰を呼べばいいのか？　どう声をかけたらいいのか？　契約はどうするのか？　全然わからないという方もいますよね。

新井：
そういうことを知っている人がチーム内にいるといいですね。

中村：
自分たちだけで何とかしようとして、疲れ果ててやめてしまうケースも時々見かけます。

何か困っていることがあるなら声をかけてほしいですし、気軽に声をかけられるようになると、思った以上に応えてくれる人がいます。

特にアジャイル界隈にいる人はそういう人が多いはずです。私自身も、もちろんレッドジャーニーとしても、困ったときはお力になりたいと思っています。

参加者コメント：
外部の方をコーチとして招くのは良いと思いますが、外部の方に作業を依頼するようになってしまうと、そもそもチームの定義から違ってきてしまうような気がします。

中村：
コメントありがとうございます。
あくまでも「チームにスキルをトランスファーする」という文脈で来てもらうのはどうでしょうか。
一時的に発生する作業なら「一時的なパワー」として作業を依頼するのもいいですよね。

新井：
チーム内に全部揃っていてどんどん成長していけたら理想的ですが、そうとは限りませんから、どうしていくのかを考えながら最終的にベストに近づいていけたらいいんじゃないでしょうか。

Message from coaches

• チームにスキルが全部揃っているとは限らない。外部のコーチや専門家の力を借りて、スキルをトランスファーしてもらったり一時的なパワーとして使わせてもらったりしながら、チームの成長を目指そう。
• どんな技術や経験が必要か、開発者たちは分かるはず。社内外にアプローチ先を見つけておいて、必要に応じて力を借りよう。
• 「がんばればなんとかなる」というマインドは手放そう。ないものは仕方がないし、無理なものは無理。顧客への価値提供やプロダクトゴールの実現のために選択肢を広げよう。
• リモートワークの定着により、スポットでも力を借りやすくなっている。不慣れを理由に二の足を踏むのはもったいない。気軽に声をかけてみよう。

「完成の定義」を見直すタイミングは？

中村：
スクラムガイドには、「開発者は常に次の結果に責任を持つ。（中略）完成の定義を忠実に守ることにより品質を作り込む。」とあります。

実際のところ、皆さん「完成の定義」をどれくらい意識しているでしょうか？

受け入れ条件ではなく内部品質の話として、どうなれば自信をもって完成と言えるのか？　明確になっていないことが多い気がします。

新井：
スプリントレビューで、スプリントゴールが達成できなかったり、タスクが終わらなかったり、不具合が発生したりしたときは、完成の定義をアップデートしていきたいですよね。

中村：
チームのペースやルールがまだできていない段階では、プロダクトバックログアイテムごとに完成の定義のチェックをするようにタスクとして置いておくのもおすすめです。細かいチェック項目がすべてクリアになれば完成の定義を満たしているということになります。

新井：
なるほど。いい作戦ですね。ちょっと面倒かもしれませんが、習慣化していくといいかもしれません。
特に、立ち上がったばかりのチームでは丁寧に見ていくと良さそうです。

中村：
少なくともレトロスペクティブのタイミングで、完成の定義と照らし合わせて、自分たちの状況や足した方が良いもの、逆にもう要らないものはないかを考えながらアップデートしていけるといいと思います。

新井：
トラブルが起きた時は、スクラムマスターから「完成の定義を見直してみよう」と促してもいいかもしれません。

中村：
チームが自発的に気づけるようになるとベターですね。

Message from coaches

• 完成の定義は明確にしておきたい。スプリントレビューやレトロスペクティブのタイミングで見直しアップデートしよう。
• 立ち上がったばかりのチームでは、特に丁寧に見ていこう。完成の定義のチェック項目をタスクとして置いておくのもおすすめ。
• うまくいかないときは完成の定義を見直してみよう。スクラムマスターが促したり、チームが自発的に気づけるようになるとより理想的。

それぞれが個別に仕事をしながら「協働」するにはどうすればいい？

新井：
そもそもチームで働くということに納得していない、コミットしていないメンバーもいたりすると、「一人でやった方が早い」っていう状況に陥りがちですよね。

そういう場合は、お互いにとってのメリットを握った上でどうするか話をしていけるといいですね。

中村：
「一人でやった方が早い」って本当に思っているとしたら、根本的な価値観のすり合わせからスタートする必要がありそうです。

アジャイルの大前提にある「やってみないと分からない」「学習していくことで可能性を広げていく」っていう状況からは、だいぶ遠いところにいると思います。

新井：
一人でやり切ったとしても、結局手戻りが発生したり、後になって分かることが出てきたりしますよね。
個人の解釈には限界があって、実際にはニーズと違うものができあがることもある。
自分とは違う解釈を得られて初めてお客様がほしいものを作りあげていくことができると思います。

中村：
協働の大事なポイントは、違う解釈や反対意見を入れられるかどうかです。
協働の良さを最大限引き出すためにも、違う解釈や反対意見を得る機会を逃してはもったいないですね。

新井：
受け入れ条件って活字で表現されてはいますが、理解や解釈には幅があります。
解釈の多様性があれば、プロダクトオーナーやお客様が求めていたものと違うものができあがっちゃうような事態も、ある程度は事前に防げるのではないでしょうか。

Message from coaches

• 協働の大事なポイントは、自分とは違う解釈や反対意見を入れられるかどうか。それらを得られる機会を逃さないようにしよう。
• 解釈の多様性が広がれば、お客様が本当に求めているものとプロダクトゴールとのギャップを減らすことができる。
• アジャイルの大前提は、「やってみないと分からない」「学習していくことで可能性を広げていく」という価値観。「一人でやった方が早い」と思うときや、チームで働くことにコミットしていないメンバーがいるときは、根本的な価値観のすり合わせから始めよう。