ソースコードの保守性の影響を経営者へ伝える方法によるリアクションの違いについて。
経緯
私は毎週金曜日にクリエイターズネクストさんのお手伝いをしています。
本業も含め、普段私がどんな感じで働いているかについては以下を参照。
前提
- 現在思うように開発のペースが上がっていない
- 週1勤務なので私自身がガンガン手を動かす担当にはなれない
役割
私はWebサービスの開発プロジェクトの要員として週に1回開発に参加しています。
私が普段の開発で得たノウハウを提供することでお手伝いしている企業の内部では気づけなかった問題
を発見、解決・改善したり、若手にノウハウを伝授していくのが一番の役割です。
週に1回ということもあり、手を動かすよりは全体の指針を決めたり、
ワークフローを作ったり、TOCなどを用いボトルネックを発見し、解決するツールを導入したりしています。
※必要なケースにおいては手も動かしています。
流行りの技術顧問のような高度なレベルではないものの、効果としては似ているので
プチ技術顧問、みたいなところでしょうか。
一般の技術顧問よりももっと中に入り込んで開発者の一人としても参加しています。
保守性の問題
現状、サービスのリリースを最優先にした結果、比較的保守性が低いコードベースになっています。
(この辺りは私の参入前からの状態なので、介入できなかった)
サービス公開後にほとんど機能の変更がないようなシステムなら現状のコードでも問題はないのですが、
サービスは長期運用し、どんどん変更・改善していく想定であるため
長期運用に耐えうる変更しやすいコードベースが必要になります。
私が参入した際に、保守性の重要さなどについては口頭で説明をしていて、
長期的に頻繁な改修を行うシステムは、保守性が重要であり、
リファクタリングを行ったり、保守性や拡張性の高いシステムを設計・実装できる
開発者を採用（外部リソースも含めて）することは非常に重要である、という点で認識合わせはできていました。
しかし、いざサービスの運用をはじめるとどうしても機能の実現が優先となり
「分かって入るけど後回し」という状態になっていました。
危機感
開発者同士の場合ならコードベースと開発速度に関して、直感的にまずいと思う感覚は共有できると思うのですが
対経営者の場合はそうはいきません。
基本的には重要性を把握していただいているものの、現実としてどの程度の影響があるのかを具体的に伝える必要があると感じました。
ちょうどwaffle.ioを導入したことで、ここ数週間のIssue消化ペースがグラフで参照可能になっていたので
これを利用することにしました。
週あたりのIssue消化ペースを元に、あるエピックを実現するためには
今のコードベースと開発担当では約1年半かかることを伝えました。
社長の顔が青ざめています。バッチリ伝わったようです。
そして、コードベースを改善し、そのレベルを継続的に保つことができるレベルの
アプリケーションエンジニアを採用すれば、この作業全体はたかだが1,2ヵ月で実現できる内容であることを知らせました。
この辺りの仮定を信じていただく前提として、
- 私も実際に手を動かし、いくつかのIssueを即対応することで実際の開発速度を見せる
- インフラ担当者は超優秀。最小限のコミュニケーションで手離れがよく、あっという間に成果をあげてくれる
- この改善の見積もりは私＋インフラ担当者で行った
などもありました。
社長は経営者であり開発者のバックボーンは持っていないですが、ある程度プログラムを読むことができるのも幸いしました。
補足
こういったエントリがあると既存のシステムの開発者さんに角が立つと思いますが、
システムをリリース段階まで地道に構築していただいたのは多大な功績であり非常に感謝しております。
実際の所、1からシステム全体を作り上げたことのない現状の私には実現不可能なことであり、尊敬しております。
また本サービスのお客様がこのエントリを目にした際に不安に思われるかもしれませんが、
あくまで長期的な開発や機能の拡充を見据えた際の保守性に関する内容であり、システムの品質などに関する内容ではありません。
また、このような内容に誠実に向き合い改善していく姿勢をもっております。
お客様の要望を満たすシステムの価値、品質については日々継続的に努力しております。
