変更が制御されていれば、みんなの仕事がうまくいく（「制御させる」は、「禁止される」と言う意味ではない）。開発者に直接働きかけるような顧客は、個々の開発者に特定の変更を依頼することで変更管理を回避しようとすることがある。これは悲惨な結果をもたらす。これは、プロジェクト管理を暗闇の中でやるようなものだ。コストはエスカレートし、要求仕様書を不正確にする。こんなことをやれば、一体どこまで事態が悪化するのだろう。
（２０１の鉄則：原理１８２＜製品保証の原理＝変更制御を抜かしてはいけない＞）
１年ほど前に原理１８１を取り上げたときも少し触れましたが、変更制御は、それが有効だと分かっていてもなかなか実現しないものです。実際、コンサルティングに入って、何とか部分的であっても変更制御を取り入れるように持っていくと、バグの数も半減し、バグの収束も早まることは確認できています。
ただし、そのような事が出来ていない組織にあっては、飛躍的な効果が得られるような形では簡単には取り入れることはできません。プロセスの最初から、プログラムのバグや仕様の変更の発生する動機を減らすような取り組みをしていないため、欠陥やバグが多発し、その状態で変更制御を取り入れようとすれば、作業が溢れてしまうからです。
それでも、テスト工程の途中からでもバグの修正にあたって変更制御を取り入れることで、完成後のバグは殆ど出なくなります。工期の短縮には繋がらなくても、後のプロジェクトの邪魔をすることは避けられます。混乱が常態化している組織にあっては、まずは此処からでも着手すべきでしょう。
変更制御が行われない理由に、「制御」という言葉から来る反発もあるようです。「管理」や「制御」と聞くだけで条件反射的に鳥肌が立つのでしょうが、これも困ったものです。それが顧客にとって必要でかつ有効な方法であるなら、その人が生理的に反応しようがしまいが関係なく取り入れられなければなりません。そうでなければ、同じ効果が得られる他の方法を持ってくるべきです。それもせずに、「制御や管理は嫌いだ」なんて言うことは許されません。自分の給料や報酬は誰からもらっているかを知るべきです。
このことは、別の視点から言えば、そのような「個人的わがまま」を指摘し説得できるマネージャーがいないことを意味しています。なぜそれが許されないのかが説明できないのでしょうか。これはこの種の「甘え」が通用している組織に共通しているパターンです。マネージャー自身も、現役時代（何年か前）に「管理や制御」を毛嫌いしていて、そのことの間違いに気づかないまま、皮肉にも今、マネージャーの立場についていたりします。現場のエンジニアも、マネージャーのそのような「隙」を見抜いて、「わがまま」を通してきます。こうなるとなかなか防ぐことはできません。
やはり、みんなの仕事がうまくいくために「制御」されるという発想が必要です。此処を直すだけで大丈夫だからと、勝手に直してしまうことで、他の人に迷惑をかけてしまいます。余程、“制御された組織”でない限り、そこで作られたソフトウェアは、期待するほどの性格の良いものではありません。まさかと思うところで、別の人に影響を与えます。プログラムの設計や実装、さらには修正の行為が何ら制御されていないのですから、どこで誰がどのような処理をやっているのか分からないし、分かる方法もないかもしれません。そのような組織に限って、変更制御を嫌がるのです。
もう一つ、変更制御がなかなか機能しない理由として、「一人作業」が考えられます。プロジェクトそのものが最初から一人にアサインされているような組織では、変更制御を実施することは容易ではありません。一方、見かけは「チーム」になっていても、その実態は「一人作業」のままという組織もあります。そこでも変更制御を取り入れることは難しいでしょう。
変更制御が出来るためには、その製品の仕様やプログラムの様子が分かる人が数名必要です。その仕様の変更は、そんな方法ではうまくいかないことを判断でき、そのための時間を割いてくれる人がいなければ実現しません。
ＣＣＢ（構成管理委員会）という組織を作っても、実態が「一人作業」で、そこで提案されている変更方法の問題を判断できる人がいなければ、結果は今までと同じです。変更制御を機能させるには、自分の時間をメンバーのために使おうという人の集団（チーム）であることが必要です。
一般に、変更制御というと、バグの修正に伴って行われるレビューのことと受け止められていますが、変更制御の出番はテスト工程に入ってのバグの修正だけではありません。要求や仕様の変更が発生したときも、勝手に担当者が判断して仕様を変更してしまうことは避けなければなりません。特に、要求分析の工程を過ぎて設計工程や実装工程に入ってからの仕様の変更は、影響範囲や修正にかかる工数などを判定しなければなりませんので、何らかの「制御」や「管理」が必要です。いわゆる「要求管理」というのは、要求や仕様の変更にともなうこのような変更制御を含んだものです。
変更制御は、こうした要求や仕様の変更だけでなく、設計書に対するレビュー（ウォークスルーまたはピアレビュー）で欠陥が指摘されて、その修正においても変更制御が必要になります。簡単なミスの場合は、そのヶ所を修正するだけで済みますが、機能を勘違いしていたりすると、作業の進捗状況によっては、その修正に他の人の領域にも影響を与える可能性があります。したがって、それをどのように修正するつもりか、それに関連してどこに影響があるか、影響範囲をどこまで検討したか、それにかかる工数とリスクはどの程度か、といったことが表現され、関係者で検討されなければ、その影響は何ヶ月か経って表面化することになります。その時、「しまった、あの時、構成管理を省いてしまったからだ」と思っても、後の祭りなのです。
このように、ソフトウェアの開発工程には、変更制御が入る余地は沢山あります。テスト工程でのバグにまつわるソースの修正に限られたものではないのです。それだけに、変更制御がうまく出来ることの効果は大きいのです。これが実現していない組織は、その原因を調べて、取り掛かりやすいところから取り掛かってください。まったく変更制御抜きで顧客の望むような品質を確保することは出来ないでしょう。
▲第一勧業銀行、富士銀行、日本興業銀行の３行が持ち株会社を作って業務を統合することで合意した。興銀が参加していたこともあって、報道もビッグニュースとして報道した。証券市場もこの種の好材料に反応しやすい状況にあったため、周辺の金融株まで買い進まれるという始末である。
▲もとより、多額の公的資金を投入したものの、日本の金融機関はまだまだその数倍の不良債権を抱えており、投入した公的資金を所定の期間内に返済できる見通しを持っている銀行はないだろう。返済が滞れば、その時点で国営銀行になってしまう可能性もあり、現経営者としては「後が無い」状態のはずである。
▲確かに、世界の金融界は、金融業のあり方の変化を受けて今大きく変わろうとしている。既存の概念は取り払われ、新しいサービスを打ち出せる体制を作るのに躍起になっている。単に資産規模を競って合従連衡を繰り返しているわけではない。時代の変化のスピードにあわせて、素早く対応するための体制を競っているのである。
▲この国のバブルの終演から約１０年が経過した。この間、日本の銀行は結局は自分では何も変革を進めることが出来なかった。金融機関の業務提携のアドバルーンは幾つも上がったが、手段と目的が繋がっていないため、実際には殆ど進展していない。今回も「手段」であるはずの提携や統合が、今まで同様に「目的」に化してしまうだろう。
リストラが横行している中、世の中では「自分」の事しか考える余裕はなくなっている。隣の人との競争は、共に高めるのではなく、ともすれば足の引っ張り合いになってしまう。親の心が荒れているものだから、子供の心も荒れてきた。「誠意」なんて言葉は死語になりかねない。
◆
でも私は「誠意」という言葉が好きである。中でも「誠意は夢床に兆す」という言葉が好きである。詩経かどっかにあったかと思うが、詳しくは覚えていない。佐藤一斎の言志四録の中にも出てくる。
江戸時代後期の医師で、片倉鶴陵という人が、漢方の難書「傷寒論」に取組んでいたが、どうしても分からないヶ所があって行き詰まっていたとき、夢に著者の張仲景が現れて、教えを受けたという自署が残っているという。もちろん、片倉鶴陵も実際には会ったこともない人である。そんなバカなと言う人もいるだろうが、私にはありそうな気がする。
私は、今はプロセスのコンサルティングをしているが、１０年余り前までは、システムを設計しプログラムを書いていた。その時の経験に、夢の中でソースリストが出てきてバグのヶ所が見えたことが数回ある。この経験は、私だけではなく、私の周りにも数人いることは確認できている。でも、この話をすると、多くの人（もちろんソフトウェア・エンジニア）は、「夢にまで見たくない」という。彼らには「うなされて見る」状態しか想像できないようだ。まるでプログラムと「格闘」しているかのようである。なんで言う通りに動かないのかと鞭を打っているのだろう。だから、夢にソースリストが現れるというのは、ソースの仕返しなのである。
◆
私はソフトウェアを作ることが好きであったし、変な話だけどプログラムを愛していた。不出来であっても、自分の「分身」なのである。だから欠陥のヶ所を少しでも早く見つけてやりたかった。欠陥の方も「早く見つけて〜」と待っているのである。にもかかわらず、その日は見つけることが出来ずに床につくことになる。夢に出てきたのは、いずれもそのような状況である。だから、片倉鶴陵の気持ちが分かるような気がするのである。
余談になるが、プログラムを書かなくなった理由の一つに、夢に見なくなったことがある。時間とともに自分に求められる役割が変化し、他のことに興味が移っていったこともあって、プログラム対する自身の誠意が弱くなったと感じたのである。論語の「甚だしいかな、吾が衰えたるや。久し、吾れ復た夢に周公を見ず」と言うフレーズが浮かんだのである。
◆
ところで、誠意には２種類ある。一つは他人（人とは限らないが）への誠意で、これは一般的に使われているものである。俗に言う「誠意を表わす」というのはこれである。
もう一つは自分への誠意である。実際には、後者が伴わなければ前者の誠意もウソになってしまうが、このことに気づいている人は少ないかもしれない。本当にやれるだけの事はやったのか？そう思っているだけではないのか？自分をごまかしているのではないのか？後で後悔しないか？と、自分に問いかけざるを得なくなるのである。
何か見落としていないかと、またソースや資料を開いて、昨日までと違った視点で眺めてみる。設計書の書き方も、もっと方法があるのではないかと工夫してみる。そうしないと気が済まないのである。
余りしつこいものだから、周りからは嫌われる。こんな私と一緒に仕事が出来る人はいないと思ったから、ずっと一人でやって来た。道元禅師は、この自己への飽くなき誠意を「老婆心」と呼んだ。そして弟子の一人に対して「おまえは老婆心がない」として最後まで叱り続けた。
◆
時代の中で自分を活かすということも、自分に対する誠意と考えている。誰のためでもない。あえて言えば自分のためである。その時になって、胸を張って人生を終わらせるために誠意と向き合う。
◇
だが組織という枠の中で、多くの人は自分を裏切ってきたかもしれない。誠意とはほど遠いことをやって来たのかもしれない。今、リストラという仕打ちが、その代償の請求書にも見えるのだが。 ■
「中小企業の社長になったつもりで考えろ。
彼らは自分が全責任を持って仕事をするから、
創意工夫がある」 井深大
コンサルティングをやっていて、しばしば考えさせられるのは、なぜもっと工夫しないのだろうということである。最初にもっと真剣に考えないまま着手するものだから、しばらくして破綻したり、やり直すことになる。その時の担当者の発想が、まるで他人事である。その上、予定を３ヶ月も遅れているのに何の工夫もしない。やり直しにかかる５００万円という費用は、一体誰が払うのか？
確かに、直ぐには自分の財布が傷むわけではない。だから事の重大さには気づかないのだろうが、そのような職場では、時代が変わっているのに、いつまでも同じやり方で、同じ手順である。だから時代に合わなくなっているというのに、そのやり方自身が問題だというのに、「当然」の顔をして、今日も無駄金を捨てている。
企業という組織の中にあっては、そのような金銭感覚はマヒしてしまうのか。特に「経費」という言葉が使われると途端にマヒする。「清水さん、それは経費で出るんでしょう」とよく言われる。確かに、会社としての経理をしている関係で「経費」で処理するとしても、その原資を稼いでくるのも自分しかいないのである。だから安直に「経費」を増やすわけにはいかない。
それどころか、納期が遅れたり、不良を出したらお金がもらえない。費用は余分にかかるからダブルパンチである。だから必死に勉強する。バグを出さない方法や納期を遅らせない方法必死に身に付けようとする。時代の求めるものを誰よりも先に手に入れようとする。その前提は「時間」の確保である。だからどうすれば残業や休出をしないで済むか必死に工夫する。家庭も壊したくない。
此処までやって来れたのも、誰にも頼れない環境であったことが大きいと思う。
［“ＳＣだより”のページに戻る］