はじめに
mixiグループアドベントカレンダー3日目になりました。
私は現在CS部門の開発チームとして、オペレーターが使う管理ツールの開発・保守/運用や、お客様から頂いた不具合の調査などを行う部署で働いています。
このエントリーでは、上に挙げた管理ツールの新規立ち上げを7月に担当した時の話を書きます。
事のあらまし
新アプリがリリースしたことに伴い、問い合わせ対応のため管理ツールの新規立ち上げを1人で行うことになりました。
インフラレベルからの新規立ち上げはほとんど経験がなく、不安が残る中で更に2点の困難な状況が降り掛かってきたのです。
プロダクトの開発言語が利用経験のない新言語
プロダクトのサーバサイドがElixirという今まで触ったことのない言語で、そもそも何が書いてあるか訳がわからない状況で開発をスタートせざるを得ませんでした。
（その時に学んだ技術的な知見は 別エントリ に既にまとめています。)
このため立ち上げにあたり、
- インフラの整備
- プロダクト側のコードリーディング
- アプリケーションの新規開発
に加え、
- 新言語の学習・キャッチアップ
も行いながらの対応となり、非常にやることが多い状況に陥りました。
何も出来ていない状況から、この機能を1ヶ月後までに欲しいというプロダクト担当者の要望
ただでさえやることが多い中、立ち上げを始めたほぼ同時期に「翌月のアプリアップデートに載せたいため、1ヶ月後にとある機能を管理ツールで使えるようにして欲しい（以下、タスクAとします)」という旨をプロダクトの担当者から伝えられました。
つまり、1ヶ月後にはproduction環境で動いている状況にした上で、要望のあった機能も動く状態にしていないといけなかったということになります。
この2つの重圧から軽いパニック状態の中開発を進めざるをえず、1ヶ月ほどの間はかなりの重労働となってしまいました。
改めて振り返ってみると、やり方を改善すればもう少し余裕を持って対応できただろうなと思えることが多かったのと、この立ち上げ業務を通じて得た知見もいくつかあるので、それらを以下に「学んだこと」として3点挙げてみます。
学んだこと
(1)関係者と密にコミュニケーションをとる
バージョンアップのリリース日はプロダクトの担当者から共有を頂いており、自分はタスクAを、部署の別のメンバーが別のタスクBを依頼され、リリース日までに完了している必要がありました。
しかし、このタスクBのうち一部の作業については以下の図のような認識の齟齬があり、直前になって焦るという事態になりました。
幸いすぐに対応できる内容でしたので事なきを得ましたが、他部署と連携して仕事をすすめる上では以下の点に気をつけながら仕事を進めないと、間際になって大変なことになるという事が知見として得られました。
- 依頼されたタスクは何なのか、またその担当者は誰か
- 作業レベルのデッドラインはいつなのか
- このデッドラインは担当者/依頼者の間で認識の齟齬がないか
文字に起こして書くと至極当たり前のことに見えますが、これを行動レベルまで落とせて始めて当たり前といえる状態になると思います。（実際バタバタしているとこれらの事が疎かになりがちです。）
(2)タスクを細分化し、いつ何をやるのかを明確に
立ち上げ当初は初期リリースのレベルで何をやるのかを軽く洗い出した後、そのToDoリストを見ながら出来るところから順番に開発を進めていました。
しかしながら、何がいつ終わるかというレベルでの見通しは立てておらず、タスクAの開発にいつ着手できるのか不透明な状態でした。
この状況を見かねたチームリーダーからタスクレベルでの着手日と工数の見積もりを勧められ、以下の例のようにざっくりとではありますがガントチャートを引いて計画を練ってみました。
このガントチャートがあったことにより、タスクの整理がかなり行いやすくなりました。
図にも示している通り、機能1〜3はタスクAのUI作成のために必要な作業です。こちらの図にはないものの機能4以降の作業も控えており、このガントチャートを引く前は機能4以降もタスクAに取り掛かる前にやるつもりでした。
しかし、改めて整理すると
- タスクAのUI作成に必要な作業は機能1〜3の開発であり、それらはmustで早めに行わなければいけない作業
- 機能4以降の開発はタスクAが完了してからで問題ない
といった具合でそれぞれの作業内容に優先順位を付けやすくなりました。
また事前にある程度の粒度で工数の見積をして横に並べていくことでタスクAにいつ頃取り掛かれるのか、というのが「ログイン/認証」の開発時には既にある程度把握できている状態になります。
タスクAがきちんと期日通りに間に合うか、という点についてもこのガントチャートを元に、機能2を着手しているタイミングでプロダクトの担当者に伝えることができたのも良かった点です。
(3)不安要素の残るタスクは優先して片付ける
今回の立ち上げ業務において、一番不安の残る要素はインフラの構築でした。これまでアプリケーションの開発が業務の中心であり、ある程度薄い知識はあったもののあまり実務経験がなかったという自身のバックグラウンドが要因かと思います。
さて、上のガントチャートで「デプロイ環境構築」を早めに対応したのは以下の2つの理由からです。
- タスクAがアプリアップデートのリリースに間に合うかどうか一番左右されるタスクであり、これが長引くと後々の機能開発も後ろ倒しになることが予想されていた
- 長引いて間に合わない可能性があればプロダクトの担当者に早めに共有ができる
- 不安要素が大きく、立ち上げ業務の一番のストレスになっていた
- 早くストレスから解放されたかった（本音）
- これが終われば後は安心してアプリケーションの開発に集中できるという逆転の発想
不確実性が見えないまま、プロジェクトを進めていくとき、人は確実なものから対処しがちです。その結果、見えない不確実性を心に秘めたまま日々を過ごすことになります。これは、じわじわと真綿で首を絞められるようにストレスを人々に与えていきます。
先日のhirokidaichiさんのエントリにもありましたが、やはり不確実性の高いものが残ったまま過ごすのはストレスの溜まることですし、この判断は結果的にはよかったのではないかと思います。
おわりに
今年は管理ツールの立ち上げ業務を通じて、自身の仕事への取り組み方、周りのメンバーの巻き込み方が大きく変わりました。それは私自身も感じていることですし、上半期の評価のタイミングで上長からも言われたことです。
こちらのエントリが、これから何か新規立ち上げに関わる方の参考になれば幸いです。
明日は @ushisantoasobu さんが何かを書いてくださります。