シンプル思考を徹底しよう：この半年の振り返り

先日、この半年くらい担当させてもらった仕事が一区切りついたので振り返りをしておこうかなと思います。

全部よくある話だと思いますが、「経験しないとわからないこともあるものだ」ということで、今回は思考垂れ流し回です。

とにかく余裕を

取り掛かり始めたころ、諸先輩方にファーストリリースではとにかく最低限のものを作るように言われたが、今ならそれが身に沁みてわかる。スケジュール的に余裕を持たせる効果のほか、エンハンスの伸びしろも大きくなるので、リリース後に機能拡充していくことで対外的な見た目が良くなる効果もあるという観点もあるっぽい。

最低限動くもの（いわゆる MVP ってやつ）+ アルファくらいは作りたい思いが最初はあった。やっぱりせっかく作るならいいものを作りたいというのが人情だ。
とはいえ、会社でリリースするものなのだから、初期リリースでどれだけ機能が多いかよりも、機能が少なくても品質が高いことが優先される（少なくともうちの会社はそうだ）。ギリギリまで開発しているようでは十分な確認のための時間を取ることができない。

しかも、開発中には色んな「想定外」がある。外的要因によって設計を見直さざるを得なくなることもあった。駆け出しあるあるだと思うが、思っていたより単純にやることが多かったりもした。ある程度作ってから「やっぱ違う」となることも、動作確認で不具合を見つけることもあった。

こうした変更に柔軟に対応できるようにするための唯一の対策が、余裕を持っておくことだ。
結果的にここは割とうまくいった。

チーム外とのやりとりは丁寧に。チームメンバーの力は借りまくれ

何かを作るとき、たいていは他のチームの協力なしでは不可能だ（それが会社だから）。

だが、他チームの人にはそのチームの都合があるので、無条件に何でも協力してくれるわけではない。早めに頭出しをして、握ることは握り、証跡を分かりやすく残す。更新があったら伝え、混乱が起こらないようにする。基本的にテキストベースのコミュニケーションだとしても、交換できる情報量を増やしミスコミュニケーションを防ぐために最低1回はちゃんと会議を設けたほうがいい。これはとても大事だ（私は一回失敗した）。

一方で、チームメンバーの力は存分に頼るべきだ。

一人で唸る時間よりもチームメンバーと議論するほうが何倍も有意義。まずは相談したい事項や論点を整理して、チームメンバーと議論するということを何度もやった。週に1回、最大2時間の「もくもく会」があるのだが、今となってはお互いの相談事項を持ち寄る会になっており、全然もくもくしていない。あまりに会議時間が多いと作業の阻害になるのだが、このくらいの間隔・長さで他のメンバーに相談する・他のメンバーの相談を聞く会があるのは個人的にちょうどよく、チームビルディング的にうまくいっていると思う。

いかにシンプルさを保つかが重要

いかにシンプルさを保つかがサービスを開発する上でも、運用していく上でも重要だということを実感した。

機能を増やすことはすなわち複雑性を増やすことだ。コードベースの上では検証しなくてはいけないクラスや if の分岐を増やし、さらにはインフラレベルで管理すべきコンポーネントを増やさなくてはいけない場合もある。なので、機能を増やすということは無条件に歓迎されるものではないのだ。

まず、その機能が本当に役に立つのかをユーザーのユースケースを洗い出して検討する。優先度が高くなさそうであればサービス開始後に利用状況を見ながら考えるのでも十分だ。次に、その機能をどのように実現するかいくつかの案を出す。大抵の場合は実現方法が1つであることはないので、それぞれに一長一短な案を考え、前述のようにチームメンバーと検討する。その際に重視すべき観点の1つが「シンプルさ」だ。

今回の仕事の中で、自分にはユーザーにとって便利そうな機能を付けたい、ユーザーにとって易しくしたい、という思いが比較的強いということを認識した。もちろん、これ自体は悪いことではないのだが、システムのシンプルさという面ではマイナスであることが多い。ベテランのエンジニアはシンプルにシステムを作り運用することに長けていたので、採り入れるべき対極の意見をしばしば出してくれた。今回の仕事でそのあたりのバランスを見極める力が多少はついたと思う。

おわりに

これからもがんばります。