＜稼働ソフトウェアへの対応は保守が上流，開発が下流＞
たびと ソフトウェア保守プロセスの国際規格，まさに「修正の実施」がポイントなのです。規格では「修正の実施」内のタスクに「開発プロセスを呼び出しなさい」というのがあるのです。
保品 「修正の実施」で開発プロセスを呼べ？ う～ん。さっぱりイメージが湧きません。
たびと 「開発中心」の考え方でものを見ようとしているから，たぶんイメージが湧かなくなるでしょうね。
保品 「開発中心」で考えるな？ どういうことですか？ ますます禅問答です。
だひと ソフトウェアを保守する段階，すなわち稼働後のソフトウェア対応では，保守プロセスのタスクが上流工程で開発プロセスのタスクが下流工程と考えればイメージできると思います。
保品 えっ？ 保守が上流工程で開発が下流工程？ そんな天と地がひっくり返ったような発想の転換は今のソフトウェア関係者の要人の誰もが受け入れないでしょう。
たびと 「開発中心」に凝り固まっているからですよ。ただ，私が勝手に申しあげているではなく，その国際規格にそう書いてあるのです。「開発中心」でしか考えられない頭の硬い学者先生や企業のIT有識者と呼ばれている人たちはこの国際規格をまったく受け入れようとしないのです。
保品 たびとさんが何度も「開発中心の発想から抜け出せ」とおっしゃったことはこのことですね。
たびと はい。修正に開発プロセスというのは確かに分かりにくいと思いますが，建築の例を出すとイメージできるかもしれませんよ。
保品 また，別の例でごまかそうとしていませんか？（笑）
＜保守はソフトウェアのリフォーム？＞
たひと いえいえ，そんなつもりはまったくないですよ。ソフトウェア保守は，建築でいうと「増改築」，今風では「リフォーム」ということになりますよね。
保品 確かにイメージとしては，その通りだと思います。
たびと 築20年の２階建て一軒家の北側の小さな窓すべてを，断熱性の高い出窓に変え，その窓のある北側の寝室を和風から洋風に変えるというリフォームを考えましょう。
保品 僕はまだシングルで，親と一戸建てに同居していますが，親もそんなリフォームの話をときどきしますね。暗に「早く結婚しろ」というメッセージにも聞こえます（笑）。
たびと そのリフォームで，既存の住宅の建築手法，老朽化の程度や現在の強度，可能な改築方法の候補などを見て，10年以上先を見据え，とりかえが必要な部分はどこまでかなどを調べることは，新築では考慮の必要がほぼないタスクだと見ることはできませんか？
保品 リフォーム作業のように，新築では必要のない既存の建物を調べる作業を，ソフトウェアの保守プロセスに当てはめれば，開発にない保守独自のタスクとなる訳ですね。
たびと ご認識合っていますよ。さらに今ある窓を撤去，壁紙や畳をはがす，それらを廃棄するといった作業は新築では必要ない作業ですが，新しい窓を取り付けたり，新しく壁紙やフローリング材を張る作業そのものは新築とほとんど変わりません。
保品 ソフトウェアの修正そのものの作業は開発と同じ部分があるからそれを使えということですね。でも，小修正だと開発工程のほんの一部しか当てはまらない？
たびと そこがこの国際規格ISO/IEC/IEEE 14764のすごいところだと私は思います。この規格で扱う保守は前も言ったように小修正だけでなくエンハンスも含むのです。
保品 システム全体の大規模な改修も保守として扱えるように修正部分は開発プロセスの全部，小修整の場合は一部を使えということですね。
たびと 「開発中心」の発想を捨て，ゼロベースで考えると割とすんなり入ってきませんか？ 私が住む200世帯弱のマンションは築30年です。もうじき3回目の大規模修繕ですが，今まで2回はそれぞれ億を超える修繕費を掛けて修繕しています。今回もその程度のお金は掛けて修正するようです。
保品 億を超える修繕費ですか？ 中にはそんなに金を掛けなくてもという居住者はいないのですか？
たびと やはり少しはいますが，修繕積立金の範囲内ですし，それによってマンションの価値が維持できるというメリットを理解しいる居住者が圧倒的で，メンテナンスはうまく行っていると思いますよ。
保品 話をソフトウェア保守に戻すと，様々なタイプの保守を経験すると新規開発にない保守独自のプロセスと，さらにさまざまな規模の開発プロセスの両方を経験できるということですね。
たびと そうです。そうです。保守担当の若手ソフトウェア技術者に「たまには開発経験をさせないと」と考えている管理者には，私は『余計なお世話だ』と申し上げたいのです。
保品 大規模新規開発の経験は本当に必要ないのですか？
＜大規模開発経験礼拝信仰は捨てるべき？＞
たひど 逆にその経験を無理にさせることが，ソフトウェア技術者育成にはもったいない，無駄の多い育て方だと私は思いますよ。
保品 でも，2～3年に渡るような新規開発の最初から最後まで経験するのは，めったにないことで貴重な経験だと正直僕は憧れてしまいます。
たびと どの立場で参画するかによりますが，若手がプロジェクトの全工程，全役割，全タスク，全機能を経験できることは不可能です。大規模になればなるほど役割が細分化され歯車の一部としてして参画がせいぜいの可能性が高いのです。
保品 それでも，大規模プロジェクトに加わることで，その難しさや必要なスキル，そして何より雰囲気は分かり，終わったときの達成感があると思いますが。
たびと それは単なる机上で考える，または外野から見るイメージだと私は思います。ソフトウェア技術者としてキャリアを積むなら，そのような2～3年は無駄が多いキャリア形成ですよ。
保品 大規模開発プロジェクトのプロジェクトマネージャになれる早道のキャリアアップならかっこいいと思うのですが。
たびと 大規模なシステム構築プロジェクトのマネージャを育てるにも小規模なソフトウェア保守案件の対応から，じっくり規模の大きな対応を経験させて育てた方か良いが私の考えです。
保品 一足飛びに大規模なプロジェクトに参画しても，ITスキルは身につかないし，地に足が付いた実力はつかないと仰るのですね。
たびと そうです。若手にずっとプロジェクト会議の議事録や調達仕様書ばかり書かせていても，実践的なスキルは身に付きません。逆にソフトウェアの保守案件は小規模でも，利用部門，運用部門，ハードウェア保守部門，パートナー会社，元の開発者，各工程の承認上長や品質保証部門など多くの人とコミュニケーションが必要となります。
保品 確かにそうですね。最初は，保守作業ではソフトウェアの修正設計や修正そのものに苦労するだけでなく，何でいろんな関連部門の人たちに怒られなければならないのかと僕は思ったくらいです。
たびと その経験が貴重なのです。システムの稼働を支えているさまざまな役割や重要性を知らないということは恐ろしいことです。怒られるということは，そのままの理解度ではダメだと言われているだけなのです。ただ，上司やリーダが若手に保守を丸投げするのは最悪です。寄り添ってケアをしつつ保守で育てることも忘れてはなりません。
保品 そういえば，僕の場合，短いスパンで何度も保守対応していくと，1年も経たないうちに，怒られることはほとんどなくなり，いろんな部門の方々の名前や役割を理解して円滑にコミュニケーションできるようになりましたね。
たびと 保品さんは，「開発善，保守悪」の考え方を捨て去れば，もっと対人能力を磨くことができます。保守をやりたくないと少しでも思っていると顔に出ますよ(笑)。
保品 相手は「今の仕事はやりたくないと思う人」を本当の仲間とは感じないということですね。
たびと 保品さんはもうすでに感じていると思いますが，ソフトウェアの保守は素晴らしい仕事です。もっと真正面から取り組んでみませんか？
保品 分かりました。「ソフトウェア保守中心」の考え方を周りが簡単には理解してくれるとは思いませんが，たびとさんのお話を参考にして，自分のソフトウェア保守に対する取り組み方の目標をもっと前向きに再検討します。1年後にまた僕の成長を見てください。
たびと 今日は長時間つき合ってもらい，ありがとうございます。現場に私の「保守中心」の考え方をできる範囲で適用してみてください。まだまだ「開発中心という凝り固まった天動説」の抵抗はまだ大きいでしょうが，実態のソフトウェア作業を中心に据えた「保守中心の地動説」がきっと認められる時が来ますから。私が生きているうちにそれが来るかはちょっと微妙ですが‥(笑)。またお会いしましょう。
（本対話終わり）