あけましておめでとうございます。本年もよろしくお願い致します。
久しぶりに登場しました、エージェンシー事業を担当するプロフェッショナルアプリケーションエンジニアの菊池です。
新規にシステムを開発して運用フェーズに入り、機能追加や保守に関連する改修を長らく続けていると思うことがあります。あたりまえですが、運用中のシステムに対する開発は、機能追加といったビジネス要件を満たすものだけでなく、システムを良い状態に保つための開発もやった方がいい。
使っている言語やフレームワーク、ライブラリーは適切なタイミングでバージョンアップしないと、サポートが切れたりセキュリティーホールが見つかったりします。当初想定していなかった要件を満たすために止む無く入れた歪んだ変更は、やがてコードの複雑さとなって現れてきます。システム立ち上げ時には最適と思われていた技術選定も、やがて技術環境が変化して過去のものになっていたりします。などなど。
なので、こういう状態を避けるための、システムを良い状態に保つための開発もやったほうがいい。システムの見かけ上は変化しないんだけど、取り組んだ方がいい。これって、やった方がいいのはわかっているけど、後回しになってしまいがちではないでしょうか。すると、状況はますます良い方向から遠ざかってしまいます。
一昨年の秋ぐらいから、このやった方がいいけど後回しになってしまいがちな、システムをいい状態に保つための活動を部署で展開したので、その内容について書きたいと思います。よろしくお願いします。
運用しながら変更を加える難しさ
しばらく前に「新規でシステムを開発するよりも、運用中のシステムに手を入れる方が難しい」といった内容のツイートを見かけて、共感したことがあります。記事を書くにあたって、このツイートを探したんですが残念ながら見つけられませんでした。
新規でシステムを開発する場合、運用前なのでシステムのあらゆる部分を自由に変更することができます。技術選定もその時点で最適な選択ができるし、全体の設計で違ったなと気がついた箇所があれば変えればいい。コードもたやすく変更できます。そこで何か問題があっても、リリース前に適切な修正を加えることで対応できます。
これがリリースして運用状態に入ると、何かひとつ変更するにしても慎重にならざるを得ません。変更の規模によりますが、システムの一部を変更したことによって意図しない動作になった！あわや大惨事！というのを避けなくてはならないのです。これが新規でシステムを開発する時にはなかった制約で、運用中のシステムに対する変更の難しさにつながってきます。そこから、運用中のシステムに大きく手を入れられる人や組織になるほど技術力があるなーって感じたりもします。
運用中のシステムに手を入れていると、飛んでいる飛行機の部品を交換したり新しいパーツを作って組み込んだら、こんな感じなのかな？と思ったりします。影響範囲の広い変更ほど墜落しないように慎重に手を入れなくては。運用中のシステムにはそんな難しさってありますよね。
ありがちな状況
運用中の動いているシステムに見かけ上は変化が無く、やった方がいいけれど影響範囲の広い変更は、後回しになりがちではないでしょうか。自分の経験からしても、ちょっと腰が重くなることがあります。
過去の自分自身を思い返してみると、
システムが無事にリリースされてあれから数年経ちました。無事に運用に乗って機能追加も順調に進んでいます。だけど言語やフレームワークのバージョンがちょっと古くなってるな、そろそろサポート切れそう。バージョンを上げてちゃんと動くのか心配なので、後回しにしているうちにますます古くなってしまった。システムは順調に動いてはいるものの、あまりよく無い状況だとは思っている。
システム構築当初は想定していなかった要件に対応するために、かなり歪な変更を加えた。要件は満たしているし、既存の動作に影響がないのでうまくいったと判断できなくもない。しかしながら、この歪な変更を前提とした変更が積み重なり広がってきて、ちょっとしんどい状況。根本的に手を入れたいものの、影響範囲が広いので二の足を踏んでいる。
なんてことがありました。システムはいつも通りに動作しているし見かけ上は問題なさそうですが、時間が経つにつれて少しづつ降り積もる雪のように積み重なり、重く肩にのしかかってくるようです。
やった方がいいのはわかっているんだけど、なかなか思い切って取り組めない歯痒い状況。部署を見渡すとそんな状況がチラチラ見えつつあるので、エンジニアの幸せのためにも取り組むことにしました。
良い状態を保つための取り組み
幸いなことに、所属している部署はシステムを良い状態に保つための工数に対して、理解のある環境です。部署に対して働きかける前に数人のメンバーと話してみましたが、取り組みを進めることに前向きな感情のメンバーが多く、中にはしっかり取り組んでいるメンバーも居ました。これを全体の雰囲気や文化として定着させるためのきっかけを作れば、組織として前進しそうな雰囲気がありました。
部署全体への共有
そこでまずは、目指したい方向を部署内に共有するところから始めました。ちょうど良いタイミングで部署の全体会議があったので、全員に向けて『システムを良い状態に保つための開発に取り組もう』という内容のプレゼンをさせてもらいました。そもそも人間には正常性バイアスがあって、良く無い状況なんだけどまぁ大丈夫と思いがちです。以前スーパーにぶどうを買いに行ったときにこんなことがありました。ぶどうをかごに入れてレジに向かうと非常ベルが鳴りました。ところが、レジはそのまま稼働し続け、店内にいる人は誰ひとり避難をしませんでした。点検しているだけだろう、煙が出ていないし大丈夫、誰も避難していないから大丈夫などと考えて避難しなかったのでしょう。これが正常性バイアスです。開発の現場でもこういったことは起こります。システムに良く無い状況が起こりつつあるけれど、いつも通り動いているし問題無いと判断してしまわないように気をつけようね。そういった部分に対して取り組むことも大事だよね。といった内容を過去の経験をふまえつつ発表しました。
技術的な交流会
このプレゼンの後に、定期的に一部のメンバーが集まって技術的な交流をする場を設けました。頻度は月に１回で、各チーム１名程度のメンバーに声をかけて参加してもらっています。普段は別のシステムに関わっているメンバーが集まって、最近何やってるの？を月に一度集まってワイワイ話しながら、担当システムを良い状態に保つために進めていることや最近取り組んでいる内容、困っていることや気になる技術トピックなどを共有できるようにしました。ちなみにこの場の名称は「テンション⤴会議」です。みんなでお互いに助け合って気持ちを盛り上げて、システムも良い方向に上がっていく感じを「⤴︎（アップ）」の文字に込めています。
気をつけたこと
このように部署に対して働きかける際に気をつけたのが、あくまで雰囲気作りとして取り組むということです。弊社は現場のエンジニアに大きな裁量がある環境なので、日々の業務の中でチームごとに適切なタイミングを判断して取り組むきっかけを作ること。そのきっかけを通して何かしらの進展があり、やがて文化として根付いて欲しいと考えました。なので「〜までに〜を〜の状態にしてください」というような取り組み方は選びませんでした。あくまで、良い状態を保つための取り組みにも意識を向けてもらうことを心掛けました。
取り組みの進展
全体会議のプレゼン後にもらった感想で印象に残っているのが「こういう開発もやってよかったんですね！」だったり「いよいよ大物のアレに取り組むきっかけになりました！」という声だったので、ちょっとしたひと押しが必要だったんだなと痛感しました。何かしらの遠慮か躊躇があって先に進めていなかっただけなのかもしれません。
定期的にメンバーが集まって技術的な交流をする場では、時間が足りないまま終わることも多くなりました。それぞれ担当システムが異なるもののお互いのあるあるネタで盛り上がったり、システムの改善系の話やそこでのハマりどころ、大きく進展のあったシステムについては素直にすげー！という声が上がります。あれどうやって実装してるの？とか、これ使ってみたらこうなって幸せになりましたなど。システムエンジニアはこういう話がしたいですよね！この場が、システムをより良くするために知見を深めて取り組む活動のエンジンになったと思います。
これら全体の取り組みを通して、去年このブログで記事になった『テストカバレッジを30%上げてRails 4.2から6.0へのアップデートを決断をした話』といった大きな進展も見られるようになっています。その他にもシステムの改善デーを設けて定期的に活動していたり、周りのシステムの進捗に刺激されて取り組みを始めるところも見られるようになりました。
冒頭に書きましたが、運用中のシステムを動かしながらより良い状態にするには、そこそこ技術力が必要になります。この活動を通して、個人や組織の技術力や経験値の向上につながれば幸いです。
おわりに
部署内でシステムを良い状態に保つための取り組みを行い、大きな改善活動が行われるなど成果が出始めてきました。今回の取り組みで生まれたシステムを良い状態に保とうという文化を根付かせ、システム改善のモチベーション維持し続けるために、今後も交流会をはじめとした活動を続けていきたいと思います。改善活動をやった方がいいのはわかっているんだけど、なかなか思い切って取り組めない歯痒い状況でお困りの方はぜひお試しください。
それではみなさんごきげんよう。今年もよろしくおねがいします。菊池でした。
