デモの風景

デモとは

弊社では開発者と企画者が1つのチームとなって自社のWEBサービスを改善しています。
企画者はプロダクトオーナーと呼んでおり、完成した成果物が実際にどれだけの効果があったのか、チームに共有する役割もあります。
デモは、前の期間中に開発したプログラムを開発者がプロダクトオーナーに実際に動かしながら説明するミーティングで、企画の規模にもよりますが、多くの場合、本番環境にリリースする前に行われます。

デモの風景：プロダクトオーナー（右奥）と開発チーム。

和やかな雰囲気のデモ。

プロダクトオーナー（左）が開発メンバーの質問に答えている様子。皆真剣です。

どんなメリットがあるのか

実際に動かさないと分からない、使用感などのフィードバックが得られる。

プログラミングの成果物は完成するまで目に見えない場合も多く、実際に触ってみることで気づける良くない箇所が発見されることがあります。
デモでは、説明する開発者もプロダクトオーナーも、完成した機能を最初のユーザーとして利用することになるため、お互いがユーザーの目線で使用感に対する素直なフィードバックを交わし合うことができます。

プロダクトオーナーと一緒に行うため、チームとしての一体感を得られる。

デモはプロダクトオーナーと開発者が同じ場所で1つのPCを前に行います。
普段は開発者と企画者では役割が違うため考えていることや見ているところが違ったりしていますが、デモではお互い対等に意見を交わし合うことで良いプロダクトを目指すための議論ができ、チームとしての一体感を得ることができます。

デモはテスト済みの完成品を動かすため、開発の良いマイルストーンになる。

後述しますが、プロダクトオーナーも開発者も基本的に忙しい人たちの集まりですので、デモする機能は未完成品ではなくいつでもリリースできる完成品でないといけません。
そのため、デモの日程は開発スケジュールのマイルストーンとして置きやすく、デモの日程から逆算したスケジュールを各自が意識しやすくなります。

気をつけることは何か

フィードバックに対してチームは受け入れる姿勢がないといけない。

デモは大抵の場合、本番環境へのリリースの直前に行います。
フィードバックを受け入れる姿勢がないと、スケジュール後半での要件変更に寛容になれないでしょう。
しかし、開発途中あるいは完成後に見つかる良いアイデアを取り入れられないのは、非常にもったいないことです。
弊社の場合も、スクラムというアジャイルソフトウェア開発のフレームワークを導入するまでは、フィードバックをするという文化はありませんでした。
フィードバックは時に人の感情的な部分に触れることもありますので、フィードバックをする側にも受ける側にも配慮が必要です。デモはそういったフィードバックを体験できる場でもあります。

テストが通ってないものをデモしない。一部しか出来上がっていないものをデモしない。

プロダクトオーナーは非常に多忙です。
デモで成果物を確認した後、開発者の事由で本番環境にリリースできなければ、デモの時間は無駄になってしまいます。
そういった無駄を省くためにも、完成品をデモする必要があります。
なにより、デモというチームが集まる場で、未完成品をデモするのはとても格好が悪いので、みんな真剣です（笑）。

まとめ

・デモでは、実際に動かさないと分からない、使用感などのフィードバックが得られる。
・フィードバックに対してチームは受け入れる姿勢がないといけない。
・デモは、プロダクトオーナーと一緒に行うため、チームとしての一体感を得られる。
・デモは、テスト済みの完成品を動かすため、開発の良いマイルストーンになる。