丁度空いていたので入りました、闇の魔術に対する防衛術 Advent Calendar 2020 18日目の記事です。今月はアドベントカレンダーではありますまいかAdvent Calendar 2020をマラソンのように書いております。この「荒れ果てた環境」へのオッサンなりの覚悟はこちらに掲げておきたいな。
ERPパッケージソフトの開発保守をしています
自己紹介に近いところは色々リンクを読んでいただければと思うので追記。
で、私が直接お話しした相手ではないのだが、社内Slackで流れてきてふぉぉぉぉ！と私が思い、したためたくなったことを書きます。弊社員が学生さんとカジュアル面談した結果だそうです。
• 技術力ある人やOSSコミッターと働きたい
• Excel職人は嫌だ(= きちんと設計と実装ができる環境で働きたい)
• レガシーのメンテばかりは嫌だ
…と。1個目2個目はまあ言ってみたかっただけに聞こえるので置いておいて、はい、レガシーのメンテでご飯を食べております私が通りますよっと。
##「レガシーのメンテ」
レガシーと言われると半沢直樹くらいを思い浮かべてしまうような貧困発想な私ですが、これは保守点検、コンコンコンコン、異常なーし、みたいな作業があってそれは全然技術も発揮しどころがなさそうだし単調すぎるからやりたくないですってことなのだろうか。
まずレガシーをン10年もののシステムのことだと定義する。と、これは正直にこたえると こちら でも書いたように弊社でも「レガシーのメンテ」という作業がある。学生さんがどういったイメージをもって「レガシーのメンテ」と言ったかは少し幅がある（例えば銀行の何十年モノのシステムから比べたらそれほどではない）はずだが、まず我々、ユーザーが存在する以上保守対応は必要。10年を超えて同じシステムを使ってきているお客様に対するサポートというのはそれに近いと思っています。
そうであるとして問題は、レガシーに対してレガシーのメンテは単純で決まり切っていてクリエイティビティの発揮できない仕事だとどこかで思っていると思う、そこに対する誤解というか、何かアンサーを示したいと思ったのですぞ。
反論
昨日こんな話を書きました。だから「気の持ちようで工夫はできる」。工夫だ！カイゼンだ！とか精神論の問題としてかたづけてきれいごとを言いたいわけではない。
しかし例えどんなに先進的な技術を駆使して立ち上げたスタートアップも、ユーザーが増えて運用が回れば、簡単にすべてはいつかレガシーになる。その時どうするの？は考えておかないといけないと思う。そのときどうやってそれをどう乗り越えていくかは新規開発だけやってそれを捨ててを繰り返していても一生たどりつけない、意外と先進的な課題。
ユーザーをどう説得してアップグレード、または移行へのモチベーションを仕掛けていくか。そのメンテ作業の１つ１つをメンテ作業だと思っていたら何も面白いことなどない。しかし意味づけを自分の中でできるようになると割とお仕事って楽しみが見えてくると思うのですね？
例えば
トラブルや課題を解決したこと のほうが評価されがちで トラブルを起こさなかったこと は目に見えない分評価されにくい、なんて事が起こる。本当は両方同じ実績として目に見えるように評価されるべき。
トラブルや課題の原因が他にある場合はトラブルを解決したこともトラブルを起こさなかったことも同じだしトラブルの原因が自己にある場合はトラブルを解決したのは時間をかけただけで何もやっていないしトラブルを起こさなかったことのほうがむしろ評価されてほしい。
- トラブルの内容
- それがどこ起因でどれだけ影響力のあるトラブルか
- それを解決したのか、未然に防いだのか
が見える化できていたら良いと思いませんか。はいこれ、レガシーのメンテで定時運行がどれだけ達成できているかが本当にすごいことだっていう数値化につながると思うんです。
テストをそろえることでそれが数値化できるのでは
と思いつくわけですよ。記事既にたくさんありますね、レガシーコードに対するテスト。
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか
すでに生み出されて動いているレガシーコード（テストのないコード）との戦争。結局武器はテスト
仕様変更に弱いからテストは書かない……？(´・ω・`)＜仕様変更を想定するならテストを書いてくれ頼む
テストを書くかどうか議論するの不毛だから、どうやってテストを書きやすくするか議論しよう
だから今日も実践
ポイントとしてはこの記事と紹介されている書籍を読む。
レガシーソフトウェアに小さな改善を積み重ね、モダンな開発体験を実現する
- レガシーコードに対するマインドセットを持つ
- 小さな改善を積み重ねるための戦略を持つ
- モダンな開発体験を追求する
- くだらない作業・手続きを捨てる
- ドキュメントの継続的なメンテナンス
- 呼び出されていないコード、不要な機能を削除する
あと、ツール開発のすゝめ ーDevelop Fun実践編ー もあります。あのね、扱ってるシステムがレガシーであるかどうかと、それに関わっている開発者の頭がレガシーかどうかって、あまり関係ないと思います。実践的で、まあ「中の人」達は意外とこういうことを楽しみながらやってたりするものなのですよね。皆様のところはいかがでしょう！
レガシーコード改善のススメも良し。
12月もたけなわな来週には リファクタリング本 を今一度改めて読んで話をまとめていこうかなと思います。以上学生さんの闇疑問に対するマジレスでした。