この記事は、NTTテクノクロス Advent Calendar 2025 シリーズ1の7日目の記事になります。
皆さんこんにちは。NTTテクノクロスの西原です。
普段は自社製品開発リーダー及びその製品のインフラ構築/運用リーダーを担当しています。
はじめに
皆さんはDevOpsと聞いて何をイメージするでしょうか？
- 最高に効率化され働く人全員が生き生きとしている、まさにソフトウェア開発の理想郷のような状態
- IT業界で不定期に流行る、仕事効率化のお題目
人によってイメージは異なるでしょうが、今回お話しするのは
DevOpsという概念を元に現場に具体的にどういう改善を実施していったか（していけばよかったか？）
及びその活動のために何が必要だったか？を反省とともに振り返るものになります。
ですので、DevOpsとは何ぞや？な方でも、DevOpsとか聞き飽きたわ、という方でもスッと入ってくる話だと思います。
活動と振り返り
① CI/CD環境の改善とメンテナンス
普段の活動として、製品のCI/CD環境の改善を地道に実施していました。
- ビルド対象のモジュールの追加
- デプロイジョブの追加
- CI/CD環境自体のミドルウェアアップデート
等、開発メンバが効率よくタスクに取り組めるように空き時間を見つけてはメンテナンスしていました。
(構築したCI/CDパイプライン 初めてパイプラインがすべてGreenになったときの感動はひとしおでした)
改めて振り返ってみると、改善した（あるいはしようとしている）内容を
もう少し頻繁にチームメンバに展開すべきだったと感じています。
CI/CD環境が複雑になればなるほどメンテナンスも難しくなるのですが、
自分以外に任せられるメンバを育てることがなかなかできず、
結果として自分の負担が増え継続的に活動できる体制づくりの必要性を痛感しました。
（チームの仕事を楽にするために頑張ってきましたが、やはり"自分も含めた"チームの仕事を楽にしたいですよね！）
しっかりした資料を作らないと理解が難しいものだと当時は思っていましたが、
簡易な資料だけでも作って後はメンバの自己学習に任せる形式でもよかったかもしれません。
② 開発メンバの育成とテストコード範囲拡張
アジャイルのスクラムマスターおよび製品カスタマイズPLとして、開発メンバを育成しつつ機能改修に取り組んでいました。
ペアプロを取り入れて設計～製造～テストコード作成まで開発メンバと意識合わせする機会を設けつつチーム内での開発工程の改善を進めました。
ペアプロ自体は非常に楽しくできましたし、メンバからも好評でした。
（ソースを任せられる開発エンジニアとしての育成は順調でしたが、①の反省点の通りCI/CD環境を担当できるレベルには到達させられませんでした）
テストコードについては当初想定よりも難しく、
- テストコードを作る前提になっていない既存コード
- テストコードを作る経験が乏しいメンバ
- そもそもテストコードを実行するための開発標準的な環境の整理
など課題が山積みでした。
結果としては、新規に開発した機能については何とかテストコードを組み込むことができ、①のCI/CD環境での実行も実現できたのですが、
「テストコードの作り方、考え方」や「テスト環境の構築方法」について暗黙知が増えてしまい、後々課題になりました。
これも①と同じく、まとまった資料を作ろうとするとかえって手がとまってしまうので、簡易なものでもどんどん作って展開していくのが重要だったなと反省しています。
（当時はまだ生成AIは出てなかったですが、今だったら簡易な資料がある程度集まってきたら生成AIにまとめてもらう、なんていうのもありかもしれないですね）
③ 製品要望やチーム改善についてメンバ全員で話し合う文化を作る
今振り返ると、この活動が一番やってる「最中」は楽しく、やった「後」苦しかったな。という思い出です。
自分たちの製品について語るのって楽しいんですよね。良いところも悪いところもいっぱいあって。
製品の未来について語るのも楽しいものです。「こんな機能があれば売れるかも」とか、「ああいう機能がないと他に置いてかれてしまう」といった話は
普段の仕事の中ではあまり話す機会が無く、いろいろな立場からの意見が交わせます。
ただ・・・その場で出た改善案とか機能案を後で見るのが苦しいんですよね・・・だって全部「未実施」のままだから(涙)
積み重なっていく未実施の項目を見るのが辛くなってきてしまい、この活動は途中でやめてしまいました。
これに関して反省点ははっきりしていて、「スキマ時間」に取り組もうとしてしまったことです。
仕事にスキマ時間なんて本質的には無いですよね(笑)
ですので、「この改善に取り組むために今月〇時間使います！」とチーム内で宣言/合意し、
きちんと仕事の枠を確保したうえで取り組むべきだったと感じています。
（どれだけコストがかかるか分からないと、実施可否も判断しづらいですしね）
未実施のままの項目を見るのは辛いですが、
逆に「これは完了！」と項目を変更するときはとてもうれしいもので
今後のモチベにもつながります。
まとめ
これまでDevOpsに取り組んできた感想を一言で言うと「個人レベルでできることの限界まで頑張った」になるでしょうか？
個別の振り返りでも書きましたが、もう少しチームメンバに軽くでいいから改善活動を振ってみる、きちんとした形にならなくても育成を兼ねて任せてみる
といった方針をとれていればもっと大きな規模で活動できたかもしれません。
でも、自分で手を動かすのって楽しいからつい自分でやりたくなってしまう、あるあるですよね(笑)
おまけ
ここまで読んでいただいた方、ありがとうございます。
そして、「振り返りとかいう割には主観とか感想レベルで、定量的な話が出てこなくてためにならないな」と思われた方、ごめんなさい。
DevOps活動はまさにそこが肝で、効果を定量的に測定する（あるいは表現する）のが難しいんですよね。
DevOpsの効果測定でよく言われるのがFour keysという指標です。
しかしこれは遅効性で、DevOps活動がうまくいっているならばそのうち測定値が改善されていく、という性質のものです。
「今現在実施しているDevOps活動によって、チームにどんな効果が得られたのか？」と言われて定量的に出せるものを自分はついぞ見つけられませんでした。
（調べてみると、チームとして重要視する要素についてのアンケートを定期的にとる手法があるみたいですね）
効果が定量的に報告できないと、どれだけコストをかける価値があるのか説得する材料も不足してしまうので
継続的に活動していくの大変さを痛感しています。
皆さんの現場ではどんなDevOps活動をしていますか？どんな方法で効果を測定していますか？ぜひコメントお待ちしています。
引き続き、NTTテクノクロス Advent Calendar 2025 をお楽しみください。