注意

この記事は自らの読書体験を可視化するためのものです。記事タイトル内にある本の内容を正確に描写することは保証しません。

記事を書くきっかけ

本を読む作業は身になるが孤独なので、自分の体験を可視化することで情報発信になれば良いと思ったため。

記事の概要

タイトルの本全体および、章について自分なりのまとめを書いていく。
その後、章末の「練習問題」を解くようにした。

本の大まかな内容

ソフトウェア開発における品質と生産性向上のための環境をどう作るかについて書かれたもの。全４巻のシリーズ構成となっており、この本は４巻目である。前３巻までで解説した管理ツールとしての考え方を用いて、組織に健全なエンジニアリングマネジメント（本では工学管理と称していた）を将来にわたり継続できるようにするための方法を述べている。

12章の大まかな内容

この章では、プロセスについて述べられている。プロセスとは、ウォーターフォールやアジャイルなど、ソフトウェア開発を進めるための方法論のこと全般を指している。

著者は本章で、良いプロセスに存在する原理原則、つまり「プロセス原則」を述べることで、どのようなプロセスを実施すればよいかについて指針を示そうとしている。

プロセス原則は以下：

安定性原則 - 安定したフィードバックを得られるようにする
可視性原則 - プロセスはすべて、いつも見える状態にする
可測性原則 - プロセスを制御できる状態にするため、何を測定するか決める
ソフトウェア工学第0法則 - 要件を満たすために管理がある。満たす必要がなければ管理はそもそも不要である
製品原則 - 製品はプログラムかもしれないが、プログラムは製品ではない。製品とはソフトウェアが提供する利便性などの「価値」そのものを指す。
大当たりテスト - そのプロセスが無作為よりマシになることがなければ、使うな。

各原則の相互作用については以下のように捉えている。矢印の伸びる元の要素が増加することに比例して矢印の先の要素も増加する。

要件が明確であればあるほど何を計測するかが分かりやすくなり、計測できると安定したフィードバックが得られる。可視化もしやすくなり、それがまた可測性を助成する。わかりやすいフィードバックを得て開発プロセスを見える化すると、製品の価値についての理解が深まり、より要件がクリアになっていく。良いスパイラルとなる。

練習問題

問題１

この章に挙げたキーとなる言いまわしに聞き耳を立て、ノートに記録し、1日に何回耳にするか調べよ。そのリストを使って自組織の文化パターンを評価せよ。

問題解説

この章には原則を違反した場合によく聞かれる言い回しがリストされている。そのリストをチェックすることで原則に違反していないかを確認することができる。

自組織の文化パターンというのは、このシリーズの１巻で紹介された。

ソフトウェア開発チームの文化を6つのパターンに分けたもので、パターン5がもっとも高品質で高い生産性を発揮でき、数字が小さくなるにしたがってその程度は低くなる。もっとも質が低いものはパターン0である。

自分の回答

リストをチェックしていて気になったものがいくつかあった。

「もちろん十分ではないが、ともかく開始しよう」
- 安定性原則に違反している。要件定義や基本設計でよく聞こえた。「詳細は後で決めるとして、とりあえず始めましょうか」といった感じ。クラス設計のインタフェースを基本設計で決められずに詳細に持ち越したり、品質の決定権が顧客に無かったために要件が曖昧なまま基本設計に持ち越したりした。その結果、クラス設計のインタフェースは詳細設計で大幅に変わってスケジュールが遅延し、要件が曖昧な機能はシステムテスト後に削除された。
「それは全部彼の頭のなかにある」
- 可視性原則に違反している。これは、実装工程で切羽詰っていたときに自分がいった台詞だ。「自分の頭のなかにはあるんですけどね。。」といった感じで。雑な設計のツケでインタフェース矛盾が発生し、ほかのメンバーが担当していた機能は修正しなくてはいけなくなったが、自分もスケジュール遅延でいっぱいいっぱいになり、ほかのメンバーは途中から合流したので何を修正したらいいかわからず、だ。忙しいときほど可視化するようにしなければいけない。
「プログラムが完了するまで、我々はサービスを確認できない」
- 製品原則に違反している。ソフトウェアは顧客だけでなく、運用部門の人も使う。当時担当したシステムが国の組織に提出する帳票作成システムだったため、作成できないと組織側の人間も確認ができない。帳票なら、様式をデータパターンを先に洗い出して早々にチェックしてもらうこともできたのではないか。

問題２

読者の工学プロセスにおいて、明示的には含まれていない製品要素のリストを作成せよ。実際にどんなプロセスを用いてこれらの要素を作成しているか、またどんな種類の品質を生みだしているかを吟味せよ。

問題解説

製品原則をチェックするための問題だと認識している。よくいう「非機能要件」のことではなく、IT、ソフトウェアに関係していない部分（運用体制や保守体制など）について、どう考えているかを質問しているのだと思う。

自分の回答

保守体制の確立
スピーディな顧客フィードバックのための運用
顧客価値の創造

をリストとして考えた。これらの要素を作成するプロセスとしては、特に意識してやっているということは無かった。保守体制を作ることは現業の範疇を超えることという理由でやっていなかったので、反省した。

「保守しやすいプログラムの作成やドキュメント化の推進」は、いちプログラマとして、出来る範囲で常に心がけていたが、顧客価値の創造や、スピーディな顧客フィードバックのための運用というのは、WBSで管理して実行したことはない。顧客価値の創造に至っては、開発者同士で会話したことが設計レビューや実装のときにあったくらいで、正直、畳水練というか、ユーザアンケートをしたわけでもない。開発者の自己満足であったように思う。

どんな品質を生み出しているかというと、使う側に対しての用途提案ではないか？と思う。

上に挙げたリストはすべて、「安定的にユーザの使い勝手を改善するため」の施策なので、作る側の目線だけでなく使ってもらって便利だと感じてもらえるような、使い勝手の良さがここで挙げた品質なのだと思う。

問題３

SEI成熟度モデルのレベル５と査定された最初の組織である、ローラル・スペース情報システム社によるプロセス改善モデルの以下の要点はどのように本章のプロセス原則と一致するか？

プロセス特性の適切な尺度
現行プロセス特性についての不満を創出する環境
プロセス特性改善にやる気のある従業員
プロセス改善の権限を与えられた従業員
プロセス改革の現実的な生起
改善した特性を監視するタイムリーな計測

問題解説

上記の要点がどのプロセス原則と一致するかを考える。

自分の回答

プロセス特性の適切な尺度
- 可測性原則と一致。進捗完了が100%をとしたら良いのか1000%としたらいいのか、アクションを起こしやすいように決める。
現行プロセス特性についての不満を創出する環境
- 「大当たりテスト」に一致する。いまのプロセスが無作為より劣るかどうかをテストし、劣るなら改善するか止めるかを選択する。
プロセス特性改善にやる気のある従業員
- 可視性原則と一致。成果物の状況を見える状態にするために努力を惜しまないようになると思う。
プロセス改善の権限を与えられた従業員
- 製品原則と一致。ソフトウェア以外の部分について、WBSで管理しながら実施できる人物となりうる。ソフトウェア以外の部分は担当部門が違う人であったりするので、その調整はまた上位の権限を持った人物が行うほうが良いかもしれない。
プロセス改革の現実的な生起
- 可視性原則と一致。どんなものでもレビューを通らなければ客観性が欠けたものとなりうる。潜在的な欠陥を埋め込む可能性が高まる。
改善した特性を監視するタイムリーな計測
- プロセスの安定性と一致。フィードバックを早く出来れば立て直しがしやすい。

問題４

「”ジムだけがその中身を知っている人物だ”というような理由で欠かせない人物は誰であれ追い払え」というのは良い助言だが、ほとんどの人々はその方法を知らない。それによる知識喪失の結果や、その人物が放逐されたとき何をしでかすかが怖いのでなかなかそうできないが、ちょっと考えてみればその恐怖心は軽減できる。そのような人物を取り除き、知識の喪失、仕事の喪失、そしてその人物がとるかもしれない破壊的行動を防御する計画を策定せよ。この計画についての知識は、実際どのように誰かをレイオフしなければならない状況を予防する役に立つか？

問題解説

可視性原則を達成するための問題である。「属人化は悪」と自分もよく聞くが、ではいったい何が悪なのか？

自分の回答

一般的に考えると、属人化が悪なのは知識の集中によってその人物が権力を握ってしまうからでは？と思う。抑止方法を持たない権力は暴走しやすいので、悪だと言える。

権力集中を防止するためには、まずその人しか分からない状況を防ぐために、文書化とそのレビューを徹底する。設計書だけではなく、補足文書や図などを用い、可視化を徹底する。設計書には「プログラムの実現方法」が書いてあっても「なぜそれを実現するのか」について書いてないことが多いため、ブラックボックス化しやすくなってしまう。特に詳細設計だと「なぜ」は殆ど書かれないので、「なぜ」を文書化するようにする。

また、仕事は一人に集中しないように敢えて分散させる。出来る人にどんどん任せたいのは自分も同じだが、これだと一人に負荷が集中しすぎてチームが成長しないし、出来る人は不満を溜め込むだけだ。出来る人に新人を付けてスキルトランスファーをしつつ、チーム全体の負荷状況はWBS（で出来るかわからないけど）で監視する。

周りが気にしてあげるのはもちろん大事なのだが、「結局は自身の発信が無いと周りも動けない」なんてこともあるかもしれない。なので、常にメンバーには自身の状況を客観化するための時間を計画に含めるようにしたほうが良いと考える（一日8hが業務時間だとすると、そのうち1.5hくらいは自身の客観化の時間に充てられるようにしても良いと思う。極端なことを言うと、仕事の時間なんて一日4hくらいのペースでも良いと考えている。そうしないと自分の知識をアップデートする時間が確保できない。）

チーム全体の力を底上げできれば、権力集中も起こらないし、負荷が高くなって燃え尽きてしまう人もいなくなるし、なによりも心理的に安全だ。わざわざ危険な思いをする人はあまりいないと思う。自分も、すぐ近くにとても刺激があって面白い場所があるなら、遠くに離れることはしない。

問題５

読者の組織で、無作為より悪いつまり大当たりテストに失敗するプロセスを一つ以上同定できるか？そのプロセスをすぐに無作為プロセスで代替するのを何が妨げているか？

問題解説

無作為に取り組んだほうがマシなプロセスには、例えばクレーム処理のケースがある。一番うるさいクレームをいう顧客から対応してしまうようになると、クレームさえ上げればいいのだと相手に思わせてしまい、プロセスを最適化することができない。

自分の回答

年功序列制度が一番に思い当たった。

年が上だからといって管理能力が高いわけではないと思うし、管理は専門技術であり体系化された訓練が必要だと思うので、人生経験が長くても管理能力とは関係ない。ただ、人生経験を重ねると人は謙虚になっていく傾向があるので、他人の話を聞くことに抵抗がなくなることはあるかもしれない。

妨げているのは、道徳教育？まで言っては大げさかもしれないが、「そうなっているから」「そういう決まりだから」という理由で変化を嫌っているのが大きい。自分もそうだが、本当に変化は億劫だと感じる。今の状態に不満を持っているわけでも、具体的な危機感を持っているわけでもなければ、自分も変化したくないのが本音である。