思考と現場の間で

「いいサービスづくり」のために、組織づくりやソフトウェア設計など、考えていることを書きます

アジャイルサムライ読書会 横浜道場 特別編First でワークショップを行いました

もう1週間経ってしまったのですが、4月26日に、アジャイルサムライ読書会 横浜道場の特別編でワークショップをやらせていただきました。

ワークショップの内容

SCRUM TRAINERS GATHERING から、THE SPECIFICATION EXERCISEを行いました。

私が1週間サボっていたので、どのようなワークショップだったかは、皆様のリポートにお任せしまして、考え方を書いておきたいと思います。

ドキュメントでのコミュニケーション

仕様書を文章だけで書いて伝える、という縛りを設けたワークショップなので、当日はドキュメントでのコミュニケーションをテーマに話をしてみました。

コミュニケーションというのは、隣に座っている同僚や、家族でさえもうまくいかないことが多いにもかかわらず、

  • 毎日一緒にいない人に対して
  • ドキュメントで仕様を伝え
  • 説明はせいぜい数十分

で伝えたりしています。その仕様書が1枚ならまだしも、数十ページあることはザラです。しかも以下のように、工程(要件定義とか詳細設計とか)によって、会社も立場も違う人が作業する場合も多い。

この状況で仕様の認識に齟齬がでた場合、ソフトウェア開発では下流(と言われる)の仕様をもらって詳細化もしくは作る人が責められたり、上流の人が例えば上司に、もっと詳細に分かりやすく書きなさい、と責められることになります。

でも、それで本当に認識の齟齬が減るの?という問いがこのワークショップに含まれています。ドキュメントは必要なもの*1なのですが、ドキュメントしっかり作ることとは別に何かをやらなければならないんじゃないの?ということです。

その答えの一つがアジャイル

アジャイルサムライに出てくるプラクティスを紹介し、最後にこのスライドをお見せしました(当日トラブルでこのような見た目になってなかったので公開!)。例えばスクラムの基本的なプラクティスに乗っかると、自然とこのようなフィードバックプロセスが回ります。

プロダクトに対するフィードバックと、チームに対するフィードバック。これが作るプロダクトへの疑問と課題を連続的に顕在化させ、Tryを行うことにより、問題を解決していきます。

コミュニケーションというのは、ただ話す時間を増やせばいいということではありません。課題を解決することであったり、曖昧な部分を明確にしたり、より良いプロダクトをつくるために行うものです。

そういう意味で、目的に即したコミュニケーションが自然と発生するスクラムのプロセスは、理にかなっていると言えるのではないでしょうか。

この気づきを職場に持って帰ってもらえると嬉しいです

このワークショップを上手くなっても何も役に立たないわけで、ここから例えば上記のような気づきを職場に持って帰り、カイゼンに向けて何か行動を起こしていただけると、これほど嬉しいことはありません。

また、やり方は公開されていますし、簡単なので、同様のワークショップを職場でやってみてください!


最後に、このような場を与えてくださった木村さんをはじめとした横浜道場のスタッフの皆様、このワークショップをスクラムプロダクトオーナー勉強会で紹介してくださった川口さん、活発にお付き合いいただいた横浜道場参加者の皆様、ありがとうございました!

*1:誤解の無いように申し上げておくと、ドキュメントが要らないと言っているわけではありません