TL;DR
モフトレの開発の運用に関してサマって伝える。ジョインしてから整えたことをまとめてみる。
背景
開発体制を整備する役目を受けてMoffにジョインした背景があるので、それまで何をしてきたかを簡単にサマってお伝えできればと思います。
ジョインした当初
今からおよそ２年前くらいにジョインした当初は一人一人独立して開発しており、本当に最低限のところが整っているだけの、よくありがちなスタートアップっぽさが出ておりました。（いい意味でカオスなところが好きではありますし、カオスながらプロダクトを出していくってスタイルはいい意味では共感が持てます。）なので当然ですが会社全体としてドキュメント運用やら情報共有はてんでバラバラですし、「あれ言ったこれ言った、あれ言ってない、これ言ってない」が基本錯綜しているので収拾がつかないこともままあったりしました。
なので、当然開発におけるルールや作法などの諸々は
- 未整備
- 整備はされているが持続的に発信する人がいない（ので、一人はその手がかりがわかるが、他の人はわからないことがある）
- 整備されているように見えて実態と細かく違う点がある
- 整備したが運用されないことがままある
- 整備完了している
のどれかに当てはまる、という認識でした。感覚的には大半は1-4のどれかに当てはまる状態ではありました。
当時は初のヘルスケアプロダクト「モフトレ」のリリースが控えており、リリースしなければ大人の事情でいろんな人を納得させられないので、プロダクトを作ることにフォーカスすれば必然とそうなります。でもこれはこれで短期的な物の見方としてはよかったとしても、リリースして以降何も準備しないでいると、急に開発メンバーを増やすにしても、大改修するにしても多大な時間を要する環境になってしまうので、メンバーを増やしてより大きな、複雑な課題解決することが難しくなります。
問題点の洗い出し
そういった中で何ができるかということで、それなりに環境を整えるために何が必要かを考えた次第です。
誰が何をやっているかわからない
ありがちですがIssueが誰がどう管理していて、タスクを誰がどうウォッチしているかてんでバラバラだと、本当に現時点で誰がどのタスクをやって居るのか把握がしづらいです。ワンマンプロジェクトだとissue管理が個人に依存するので、ルールがてんでバラバラでした。まあ誰にも邪魔されず開発すること自体は一番理想的ではありますし、自分も割と自由にやりたい側ではあるんですが
ただ、ルールを統一するにしてもルールで縛るにしてもベストパフォーマンスをだすことから遠ざかるのはまた違うので悩ましい。
※あくまでイメージです
誰に聞いたらいいのかわからない
これはエンジニアに限らず全社的になりがちだったのですが、誰が何を把握しているのかを誰も握らない、って状態であったので、新しい人からしてみればだいぶ敷居高い環境なんじゃないかなあってのが肌感ありました。（こんなこというとあとで怒られそうですが、もう今となっては終わった話なんでもういいですよね）確かに一定のコミュニケーション能力あれば、個人の突破力で情報集めればなんとでもなる、ってことではありますが、世の中そんなに器用な人は多くないでしょうし、そんなところにかける力を、よりプロダクトに向けて、本来の仕事に時間をかけるべき、と当時は考えていました。
※これもあくまでイメージです
「忘れる」
これも全社的な傾向ではありましたが、議事録がない、せめてミーティングで決めたことのメモがないってのがざらでした。忘れることが悪というより、記録がないので誰も辿れないし、記憶から消えれば大事なことですらそのままなくなるってことが往々にしてありました。これも新しく入った当時の自分からしてみれば会社に対してちょっと不安に感じた次第です。
※しつこいようですがあくまでイメージです
整備する
基本的にはみんながある程度は
- 設計・開発・改修・リリース・効果測定の作業負荷をある程度下げられる
- 試行錯誤の負荷をある程度下げられる
- 何か忘れてもどこかに集約されている
- 新しく人が入っても、最低限のポイントだけ抑えればだいたい自走して作業できる
ような環境がある程度整えられればいいかなーと思い、どれかがなんとかうまくいくようなアクション、施策を打ちました。あくまで独自の私見ですので、これらを整備すればいいって話ではないですが、入った時点で足りないものを埋めていくという発想で実行したことを羅列してみました。
以下は開発チーム内でやったこと
- リファクタリング（一部作り直し）
- リリース体制と開発フロー・リリースフローの明文化
- プロジェクト・プロダクトの責任者・担当の明文化
- バグチェック、デグレチェックのためのテスト検証シートの導入
- 単体テスト・CIの導入
- E2Eテストの導入
- リリース済みのプロダクトマップをかく
- 開発定例の実施
- 定例資料置き場の用意
- 進捗状況共有の時間を週１回設ける
- 1on1の設定
- 開発マイルストーンの整備
- 開発のバリューの定義
以下は開発チーム外でやったこと
- 各種ビジネスチームと関わる部分での定例化
- 不具合等の問い合わせ窓口整備
- 障害対応ルールの整備
- リリースにおけるSlack上のコミュニケーションフロー
- サービスに関する数字閲覧基盤の構築
- 週次のサービス関連のレポート自動配信
整備しても終わることはない
書き出してみるとごくごく当たり前なことを粛々とこなしただけな感じもしますし、
あまり独自性っぽいことはないかなあとは思っています。
それぞれにそれなりに効能もあった気もしますし、あまり効果がなかったものもなくはないかと思います。でもどれも一時しのぎでの対応じゃないか？とも見えるので、徐々に改善していくことが本質的には大切だし、定期的にチェックするように意識付けしていかないとなあと思います。
チームとして最初から各種機能が万全なスタートアップであればもう既に上記のことは整っている気もします。開発チームをこれから編成する人にとって、１つの参考として、アクションのチェックリスト程度に活用してくれると幸いです。（もちろん会社それぞれで抱えている課題が一部もしくは全部違うこともありますので、当該記事に当てはまらないこともあるかと思います）
色々な整備をしてて思いますが、まだまだ足りない。足りることがあるのかというくらいに足りない。
多分「足りる」なんてことは永遠にないんだろうなあと思います。
「エンジニア経験年数が浅い人でも円滑にジョインできるプロダクト開発環境」にするには、まだまだ先が長そうですが、技術を追ってそれを応用してプロダクトに還元して運用していくにはそれなりに時間もかかるし学習コストも跳ね上がるので、せめて社内だけでもそこをフォローできるようなことができないかと考える次第です。ちなみに書籍購入制度は存在しているんですが、もう一歩ないかなあと思案しています。
「まだまだ足りない」とか言ってはいますが、それでも「何か」が良くなっていると実感できているだけマシな方かとは思います。
まとめ
- 開発運用をある程度整えてみた
- 整えることが多すぎるので時間はかかっているがいろんなものがそれなりに整備されたと思う
- 整備してもまだまだ足りないので長い目でみて少しづつこなしていこう
- （ポエム書いてしまったなあ。。。w）
宣伝ぽくなりますがそんなMoffで社員を募集しているのでよかったら声かけてください。
hkawaji@moff.mobi
ありがとうございました。