[SCだより 99号]

(第17回)

  システムが置かれている環境は本質的に無限であり、完全に理解することは不可能である。システムを設計する際、その環境における問題を解決すると称してその環境について仮定をする。Manny Lehman は、「我々はコード10行につき大体1つの仮定を、あるいは、私の推測が2、3倍ずれていたとしても、最低コード20から30行につき大体1つの仮定をしている」という仮説を立てている。無限の世界についてこうした有限の仮定をすることはトラブルのもとになりかねない。Lehman は、期待通り動作しなかった線形加速装置の例について、次のように述べた。ある物理学者が月の位相が影響しているかもしれない、と主張した。もちろん、物理学者のこの突飛な提案に、他の誰もが冗談をいっているのだと思った。しかし、実際に月に関する要因を分析してみると、結果として作られた方程式は「おかしな」動作をしているように見えた原因の大部分を説明するものであった。これは、立てられた仮説(この場合は月の影響などあるはずがないという仮説)が無効であったよい例である。

 要求分析、設計、コーディング、及びテスティングの期間中に全ての仮定を意識的に立てることは不可能である。にもかかわらず、私は意識的に立てた仮定を毎日記録することを勧める。たとえ仮定が明らかに正しいように思えるものであっても、また、他に採りうる代案がばかげたものに見えても記録せよ。また、これらの意味、つまり、製品のどこに仮定がそれ自体明確に関わっているかも記録せよ。理想的には、各々の仮定をカプセル化することによって、こうした複雑な絡み合いを隔離したいものである。

(201の鉄則:原理20<一般原理=仮定を記録せよ>)

― 解  説 ―

 多くの関係者は、この「仮定」について殆ど意識していないと思われます。この「原理20」を読んでも、恐らく何のことか分からないのではないでしょうか。翻訳も少し回りくどいところがありますので、余計に分かりにくいでしょう。

 人は、そのことを少しでも考えたことがあるような場合、直にイメージができるのですが、全く考えたこともないことに対しては、イメージできないものです。

 「原理20」にあるように、システムのあらゆるものが「仮定」なのです。いや、要件だけでなく、開発の環境や要員も「仮定」なのです。そこから出発することが、優れたソフトウェアを開発する最大の条件であることを、目を反らすことなく見つめて欲しいのです。

要求はすべて仮定

  「仕様を早くFIXして欲しい」・・・これはソフトウェアの開発現場では良く聞かれる声です。しかしながら、そこでは「仕様は仮定」であることに気付いていません。それどころか、そんなことを言ったら「そんな曖昧な状態ではソフトウェアは作れない!」と声を荒げるのです。

 でも、良く考えてみて下さい。1日の伝票枚数はFIXですか? 入力の操作画面はFIXですか? その帳票のレイアウトはFIXですか? そのDBシステムを使うことはFIXですか? その経営分析の計算式はFIXですか? そんなはずはないことは、ちょっと冷静になって考えれば分かることです。

 これでは開発できませんか? FIXしてくれなければ作れないという人たちは、一体どのような「システム」を作ろうとしているのでしょうか?

 要求仕様書の中に、その要求が存在する理由や、ある仮定によってそこに書かれている内容になったことなどを、記録しておくことが求められることがあります。もちろん、求められなくても書けばいいのですが、そこは現実問題として開発期間などの制限から、理想的には進まないのですが、それでも、要件によってはそれを書いておくことは出来るでしょう。

仮定から高品質が生まれる

 そう! 「要求」は全て仮定なのです。仮定であるという認識が出来てはじめて、その仮定が安定している「寿命」が問題になるのです。100年安定しているのか。10年なのか。1年なのか。3ヶ月なのか。それが問題なのです。逆にいうと、もし1ヶ月の伝票枚数が、そこで明らかにされた枚数で安定している期間が3ヶ月であるとき、まるで10年間安定しているかのようなシステムを設計すれば、どのようなことが起きるか想像に難くないでしょう。

 1年も経てば、もっと使い勝手もパフォーマンスも優れたDBシステムが発売されるというのに、当面のDBシステムに対して強く依存するようなシステムを作ってしまったら、どうなるか分かるはずです。

 要求が仮定であると認識し、その安定の期間を見積もることによって、機能以外に隠れた部分で配慮の行き届いたシステムを作ることができるのです。つまり、保守性やポータビリティに優れたシステムを作ることができるのです。

作業も全て仮定

 仮定は何も要求に限りません。「原理20」にも「設計、コーディング、及びテスティングの期間中」にもあると書かれています。ある機能の実現に際して、なぜそのような設計をするのかというとき、そこには仮定が存在しています。このときの仮定には機能面だけでなく、開発時間やチームの要員の都合なども含まれます。ただ、殆どの場合、そこまで意識されないだけです。

 また、「スケジュール」の中にも、仮定が出てきます。工程の中で想定される成果物のサイズ(量)も、前回の事例など、何らかの仮定にもとづいています。そしてその作業に合計18時間必要であるというときにも、1時間当たりどれだけの生産性を発揮できるかという仮定から導きだされます。

 多くの人は、このような性質の仮定は意識せずに使っていることがあります。もちろん、仮定など全く使われることなく、“あてずっぽ”で見積もられることもありますが、それは悲しい結果を生むだけです。

 「原理20」は、このように用いられた仮定をすべて記録せよと言っているのです。

追跡されるのは仮定

 CMMのレベル1から2への取組の中に、「プロジェクトの計画」と「プロジェクトの追跡と監視」というのがあります。その中に「見積もりの根拠として使用した仮定を記述する」ことが求められています。つまり、計画の段階で、それぞれの成果物や作業の見積もりに使用した仮定を記録しておき、「追跡と監視」の中で、その仮定を検証するデータを収集します。そうして計画との照合が適時行なわれ、そこで仮定との食い違いが認められたとき、計画の見直しが行われることになります。

 一般に、計画には既に時間軸に変換された情報が書かれているだけであるため、作業の進捗に合わせて適切なデータの収集が行なわれることがなく、その結果、計画の見直しの機会を手に入れることが出来ないのです。

 計画の追跡で一体どのようなデータが手に入るでしょう。日数がオーバーしたことですか? プログラムのサイズがオーバーしたことですか? 勿論そのようなデータも入手できるでしょうが、それらのデータが手に入ったときは、大抵遅いのです。それよりも前に手に入るものがあります。それは「仮定」に用いたデータです。1時間に2ページ書けることを前提に20時間と見積もったものが、実際には1ページしか書けないことが判明したとき、直ちにスケジュールの見直しに入ることが出来ます。仮定を追跡することで、スケジュールを狂わす要因を早く手に入れることができるのです。

 スケジュールや、マイルストーンのリストに、成果物のサイズ(量)だけでなく、時間データに変換するまでに使用した仮定も記録しておくことで、簡単に約束できる重要なデータが手に入るのです。「原理20」には、とても重要な示唆が含まれているのです。


“SCだより”のページに戻る



 第82回

システムって?


 世の中、「システム」という言葉が溢れています。

 コンピュータ・システム、ソフトウェア・システム、運航システム、防災システム。最近では、金融システムという言葉も盛んに使われています。私たちは日常、何の不安もなくこの「システム」という言葉をそのまま使っています。そして何となく分かった気になっているようです。

     ? ◆ ?

 でも、「システムってなに?」と改まって尋ねられると、なかなか上手く答えられません。かく云う私も確信があるわけではありません。「システム」を辞書で引いてみると、組織、系統、体系、制度、方式、順序・・などという訳が載っているます。でもどれもしっくり来ません。「金融システム」というとき、それは「金融体系」でも「金融制度」でもありません。もちろん、方式や順序でもありません。

     ? ◆ ?

 「金融システム」と云うとき、そのような静的な「形」や「制度」をイメージしているのではありません。「システム」を構成する“もの”が連携して“動いている姿”を想像して使っているのです。そのシステムを構成する要素が、そのシステムの目的にそって有機的に機能しあう仕組みとして使っているのです。だが、それを表現する適切な言葉が日本にはないのかもしれません。だから「システム」という言葉が日本語にならないでそのまま使われているのでしょう。

     ? ◆ ?

 適切な言葉が存在しないということは、その「もの」を理解できないという可能性があります。「金融システムを守るため・・」と云われたとき、守られる「金融システム」とは何か? 預金者でもありません。「預金者」は金融システムを構成する要素の一つです。では金融機関かというと、それも単なる一つの要素です。預金者よりは、中心に位置しているのですが、それ自体、直接に公的資金を投入して守られるべき対象ではありません。もちろん結果として守られるかもしれませんが、それは「金融システム」を守り、運行していくうえで、有効な役割を果すと認められたからに過ぎません。

     ? ◆ ?

 このシステムという「見えないもの」が、国民の共通の認識として存在していないため、最初は、「金融システムを守るために預金者を保護する」と言っていたのが、一週間も経たないうちに「金融システムを守るため公的資金を投入して金融機関を救済する」というように変わってしまうのです。

     ? ◆ ?

 サッチャー政権下での「ビッグバン」という政策も、アメリカでの「S&L」の行き詰まりに伴う公的資金を投入した政策も、さらには、北欧だったか記憶は怪しいが、金融機関を一時的に「国有化」するという政策も、それぞれの国に於ける「金融システム」の意味や役割を知っているところから出てきた、その国に適った政策なのです。したがって、それぞれがユニークな選択なのです。

     ? ◆ ?

 「金融システム」と一言でいっても、その役割や存在は、それぞれの国によって異なります。つまり、「金融システム」はその国の経済システムの中に組み込まれていて、その中核をなす「部分システム」でもあります。そのため、「金融システム」に課せられた役割もある意味ではユニークなものです。そのような状況のなかで、守らなければならない「金融システム」とは何なのかということです。

     ? ◆ ?

 単に預金者が預けたお金が確実に保証されるというだけでは、金融システムを守ったことにはなりません。取り戻したお金がそのまま「箪笥預金」に回ったのでは、それこそ「金融システム」は崩壊してしまいます。保護したはずの預金者によって「金融システム」が崩壊したのでは、笑い話にもなりません。

 同じように、「金融システム」を守るために、公的資金を投入して金融機関を救済したとしても、預金者がその金融機関を避けて通れば、投入した救済資金は、そこで凝固してしまい回収不能となってしまいます。云うまでもなく「金融システム」は崩壊します。

     ? ◆ ?

 いわゆる「金融システム」を取り巻く環境は、国民性や文化が違う以上、国によって全く違うといっていいでしょう。にもかかわらず、この国は他の国の方法を真似ようとしています。表面的には似ている「システム」でも、それを支えているものは大きく異なります。それを見ずに「制度」が似ているということに目がいってしまうと、判断を誤る危険が高くなります。

     ? ◇ ?

 どうやら、この国は「システム」という“見えないもの”が分かっていないのかも。         ■


“SCだより”のページに戻る

 (第99号分)

「盛衰の理(ことわり)は天命というと雖(いえど)も、豈(あに)人事にあらざらんや」 欧陽修


 欧陽修は、宋代の名宰相の一人であるが、直言が災いして、余り活躍のチャンスに恵まれなかった人である。最後は、王安石と対峙して下野した。だがその見識は高く、この人の書物を読むと背筋が伸びる思いがする。

 確かに、会社や国の盛衰は、大きな時代のうねりの中で、抗いきれないものがあることは否定しきれないように思われる。石油などの天然資源によって成り立っている国は、それが有限である以上、そのままでは資源の枯渇と共に衰えていかざるを得ない。国民経済に頼り切った国は、そのままでは経済がグローバル化する中で、衰えていかざるを得ない。逆に、人材以外の資源を見出せない国であっても、グローバル化する経済の要求に合わせて対応することで、国を盛んにすることも出来る。

 全く同じことが企業にも言える。膨大な資産を有し、隆盛を誇った企業でも、状況の変化と対応の仕方次第では、その資産が負担となってしまう危険がある。

 結局、その局面を切り抜けていくのは、王陽修の云うように、人事しかないのである。優れた人を見つけ、彼を適切に配することある。GEが100年も「一流」であり続けた理由は、人事以外に見出せない。ノキアが100年の眠りから目覚めて蘇ったのも、人事以外にその理由を見出せない。人事と云っても、何もトップの人事だけに限らない。現場に近いところの人事も、どれだけその役に相応しい人を確保し、その人に権限を与え配するかによって、企業は生きもし死にもする。

 だが、現実には相応しい人を探す努力をしていない。また育成する努力もしていない。このことだけ見ても、この判断をする立場にいる人が、正しい人事に基づいていないことを意味している。本当に企業を再生しようと思うのなら、「真剣な」人事を行うべきである。


“SCだより”のページに戻る