ソフトウェアの維持管理(改造)はコワイという話

on


昨日、リーンカンファレンス2014 〜ヒット商品を作るための仮説検証プロセス　- 日本でリーンを進化させる -　〜に行ってきたのはこのブログに書いたですが、そこであった講演の中の“【派生開発をリーンにするXDDP】”が妙に気になっていたんですが、その理由は一番最初にした仕事がそのタイプだったから、です。


いやー、最初って大事ですよね。彼女も、仕事も。それに依存するわけではないですけどいつの間にか染まっちゃいますもんねぇ、ダンスィだって。


大体、初めての経験はその体験がどうであろうと無理矢理でも成功体験にもっていきたいじゃないですか。こうやったから成功したとか、やり遂げられたとか。仕事のやり方なり、漢書との付き合い方なりがそれを基準軸というか評価基準の方が表現的に適当かもしれないけれど。


“派生開発”とは“維持管理”です
講演者の清水氏の話からだと、

  • 派生開発は従来“改造”と呼んでいたもの
  • 対象は組み込み系やパッケージ
  • 新規開発が済み、システムを変更する“母体”となるソースコードが存在する


あぁ、そうですか。確かにワタシが初めて仕事したのはワンボードマイコンに載せたプログラムの改造でしたね。ドンピシャです！


で、母体となる最新のバージョンのソースコードをそのまんまコピーして、別の用途向けにシステム変更していたんですね。ナツイ。勿論、その頃は“派生開発”なんて言葉ないですから、先輩エンジニアから言われた仕事の説明は「嫌かもしれないけれど“維持管理”なんだ。でも“改造”も面白いよ。」だったような気がマンモスするんだなぁ。


“改造”や“派生開発”は組み込みばかりじゃないですよ
その後、巡り巡って金融公共セクターに移ったときの大規模開発の線表(マスタースケジュール)を見たときは「へー。」って思いましたね。リプレースのプロジェクトなんですが、その基本となる開発線表を作っている途中から二次、三次開発がもう予定されているんですよ。「へー」って思いましたね。


“改造”や“派生開発”の怖さ
単純に怖いですよ。コワイ。何が怖いかって、アレとソレです。アレは、構成管理。ソレは見積もり。


構成管理は、ほんと厳格にやらないといけないんですね。基本開発の線表で開発してある工程まで進んで来ているのに追加要件とか仕様変更とか長期的な不具合対応とかそうしたもろもろの変更で基本開発に乗れない個別案件を別の線表の要件として括りだすわけです。


でも、中の人は増えれば幸いですが、進捗している工程の作業規模で役割分担するわけで。そうすると基本線表を考えている人もいれば、二次開発などの仕様を顧客と調整している人もいるわけです。


さて、なにが起きるか。基本線表の開発のドキュメントの上から二次開発のドキュメントの上書きとかですよ。ぞっとしますね。構成管理されていないと。


まぁ、二次開発に着手できるように見積もりが済んで合意されていればいいんですが、その二次開発などの見積もりが危ないというかコワイ。


変更要求に対して、影響範囲の調査がきちんと＝漏れなくできればいいんですけどね。それ、母体となる基本開発の使用を分かっている人がいないとチョー危険ですよね。増してや、お金が絡むシステムとか人命に関わるシステムだと洒落になりませんし。


その変更要求の影響の仕方も、“新規機能追加”と“変更”があるわけです。まだ、新規機能追加はカワイイです。はい。追加する機能なので独立してインタフェースが確保できるから。でも、変更はそうはいかない。母体を正に改造するんですからね。


先の講演では、そうした変更要求の影響ヶ所の洗い出しに“トレーサビリティマトリックス”と呼ぶ直交表を作っていましたね。経験したプロジェクトでも同じようにやっていました。10年以上間ですけど。


行が変更要求、列がインタフェース、ストア、機能を並べて。で、どこを変更対処として設計見直しをするのかを明らかにする。


で、結局何が怖いかって言えば、ドキュメントが最新化されていないとドキュメントから影響範囲を追えなくなっちゃうんですよ。これコワイ。ソースコードから仕様を起こしてくれればいいですがそれもあれですよね。事後対処というかその場凌ぎと言うか。ワタシ的には上流設計から特定していきたい。上流からMECEにここは範囲外、あたり、とかしたい。そうしないと漏れちゃうもん。変更の仕様を掴みたいのにソースコードを読むんでは視野がプリミティブになってしまうから、考慮漏れが必ず発生しそうで好きじゃないなー。


でね、基本開発の設計者がいなくなったら、なんでそんな設計になっているとかコードになっているのとか想定できないじゃないですか。それがコワイんです。


あと、そこもコワイんですが、見積もりがコワイ。影響範囲の特定誤り、影響調査を作業工数に入れられるか、仕様レビューを何回で通せるかとか、リグレッションテストの工数の見積もりの規模感とか品質の確保の考え方とか。顧客からは小さくしか見えない変更でも母体の品質を維持するための工数ってものすごく必要なんです。でも中々難渋するんですよね、合意に至るのが。


あと、潜在バグがね、するんですよ。「コンイチワ！」って。