最近思っていることをツラツラと。
サービスにとって「コードを書く」という行為以上に「何をどう実装するか？」を決定するスピードと精度が非常に大切だと改めて感じている。一般的な言葉で言うならば「要件定義」や「設計」に当たるところ。ある程度サービスが成熟してくると、その理念としてもビジネス的にも「ある程度」正しい要件を決め、矛盾や運用に負荷の無い設計を企てることが一番重要なんじゃないかと。もちろん「やれることを増やす」という意味では技術的な調査や実装として手を動かす作業は日々続けるとして、僕らの現状を話します。
チームスペック
まず前提としてのチームの規模。僕らのサービスはアプリにして500万弱のダウンロード数を誇るものの、比較的ミニマムな人員で開発されている。以下はザックリとした役割と人数です。
- APIサーバを含むWeb側の開発 => 2人（僕含む）
- iOS/Androidネイティブアプリ開発 => 2人
- デザイナー => 1人
- ディレクターやマーケティング担当 => 2人〜3人
ちなみにこれらの人達は決してオフィスに定時で集まるというスタイルをとってはいなく、リモートかつベストエフォートでリソースを割くという方式で動いています。 なので打合せや集まっての作業はノマド的な喫茶店で行なうのが主流です。
コードは書いた瞬間に負債になりうる
我々にとって「闇」として話題に上がるネタに技術的負債という言葉があります。以前から参加させてもらっている「IVS CTO Night&Day」のアンカンファレンスでもそのテーマがあって色々考えたんだけども、辿り着いた結論は
コードは書いた瞬間に負債になる
かもしれない。ということだった。コロコロと移りやすいWebやアプリへのニーズや技術の進歩によって、書いてしまったものが負債になる日は近いな、という印象。これは残酷だけどわりと言えてるかもしれない。確かに、プロダクションに投入した例のXXXのコードはカオス化していて毎回ソースコードを読まないとAPIが理解出来ない... なんて過去の経験もある。だからコードは短い方がいいし、つくらなくて済むならばつくらない方がいいかもしれない。ヒエーボクハコードカキタイヨ... でもスパゲッティになったコードを読むのは辛い。なんというかこの矛盾的思惑が面白いところだとは思う。もちろんそれを設計実装するエンジニアの腕もあるだろうが...
まぁ、といってもサービスとしてプロダクトを良くしていくためにはコードを書くのは必要だろうし、そのために「過ちのない」機能や改善点を定義することが大事なんだろうね。
それぞれの思惑とディレクター
僕らはここ数年、年始に今年何をやるか？と言った中期的な目標やマイルストーンを決める。今年も決まった。だが、粒度が荒いと「じゃ今すぐこれつくります」とも言えない。
優先順位を決めた細かい実装計画が必要なんだけども、それを決めるにあたって、ステークホルダーそれぞれの思惑がバラバラだったりする。とあるAさんは機能1を叶えたいと言い、Bさんは機能2を推す。実装する側としては色々試しましょう！と言いたいところだけれども、上記の「負債」の件も含めて、機能を追加することに関してはちょいと慎重になってしまう。結果「どこから実装すればいいの！？」という迷いが生じる。
そこを解決するのがディレクターという「役割」である。あくまで「役割」なので「ディレクターひとり」がいるという状態じゃなくても構わないと思う。ディレクターはプロダクトを愛し、責任を持ち、そのプロダクトの「小さな方向性」についてジャッジをしてくれると嬉しい。
たった今の話なんだけど、各自のやりたいことが微妙にバラついてるという上記した状況なので、今度メンバーのうちの数名で細かい実装の優先順位を決める打合せをする。誰かがディレクションするのかみんなでまとめていくのか？気になるところであるが楽しみである。
要件と設計をテキストでまとめる
これをやるぞ！と決まれば、後は正確に要件を洗い出し、設計のたたき台をつくってみんなで叩けばあとは大抵上手くいく。
その際に、最近ではある程度構造化されたテキストで「要件定義と設計の中間」くらいのものを文章や箇条書きでまとめるといいんじゃないかって思っている。 僕らはそのためにesa.ioを使い出した。この場合Markdownや図のファイルでやることを整理するページを僕がつくり、みんなに投げる。オンラインや喫茶店での打合せでアラがないかツッコんでもらうという形だ。
例えば、今回話題にあがっているサービスでは新規登録フローをとある事情で変更したのだけれども、以下のようなページを作成し、みんなで共有＆議論した。一部のスクショを掲載する。
ここでは以下の様なことを「特に書式やフォーマットを気にせず」書いている。
- ユーザーフロー
- フローに基づき裏側で何が起こるか？
- 前提条件、事後条件
- データ構造の変更点
- WebAPIのエンドポイント
- Webのパス設計
- デプロイ計画
これがなかなかいい具合である。
いかに迷いなくコードを書くか？
僕は今まで設計にまつわることを一人でやっていた... と思うんだけれども、このように一度esaなどを使ってテキストに落としこんでみんなに見てもらうと、コードを書く前の迷いが消える気がする。このドキュメントにツッコんでくれるのは開発陣数人とアプリのディレクターのせいぜい3人程度なんだけども、それだけでも、ありがたい。抜けや欠けがどうしても出ることを防げれるので「何をつくるか？」に対する精度が増す。また、WebAPIとモバイルアプリの様に連携しあうサービスなので、API側の機能変更を予めモバイル側のエンジニアが把握しやすいという利点もある。
効率よくコードを書く際には上位工程である設計の迷いを持ってきてはよくないのだろうな。良いコードを書けたとしても「このままの仕様でつくっていいのかな〜」なんて思いながら、はなんかヤダなぁと思う。
Microservicesへの考慮
粒度によっては日々発生するビジネスレイヤーの要望に対してMicroservicesを適応することで技術的負債を削減することが出来るかもしれないという淡い淡い期待はある。なるべくアーキテクチャ設計の時点で構造化していおくことで、サービスの様々な機能を追加を試せる土壌をつくっておくことに努力したい。そういう意味で「マイクロサービスアーキテクチャ」はいい本だったのでまとまったら、どこかで書くかPodcastで話そうと思う。
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
まとめ
「サービスにとって」という前提ではあるが、なるべく無駄なコードは書きたくない。だからこそ「何をつくるか？」のジャッジをディレクターという役割を利用して精度高く決めていきたい。また、要件や設計仕様をesa.ioなどの構造化テキストでまとめていくのは、迷いなくプロダクトコードを書いていくために役に立つかもよ、というお話でした。コードを書かない時間も大事だし、コードを書くことを止めないでいきたい。
宣伝
Podcastやってます！ジングルが面白いです。聴いて下さい！