長らく保守し続けられているパッケージの開発に従事していると、
当時のレビューでどんな議論がされたのか分からず、
また担当のエンジニアがどういう思想や状況で開発したのかが理解できないことがよくある。
この点に関して、非マネジメントである私のようなエンジニアが、
パッケージを長く保守し続けていくうえで重要だと考えていることについて考えていることをアウトプットしてみる。
老舗パッケージのジレンマ
たびたび**「このサブシステムのXXXという機能なのですが、YYYのように動きます。なぜですか？ZZZという理由により不要な仕様に見えます」**のような質問をされることがある。
10年、20年保守開発をしているプロダクトにはよくある話かもしれない。
しかし、現在担当しているエンジニアは即答できない場合が多い。
その理由として以下3点が考えられる（少なくとも私が即答できない理由）
- 1つ目は、今現在、そのサブシステムは問題なく運用されているので、YYYという動きの存在意義（なぜこういう設計になっているか）がわからないこと
- 2つ目は、実装された当時の「判断」と「根拠」がどこにも残っていないこと
- 3つ目は、そのプロダクトのその機能の仕様がわかりにくく複雑であること
当時の設計思想がわからない
スタートアップのプロダクトではない老舗パッケージは、
設計開発したエンジニアがすでに退職しており、
ドキュメントもまともに残っておらず、
ソースコードがすべてということがよくあると思う。
ゆえに、保守担当のエンジニアは、
自分なりにサブシステムの役割や使われ方を理解し、学び、
そこから仕様を推定するしかない。
それゆえ「どういう意図でこうなっているの？」と質問されたら、
「XXXXという業務で、YYYYのように使われているという想定なので、こうなっていると思われます」
という回答で終わる。
だから、自分が生み出すのにかかわったサブシステムや機能以外は
フロントのメンバーにはいつもこのように回答している。
これは変えられない過去をいくら議論しても無理なので、
これからこうならないように変えていこうと努力している。
当時のレビューの議事録が残っていない
議事録を取る文化は重要だし尊重されるべきだ。理想は一言一句。
その議事録を見れば、レビューの情景が思い浮かび、何年も前のレビューに自分が参加しているかのような体験ができる。
しかし、往々にして、出荷フローに乗らない議論は残っていないことが多い。
そして、そこにこそエンジニアの考えや、思想、メンバー間の議論があり、最も残しておくべき情報であると考える。
出荷プロセスの中で、エンジニアは何度もレビューを重ねることが多い。
ルールとして定められているレビューも複数存在する。
しかしそれはほとんどが「進捗報告」「決定事項の説明」であって、
「議論」の余地はほとんどない。
それ故に
- 「設計レビュー」
- 「修正内容レビュー」
- 「テストケースレビュー」
などと名前がつくものは
**「完成品お披露目の場」であり、「途中の試行錯誤」**は適度に省かれていることも多い。
このレビューの議事録があったところで、「そんなのは仕様書見返せばわかるよ」となる。
私が考えているのは
- 当時どんな紆余曲折があり、今の仕様に決定されたのか
- ボツ案は何個あって、どんな内容だったのか
そっちのほうが、実は興味深く、知っておくべき製品の背景である。
プロダクトの成長と、当時の最適解は必ずしも一致しない
20年以上の大規模老舗パッケージともなると、
内部構造は当然のことながら、
機能コンセプトも時代に沿わなくなってくる。
当然時代にあわせて機能追加、機能改善をすべきである。
「出荷当時こうだったから、こうで行きます」
「出荷当時こうだったから、こうなっているので納得してください」
「基盤がこうだから、こうで行きます」
のような議論は時代とともに見直すべきである。
弊社のプロダクトは業務カバー率を売りにしてきたが
それ故に、UI/UXがおろそかにされてきた面がある。
今の時代「機能網羅性」よりも、「UI/UX」が洗練されていて、「すぐに使える」ほうが時代に沿っていると思う。
例えば、
入力負荷の軽減が**「2回以上入力させない」** から **「音声認識」「画像認識」**に変わっているように、
当たり前は見直していく必要がある。
入力項目が大量に並んでいて、保存ボタンがついている画面よりも、
画像読み込みのアイコンやマイクアイコンだけのほうが良かったりする。
複雑でもやりたいことができるんだから設定頑張れ！ではいずれ追っ手に追いつかれる。
BtoBでもリーディングカンパニーを目指す以上、
BtoCのモダンな技術に追従すべく、当たり前や常識はアップデートしていかなくてはならない。
そのためにも常に情報を集め、学び、常識を疑う姿勢がエンジニアには大切な点であると考える。
※だからと言って機能網羅性を下げてまで、モダンを追いかけなければならないか？というと、
弊社は1度それで失敗を経験しているので、即実行というよりは、各自が意識しながら設計することが重要ではないか？ということ。
#最後に
私が日々感じていることを雑な文章ながらアウトプットしてみた。
エンジニアとして、
- 顧客の価値を創造する
- 価値創造の速度を高速にする
- 時代の変化に柔軟に対応する
これらを意識し続けることで、
ただの保守開発業務ではなく価値あるエンジニアとしての業務に変わっていくと考えている。
そのためにも、設計思想という面で
- コードは重要だが、コードだけではだめ
- プロセスは重要だが、プロセスをこなすことが重要なわけではない
- 複雑な機能群で難解な仕様は10年前はウケたが、今はウケない
あたりは、意識していきたいところである。