保守について学ぼうかと。
なお、ISO/IEC 14764を基にしたJIS X 0161は下記から閲覧が可能。
日本産業標準調査会：データベース-JIS規格詳細画面
ISO 14764は、ISOとIECのJTC1/SC7/WG7がISO/12207:1995 Information Technology - Software Life Cycle Processの中の保守プロセスについての詳細規格という位置づけで原案を作成し
p. 38
ISO/IEC 12207との関係を理解。
12207の主要プロセスの中で特定の主要プロセスについて詳細にガイドした規格が出ているのはソフトウェア保守プロセスのISO 14764のみです。
p. 49
これは知らなかった。本書が書かれたのは2007年だが現在でもそうなのだろうか。
ところで、共通フレーム2013では、保守コストを削減するアプローチとして下記2つの視点をあげている。
- 企画から稼働までの品質をさらに高め保守案件の発生数を少なくする
- ソフトウェア保守をいかに効率的かつ高品質に行うか
保守チームの場合には後者に目が向きがちだが、本質的には前者にどれだけ知見をフィードバックできるかが重要に思われる。
図3.4.2 ソフトウェア保守の戦略の目的
- 開発に比べて思い切った予算化・設備投資が難しい
- 費用対効果が見えにくい
- 保守要員の動機づけが困難
- 保守要員に対する特別な教育訓練が必要
- 不測の事態への対応が可能とする必要あり
- あらゆるケースを想定した保守の見積もりが困難
- ソフトウェアの寿命予測が困難
- 古い設備を維持する必要があり
- 保守は固定費扱いで経費削減対象になりやすい
→保守者にとってソフトウェア保守の戦略が必要
p. 73
これらはあくまで一例であろうが、保守について考えるべき課題が多いことは直ぐにわかる。
保守開発をおこなう部門は、新規開発のミッションをあわせてもった部門であったとしても、保守開発業務のために専任の管理者を置くことが望ましい姿です。その理由は、新規開発と保守開発の両方を見ている管理者は、納期が決められ、単位あたりの作業量が大きな新規開発の管理にどうしても重点が移ってしまうことが考えられます。保守開発プロジェクトは日常的な管理が重要になりますが、ある時期に長期間にわたり管理者が不在になると、思わぬ保守開発対応の不手際をおこす危険性が高くなります。
p. 96
「アジャイル時代」の考え方ではないのかもしれないが個人的には開発と生産は違うという立場に立ちたい。Facebookの提唱するsoftware engineering/production engineeringという区分がしっくりくる。
トレーサビリティ・マトリクス（TM）
p. 115
『XDDP』では｢トレーサビリティマトリクス(TM)｣で変更箇所を特定を参照のこと。
保守プロセスを確立することは、保守開発の組織体制が明確になり、構成する担当者の役割が明確になり、組織としてのSLAが明確になり、組織目標が明確になり、ここの担当者の目標やキャリアパスが明確になることを意味します。
次に、たとえ保守プロセスが確立されていても、組織や作業の進め方の健全性を測る指標のデータが定期的に採取されていないと健全性の変化を見ることができません。
p. 151
非常に基本的なことを述べているようだが、これが徹底できている組織は強いと思う。「健全性」などの言葉遣いが私の感覚とは異なり学びがある。なお、健全性を図る指標としてODC分析はなかなか見込みがあると考えている。欠陥分析手法でありながら、実際にはプロセスの評価をしている。
保守開発で必要な情報は、WhatやHowのほかにWhyという情報が必要です。
p. 155
最近思うのだが、Whyというときには「なぜそうなっているのか」というよりも、「なぜそれ以外ではなかったのか」という観点で文書を残すのが良いように思われる。現行の仕様のWhyはコードから推測することも可能だが、他のありえた可能性にならなかった理由はコードから推測が難しい。コード至上主義に対する反論の一つ。
やや話を一般化して、資本のメンテナンスということを考えている。金融資本はさておき、社会資本および人的資本は適切なインスペクションとメンテナンスによって価値を高めることができるようにおもわれる。社会資本のメンテナンスは例えばインフラの老朽化対策など。人的資本のメンテナンスは例えば人間ドックやリカレント教育など。
新規開発する経済的コストと比較して、安いということも当然あるだろうが、「希少資源の最適な利用」という経済学の目的からもより望ましい。
パタゴニアのWorn Wearなども思い当たる。
