ここ数日流行りの言説「～はブルーオーシャン」に乗じて過去のメモを放流しています。
保守開発はブルーオーシャン
エンタープライズ製品、花形は設計、新機能リリースであって欲しい。一方、当然その裏には保守、サポート開発という甚だ地味なチームがいる。
保守開発の1日
- お客様からの問合せを捌き
- 今月の不具合対応チケットを捌き
- それでも差し込みが入る。
- トラブれば他部署との打合せが多くなるから
- 残りの時間で頑張って本でも読めたらそれは最高だがそんな日がなかなかない。
- 成長の法則には70:20:10というものがあるらしいが私の場合は20を仕事で学び80をコミュニケーションの難しさに悩み10を無理やり溢れさせてどうにか学習しているもんだなあなどと思う。
- なんてことを少しは反省して以前、こういうことを書いた : 有害な頑張り
コロナ禍で在宅勤務が増えた
- エンドユーザの自宅PCからPingだWiresharkだ、をお願いできるわけがない。
- が、お客様にはアプリ屋さんインフラ屋さん電気屋さんの区別はない。
- 在宅利用でAzure利用でWindows versionいくつで、Excel、Word、メモ帳等では問題なく日本語入力できるが、なぜか弊アプリだけ日本語の入力ができない等、聞かれる。お客様のPCは我々のインフラ。
- 「～～のような事例が起こり得るのかもしれないですね」とか、頑張ってググった内容を教えてあげる。
- 画面キャプチャ位は添付してくれたら嬉しいんだけどなあ。
- 挙げ句お客様側調査で解決したとか、ご連絡を頂き一件落着する。
非推奨機能に対する無理な使い方とそこへの指摘をもらった
- 本来推奨していない機能でも、お客様にとってはあまり関係ない。互換が取りきれていない我々が悪い。
- ゴメンナサイ言えるようにするためだけに調査しないといけないこともある。
- それが今回のお客様だけのためだろうが1度きりだろうがそういう問題ではない。
- むしろお客様の顔色を見ないといけないことも事実ある。
- どんな界隈もキラキラした仕事ばかりではないでしょう。とデータサイエンティストの終わりなき戦い を読んで思った。
青い芝生
- AWSだNodejsだTypeScriptだ、と何やら楽しそうだなあという界隈を尻目にJava6とたたかう。
- 20年以上前の技術選定に従ったままだよなあ。とこれを読んで思った。
-
モダンプログラマになれない組込みプログラマの苦悩 - Qiita
モダンプログラマになれないけど組込みプログラマは楽しい - Qiita に共感している。
自分や、チームメンバーのモチベーションの保ち方
- 開発者として自分は開発者なのか？とアイデンティティが良くゆらぐ。
- 技術的に難しいことを力技でやってしまうこと の悩みもよく分かる。
- 自分が自走できていないのにひとに自走する方法を期待するとかよろしくない。と「自走できるエンジニアとは」を読んで思った。
とにかく時間
- 開発に「遅れ」などという表現をするのはちょっと違っておりそれは「見積もり」と「実績」の差分でしか無いようです。むしろ見積もりがおかしかったという分析をすべきでしょう。全力疾走、全員が疲れない前提での見積もりなどに意味はないのです。
- 数ヶ月体力で頑張っているふりをしても、それは「意外となんとかなっている」という誤解を周囲に生むだけです。なんとかなっているわけはないので我慢せず休みましょう。
- 冒頭の通り、トラブれば説明に時間を割かれるので自分の勉強時間や、チームでの雑談時間を余計取りづらくなる。リモートワークならではの勤務時間超過は損しか無いです。
- そんな中で「雑談しづらいなあ」なんて空気ができていてはそれはもう「どうにもなっていない」であります。
なぜ保守開発がブルーオーシャンだと冗談めいたことを言うのか
いろいろと述べましたが、またこれをどう表現するかは難しいですが。あらゆるものはいつかレガシーと言われる。上のような悩みに対して何も考えられないかと言うとそんなことはなく、むしろこれでもかというくらい工夫のしがいがある。そこが保守開発の最大の強みだと思えるならやはりそれは、敢えてブルーオーシャンと言えるでしょう。参考: 「レガシーコード改善ガイド」
工夫: 在宅環境問合せ事例集をつくる
- コロナ禍で在宅勤務が増え新たな環境問題での問い合わせで困った...
- なら、それをそのままタイムリーな話題として、事例集にしてしまえばいい。
工夫: 徹底的に仕様と動作を調べる
- 非推奨機能に対する無理な使い方とそこへの指摘で困った...もちろんソースそのものは読み尽くしているつもりでいたりノウハウも溜まりきっているように思え、短調なものもある。
- が、それでもやはりトラブルは起こる。ハードウェアやミドルウェアやお客様環境側は進化していることもあるからだ。常に調べる対象はやってくる。ならばそこへの興味。
- いつものソースだと思って読み解くと全く面白くはないが、
- 1秒でも早くならないか
- 1バイトでも節約できないか
- つまりいくらでもこだわれる。
工夫: 現状把握する。数値化する
- 他チームや他社とのギャップで困った...
- ならとりあえず資格をとってみるとか、本を読みまくってみるとか、オンラインで試せるコーディング問題（atcoderみたいなやつ）を解くとか、とにかく自分のスペックを可視化できる手段を試してみていいと思う。それって転職時も必要である。笑。
- だから自分と、チームメンバーのモチベーションの保ち方に悩みが増えて困ったなんてときも、
- 褒め合うふりかえりをしたり
- 積極的な学びを推奨しあったり
- で、自分が学んだ内容を共有し合ったり、再利用できるようにしたり
- すると結構毎日楽しくなってくるものだとおもう 多分。
- その前に上司や同僚、先輩と愚痴り合って話せる関係であることもかなり大事である。
- ウソは一回つくとその時点で次のウソを生む。矛盾が発生する。常に正直に、事実を伝えることが矛盾を産まない唯一だし、お客様を結果的にリスペクトすることだと思う。
- チームで話す関係を作っておく。皆が動きやすい環境を作る。普段から作る。
- お客様がこう言ったから、だからこうする、というのは別にお客様を尊敬しているわけでもなんでも無い、お客様の考え方に対して向き合っていないことだと思う。
- チームの中でも同じでルールだからとかマナーだから尊敬語謙譲語っていうのも別に、私は意味はないと思う。
- 正解は無いしヒトに依存するので普段からこういうの折に触れて話せると良いんじゃないかなと思う。話せる関係を持っておくっていうのが何より大事かも。同調圧力とチームワークは別物である。
工夫: 存在意義を再構築、言語化する
- 保守開発に開発者として入って困ることのまとめ（実体験） という記事。
ここに書いたこと以外でも、「このアプリ、どうやって保守するんだろ。。。」っていうことを新参者や保守チームに思われないように、普段から開発側が「どうやったらアプリ保守しやすいかな」を考えて開発すると良いものができあがるのかなと思います。
- そうは言っても保守の経験がないと、作ってしまうのです、
クソテストしづらいコード を。だからこの本: 「良いコード/悪いコードで学ぶ設計入門」はSNS時代の冒険活劇ゲーム攻略本だと思った - Qiita - 保守経験は、裏を返せば、新規設計時のアンチパターンとして手っ取り早く、深く、自分の糧になる。
- クレームも要望も、お客様が居るから受けられるという裏返し。
- お客様がいるから会社が成り立つ。
- 会社を支えて、ゼニを稼いでいるのは我々だ となる。当たり前の存在意義に気づく。だから保守開発は会社の最前線で最も評価されるべき部署なのだ。
工夫: やりたいことなら続けられると自己暗示しつつ、締切をめでたく越えたら思い切り寝る、休む
- まあ締め切り越えなくてもたまにはネットワーク自ら切って音信不通になったら良いと思う。笑
- 忙しい自慢しても文句だけ並べても誰も得しない。有給をちゃんと使おう。こんなもの読んでないで寝よう。連休は休もう。
まとめ
以下Tweetに共感
- インフラ人材はブルーオーシャンなのか？／ITエンジニアキャリアにおける「ブルーオーシャン」とは｜久松剛／IT百物語の蒐集家｜note
- 「エンジニアはテクニカルサポートを絶対にやったほうがいい」 - カスタマーサクセスエンジニア論 - Qiita
- 新人さんにすすめる (弊社の) 有益な記事達 2022春 - Qiita
- どの界隈も極限環境はそりゃあブルーオーシャンで、その学びに魅力を感じるならどんどんやってみたら良いとおもう。ヒマラヤ登山はブルーオーシャンでしょう。
- 保守、サポート開発の何が醍醐味なのか。自分の目線の意見なので異論あると思われるが、その魅力を少しでも面白がっていただければ、さいわいです。