ソフトウェア・シンポジウム2016in米子のセッションでユニークだったのは増井和也氏（ソフトウェア・メインテナンス研究会代表幹事、http://serc-j.jp/serc/）によるFuture Presentation「ソフトウェアの少子高齢化が急加速〜開発中心パラダイムに未来はあるか？〜」だった。ＩＴシステムは開発が終わったあと、その価値を維持し向上することが重要なのだが、保守に関する工学的アプローチはほとんど認知されていない、いまこそ現場のサイレントマジョリティに寄り添った議論を、と増井氏は言う。6月7日午前9時から１時間行われたFuture Presentationの内容を採録する。
保守に関する工学的アプローチはほとんど認知されていない、と増井氏は言う
定年したあと現場に復帰した
増井 今日は皆さんと少し違う視点から、お話をしようと考えています。わざわざ米子まで来て、何か新しい話を聞こうといういうよりも、例えば私がプロレスでいうヒールのようにですね、最後の質疑応答でヒーローが現れてヒールをコテンパンにしてマットに沈めて、わ〜やっぱりソフトウェア開発中心のアプローチでよかったんだと。そういう場面を見たくてやって来られた方もいるんだろうと思います（笑）。
簡単に自己紹介をしておきますと、ソフトウェアにかかわる仕事を40年ほど、3分の2が保守、開発が2割程度、残りがプロジェクト管理とかマネジメントとか営業の支援、本意ではありませんでしたが部門長とかをやっていました。ソフト業界の多層・多重構造のなかで、いちばん下で仕事をしたこともありますし、真ん中で上から責められ下からせっつかれたこともありますし、自分たちがプライムになってパートナーさんを使ったこともあります。
４年前に定年で退職したんですが、頑張って現場に復帰しました。今は保守の現場でソースコードを読みながらバグの調査、改造の提案などをしています。並行して1990年に岸田さん（岸田孝一氏）がソフトウェア・メインテナンスの研究会を立ち上げたときに参加して、調査レポートを作ったり2007年には『ソフトウェア保守開発―ISO14764による』、複数の方との共著で本を出しています。
増井和也、馬場辰男、 松永真、 弘中茂樹共著（2,808円）
（https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E4%BF%9D%E5%AE%88%E9%96%8B%E7%99%BA%E2%80%95ISO14764%E3%81%AB%E3%82%88%E3%82%8B-%E5%A2%97%E4%BA%95-%E5%92%8C%E4%B9%9F/dp/4883732495?ie=UTF8&*Version*=1&*entries*=0）
また昨年の12月、岸田さんからバトンタッチを受けて、ソフトウェア・メインテナンス研究会の2代目の代表幹事を務めることになりました。新米の代表幹事ということで、なかなか苦労しております。
で、何でソフトウェア保守かといいますと、1980年代から90年代の最初にかけて、バブルのころですね、ソフトウェア産めよ増やせよという時代がありました。それはもう大変でした、開発、開発ということで。でもいずれはですね、開発っていうのはグッと少なくなって、いいソフトウェアが長く使われる時代になる、と。機能の追加や改良・改善が主流になるだろう、と。そのような予測をしたのはごく少数だったと思います。
エキスパートは100万行超を担当
皆さんにうかがいたいのですが、ソフトウェア保守というのは技術的に非常に先進的で達成感がある、さらに周りにアピール力がある、自慢できる高度な仕事であると思う方、いらっしゃいますか？ ……手が上がらないですよね。でも私がそちら（受講者席：筆者注）にいたら手を上げたと思います。それくらいソフトウェア保守フェチなんですね。保守が高度な仕事だと考える人が3割ほどいると私も鼻高なんですが、0.1％もいませんから「ヘンタイ」になってしまう（笑）。
ネットで本の名前を検索しますと、バラツキはあるんですが「保守」でヒットする件数を「開発」でヒットする件数で割ると2％未満、50分の1もありません。創造性はない、技術的な先進性はない、達成感はない。一人でコツコツ、黙々とやる地味な仕事というイメージが強いので、進んでやりたいとは思わない。
ところがソフトウェア保守をやっている人が意外というか非常に多いんですね。JUAS、情報システム・ユーザー協会の「ソフトウェアメトリックス調査」2014年版は、ソフトウェア保守の専任者１人がどれだけのプログラムを担当しているかを調べています。ユーザー企業内の情報システム部門を対象に調べたものですが、それによりますと、平均で36.5万行。COBOLで記述したプログラムもあればJavaのプログラムもあるので、カウントの仕方によって変わると思いますが、ざっくり36.5万行、中央値は16.8万行です。
平均値が中央値の倍以上ということは、1人で100万行以上を受け持っているエキスパートがいるかもしれない、ということです。別の見方をすると、ソフトウェア保守の生産性にはものすごい差があるわけです。初心者は5千行がやっと、というこもある。ソフトウェア保守の仕事が簡単なのなら、初心者でも相当量を担当できるでしょうから、こういう結果にはなりません。
保守運用費は5年で開発費の2倍以上
ソフトウェア保守というと、既存のソフトウェアの機能追加や再構成だからそんなに難しいことじゃない、と考えがちです。注文を出すほうは「ちょっとここ直してね」と言うだけですし、現象的には一部を修正する作業をやるわけですが、実際にはどこまで影響するか、直しやすさはどうなのかを見極めてからじゃないと、安易に手を着けることができません。費用との兼ね合いもある。システム全体を見ないと見積もりができません。
「じゃ、見積もってくれ」というんで正直に見積もると、お客さんは血相を変える。「たったこれだけの修正に何でこんなにかかるんか」と。お客さんだけじゃなく、自分の会社の営業も文句を言う。「メインテナンスでそんな見積もり出されたら、開発の仕事が取れなくなる」と。運用部門との調整もありますから。
ユーザー企業の予算を中長期的に、システムのライフサイクルで見ると、新規開発費を１とすると5年間の保守・運用費は２倍以上かかります。10億円で開発したシステムは、その後５年間で20億円以上かかる。１年間４億円以上です。そう考えると、ソフトウェア保守という仕事を一時的な開発の付け足し、片手間仕事に位置付けるのは大きな間違いだということが分かります。
さらに言うと、これからの少子高齢社会でソフトウェアを新規に開発することがほとんどなくなってくる。いや、もちろんスマホのアプリとか、流行りの自動運転のシステム、AIとか、ビッグデータの解析とか、そういう新しい分野のソフトウェアはどんどん作られてくるでしょう。だけど、ある程度できあがったシステムの場合は改造すればいい。超高速開発とかでダ〜ッと開発できるかもしれないけれど、そのあとどうするの？ という問題がある。
そうやって作るだけ作って、例えば3650万行のプログラムだったら100人、365万行なら10人。それだけの保守専任者が必要になります。基幹業務システムであろうと事務管理システムであろうと、ドメインによって保守は不要なんてことはあり得ません。
保守を誤解させている都市伝説
ソフトウェア保守というものを誤解させている都市伝説的な、開発と保守の区分けがあります。「5人／月以上は開発ということにしよう」とか、無形固定資産資産、減価償却に関すること、つまり「経費で処理するのは保守」「瑕疵担保責任の期間は保守だけど、それが過ぎたら金を取れるから開発だ」というような考え方ですね。5人／月を超えたからプロセスが変わるか、といえば、そんなことはありません。技術的には何も変わらないのに、勝手か区分けがそのときの都合で行われる。こういうのは現場のソフトウェア技術者にとっては迷惑な話です。
開発と保守がどういう組織形態で行われているかというと、一つの開発部門の中でやられている。組織の名称として「ソフトウェア保守第１部」なんていうのはあり得ないです。たいていは「開発」という名前で一括されています。「何やってるんですか？」と尋ねると、「開発やってます」というんですが、よくよく調べると実態はその８割が保守と運用だったりします。保守に準じる仕事も「これも開発なんだ」ということにしてしまう。ソフトウェア保守が隠されている。
もう一つ、開発と保守はどう違うのか、どういう位置関係にあるのか、ということです。呼び方が違うだけで作業の中身は一緒だったら、現場にいるエンジニアは混乱しないで済む。ですが、「保守」といったとき、開発と違うプロセスが必要であれば、これは話は別です。実際、開発では「関係ないや」というプロセスが、保守には存在します。それは私が言っているんではなくて、IEEE14764（ISO14764）という国際規約、JISになっていますが、そこに「ソフトウェア保守プロセス」が書いてある。
どういうことが書いてあるかというと、「既存のソフトウェアに手を加えることはすべて保守である」ということです。アジャイル開発やスパイラル型開発のイテラティブ（反復）、派生開発。いずれも既存のソフトウェアに手を加えることですから、保守ということになります。保守プロセスでやらなければならないのは、既存のソフトウェアの問題分析や品質評価です。建築を例にすると、2階建ての家に3階を増築するとき、既存の家の構造を調べて耐荷重や耐震性能を評価しないと増築部分の設計もできないし、技法も素材も決まらない。
基礎がシロアリでグズグズになっていたら、増築する前に基礎を直さないといけないのに、これまで「開発」は作ることばっかりで、既存システムのことはあまり考えない。そんなことでうまく行くはずがないのですけれど、現場の保守担当者に「何やってんだ、こんな簡単なことがなぜできないんだ」と言ってくる。
ところで、見方を変えると「修正の実施」のプロセスは開発と同じかよく似ています。それで「保守」を上流工程の一つに位置付けると、「開発」との関係がスッキリします。既存のソフトウェアの問題分析や品質評価は保守のベテランのエキスパートじゃないとできないけれど、その情報をもとにすれば修正プロセスや新規開発に移ることができます。
だけど。だけど、です。
フタコブラクダと経年劣化を理解せよ
新規開発の場合、ピークは製造／修正（プログラミング作業）です。しかし保守は製造／修正の前に既存システムへの影響を調べたり問題の有無や品質を分析する作業が最初のピークを作って、そのあとテスト・移行の作業が2つ目のピークを作ります。それで私は「フタコブラクダ」と呼んでいます。
開発はコードの自動生成も可能ですが、保守における影響分析や品質分析はベテランのエキスパートがやるしかないし、時間がかかります。システムが複雑に入り組んで規模が大きくなればなるほど、フタコブラクダの山は高くなります。複雑に入り組んでいるので、テストを繰り返さないといけません。
昨日の和泉さんのお話（6月6日オープニングキーノート「オントロジーとモデル理論に基づくソフトウェア開発の品質向上の実践ー上流工程支援と下流工程技術の両立を目指してー」：和泉憲明氏）のように、アルファベット3文字の用語が次から次に出てきて、ますますややこしくなるのは、ソフトウェア保守がちゃんと理解されていないからです。
で、もう一つ、そろそろ時間がなくなってきたので簡単に話します。
一般に、ハードウェアは時間が経つと劣化して価値がなくなっていく、と考えられています。それに対してソフトウェアは経年劣化しない、いつまでも価値は変わらないんだ、という言い方があります。これは大きな間違いでして、ソフトウェアも経年劣化します。
新開発が終わって本番稼動すると、その時点で「こんなはずじゃなかった」というのが出てきます。しばらくするとシステムの便利さが日常になってきます。もっと便利にしたい、使い勝手をよくしたい、ここをこうしたい、ああしたいという要求が出てきます。相対的に有難味、つまり価値が下がっていく。組織編成や社会制度、取引先との関係、法律などが変わっていく。
要求は不満になるので、運用で逃げる、パッチを当てたり、手計算や手書きで対処するといったことをやります。そうやってソフトウェアの価値はどんどん下がっていくわけです。そうならないように、機能を維持していくのがソフトウェア保守というものです。ところが「維持」という言葉が独り歩きして、「やって当たり前」になってしまう。そうじゃなくて、ソフトウェア保守は機会損失を防止し、中長期のトータルコストを低減する非常に価値がある仕事だということです。
いまこそ技術者に寄り添う議論を
その意味で、ソフトウェア保守に市民権を、というのが私の主張です。ソフトウェア保守を隠さない、一部の人に集中させない、ソフトウェ保守に適正な対価を認める、といったことです。作り手と直し手をそれぞれ専門職として分離する「第三者保守」も検討課題ですし、システムのライフサイクルを医療に例えれば、寿命が来たソフトウェアの廃棄を判断する「ソフトウェア医師」の概念もたいせつです。
まとめますと、「新規開発に固執したレガシーパラダイム」からの脱却が必要ではないか、と思います。ソフトウェア保守に焦点を当てた資格はありません。しかし現場には大勢のソフト技術者が保守作業に従事しています。いまこそ現場の技術者に寄り添った議論が必要だと強調して私の話を終わります（拍手）
