スタンドファームではクラウドで請求書を管理できる「Misoca」というサービスを2年前から提供しています。

今日はMisocaの機能を強化していく過程がどのように行われているのか過去から現在までの開発プロセスの進化をご紹介したいと思います。

まずはカウボーイ期から。

1. Ver1.0 カウボーイ期 (〜2013/12)

Misocaはスタンドファーム創業者である豊吉(@toyoshi)と松本(@Dominion525)の2人によって作られました。

チームではなく個人が頑張る時代

そこにアルバイトとしてプログラマーを数名を雇うことになりました。そのため2人だけで共有していればよかった情報をチームとしても共有する必要が出てきました。

しかし、当時はチームとして活動する意識が低く、今までの2人だけで作業をしていた環境を引きずるようになってしまいました。この頃はまだ受託開発が主な業務内容であったため、チームとして活動する必要性が低かったこともあります。

タスクは指示されてやるもの、他人の作業は知らない

個々のプログラマーに対して、豊吉と松本のどちらかが指示を出し、プログラマーがSubversion+Redmineを使いながら進捗を報告する、という流れで開発が進んでいました。

プログラマーからすると、指示をもらってレビューをしてもらうのは常に豊吉、松本のどちらかでした。この時期の問題点は2点です。

• 個々のプログラマーは豊吉、松本しか接点がないため、他のプログラマーが何をしているのかわからない
• プログラマーへのタスクの指示とレビューをする業務で豊吉、松本の仕事が忙殺される

チーム全体として情報交換をする場が設けられていないため、他のメンバーの作業をよく知らないまま開発が行われていました。少しでもメンバー間のコミュニケーションを促進しようとChatWorkを導入したり工夫を試みましたが劇的な改善にまでは至りませんでした。

それでも、まだせいぜい数名のチームのため大きな問題には至りませんでした。

どうにかしたいと思いつつ…

そんな状況ですが、ツールは常に新しいものを取り入れようという意欲はありました。

• ChatWork導入(2012年7月末)
• SubversionからGitHubのPull Request運用に移行(2012年8月)
• RedmineからPivotalTrackerへ移行 (2012年10月)

問題があるのはわかっているが、どう改善したらよいのかわからない。もがきながら開発してる時期でした。

2. Ver2.0 開発ミーティング導入期　(2014/01 ~ 2014/03)

資金調達に成功、飛躍のときへ

スタンドファームは2013年9月に資金調達を行いました。それまでは受託開発を主な収益源としていましたが、これを期にMisocaの開発を本格化させて行くことになります。

その結果、新たにWebマーケティング担当やプログラマーがチームに参画しました。

さすがに従来の豊吉、松本が直接指示〜レビューするプロセスのままでは限界が見え始めています。

そこで改善案として出されたのが、「週一で開発ミーティングをやってみよう」というものでした。

開発ミーティングの内容は以下の通りです。

• 先週一週間の成果をみんなの前で発表をしよう(≠スプリントプランニング)
• 開発のプロセスをふりかえろう
• プランニングみたいなことをしよう

みんなの前で発表会をしよう

発表会とはスクラムなどで言う、スプリントプランニングから着想を得ていますが目的が異なります。

スプリントプランニングはチームの作業をプロダクトオーナーが成果として受け入れるかどうか、という会ですが、

この時のスタンドファームでいう「発表会」とは単にお互いの成果を共有をしましょう、ということが重視されていました。

開発のプロセスをふりかえろう

既にふりかえりというイベントがスタンドファーム内で行われていました。

しかしふりかえりといっても開発プロセスについて改善を考えるものではなかったため新たに設けました。

プランニングをしよう

それまではMisocaのロードマップがチームに対して語られることはありませんでした。チームとしての形になっていなかったため話すことの必要性も感じていませんでした。

それはよくない、ということで、豊吉、松本に直近で予定している機能追加について話してもらう場をつくることにしました。

以上のことを、毎週、月曜日に実施しました。

それまでは個々のことだけしか見れなかった環境であったのを、チームとして取り組む意識を根付かせる時期だったと思います。

しかし、ミーティングを開催するものの、個別の議論に深入りしすぎて予定の時間をオーバーするなどして、開発の時間を圧迫する事態に。そこでまずはミーティングの時間を計測して記録を取るようにし始めました。ダラダラと時間を消費することを好まないメンバーばかりであったため時間についての意識は常に全員が持っていました。

3. Ver2.1 タスクかんばん導入期 (2014/03 ~ 2014/06)

タスクの見える化

開発ミーティングをすることでチームとしての一体感が生まれてきました。次に望まれたのが、より詳細なタスクの管理と見える化でした。

Misocaでは機能の追加を重視して開発されていたため、細かい使い勝手の改善が放置されがちでした。

この時期にパートタイムのアルバイトとしてプログラマーが2名増員されました。フルタイムでは働けないため大きな機能の開発は任せられません。そこで、後回しにしていた細かいタスクをしてもらうことになりました。

そのために、タスク管理には「機能追加」と「機能改善」を分けて管理する必要が出てきました。

アナログなホワイトボードを活用する

当時は、Pivotal Trackerで開発タスクを管理していましたが適切に運用されているとは言い難い状況でした。みんなでタスクを共有している、という意識が欠如していました。

そこで考えだされたのが、スタンドファーム版(社内ではコクボ式とも呼ばれる)タスクかんばんです。デジタルなツールに頼るよりもまずはアナログなホワイトボードを持ってきて、フリーフォーマットでやってみよう、という話になりました。

「機能追加」と「機能改善」の境界を上下で分けて付箋を貼ってタスクの見える化をするようになりました。

メンバーのTwitterアイコンを印刷したマグネットを作成して担当している付箋(タスク)に貼るようにしました。

ホワイトボードにチームがやることがすべてある

このスタンドファーム版タスクかんばんによってタスクを管理して、開発ミーティングなどを進めることにより、お互いの状況の把握がより容易になりました。

自分以外のタスクも含めてチームとしての取り組むべきものだと意識付けに取り組んだ時期でした。

しかし、同時に次の課題へと直面しました。

4. Ver 3.0 脱アナログ化 (2014/06 ~ 現在)

メンバーがオフィスにいるとは限らない

スタンドファームは名古屋の会社です。オフィスも名古屋にあります。

名古屋だけではなく岐阜や東京で働くメンバーもいます。

それに加えて、2014年に入ってから、スタンドファームではリモート勤務が自然と取り入られるようになったため、普段はオフィスに来ているメンバーも自宅で仕事をする日も増えてきました。

リモートメンバーと協調するために

リモートメンバーとオフィスメンバーの垣根をなくすために、Googleハングアウトで常時会話ができるようにしました。高解像度カメラと広角カメラの2種類を用意して、指向性のあるマイクも導入しました。2種類のカメラを使い分けることで、的確にリモートメンバーへ映したいものを映せるようになりました。

開発ミーティングにも可能な限り、リモートの人に参加してもらうようになり、コードレビューや発表会もハングアウトの画面共有を使って全メンバーで行うようになりました。しかし、頑張ってカメラで映してもどうにも伝わりにくいものがありました。それがアナログなホワイトボードを使ったタスクかんばんです。

タスクかんばんの致命的な問題は次の2点です。

• リモートで作業している人から見えにくい
• デジタルツールとの同期が煩雑

それまでは、「まずはオフィスメンバー内だけでの意識改革をやろう」と行ってきたのが、リモートメンバーを含めてチームとしての一体感を出す方向へと舵を切り始めました。

(Webカメラを使ってタスクかんばんをハングアウト経由で共有するなど試してみましたが、コストに見合うほどの効果はありませんでした)

アナログを超えて

そこで決断したのが、

• タスクかんばんの廃止
• デジタルツールへの情報の集約化

です。

タスクの管理はTrelloに集約することにしました。ふりかえりもKPTを付箋に書くことをやめました。

リモートメンバーとともに

さらにアナログ偏重のため、Trelloの更新が怠りがちだったのを改善するため、朝会時に進行中のすべてのカードのステータスの更新を全メンバーの前でやるようになりました。個人の特徴が大きく出るアナログ的な良さが失われたのは確かですが、それ以上にリモートメンバーを含めて、全員がチームとしての一体感を出せる選択をしました。

今も毎日、試行錯誤しながら「チームのパフォーマンスを最大化する」ための改善を日々取り組んでいます。

5. 今後の課題

今見えている課題としては以下の2点です。

• タスクの見積ができていない
  • そのため計画も立てられない
• コードレビューをプロセスに上手に組み込めてない
  • レビュアーのアサインとレビューの実施に時間がかかっている
  • (コードレビューは昔から行われている)
• 仕掛中(Work in progress)のPull Requestがとても多い
  • rebase/mergeするときに競合することは多くはないがいつも渋滞してる

見積については、自社サービス開発であるが故に後回しにされてきました。見積をするためのコストと得られるメリットのバランスを見ながら取り組んでいきたいと思っています。

コードレビュー・仕掛中Pull Requestについては、やはりまだメンバー個々で黙々と頑張る文化が残っているために協調作業が難しくなりがちになってしまいます。チームメンバーの殆どがフルタイムではなくパートタイムでの勤務のため、致し方ないところはあるのですが、今後取り組んでいくべき課題だと認識しています。

6. スタンドファーム独自の文化

豊松会

開発ミーティングの一部として「発表会」があります。発表会は今では「豊松会」と呼ばれています。その経緯についてご紹介します。

元々、発表会の目的は「自分がやった成果をみんなの前でアピールしよう」という趣旨でした。

それが会を重ねるごとに「(主に)豊吉、松本からのフィードバックを受ける会」に変わってきました。

「発表する」と必然的に「フィードバックを受ける」ことになります。そのフィードバックを受けることにチームとして価値を感じたためです。そして、豊吉、松本はMisocaの責任者であるため機能や仕様を決めるのは必然的に2人の同意が必要です。

2人とも自分が関知しない仕様になることを望みません。

その2人からのフィードバックを重視する(2人が揃っていないと意味がない)という意味で豊吉と松本の頭文字をとって「豊松会」と呼ばれるようになりました。

ふんわりバックログ

通常、スクラムなどでいうバックログにはReadyな状態になっているバックログ・アイテムが入ると思います(要件から受入基準までしっかり練られている)。

スタンドファームではバックログ・アイテムがReadyかどうかは重視されません。これは、新機能の追加をどういった仕組み(UIや表示項目など)で実現するのか最初から決められないためです。

ふんわりした要件からサンプル設計・実装と豊松会によるフィードバックを繰り返しながら細部をつめていきます。なので、スタンドファームでは明確なイテレーションの単位がないとも言えます。

豊吉、松本が常にチームと近い距離感にいるため最初からバシッと決めるよりも、細かくフィードバックを受けて細部を詰めていく方向へ流れています。要件を出す人と開発するチームの距離が精神的にも物理的にも近いからこそできることですね。

7. タスクかんばんは無駄なコストだったのか？

タスクかんばんは運用開始してから数ヶ月で終了することになりました。

果たしてタスクかんばんは必要なツールだったのでしょうか？

いろいろな視点があると思いますが、私たちは必要だったと考えます。チームのタスク管理を本気でやろうと思った時、まずはアナログでやったことに大きな意味がありました。

アナログであるが故に物理的にもオフィスの一部になるわけでその存在を否が応でも自分たちのことだと意識することができたと思います。またメンバーそれぞれの身体性を視認できることもアナログの大きなアドバンテージです。

デジタルとアナログのどちらがよいか、という優劣の問題ではなく、これは選択の問題です。

8. スタンドファームで今使っているツール

• Trello
  • タスク管理
• ChatWork
  • リアルタイムなコミュニケーション
• Jenkins
  • CI
• GitHub
  • issues
  • pull request
  • wiki
• Google Apps
  • Docs
  • Gmail
• Qiita:Team
  • 日報
• Google Hangout
  • オフィスメンバーとリモートメンバーの中継

チームのアクティビティはTrelloとGitHubのPullRequest一覧を見ればすべてわかるようになっています。Qiita:Teamは最近になって取り入れられたのですが、日報を書くという習慣が定着することで想像していた以上にチーム間の結びつきがよくなった気がします。日報といっても各自の裁量で書かれているため緩い内容ですが、ゆるふわな空気で組織の文化をつくるのに役立っています。

過去に使っていたツール

• Pivotal Tracker
• Redmine
• Subversion

Pivotal Trackerはとてもよくできた優秀なツールでしたが、ツールの持つプロセスの制約が強すぎて使いこなせませんでした。

9. 書いた人

小久保 祐介 (こくぼ ゆうすけ)

株式会社ファントムタイプ代表取締役

2013年12月よりMisoca開発者としてチームに参画。プログラマーとしてMisocaの機能開発を行いつつ、本記事でご紹介したような開発プロセスの改善にも取り組んでいます。株式会社ファントムタイプはスタートアップ企業の成長を応援する会社です。

• Phantom Type Co. Ltd: 株式会社ファントムタイプ
• @yusuke_kokubo