Webエンジニアが新規でプロジェクトに入った時に確認すること
※この内容は https://nazo.hatenablog.com/entry/project-onboarding と同一です
フリーランスとしてWebエンジニアをしておりますが、プロジェクトに新規に入った時にどういう点を確認しているのかをまとめておきたいと思います。
プロジェクトの目標と直近の目標が問題ないか
プロジェクトの最終目標（理想）はとにかく大きくあるべきで、一方で直近の目標は具体的かつ十分に実現可能なサイズになっているべきです。もちろんその間くらいの目標（いわゆるマイルストーン）も存在しているはずです。
フリーランスの立場だと目標そのものに直接口を出すことはないですが、直近の目標が大きすぎると手を動かす時に困ってしまいますので、どこを削ぎ落とすのが良いのかこちらから提案することはあります。
開発プロセスが問題ないか
プロジェクト参加直後はベロシティ（スプリント期間内の平均作業量）が不安定ですので、そこを許容できてちゃんと
個人的には常にスクラムである必要はないと思いますが、マネージャーがいる場合はマネージャーが各メンバーのベロシティをちゃんと把握している、不在の場合は自分でベロシティが把握できていてタスクの見積もりができる、という状況になっていれば良いかと思います。「何だかよくわからないタスクをよくわからない期間で対応している」という状況では、前述の直近の目標の提案と同時に対処方法の提案を行うこともあります。
デプロイが安定かつ高速に行えているか
デプロイ速度は修正速度に直接繋がりますし、安定したデプロイができなければデプロイする単位が大きくなりがちですので、デプロイの安定性は最重要になります。
当然デプロイは完全自動化されていて、誰でも気軽に（承認フローなどは別として）デプロイできることが前提です。
誰でも簡単にデプロイできない場合、誰かにデプロイをお願いするというようなことが発生します。これでは自分と誰かの作業と、それを連絡する作業が増えてしまい、当然作業効率が悪くなってしまいますので、「誰でも」は重要です。「コマンド一発でデプロイできる」と見えても「（コマンドを実行する前にアクセスキーを取得して手元でデプロイ準備をして…）コマンド一発でデプロイできる」という場合がよくありますので、デプロイ環境自体が CI/CD 環境に移されていて手元の環境に影響せずデプロイできる（ CI サーバーが落ちていた場合は手元でも実行できる）というのが理想です。
デプロイ方法が複雑になっていないか
安定して高速にデプロイできていても、それを処理している方法が複雑だとメンテナンスの時に困ります。
メインのコードは綺麗にできてもインフラ系のスクリプトは長くなりがちみたいなケースはよく見かけますが、インフラ系のスクリプトもメインのコード同様に読みやすく構造化されているべきです。またインフラ系はツールが充実していることが多いので、なるべく自分で書くスクリプトは最小限にするのが良いと思います。
デプロイ自体が安定高速動作していればとりあえずは問題ないので、ここは後回しにすることも多いです。
CI でコード品質が十分に守られているか
CI の整備は後になればなるほど大変です。[1]これは CI で行うことの多くはコード品質そのものを一定の品質にする（ lint など）もののため、コード量が増えた後からそれを適用しようとすると修正点が膨大になるためです。
lint はとにかくコード量が増える前に対処することが大事なので、ここは真っ先にチェックを行います。リリース前プロジェクトであればすぐ導入しますが、リリース後だと手を入れにくいので、最小限の設定にして少しずつ厳しくするという手法を採ります。
（自動）テストはそもそもテストが書けているかというのをまず確認しますが、その上で「テストに再現性があるか」「テストの内容が十分か」「Test Sizes の分類が十分にできているか」といった内容を確認します。
数回に１回落ちるようなテストがある場合で、それがテストの実行順に影響している場合はテストの書き方そのものに問題がある場合がほとんどですので、その場合は削除してしまったほうが良いことが多いです。一方で、時間に関わるテストや、乱数や数値計算の誤差などが影響するようなテストは、それ自体が重要なケースが多いのでちゃんと調査したほうがいいと思います。
Test Sizes は、テストの分類を「単体テスト」「結合テスト」といった曖昧な呼び方ではなく、「我々のプロジェクトでは３段階の分類があり、それぞれのレベルではこうなっている」というものをプロジェクト固有で定義しようというものです。
ローカルでの環境構築が問題なく行えるか
自分が受け入れられる側になるのですが、この時に受け入れ準備が十分にできているか確認し、できていない場合は改善しながら作業することになります。
一番ありがちなのは環境構築手順が整備されていないということで、これは自分がそのまま作業するのですぐわかります。
ローカルの開発に外部のサーバーが必要な場合はまずそれがローカルで再現できないのか確認します。単なる MySQL や PostgreSQL などをサーバーに繋いでいる場合はローカルで立ち上げるように変更します。エミュレーターが用意されているサービスであればそちらを使うようにします。この際に設定が直接書かれていたり ENV などでの切り替えしか対応していない場合は、設定を環境変数に出して変更可能にします。[2]
最近だと自分は M1 (Apple Silicon) Mac を使用しているので、この環境で動作しないものを使っているという場面に遭遇することもあります。この場合は Docker 化を真っ先に行います。
手順はあるけど手順通りにやっても上手く行かないという場合、「使っているライブラリのアップデートで動かなくなった」というケースと「プログラムの構造の変化に対応していない」というケースが多いです。どちらにしても変更を把握できていないということが原因ですので、メンテナンス体制に難があることが多いです。外部ライブラリの更新などは把握しておく、自分で修正した場合は環境構築手順もアップデートするフローにしておく、ということが必要になります。
受け入れタスクが十分に実施可能な内容になっているか
ここでの障害は「ライブラリやツールの使い方が独自性の強いものになっていないか」「暗黙の知識が多用されていないか」といったものがあります。もちろん前述までの内容がクリアになっていないと作業に入ることもできませんので、それらを取り除いた後にようやく作業ができるということになります。
「ライブラリやツールの使い方が独自性の強いものになっていないか」というのは、自作ライブラリとかを使っている場合は当然ですが、ベストプラクティスに即していないようなライブラリの使い方をしているとか、魔改造されているというような場合には、なるべく本来の使い方に戻すよう指摘することがあります。「ライブラリやツールの公式のチュートリアルを見た上でそれを使っている部分を読んだ時にすぐ理解できるようになっているか」というのが指標になります。
「暗黙の知識が多用されていないか」はそのままですが、プロジェクト固有の暗黙の知識がある場合は当然手を入れることができません。暗黙の知識が登場する場合はコメントなどで把握できるようになっていること、仕様と実態の乖離がないことなどを確認します。
まとめ
これらの点がクリアされているプロジェクトであれば、新しく人を入れることも容易ですし、引き継ぎの時にも困らないのではないかと思います。
書き漏れがあるかもしれないので、思い出したら追記する可能性があります。
今回はインフラの話は除外しましたが、インフラでチェックする点もまた機会があればまとめてみたいと思います。
これらの点でお悩みの方は是非私までご相談をお願いします。詳細は https://nazo.dev/profile をご覧下さい。
Discussion