今回のテーマは開発負債リスクについてです。
私のエンジニアとしてのキャリアのスタートは個人開発だったため、開発負債について考える機会は少なく、ここ4年チーム開発を経験してきたことで、その重要性をひしひしと感じています。
過去の自分が残した開発負債の責任を取るべく(笑)、現在は開発負債の削減に興味を持ち、いったいこの負債はどのようなところから生まれているのだろうかと日々考えを巡らせています。
まだ少ない私の経験をもとに開発負債の原因となるリスクについて深ぼっていきます。
開発負債の原因
開発負債について語れれる機会は多く、複雑なコードで意図が読み取れない。ブラックボックス化したコードは怖くていじりたくない。何か問題が起きれば自分が咎められてしまう。
エンジニアも人間であり、スキルもさまざま。コードを読めば全てが理解できるわけではないし、時間をかければ解決できるわけでもない。
リスクが高ければ、アクションが鈍るのは当たり前の現象です。
このような状況が継続されれば、サービスの改善速度は低下し、機能が古くなりユーザーが離れていってしまいます。
つまり、開発負債はサービスの命と直結しているとも言えるのではないでしょうか。
負債となるリスクは至る所に転がっています。原因をエンジニアのスキルと安易に解釈してしまうと一向に解決には結びつきません。
私は、負債が膨らむリスクとして大きく5つあると考えています。
メンバー変更
サービス仕様の意図を残さない
旧バージョンの正当性が不透明
自動化が実施されていない
開発責任者の不在
メンバー変更
なかなか着目されないが、大きな負債のきっかけとなるのが、メンバー変更リスクではないかと考えています。
特定のメンバーに頼り切った運用はそのメンバーの離脱と共に大きな負債となります。
なんとなく、ずっと居るだろうと言った過信がどこかのタイミングで崩壊するケースというのは少なくありません。
対策として、ドキュメント整備や段階的な権限委譲に適切なリソースを割いていくことが必要です。
ドキュメントとして重要なのが、全体像を把握することができる情報です。どのようなアーキテクチャになっているのか全体がわかるだけで、後任者はかなり動きやすくなります。
環境構築やコマンドの説明、運用フローについてドキュメントに記されているケースは多いですが、プロジェクトの全体像、利用パッケージの用途など、どのような目的で何が行われているのか説明されているプロジェクトは少ないように感じています。
後に述べる、テストや自動化と重複しますが、最悪のケースに気がつける状態が構築されているかがポイントです。
サービス仕様の意図を残さない
初期開発で起こりがちなのが、口頭ベースで話し合われたサービス独自の仕様がそのままロジックに落とし込まれてしまうというケースです。
話し合いに参加しているメンバー同士で認識が取れているという前提で話が進んでしまうため、エビデンスを残すことが疎かになり、それがそのままロジック化されると、後から参画したメンバーは、そのロジックに対して目的がわからず、触れないコードになってしまいます。(この処理何?なんでこんなことしているの?と言った疑問が生まれるケース)
チャットに残された情報は流れてしまいます。コードの中や仕様書等がある場合はそこにしっかりと残していくことが大切です。
しかし、ドキュメントの運用は大変難しく、必ず古くなっている部分が発生します。また、コストも高いです。そのため、テストコードなどによってテストケースを用意したり、コード開発と並行した部分でこれを対策することが効率的だと感じています。(開発担当者とドキュメントの保守がうまく分掌されている場合は別です。)
旧バージョンの正当性が不透明
テストコードは重要です。テストはなるべく自動化しておきましょう。
テストを導入しようとすると、必然的にテストしやすい設計を行うことができます。
テストしやすい設計は、運用しやすくコードの役割が明確に分掌されている状態とも言えます。
事業者にテストの重要性を理解してもらうのが難しいとの声をよく聞きます。事業者にとって目に見えないものは信頼しづらいものです。
テストレポートやテストケースの一覧を吐き出したりすなど、成果物として事業者に提出することをお勧めします。
また、テストは目的によってスコープを絞ることが重要です。オーバーワークにならないように事前に目的を決めて行うようにしましょう。
ユニットテストやE2Eテストなどテストの目的を明確にして、テストを進めていくために、テストコードの導入は大切です。
全て手動によるテストを実施することになる場合、データベースの情報を書き換えたり、ユーザーを変更しないとテストができないといった、テスト以前の準備にかかるコストが肥大化してしまいます。
テストを実施することで、旧バージョンの正当性を担保した状態でアップデートを行うことができます。開発者としてもあのテストが通っているから大丈夫という安心材料になりますし、問題が起こった場合の原因特定に役立ちます。
自動化が実施されていない
自動化をは中長期の運用生産性に大きく影響します。
先に述べたテストはもちろん、デプロイや開発フローの中で行うべき作業はなるべく自動化しましょう。
手動でしか行わない場合、実施することを認知していなければ忘れてしまいますし、認知していたとしても人間が忘れてしまいます。
開発を進める上で必ず実施されるような部分(プルリクエスト作成やデプロイ時)で自動化フローを盛り込んでおくことで、事前に問題に気がつくことができますし、自動化フローがアラートを吐かなければ、そこに意識を持っていかれることもありません。
また、コードレビューで記述方法やゴミコードが残ってしまっているといった、本来の開発に必要のないコミュニケーションなどはエディタなどの設定によって削減することができます。
開発責任者の不在
とにかく属人性を排除した状態を作りましょうということを話してきましたが、最後は少しこれまでと矛盾しているような内容だと感じるかもしれません。
リポジトリの責任者が不在の状態というのは、開発メンバーが個々のチケット単位で動いている状態を指します。
例えば、「この機能はAさんが作ったものなので私はわかりません…」というAさんに聞かなければわからない状態は非常に危険です。
開発チームが大きければ自然と機能単位で動くメンバーも現れる可能性はあります。そのメンバーは自分のタスクと関係のある情報しか持っていないという前提でプロジェクトを進行する必要があります。
メンバー全員がその状態では開発進行はうまくいきません。リードエンジニアのような開発メンバーを牽引する存在を置き、その全体像を管轄する責任を委譲したメンバーを任命するようにしましょう。
さいごに
今回述べた5つのリスクを全て対策できているプロジェクトは少ないと思います。
どれかが対策できていても、どこかは課題として残っているという状況が常ではないでしょうか。
プロジェクトに参画した以上、目の前の課題を悪化させないアプローチ(可能ならば改善する)が重要です。そしてそれをひとりで行うことなく、チーム全体でコミュニケーションを取り、課題を共有し合うことが大切です。
ダメだよね…と嘆かずに課題解決に向けて前向きなアクションが取れる存在になりたいですね。そして、解決した暁にはソースコードにその名を刻んでみたらいかがでしょうか?笑
きっと長い年月運用されるサービスのソースコードに刻まれた、その名が拝まれる未来が訪れるかもしれません。
開発者にとって明るい未来が訪れることを願います。
Editor’s diary
先日本屋で結構分厚い面白そうな本を見つけました。
創始者たち──イーロン・マスク、ピーター・ティールと世界一のリスクテイカーたちの薄氷の伝説
創業系の話は、自分にとって憧れでもあり、ファンタジー感があって結構好きで読むのですが、イーロンマスク氏のペイパルを舞台としたエピソード本当のことです。
本屋でそのまま一章を読み終えてしまうくらいに引き込まれてしまいました。最近割とバタバタしていたので、少し落ち着いたら、休みでも取って読書したいと思います。