はじめに
弊社内でも世間的にもエンジニアとしてかなりの年長者であり社内開発、客先常駐での開発など様々な経験をしてきました。
技術的なことは若い人に任せて、私からはこれまでいろいろなお客様と開発業務共に達成していく中で、技術や時代に影響されずに大事だなと思う「変わらないもの」をいくつかお伝えしようと思います。
画面の見た目と画面遷移を早めにお客様に見せてお互いの認識の相違をつぶす
紙芝居レベルでも良いので、可能な限り早めに画面の見た目と遷移だけ作って画面と全体的な動作イメージをお客様(決定権を持った相手)に見せて、認識の相違を無くすことで、後から「こうじゃない」「ここはこうしたい」「やっぱりこっちの方が」といったものを回避するというものです。
経験上、多くのお客様が実際の画面を見たり、動きを見ると「あぁこうなるんだ」「ここはこうして欲しい」「いやそうじゃなくて、こういう風にして」というのが多少なりとも出てきます。
若い頃、お客様が作った仕様書のイメージを元に開発を行ってプロジェクトの最終段階で完成レベルを見てもらった際に、かなりの修正要望が発生したことや、システム開発に関わっている企画の方(エンジニアでは無い)も、出来上がった画面や動きを見ると「そうじゃなくて」「やっぱりここはこうしたい」というのが出てきて、納期ギリギリに修正作業が発生してバタバタした経験があります。
仕様を作成するお客様が必ずしもエンジニアであるとは限らないことも含めて、実際に動くものを見ると自分のイメージとのギャップに気付くことになるので、可能な限り早めに実物を見せて相違が無いかを確認するようにしています。
逆に言えば、こちらはそのギャップを早めに気付かせることが役割の１つとも言えます。
バッファの無いスケジュールは絵に描いた餅
開発工数とスケジュールには適切なバッファ(予備日)が必要で、これが無ければそのスケジュールは無意味なものになります。
理由は未来を完全に予測することは不可能だからです。
私も大昔、スケジュール管理を色々勉強して実際に試してみましたが、きっちり出し過ぎたスケジュールで直ぐに再調整が発生することになり、複数回それが発生すれば信用されなくなりますし、クレームにもなります。
逆に緩過ぎるスケジュールだと工数に比例するので、仕事が取れなかったりします。
現在は機能単位に開発工数を算出し、全体的にも少しバッファを加味してお客様に伝えるようにしています。
当然ながらそんなにかかるの？と言われることはありますが、前倒しになることはあっても超過することは稀になるので(バッファがあるのである意味当然ですが)、最終的にクレームになったことはありません。
(こちらから提示したスケジュールや工数を元にお客様と調整を行い、お互いに納得した状態で開発を行うからです）
IT業界あるあるですが、先にリリース日が決まっている場合がありますが、その時は収まり切れないのであれば「どの機能を削りますか？」もしくは「この機能は後追いリリースに出来ませんか？」などの調整を行います。
事前調査をしっかり行ってシステムを理解して適切な工数を出すことは大事ですが、それでも実際に開発を進めると追加調査が発生したり、複数の実装案が出てきて適切な案を検証したり、病気で休んだり、会社のイベントがあったりと何が起こるか分かりません。お客様から見れば「そんなのは関係ない。決めた納期は守ってほしい」となりますし、当然のことです。
未来に発生する事を完全に予測することは不可能なので、このバッファで吸収することになります。(限界はあると思いますが、バッファがゼロよりは遥かにマシです）
ただむやみに多くのバッファを持つのでは無く、適切なバッファを算出することが大事ですが、この辺りはシステム規模や開発メンバのスキル、お客様の状態によって変わるのでその都度調整しつつ経験していくしかありません。
見て理解できるコードを書く
リリースサイクルが速いシステムや企業や巨大なシステムを様々な部署が保守や開発を同時に行っている場合などは特にそうですが、システムや機能のドキュメントを残すことは不可能（変化が速いので無意味）となります。
関数ヘッダ、ファイルヘッダとしてのコメント記載やテストコードなど「コードがドキュメント」になります。(このコメントも間違っている場合がありますが）
お客様のシステムを保守、開発を行っていて思うのは見て分かるコードと追いやすいコードを書くことが大事という点です。
(昔は「俺のコードが分かるか！？」的な職人技が多い時代もありましたが）
すごく基本的な事ですが、現実には古いシステムだと１つのファイルで数千行だったり、１つの関数が数百行だったり、どこから呼ばれてるのかなど全体の流れを理解することが難しかったり、現状どうなっているかを追って理解するのに大幅な時間がかかったりと誰も幸せにはなりません。
特に障害対応時に時間がかかることにもなりますし、機能追加や改修作業を行う際も開発工数が無駄に増えることになります。
変数名をちゃんと意味のある名称にするだけでも追う側の負担は減ります。
あるお客様の開発環境では、GitHubでのプルリク時に既存システムへの影響が無いかの自動テストが実施されるため確認が出来るのと、コードに対する制約違反になっていないか(行数や書き方、複雑度係数など)が自動チェックされ、修正しないとマージできない仕組みになっています。
おわりに
数十年この世界に居て、色々な経験をさせてもらった中で、今も昔も変わらない大事なものと思うものから３つお話させて頂きました。
どなたかの参考になれば幸いです。
