新規開発 VS 保守運用

保守運用はつまらない？

多くのソフトウェア開発組織は伝統的に、プロダクトのライフサイクルにおける「新規開発」と「保守運用」を異なるフェーズとして扱ってきた。そして両者を分断し、フェーズごとに異なる人々、つまり「新規開発チーム」と「保守運用チーム」にそれぞれ担当させる。このようなやり方は、一見効率的で上手くいきそうなものだが、実際のところ多くの問題を生み出している。そのひとつは、「新規開発チーム」は先進的でやりがいがあり、「保守運用チーム」は古臭くてつまらない、という固定観念だ。その傾向は強く、たとえばRubyGemsの開発者としても知られるチャド・ファウラーは、彼が経験したとあるプロジェクトを次のように振り返っている。

この開発センターの立ち上げでは、全く予期していなかった問題に直面した。誰もが新しいシステムを開発したがったんだ。旧システムの保守に携わることを希望した開発者は一人もいなかった。(中略)
栄光に浴するのは新世代の製品を構築した開発者たちに決まってる。こういう考え方が開発者たちに広く浸透していることは、過去に一緒に仕事をしたプログラマたちを見て僕にも分かっていた。それでも200人以上もの人材を集めてみて初めて、それが予想以上に極端だと言うことを思い知らされた。^[1]

保守運用がつまらないのは固定観念だと述べたが、残念なことに、それは単なる偏見とは言い切れない。実際、技術的なチャレンジの機会は少ないし、安定運用を続けたとしても「栄光に浴す」ことはない。新規開発チームで「成長」を続ける同僚を目にして、惨めな気持ちになる人もいるだろう。また、新規開発チームが不味い置き土産を残したならば、尻拭いをするのは保守運用チームだ。熟練した開発コンサルタントであるマシュー・スケルトンらも両者の非対称性を指摘する。

新規サービスチームは新技術と新しい手法を実践できるが、これらのアプローチが有効かどうかを確認できない。新しい手法はダメージを与えるかもしれないが、新規サービスチームはそれを気にする理由がほとんどない。選択ミスによる辛さを味わうのはBAU(通常業務)チームだからだ。^[2]

とはいえ、ここで「新規開発チーム」と「保守運用チーム」の分断を強調し、両者の対立を煽るのは本論の目的ではない。筆者の関心は、両者の分断を乗り越えて、より健全で強い開発組織を築けるようにすることだ^[3]。しかしながら、「新規開発」と「保守運用」の隔たりはたいへん根の深いものだから、もう少し事例を並べたて、その窮状を凝視してみよう。

運用軽視の世の中で

「新規開発」と「保守運用」の分類に従うならば、例外はあるものの、世の中に存在するソフトウェア開発者の仕事のほとんどは「保守運用」だと言ってよい。著名なプログラマーのケント・ベックは皮肉めいて次のように語る。

私が若いプログラマーだったころ、ソフトウェア開発コストの70%がメンテナンスに費やされているという悲惨な報告を聞いたことを覚えている。70%も！モノを作って動かし続けるのにその2倍のコストがかる仕事とは、なんとお粗末なのだろうか？^[4]

一方で、「保守運用」は「新規開発」よりも簡単で、少ない人員でもできるだろう、あるいは低賃金の非熟練者でもできるだろう、という先入観が蔓延ってきた。そしてその先入観はときに由々しき事態を引き起こす。みずほ銀行のシステム統合プロジェクトはその一例で、2019年に稼働を開始したものの、大規模障害を幾度となく発生させた。その要因の一つが運用軽視の姿勢であったという。

みずほFGは2019年7月にMINORIが全面稼働した直後、2019年8月26日に開催した経営会議で、MINORI開発プロジェクト管理体制の終了・廃止を決定した。これに伴いMHRTはMINORI開発に参加していた人員を、みずほグループ内の他のプロジェクトやグループ外の顧客を対象とするプロジェクトに異動させた。(中略)減少率は67%に達する。
MINORIの開発や保守の実務を担うMHRTの要員を急激に減少させたことが、運用体制の弱体化を招いた。金融庁はそう指摘したわけだ。^[5]

「新規開発」と「保守運用」という問題系の根深さを捉えるには、政治哲学者ハンナ・アレントの分析が参考になる。アレントはその著書『人間の条件』のなかで、「仕事 work」と「労働 laber」という二つの言葉の違いに注目した。仕事と労働は似た言葉であるが、ほとんどのヨーロッパ言語においても両者に対応する単語が存在し、人々はそのニュアンスを巧妙に使い分けている。

たとえば、ロックは、仕事をする手と労働する肉体とを区別したが、それは、古代ギリシア人が行った区分と多少似ている。つまり、古代ギリシアでは、ドイツ語のHandwerkerに相当する職人[ケイロテクネス]と、「奴隷や家畜のように自分の肉体をもって生活の必要物に仕える」人びとが区別されていた。^[6]

「新規開発」と「保守運用」の区分は、この現代版と考えられなくもない。つまり、新規開発は新たなものを創造する「職人」の「仕事」であり、保守運用は目新しいものを生み出さず、「奴隷や家畜のように」日銭を稼ぐ「労働」というわけだ^[7]。実に悲観的な見方ではあるが、先に列挙してきたさまざまな事例を振り返るなら、筆者のこじつけとは言い切れなくなってくる。

新規開発のつらさ

さて、ここまで「保守運用」の苦しみを共感的に述べてきたが、「新規開発」にも多くの苦しみがあることを忘れてはいけない。あなたが「後先考えずに興味ある技術を好き勝手に導入し、乱雑なコードを残したまま、用が済めばさっさと転職してしまう」ようなエンジニアでなければ尚更だ^[8]。

実際、新規開発には多くの困難が伴うし、過重労働となる人も多い。そしてもちろん、作り上げたプロダクトが商業的に失敗し、失望を味わうこともある。2010年代半ばのモバイルゲーム業界では、その極端な例を見ることができた。筆者の友人に大手ゲーム開発会社に勤める人がいるが、彼の話によれば、ある同僚は4つのゲーム開発プロジェクトに関わったものの、その1つとしてリリースに至らなかったという。その頃のモバイルゲーム業界は流行の移り変わりがきわめて早く、新作ゲームであっても陳腐化が激しかったために、リリースしたとしても高額な広告費用を回収できる目処がすぐに立たなくなってしまうからだ。

開発と保守の境界を乗り越える

ここからが本題である。これまで長々と見てきた「新規開発」と「保守運用」をめぐる苦しみを、どのように乗り越えるのか。単純だが効果的な方法のひとつは、両者を分けずひとつのチームにすることだ。AmazonのCTOであるワーナー・ヴォゲルスが述べた「you build it, you run it（自分で作ったものは自分で運用せよ）」の原則はその基本的な考え方だ。先に紹介したマシュー・スケルトンらの指摘にもあるように、新技術・新手法の導入は必ずしも成功しないのだが、その「選択ミスによる辛さ」を味わうのが導入した人自身であれば、それは大きな学びとなる。誰の言葉か忘れてしまったが、「ソフトウェアアーキテクトとして成長する唯一の方法は、自ら設計したプロダクトを、自ら長期間にわたって運用することだ」という話を聞いたことがある。まったくそのとおりであろう。

フレデリック・ブルックスが名著『人月の神話』のなかで、ソフトウェア開発プロセスの特徴は「漸進的」なことだと言い当ててから半世紀が経っている。漸進的な状況下では、本来「新規開発」と「保守運用」は一体のものであるのだが、製造業以来の慣習からか、あるいはパッケージソフトウェアの時代が近年まで続いていた所為か、両者は長らく分断されたままだった。もちろん、この問題に対して多くの人が関心を傾け、懸念を表明してきた。そしてここ十数年に至ると、過去への反省から「進化的アーキテクチャ」などの具体的なコンセプトが生まれ、両者の垣根は次第に取り払われつつある。この傾向は今後も続くだろうか。巷では生成AIが「新規開発」を担い、人間が「保守運用」を担うようになるといった意見もある。いずれにせよ、筆者が重要だと考えるのはエンジニア自身の倫理観と自制心である。現在、ソフトウェアエンジニアの採用環境は求職者にきわめて有利だから、プロダクトに問題を残したまま転職するのは簡単だ。また、「新規開発」のなかで「新技術や新手法を導入した」という経験は、求職者にとって定番のアピールポイントとなっている。しかし、それらの新技術が現場に大きな混乱をもたらしていたとしても、面接官がその実情を見抜くことは困難であろう。

もちろんこのような指摘は、新技術や新手法の導入を過剰に抑制しようとするものではない。早かれ遅かれ人の出入りはあるし、個々人の健全なチャレンジは好ましいことだ。すべてはケース・バイ・ケースと言えるし、このような問題が起きるのは個人だけでなく組織に起因する場合もある。GoogleのCEOを務めたエリック・シュミットは次のように反省する。

経営陣は、新プロダクトがまともな売上を計上しはじめるまでの期間を過少に見積もる傾向がある。手垢のついたコアビジネスに比べれば、ピカピカの新プロダクトのほうがはるかにおもしろい。しかし会社の経費をまかなうのはコアビジネスであり、そこで失敗すればおそらく立ち直れない。^[9]

そのようなことだから、新規開発と保守運用をめぐる問題系を乗り越えるには、組織的な決断と支援が欠かせない。とはいえ、その道のりは長くはあるものの、あなたが良きエンジニアとしての誇りを持つならば、その一歩目を踏み出すことができるはずだ。

脚注

1. Chad Fowler 著, でびあんぐる 訳『情熱プログラマー ソフトウェア開発者の幸せな生き方』2010, オライリー・ジャパン, pp86

2. マシュー・スケルトン, マニュエル・パイス 著, 原田騎郎, 永瀬美穂, 吉羽龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』2021, 日本能率協会マネジメントセンター, pp213

3. このような目的にもかかわらず本論のタイトルを「新規開発 VS 保守運用」としていることに対し、疑問に思う人がいるかもしれない。その理由は、筆者が東宝の怪獣映画『ゴジラ』の『VSシリーズ』を観て育った経緯から、「VS」という文言に特別な親しみを抱いているためだ。「新規開発」と「保守運用」も考えようによっては怪獣のようなものだから、言い当て妙とは言えないだろうか。

4. ケント・ベック 著, 吉羽龍太郎, 永瀬美穂, 細澤あゆみ 訳『Tidy First? ―個人で実践する経験主義的ソフトウェア設計』2024, オライリー・ジャパン, pp105

5. 日経コンピュータ 著『ポストモーテム みずほ銀行システム障害 事後検証報告 (日経ビジネス人文庫)』2024, 日経BP 日本経済新聞出版 pp197

6. ハンナ・アレント 著, 志水速雄 訳『人間の条件 (ちくま学芸文庫)』1994, 筑摩書房, pp134

7. 筆者としては、「奴隷」という言葉が持つ差別的なニュアンスと歴史的な背景の複雑さを踏まえれば、この語は軽々しく使うべきではないと考えている。今回は参照元の文意を明瞭に示すため、そのままの表現に留めた。

8. 意地悪く書いてしまったが、このような状況に陥ってしまう原因の多くは、新技術を臆せず扱えるエンジニアはひっぱりだこだから、はからずとも多くのプロジェクトを渡り歩くこととなってしまうというマネジメント上の傾向に起因すると考えている。

9. エリック・シュミット, ジョナサン・ローゼンバーグ, アラン・イーグル 著, 土方奈美 訳『How Google Works 私たちの働き方とマネジメント (日経ビジネス人文庫)』2017, 日本経済新聞出版, pp285