横浜道場の特別編でワークショップをやらせていただきました。EXERCISEを行いました。私が1週間サボっていたので、どのようなワークショップだったかは、皆様のリポートにお任せしまして、考え方を書いておきたいと思います。ドキュメントでのコミュニケーション仕様書を文章だけで書いて伝える、という縛りを設けたワークショップなので、当日はドキュメントでのコミュニケーションをテーマに話をしてみました。毎日一緒にいない人に対してドキュメントで仕様を伝え説明はせいぜい数十分で伝えたりしています。その仕様書が1枚ならまだしも、数十ページあることはザラです。以下のように、工程(要件定義とか詳細設計とか)によって、会社も立場も違う人が作業する場合も多い。この状況で仕様の認識に齟齬がでた場合、ソフトウェア開発では下流(と言われる)の仕様をもらって詳細化もしくは作る人が責められたり、上流の人が例えば上司に、もっと詳細に分かりやすく書きなさい、と責められることになります。それで本当に認識の齟齬が減るの?という問いがこのワークショップに含まれています。ドキュメントは必要なもの*1なのですが、ドキュメントしっかり作ることとは別に何かをやらなければならないんじゃないの?ということです。その答えの一つがアジャイルアジャイルサムライに出てくるプラクティスを紹介し、最後にこのスライドをお見せしました(当日トラブルでこのような見た目になってなかったので公開!)。スクラムの基本的なプラクティスに乗っかると、自然とこのようなフィードバックプロセスが回ります。プロダクトに対するフィードバックと、チームに対するフィードバック。これが作るプロダクトへの疑問と課題を連続的に顕在化させ、Tryを行うことにより、問題を解決していきます。コミュニケーションというのは、ただ話す時間を増やせばいいということではありません。課題を解決することであったり、曖昧な部分を明確にしたり、より良いプロダクトをつくるために行うものです。いう意味で、目的に即したコミュニケーションが自然と発生するスクラムのプロセスは、理にかなっていると言えるのではないでしょうか。この気づきを職場に持って帰ってもらえると嬉しいですこのワークショップを上手くなっても何も役に立たないわけで、ここから例えば上記のような気づきを職場に持って帰り、カイゼンに向けて何か行動を起こしていただけると、これほど嬉しいことはありません。BIGLOBE道場でCIについて話しました。Yasunishiクラシック音楽好きのWebエンジニア、マネージャー、コーチ。Webのフレームワークを作ったり、サービスを作ったりしていたところ、スクラムとドメイン駆動設計(DDD)に出会いました。スクラムでの考え方に感動し、いかに最高のパフォーマンスを発揮できるチームにすることと、組織をどう変えていくかを考え続けると同時に、ドメイン駆動設計で巨大で複雑なソフトウェアをどう設計するかということを追求しています。頭で考えるのも好きですが、あくまで現場が大事。現場で体験したことをベースに、書いていきたいと思います。(2)スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。