開発前の「要件定義」まで入りこんだ受託開発を！

弊社は最初に、受託開発の事業からスタートしました。お客さんとモノを作る時は、オーダーされたことを実行するだけではなく、自分達の意見もしっかりとお伝えし、1つのチームとして開発していくことを心がけています。

なるべく企画から一緒に入らせてもらうようにお願いしていますね。

企画段階ではリーン・スタートアップと言いますか、「プロダクトの価値がなんなのか」という部分についてお客さんと一緒に仮説・検証を繰り返し行うスタイルを取っています。

実際にターゲットになるユーザーの方に、お客さんと一緒に話を聞きに行くことも多いですね。

一般的な受託開発であれば、発注されたモノを作って納品すれば終わりなのですが、僕たちは「開発の手前」のプロセスも良くしていきたいと考えています。

というのも、過去に非常に完成度が高いプロダクトを作ったのに、誰にも使われないことがあって…。誰も望んでいないものを、高い技術や開発手法を使って作ってしまったんですね。

このようなことを繰り返さないためにも、ターゲットとなるペルソナをしっかり定めてヒアリングを行った上で、「何を作るべきなのか」をしっかりと見定めていくようになりました。

今ではユーザーストーリーマップ、デザイン思考、といった開発要件を整理する手法も積極的に取り入れています。

機能単位ではなく、「ユーザーにとっての価値」で切り分けて開発

ユーザーへのヒアリングによって開発要件を定めた後は、スクラムのフレームワークに沿ってプロダクトを作っていきます。スクラムの目的の一つは、決められた時間の中で製品やサービスの価値を最大にすることです。

そのためには、開発する対象を機能単位で考えるのではなく、「ユーザーから見て価値があること」という単位で切り分ける必要があります。

以前の弊社でもよくあったのは、例えば「データベースのテーブル名を変える」みたいなタスクの切り分け方です。

ただ、ユーザーからしたらデータベースのテーブル名なんて何でもいいんですよね。それよりも「サイト上で何かを購入したい」といったような、ユーザーにとっての価値を開発単位として設定することが重要だと考えています。

Pivotal Trackerで各タスクを細かく進捗管理！

このようにユーザーにとって価値ある開発単位をユーザーストーリーとして設定し、Pivotal Trackerを使って管理をしています。

プロダクトオーナーがPivotal Tracker上で1つひとつのユーザーストーリーを確認することで、プロジェクトの進捗管理をしているイメージです。

タスクの完了は、「データベースの中がこう変わった」というようなものではなく、「画面上で実際に商品を選んで購入出来る」といった単位まで実装された時点になりますね。

Pivotal Trackerを使うことで、各タスクの細かいステータス管理が可能です。まだ優先順位付けされていないユーザーストーリーは「Icebox」と呼ばれる場所に格納されます。

▼「Icebox」にどんどんタスクを投入！

そこから優先順位付けされたものは「Backlog」に、開発がスタートしたものは「Current」に移動していきます。開発が完了しエンジニアのパソコンの中で動くようになると、Pivotal Tracker上の「Finish」というボタンを押してPull Requestを送り、誰かがコードレビューを行います。

そして、コードに問題ないことが確認できて開発サーバーに設置されると、「Accept」と「Reject」というボタンが押せるようになります。

ここで、プロダクトオーナーが動作を確認できたものは、Acceptを押すと「Done」というステータスに分類され、タスクが完了となる流れですね。

▼「Icebox」⇒「Current」⇒「Done」とステータスが移行していく

指示待ち時間の削減や、コードの属人化防止にも貢献

Pivotal Trackerを使った開発では、プロダクトオーナーがタスクの優先順位を付け、開発チームの中で手が空いている人が優先順位順にタスクを取っていきます。

手が空いたらどんどん次の作業を取っていくので、指示待ちが発生しません。

Pivotal Trackerを使うと技術者でなくても開発速度を簡単に把握できます。実装にかかりそうな工数に応じて各タスクにポイントをつけるのですが、1週間で開発チームが消費したポイント数を集計してくれます。

そして3週間ごとの平均値も算出されるので、そのチームの開発速度が常に数値として可視化されるんですね。

また、タスクを順番に取っていくことで、作業の属人化を防ぐことができます。そのルールがなければ「あなたはこの機能に慣れているからここの実装をやってね」という形でタスクをアサインすることが多くなるかと思います。

でもそうすると、その機能に関しての知識が属人化してしまうんですよね。タスクを優先順位順に取っていくようにすれば、誰かが最初に書いたコードを別の人が引き継いだり、コードレビューをしたりといった形で、必ずひとつのコードを複数の人が所有することになります。

コードの属人化を防ぐことが出来るんですね。引き継ぎやレビューが頻繁に起こるので、短期的に考えると工数はあがりますが、バグはかなり減ります。更に、技術的負債が減るので、長期的な視点で見れば工数も運用フェーズの負担も減少します。

今後も「チーム開発」にこだわってプロダクトを作っていく

Pivotal Trackerは機能的にはシンプルなツールですが、エンジニアが5人程度のチームで行う1年ほどの開発であれば十分だと思います。「作るべきもの」と「納期」が一緒に並んでいれば、それ以上は特に何も必要ないですね。

クレイでは今後も、チーム開発を良くするようなツールやサービスをどんどん作っていきたいと思っています。

弊社のプロダクトであるDocBaseもそういった考えから生まれてきました。弊社自身がチーム開発を追求し、開発のお手本になりたいと思っています。そしてその形を、より多くの会社にも提案出来るようになったら嬉しいですね。(了)