プレイブック -計画-

私たちの開発プロセスにおいて、動くソフトウェアを頻繁に小規模リリースすることは、主要目標の1つになっています。

この記事では、1つのプロダクトのイテレーションを1週間周期で行うコツをお話します。では、そのために必要なプロセスとコミュニケーション戦略について説明していきましょう。

デイリースタンドアップ(朝会)

私たちのチームは毎朝10時から10分間集まります。

そこで昨日の作業内容と今日の予定、そして作業を妨げている問題があれば、その内容について話します。スタンドアップが終わるとすぐに、問題点の解決や担当者のフォローにあたります。

スタンドアップをする目的は以下の通りです。

  • チームメンバー同士、顔を合わせる
  • 互いの作業を理解し、フォローし合えるようにする
  • 説明責任能力を高め、信頼関係を築く

タスク

私たちは長年、JIRAやPivotal Tracker、Lighthouse、Basecamp、Trajectory、Unfuddleなどのタスク管理システムを使ってきました。ここから先は、Trelloを使ったプロセスについて詳細に説明していきますが、全体的なプロセスは他のシステムでもそれほど違いはありません。

どのプロダクトをとっても同じものは存在しないため、プロダクト開発プロセスにおいては、柔軟性が重要になります。Trelloは開発体制の変更に対して、”臨機応変”に順応できるツールです。

Trelloボードは、縦列に付箋が貼られた壁をソフトウェアにしたようなものです。Trelloの用語では、壁が”ボード”、縦列が”リスト”、縦に貼られた付箋が”カード”に相当します。

以下の画像の例では、”Current”がボード、”In Progress”がリスト、”Set up Splunk for logging”がカードになります。

Next Up Trello board
Next Up Trelloボード

どのタスク管理システムにおいても、このような形式でプロダクト開発プロセス全体を見ることが重要です。このNext Upリストは1つの優先リストになっていて、これを見ればチームメンバーは次に何をすべきかが分かります。つまり1週間分の作業一覧になっているのです。

各カードの内容はジョブ・ストーリーやバグ修正、技術的なタスク、一般的なToDoなどです。

カードにはまず、簡単なアイデアを1、2文程度で記載します。その後、ボードからカードをピックアップし、詳細を追記していきます。(ビジネス的な視点で)その作業に注力する理由を説明したり、時には実装提案をメモ書きにしたりします(その提案が通るかは、設計者や開発者たちの判断によります。規範的ではないにしても、便利なやり方だと言えますね)。

Live Trello board
Live Trelloボード

Next Upリストにあるカードの優先順位付けと内容の精査が終われば、設計と開発の準備は完了です。次に設計者や開発者はカードの割り振りを行い、担当するカードに自分の顔写真を載せます。そして、そのカードをIn Progressリストに移します。

このIn Progressリストにあるカードの内容は、常に検討され、進化していきます。なおルールとして、同一人物の顔写真が同時に3枚以上のカードに表示されてはいけません。その後は、フィーチャーブランチで作業を行います。

設計者や開発者は、自分たちのフィーチャーブランチに対するプルリクエストを作成した時点で、カードをCode Reviewリストに移します。レビューアは、コードレビュー中に自分の顔写真をカードに載せます。

マスター環境へのマージ作業にボトルネックはないため、誰でも作業が可能です。

Testing on Staging(iPhoneアプリの場合はTesting on Ad Hoc build)リストにあるカードはステージング環境にデプロイ(iPhoneアプリの場合はHockeyApp経由で配布)されます。ここでカード作成者と設計者は、プロダクトの精度やユーザエクスペリエンスのレビューを行います。

ステージング環境へのデプロイ作業にもボトルネックはないため、誰でも作業が可能です。

Ready for Productionリストにあるカードの中には、ステージング環境で承認され、本番環境へデプロイできるもの(必ずしもロールアウトするとは限りません)が含まれています。

もちろん本番環境へのリリース作業にもボトルネックはなく、誰でも作業が可能です。

Live(Week of [date])リスト上にあるカードはすでにリリースされたものです。週ごとにLiveリストが存在するので、いつ何がリリースされたのかを後から調べることができます。

ウィークリーミーティング

週に1回、主に月曜日に、全員が1時間ほど対面もしくはテレビ会議で顔を合わせます。月曜のデイリースタンドアップの代わりにこれを行います。成果や障害、全員のゴールに関する懸念事項について話しあいます。1週間の始まりには、全員が元気で、やる気がみなぎった状態でなくてはいけません。

ウィークリーミーティングの進行役を務めるのはアドバイザーです。

  • 先週の進捗についてチームがどう感じているか、そして今週はどうするかを理解しましょう。クライアントとthoutbotの両側の各チームメンバーに、「先週はどうでしたか?今週の仕事に臨んでどのように感じていますか?」と確認するのです。これは「先週完遂した仕事のまとめ」というより(これはむしろデイリースタンドアップで行うべきです)、「各自がどう感じているかについて、定期的に喚起させる」という意味合いになります。ここではメモを取るようにしましょう。
  • 各メンバーに、リスクや懸念事項について言及してもらうようにしましょう。全員がこれを行った後に、全体としてこれらを軽減できるように仕事をするようにしましょう。また、たとえ自分以外の参加者が先に言及したものがあっても、同じ懸念があればそれに言及してもらいましょう。そうすることで、何がチームにとって最大の懸案事項で、それの解決に時間を費やすべきかの優先順位を決める手助けになります。これが、共に構築しているプロセスとプロダクトをどのようにして改善するか議論する機会となるのです。誰が何を懸念して、誰にその問題を割り振るか、ということをメモするようにしましょう。
  • 先週出したプロダクトをレビューし、実際のプロダクトを全員に見せ、その実現に貢献した仲間をたたえることで、プロジェクトの成功を祝いましょう。
  • 以上の事が終わったら、取ったメモをチームに公開し、ここまでの要処理事項がすべて書きとめられているかを確認します。これにより、チームメイトは進捗を見て、これまでのプロジェクトに対するフィーリングがどのように変動してきているかを理解し、ここまでの成果から導き出されるToDoを完遂することができるようになります。
    このような会議で得られるメモは、例えば以下のようになります。
Joel
* 先週
  * あっという間に過ぎてしまったように感じた
    * 最初数日は、プロジェクトについて考えたり理解していた
    * 我々がコードを十分に実装できているように思えない
    * 自分たちが何を作ろうとしているのか理解できたので気分がいい
* 今週
  * 自信がある

Ryan

* 先週
  * 急速に理解が進んだが、複雑さに圧倒されている
  * 週の終わりに向けてプロトタイピングとイテレーションをして、それが役立った
* 今週
  * 先週の始めに比べて大分いい感じ
  * ブレインストーミングとプロトタイプが助けになっている

Yadid

* 先週
  * 一瞬かのように過ぎ去ってしまった
  * かなり進捗が得られた
  * インタラクションの定義がとても重要だった
  * 目標に向かってきちんと進められている自信がある
* 今週
  * 時間が不安
  * ユーザスタディがリスクになりうる

懸念事項

* タイムライン - プロジェクトとしてとてもタイト (JQ, RC, YA)
* vanilla Railsの選択に不安がある (JQ, YA)
  * 内部に含まれる状態が多すぎる
* ビジュアルデザインよりも、インタラクション周りに不安がある (RC)
* テスト (やったところで成果が得られないかもしれない) (YA)
* ステージング用サーバが必要 (JQ)
  * 実APIと接続したくない
  * dev+testで、偽のAPIを作って接続している
  * Herokuだとこれはできない

懸念事項の割り当て

* Yadidがアプリと通信するためのステージング用のサーバをセットアップする
* RyanはYadidのステージング用サーバで迅速なランスルーを行う
* JoshはOmarについて調査する

企画会議は、以下のようにプロダクトの開発ステージに合わせて行うようにしましょう。

  1. 調査と検証:最低限動作するソフトウェアを開発できる段階まで、UIフローを検証したか。
  2. 発売時期:現行のソフトウェアやデプロイ済みのソフトウェアにおいて、想定通りのUIフローでユーザ操作が行われているか。
  3. 顧客エンゲージメント:エンゲージメントフローにおける各種数字はどうなっているか。

顧客からの声を共有してプロダクトが愛用されているかを検討し、数字を示して、今週は先週より使用する人数が増えたのか、または同じ人の使用する回数が多かったのかを調べます。

全ての開発段階で、以下について確認するべきです。

  • 正しいプロダクトを開発しているか。
  • 予算に基づき、どれくらいの時間が残っているか。

この答えを基に、タスク管理システムに計画を記録します。

  • 2週間経った”Live(Week of [date])”リストをアーカイブに記録する。
  • プロダクトデザインの優先順位を確認する。今週やるべき適切な分量のタスクを見積もり、Next Upに入れておく。
  • バグを確認する。重要なバグは全てNext Upに入れ、他の何よりも高い優先順位を設定しておく。常に修正作業は最初に行うようにしたい。
  • エンジニアリングタスクとリファクタリングタスクを確認する。前出したプロダクトデザインとバグのタスクについて、設計者と開発者が適切と考えるカードをNext Upに入れる。
  • Next Upにある全ての項目について、優先順位を再検討する。前週、リストの一番上にあったカードでも、一番下または他のボードやリストの下に移動してもいい場合がある。

タスク管理システムは、計画の基準となるリポジトリです。

タスクを伝える時、電話や直接会った時に口頭で知らせたり、またはグループ全体宛てではないメールや1対1のチャットを使っていては、情報が失われたり、忘れられたり、正しく伝わらなかったりします。プロジェクトにメンバが新しく加わったり、辞めたりした場合、この問題はさらに大きくなります。

会議では顧客から指導してもらうのではなく、議論をするべきです。根本的な問題が分からないままでは、解決策について話し合うことは不可能です。

機能、予算、スケジュールを減らすアプローチをしているため、私たちは挑戦的だと言われてきました。私たちは、顧客の提案に対して何度も”No”と言ってきました。”No”とは言いにくい言葉です。普通、”No”という言葉は良い印象を与えません。誰かが機能を加えてほしいと要求するには何かしらの理由があるでしょう。

私たちは”Yes”と言う人たちと対立しなければならない時があります。そんな時は、ソフトウェアの成功と失敗の歴史について知っている情報を武器に戦います。例えば、2004年の調査で、たった34%のソフトウェアプロジェクトしか成功していないという結果が発表されました。しかし朗報として、1994年の統計と比べると成功率は100%増となったということです。その主な理由には、プロジェクトが非常に小規模になってきたことが挙げられます。

あまり複雑じゃないために失敗に終わる、というソフトウェアプロジェクトはほとんどないでしょう。私たちが”No”と言うのは、開発中のソフトウェアを、できるだけシンプルにするためです。記述する全てのコードが資産であり、責務になります。

実際に公開されると、シンプルなソフトウェアの方が顧客の需要に応えるのに向いています。複雑なソフトウェアは、たとえ公開されても顧客の需要にすぐ応えることができません。

プロセスの変更

上記で説明したように、いくつかのリストを載せた単一のTrelloボードは、初期ステージのチームやプロダクトで利用すると効果的な場合が多いです。しかし、プロジェクトが成長するにつれ、もっと組織化したツールが必要になるでしょう。例えば、”Current”ボードには、以下のリストを最初に加えたくなります。

  • バグ
  • プロダクトデザイン
  • 技術的な項目

その後に、これらのリストを完全なボードとして、更に組織化していきます。ボードとして分けることで、それぞれ関連する事項のアドレスを指定する相対値が求めやすくなります。また、ボードを分けることで”Current”ボードの整然さを保ち、プロダクトチームが目の前の作業に集中できるようになります。

チームが扱うプロダクトのステージや、コミュニケーションの必要性に合わせて、それぞれのボードは組織化できます。

“Bug”ボードには、相対的なクリティカリティバグを示すのに、ラベルを使うことがあります。Critical(重要)とラベル付けされたバグは、即座に”Current”ボードのNext Upに入れられます。バグが重要ではない場合は、次の週次検討日までBugボードに残ります。バグのカードにはバグの再現手順が書かれ、任意でスクリーンショットやスクリーンキャストが一緒に添えられます。

“Product Design”ボード上のカードには、ユーザフローのスケッチの結果、ユーザビリティテスト、別のユーザ調査、ビジュアルデザインの改良案に関する設計者の考えなどがあるのが一般的です。

“Engineering”ボード上のカードには、バグを減らしユーザエクスペリエンスを向上させるのに必要な、リファクタリングや他の技術的なタスクが書かれています。”レスポンスタイム”の向上は、全てのアプリが最優先にするユーザエクスペリエンスの目標です。Criticalとラベル付けされた技術的なタスクは、即座にNext Upへ引き上げられます。重要じゃないタスクであれば、次の週次検討日まで”Engineering”ボードに留まります。