2014年6月27日(金) に東京にて行われた Agile Japan 2014 の公募セッションに採択され、「効果的に試行錯誤を行うための仕組みづくり〜失敗はおはやめに、プロダクトの成長は着実に〜」というタイトルにて発表の機会をいただきました。資料は以下に公開しております。
今回の発表では試みとして、ポストイットとペンを参加者の方に事前に配り、発表を聞きながら
- 印象に残ったこと
- 自分たちが抱えている問題・課題
- 自分たちで取り組んでいること
をメモしてもらいました。このエントリではそれも踏まえて振り返ってみたいと思います。
ポストイットの内容
まず、計 152 枚 (印象に残ったもの 76枚、自分たちの問題 41枚、自分たちの取り組み 23枚、質問・その他 12枚) ものポストイットが集まりました。
印象に残った内容には、UI 開発に積極的に開発者が参加するという部分と、最後のコミュニケーションに関わるところ ( 特にツッコミの話 ) が各々4分の1ずつをしめており、そのあとにデリバリの自動化がつづいていました。
次に、4割以上がコミュニケーションや情報共有を自分たちの課題にあげられていました。それに続いて、テストやデリバリの自動化と、アジャイルへの理解やチームビルディングといったものが 2 割ずつをしめるような形でした。
その中で、自分たちの取り組みで行っているものとしては、やはり朝会や情報の可視化といった主に情報共有といったところに関わるものが 4 割近くをしめ、それ以外は割と個別の取り組みを色々となされているようでした。
これらより、発表の中で響いた内容からも、自分たちの課題と取り組んでいることからも
- ゴールの共有や情報共有
- コミュニケーション
に関わる部分が今回の来場者の方の大きな関心事であったといえそうです。
発表者としてのふりかえり
発表者としての振り返りを簡単にしてみたのが上の KPT となります。
実は今回発表するにあたって、話し手としても一番テンションが高かったし、面白く感じていただけるであろうと予想していたのは「失敗できる環境づくり」としてのベータ環境の話でした。これは、自分たちの経験の中でもベータ環境を作ったことによって、その後続のデリバリの仕組みが整っていったり、開発プロセスの中により実験的な要素を組み込むことが出来るようになったため、ここが「響くだろう」と思い込んでいた訳です。
その思い込みがあったため、事前リハーサルをする前には、チームでのUI設計の話などを削って「ベータ環境の作り方」をより具体的に、テクニカルなものにフォーカスしたほうが良いのではないかと考えていたくらいです。そうしなかったのは、リハーサルの後に「UI 設計の部分も、もう少しストーリーの流れ方を考え直したら十分魅力的」「コミュニケーションに関わるウェットな内容があるほうが面白い」といったフィードバックをもらったからです。その結果、むしろ「ベータ環境推しにしない」方向に構成の調整をおこないました。
そして蓋をあけてみると、ベータ環境の話よりも UI 設計から開発者が積極的に関わることでゴールの共有が出来る、といったところや、ツッコミにも作法がある、といった話のほうが共感を得たり、納得感を感じて頂けました。発表の内容作りにおいても、僕らがプロダクト作りで普段意識している他者からのフィードバックの重要性を改めて感じた次第でした。
また、今回このような検証が出来たのもポストイットを使ってフィードバックをもらう試みをしたからです。このアイディアそのものは、発表の事前準備の中で、ファシリテーションを担当の方と、どう参加者とディスカッションしたりフィードバックをもらいやすくするか、といったやり取りの中であがったものでした。そういった配慮をイベントスタッフの方にいただけたことも幸運でしたし、今後自分がイベントを運営する側に回った際にもそういう配慮が出来れば、と感じています。
頂いた質問へのご回答
発表の内容に関する質問をここでは幾つかをピックアップして回答いたします。まだ私たち自身も経験のない内容もあり、そちらについてはまた私たち自身が直面したときに経験や知見などを共有させていただければと思います。
Q. プロダクションでの A/B テストはどのように行っているのか？
プロダクション環境において A/B テストはほとんど行っていないのが実状です。というのも、私たちのプロダクトの特性上、一言でいえば「出した機能 (UI) を後から変えにくい」といった側面があります。チームでお仕事で使って頂く際には、導入の担当の方がチームに画面の説明をする必要があったり、場合によっては個別マニュアルなどを準備されていたりするのですが、機能(UI)変更を行うことそのものが、こういったチームに浸透させる作業の阻害要因になりえることもあるためです。ですので、プロダクションでの A/B テストを行う変わりに、
- ベータ環境でのドッグフーディング
- ユーザへのヒアリング
- 特定ユーザのみに限定したベータテスト
といったアプローチで、プロダクションリリースの前にその精度を高める工夫をしています。
Q. UI に工数をかける効果は？
ある機能開発が完了したときに出来上がったものが、事前にチームで認識あわせしたものと「全然違う」ということがなくなります。また、デザイナさんにデザイン依頼するときも、既に様々なパターンを思考実験しているため、認識あわせも行いやすくクオリティの高いデザインを作成いただけることにつながっていると思います。
正直なところ定量的な効果をお伝えしがたい部分もありますが、以下の記事で述べられている感覚に私たちも近いものを感じています。
エンジニアを含めたメンバー全員がUI・UXについて真剣に考えることできれば、おのずとデザインの精度も上がりますし、無駄な修正を減らすことにもつながります。結果、プロジェクトの遅延も防げる。だからこそチーム内の議論を大事にしたんです
参考: 「UXづくりは開発風土づくりそのもの」会計アプリfreeeの関口聡介氏が、Googleでつかんだ信念【連載:UI・UXキホンのキ】
Q. 「使いやすい」UI はどう決定するのか？
とても難しい質問ですが、私たちは UI ベースのディスカッションをして、ドッグフーディングを通してみた結果、チームのメンバー間で大きく意見が異なるといった事はそこまで多くはありません。ですので、大体のところはチームの皆の体験に基づいて決まることが多いです。
ただ、それでも方向が決まらない場合も勿論ありますので、そういったときはプロダクトオーナーの意見を優先します。UI の方向性に対しては多数決で決めるよりは、プロダクトオーナーの意見を信頼することで、UI の方向性が迷子にならないよう配慮しています。
Q. フィードバックに利用される成果物は毎回更新されているものなのか、スプリント等の定期的なものなのか？
まず、ベータ環境へのデリバリは、開発チームで合意がとれたタイミングで不定期に行っています。広くフィードバックが欲しい時と、開発チームに閉じた実験的な内容の確認をしたい場合の双方があるため、前者の場合に全メンバーにフィードバックを欲しい旨の呼びかけをするような運用をしています。
Q. ( 情報の透明性について ) 人数が増えるとどのように管理、範囲を決めていくのか？
今のところ、弊社は 24,5 名の小さなチームですので、プロダクトに関わるものは原則「オープンにする」という形で運用しています。人数が増えた場合にこのポリシーに対する懸念の一つは、情報流量が増えることから、情報がスルーされるようになり、結果共有されていないのと同様の状況になる事かとは思います。その場合は、何らかの対策を講じるとは思いますが、基本それは「情報量」への対策であって「原則オープンにする」という姿勢そのものは、なるべく保とうとするのではないか、と考えています。
Q. 透明化した情報はどのようにまとめるのか？
基本は Backlog に Wiki や課題といった形で集約しています。また私たちが利用している Typetalk には「まとめ」機能があり、それを利用することで、議論した内容が流れてしまわないようにしています。
参考
Q. 「フィードバックを得やすい環境づくり」をどのように工夫しているのか？
私たちは基本プロダクト毎のチーム構成になっているのですが、情報共有ツール ( Backlog, Cacoo, Typetalk ) では分け隔てなく、全てのスタッフが全てのプロダクトの情報を見れるようにしています。
また弊社は拠点が分かれているため、日常的な軽いコミュニケーションがしにくかった問題があったのですが、以下のようなオンラインの常時接続の環境を導入してその問題を解決しました。
発表の中の「ツッコミビリティ」の話で取り上げた Aiming さんでは企画の方と開発の方を近くに机をおくといった工夫もされているようです。具体的な工夫については、各々のチームの背景に依存する部分が大きいと思いますし、私自身も他の方々がどんな工夫をされているか知りたいです！
参考: 変化の時代で勝つための開発組織のあり方 (21,22 ページあたり)
Q. シェルやバッチではなくチャットツールでデリバリしている理由を知りたい
日常的に気軽に利用しているツールからデリバリ出来るようにすることで、デリバリ作業に対する心理的な障壁を取り払うのが意図の一つです。これによって、アプリケーション開発者も気軽にデリバリに参加する事が出来るようになりました。またトラブル等があった場合でも、作業が共有されており、そのチャットを起点にコミュニケーションをやりやすい、といった側面もあります。
私たちはデリバリを実行するジョブを CI サーバ上に構築しているのですが、それによって
- デリバリ時のログが残る
- デリバリに必要な環境構築を手元で行わなくてよくなる
といった運用面でのメリットもあります。
参考: GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（後編）～DevOps Day Tokyo 2013
Q. ベータ環境が出来る前はどのパターンで作っていたか？
プロダクション環境とステージング環境のみでした。ステージング環境ではテストしていたものの、2012年秋のビッグリリースでは失敗してしまいました。その経験から「どうすれば事前に防げたのか？」を考えた結果「日常的に利用するベータ環境」に取り組むことになりました。
最後に
ポストイットにも何件か書かれていましたし、発表後に直接質問にこられた方ともお話したのですが、今回の発表で一つお伝えしたかったことは、
- カイゼンには時間がかかる
- 成果はすぐにあらわれるものではない
ということです。スライドでもお見せしたとおり、やはり半年くらいはプロセスそのものが安定するのに時間がかかりますし、それがチームに定着していくのには年単位でかかるものもあると思います。ただ成果がまだ出ない渦中にいるときは、正しい方向に向かっているのか不安になることもあると思います。そうした時に「これくらい時間かかるものなんだ」という一つの実例として、今回の発表をみてもらえると嬉しく思います。
懇親会の発表者インタビューでもお話しましたが、私自身が今回の発表内容を何かの最終形であるとは考えていません。むしろ、自分たちの取り組みを共有することで、他の人からフィードバックをもらい、またそれを進化させていきたいと考えています。参加者のみなさまも、自分たち独自のやり方や考えはきっとあると思いますので、是非そういった事で一言共有したい！等ありましたら、お気軽にこのブログにでもコメントいただけると幸いです。
最後に、参加者のみなさま、そしてこのイベントを実現した実行委員のみなさま、本当にありがとうございました！