ピクシブ株式会社 Advent Calendar 2015の12日目の記事になります。

こんにちは、見習いイカエンジニアの @minamitary です。

自分はいま、とあるプロダクトの設計と開発を担当しています。4人のメンバーで構成されたチームで進めているプロジェクトで、現在リリースに向けてガシガシ開発を進めているところです。

今日はそんなチーム内で、プロジェクトの初期段階、それも最初の一週間においてどのようなことをやったかについて書きたいと思います。

プロジェクトの初期段階において、エンジニアはどういったことを重視すべきでしょうか。

様々あると思いますが、今回のプロジェクトでは以下の2点に注力しました。どちらも重要なことなので、腰を据えてじっくり取り組みたいところです。

これから作るプロダクトの仕様を明らかにし、設計を練ること
作業量を見積り、現実的な計画を立てること

しかしもう一つ考えなければならないことがありました。

それはプロジェクトに使える人員と時間が限られていることです。そうした制限のないプロジェクトというのは世の中的に見ても稀でしょう。今回もまさしくそうした状況でした。

設計や見積りを進めるそばからリソースは消費され、実装に使える期間は減っていきます。プロダクトの質を高めるために、初期段階にすべきことを迅速にこなし、速やかに実装に着手する必要がありました。

そんな状況を我々プロジェクトチームがどのようにして乗り切ったか、共有したいと思います。

【手順1】チーム内でのディスカッションを通し、プロダクトについての理解を深める

まずは自分たちが何を作ろうとしているのか、チーム内でのディスカッションすることから始めました。

プロジェクトがスタートした時点で、参加メンバー全員がプロダクトの完成イメージを厳密に理解できていることは稀です。例えば「イカ」というコンテンツを扱うプロダクトについてディスカッションすると、「イカにはどのような種類があるか？」「タコではダメなのか？」などの疑問がうまれます。曖昧にしか理解できていないことや各々の認識に食い違いがあることが浮彫りになってきます。

またディスカッションのなかで特に注意したが「新しいワード」です。新しいワードが指す対象を見極めた上で以下のようなアクションをとりました。

既知のワードと同じ対象を指し示すものであれば一つのワードに統一する
新しい対象を指し示すものであればそれを分析し、理解に努める

こうやってチームの中で用語を明らかにして統一することで、「メンバー間での認識の食い違いがなくなる」「プロダクトに対する理解が深まる」といった効果が得られます。

弊社のディスカッション風景です： f:id:devpixiv:20151212205048j:plain

【手順2】実装にあたりをつけつつ、設計に考えを巡らせる

ディスカッションで得られた理解をもとに、実装と設計について考えを巡らせました。

またイカを例にして考えてみます。

イカがスミを吐く場合のスミはどういった形で実装するのがいいか
イカとタコは似ているが、別物なので区別できるようにする必要がある

このような発想を起点に、データの持ち方やその使い方についてイメージを膨らませていきました。そうやって設計の足がかりを掴み、同時に機能や画面といった実装すべき対象を徐々に明らかにしていきました。

【手順3】手順1-2を短期間で繰り返し、プロダクトへの理解と設計の精度を高める

以上の手順1-2を、短い時間で何度も繰り返しました。一回ですべての曖昧さを排除し、かつ完璧な設計を導き出すことができれば苦労はしません。できたとしても、それにはかなりの時間がかかるでしょう。

設計するなかで新しいワードが見つかったり、矛盾に気づいたりということは多くあります。うまく設計できない・実装をイメージできないといった時に、手順1に立ち返ってみると実は勘違いをしていたことに気づく……なんてこともありました。設計がプロダクトへの理解を深め、深い理解が設計を精緻にしていきます。一つ一つの手順の精度にはこだわらず、とにかく短時間でのトライを心がけ、徐々にお互いを精緻化していく方法を取りました。

疑問点が浮かび上がる度にメンバーに質問や相談をして疑問点を解消する
設計に手を加える
ドキュメントにアップデートを加えて共有する

こういった単純な手順です。スピードを上げるために打ち合わせの回数は少なめに、一方でドキュメントは細かくアップデートして、ディスカッションに参加していないメンバーにも情報を共有するように心がけました。(更新しやすく差分も見られるesaが威力を発揮しました)

また、ある程度理解が深まった時点でプロトタイピングにも着手し、画面の設計と内部の設計を照らし合わせることで、より精度を高まっていきました。

結果としてチームメンバーのプロダクトに対する理解は深まり、メンバー間で共有できている状態となりました。また、実装対象がリストアップされ、それぞれに対して大まかな設計と実装方法が見えるようにもなりました。

【手順4】実装対象に優先順位をつける

手順3まではあえてリソースなどの制限を考慮せず、「プロダクトのあるべき形」を模索するように心がけました。とはいえ最終的には現実的な計画に落とし込まなければなりません。ここまでは夢を膨らませるフェーズでした。現実への着地を目指すフェーズが始まります。

ディスカッションを通し、手順3でリストアップした実装対象それぞれを以下の3つに振り分けました。

MUST: これがないとプロダクトが成り立たない
SHOULD: なくてもプロダクトは成り立つが、初期リリースには含めたい
MAY: 初期リリースに含める必要はないが、ゆくゆくは実装したい

以上の手順を通して、「初期リリースにおいては、MUST+SHOULDが実装された状態を目指しつつ、余力があればMAYも実装したい」というように、初期リリース時点でのプロダクトの形を思い描くことができるようになりました。

全てesaにまとめていきました：

f:id:devpixiv:20151212213347p:plain

【手順5】見積りを通して現実的なプランにまとめ上げる

あとは実装対象それぞれにかかる工数を割り出し、リソースや期日と照らし合わせるだけです。手順3までの時点でだいたいの実装方法は見えてきているので、工数の見積りはそう難しくありません。

MUST+SHOULDでの合計工数を1日あたりに使える人日で割り、かかる日数を算出します。(例えば合計工数が100人日でチーム内で1日あたりに消化できる工数が2人日であれば100/2で50日かかるといった計算です)

よって「MUST+SHOULDを全て実装すると足が出そうだが、SHOULDに当たる実装対象をカットするなど、工夫すれば期間内に収まるだろう」といった予測が立てられる様になりました。

実装対象の実現に必要となる工数が明らかになったので、優先順位を考慮しながら、カレンダー上にプロットしていけばスケジュールができあがります。

やってみた感想

いかがでしょうか。以上が自分が携わっているプロジェクトにおける、スタートから実装に着手するまでの大まかな流れです。

実装着手までかかった日数は一週間ほどで、結果としてかなり近道ができたように思います。

本当の戦いはこれからです。プロジェクトを効率的に進めることは大事なことですが、結果できたプロダクトが良いものになるかどうかはまた別の話です。プロダクトが無事リリースされユーザーに価値を提供することがプロジェクトの最終的な目的であるはずです。達成するためには、開発を進めながらもプロダクトのあるべき姿を模索していくべきでしょう。初期段階において固めたプロダクトの仕様や設計はあくまで叩き台にすぎず、実装が始まってからも何かあるたびに手順1にまで立ち返り、適宜アップデートを加えていくことが求められると考えています。

今後も試行錯誤を重ねつつ、プロジェクトの成功を目指していきたいと思います。