この世界で１０年も仕事をしている人なら、要求項目毎に番号を付けることが有効なことは容易に想像できるでしょう。しかしながら、それを実際にやっている開発組織は、いったいどれだけあるでしょうか。
もちろん、この考え方を大胆にも否定する人はいません。そのような組織には、この案を否定できるような材料は持ち合わせていないでしょう。多くの開発組織では、否定はできないけど実施も出来ないのです。
現実には、番号をどのように付ければいいのか分からないだけでなく、要求そのものが明確に示されていません。その上そこで示された要求は曖昧で、すぐに形を変えてしまいます。
このような事が、要求項目毎にユニークな番号を割り振るという行為を妨げているのです。そして、ソフトウェア開発作業の一番最初の工程が野放図に行なわれている状態では、この後の工程において秩序だった取り組みは望めません。ですから、この原理５２が実施できるように、逆に要求の出方も変えなければなりません。
全ての要求項目に番号をつけるといっても、連続番号で付けるわけにはいきません。作業が一人ならそれも可能かも知れませんが、ある程度の規模のシステムになれば、要求分析は数人で行なわれるでしょう。そのような状況において、「連続番号」では作業は進みません。それに途中での追加や削除あるでしょう。
そのような場合でも作業をスムースに運ぶために、システムの機能を適当なカテゴリに分割して番号を割り振るとよいでしょう。例えば３桁の要求番号の最上位の桁がカテゴリを表し、後の２桁がカテゴリ内の連続番号と言うように。システムの規模によっては、もう一段の分類コードを設けても良いでしょう。これよって、作業を分担することが出来ます。
要求につけられた番号は、一度レビューされた後はプロジェクトが終了するまで変えないことが重要です。
カテゴリによって番号が大別されていることで、要求が追加される場合は、そのカテゴリの最後尾に加えられ、削除の場合は、その番号は「欠番」として扱われます。また既存の要求に関連して追加される場合は、要求番号を階層化して対応し、前後の無実の要求項目の番号に影響を与えないようにします。実際に設計を進めていく過程でも、要求が細分化されることがありますが、そのような場合でも、前後の要求に影響を与えないで対応することが出来ます。
システムの開発には、新規開発と保守開発があります。一般に各種の分析設計手法で述べられているのは、殆どが新規開発用です。新規開発の場合は、要求項目も多く、最初から全体に亙って設計が進められるため、要求仕様書に記述された要求項目は、幾つかの設計書の中で“参照”されることになるでしょう。
新規開発でも保守開発でも、一つの要求が実現されるためには、いくつものタスクやクラスの協力が必要ですが、新規開発の場合は、一つのタスクが設計されるときには、最初からいくつもの要求に応えることを想定しています。
しかしながら、保守開発の場合は、部分的な変更であったり小さな機能の追加であることが多く、そのような場合には一つの要求ごとに、その実現方法が検討されます。
（なおこれ以降は、話を分かりやすくするために、保守開発の場面に絞って話を進めます）
たとえ１年もの工数をかけて開発したシステムも、一般にはその後何年もの間、保守開発に回されます。しかも、１回の保守開発に投入される期間は、新規開発の時の数分の１です。当然、それなりの進め方を工夫しなければなりません。
新規開発と違って、保守開発の場合は、ベースモデルに対する「差分」として要求項目が認識されます。この要求「差分」をカテゴリ別に分類してユニークな番号を割り振ります。保守開発の場合は、時にはこの「差分」が５０〜１００個程度に収まる場合もありますので、それ程困難な作業ではありません。
また、現実問題としてベースとなるシステムの設計書が（最初から）存在しないこともあります。というよりも、このようなケースの方が多いのではないかと思われます。そして、多くの開発組織では、事前に“設計書が書かれていない”ことが、次の保守開発の作業に於いても、変更設計書を書かない理由としています。
しかしながら、「差分」による要求項目の把握は、必ずしもベースとなるシステムの設計書が無くても可能です。実際問題として、そのような組織でも、プログラムの変更作業は行われているのですから。それはベースモデルが担当者（関係者）の「頭」の中にあるからです。
したがって、ここで「差分」の要求項目が記述されれば、「差分」として示されている要求内容をレビュー出来るはずです。
変更要求が「差分」で番号付けされていることで、『鉄則』にも書かれているように、このあとの設計作業もこの番号に対して行うことができます。
新規開発の場合と違って保守開発の場合は、一つの要求に対して、“どのようにして実現するか”“どのタスクのどのモジュールをどのように変更するか”という「設計」を書くことが出来ます。
もちろん、要求によっては複数のモジュールの修正が必要でしょうし、時には複数のタスクにまたがることもあるでしょう。製品レベルの機能が、必ずしもシステム内部のタスク構成の枠と一致する訳ではありませんから。
ただし時間の制約等で、全ての要求に対してこのような変更設計を書くことが出来ないかも知れません。それでも幾つかの要求に付いては、「独り善がりのリワーク」に陥らないためにも、確実に設計書を書くことが求められます。
もし、要求の案件によって、設計書を“書く／書かない”という選択が行なわれる場合は、「差分」要求をレビューした際に決めておくことが重要です。後になって“時間がないから”という理由で妥協すれば、その穴はどんどん大きくなります。
こうして要求が番号付けされることで、テスト仕様書も設計と同じようにこの番号を使うことは難しくありません。そして、更には不具合の対処の祭にも、この番号は威力を発揮します。
保守開発の場合、要求の実現方法（の設計）を間違えた結果“不具合”となって表面に現れたわけです。要求がなければ、不具合も発生しません。
この不具合の発症の仕組みを解明し、対処の方法が考えられ、それによって処置されたとしても、今までのやり方では、精々「不具合報告書」に対処方法が記述されるだけです。つまり、要求実現方法の“訂正された部分”だけが、不具合報告書に書かれますが、その不具合報告書には、その要求の実現方法を全部記述されている訳ではありませんので設計書の代わりにはなりません。
もし差分要求に基づいた「変更設計書」が書かれていれば、このような不具合の対処方法は何れかの「変更設計書」に収まるはずです。それによって、その変更設計書は、当該要求の実現方法を記したより完全な設計書となるのです。
何れにしても、要求項目に上手く番号を付けることが全ての始まりです。 （次号へ続く）
最近、さすがに変化のスピードを感じることが多くなった。特に経済ニュースを見ていると、動きが早い。
通信事業と放送事業の区別もなくなってきた。日本ではまだ区別されているが、ユーザーから見れば情報の方向の差だけである。それに合わせるように小売業の形態も多様化してきたし、広告産業も手段を多様化させている。この変化を支えているのは、産業そのものが、ハード依存からソフト依存へ切り替わったことが大きい。
今後一年余りでイリジウム計画が稼働すると、世界中何処にいても一対一で通話が出来る。トンネルにでも入っていないかぎり電波が届かないという事はなくなる。
ＧＥのＪ．ウェルチ会長が、次の時代においてもトップであり続けるために、「バウンダリレス」「スピード」そして「ストレッチ」という三つの目標を打ち出したのは有名だが、この「スピード」というのは「決定のスピード」です。現場の労働者に、持ち場の移動は駆け足！というわけではないし、二倍のスピードでキーを叩け！と言っているのでもありません。早い判断、素早い決定が求められるということです。そしてウェルチはドラスティックに組織の形を変えてしまった。
組織の形は、情報の共有の仕方に深く関っている。これまでの組織の形は情報の経路でもあった。下からの収集だけでなく上からの伝達も、その組織の経路が使われてきた。しかしながらパソコンとネットワークの普及によって、情報の伝達が組織の経路に依存する必要はなくなった。組織の壁を越えて縦にも横にも、上からも下からも、同時にしかも瞬時に流すことが出来る。そうなると、組織の機能から情報の伝達という役割が消え、判断、及び決定だけが残されることになる。
ウェルチは一○年前にこの変化を素早く見抜いた。そして巨大な組織の階層を六段も抜いてしまった。意思決定に一○段以上もの階層は必要ない。社員が一○万人いようと、意思決定に一○段もの階層が必要なはずはない。
もし、五段以上の階層が必要だとすれば、その組織は相変わらず情報の伝達が組織の経路に依存している証拠だ。せっかくコンピュータ・テクノロジーを使って、社内にネットワークを張り巡らしているのに、情報の伝達が、相変わらず組織の形態に縛られているとしたら、それはバカげているとしか言い様がない。それではネットワークが紙に置き変わっただけではないか。
組織の役割から情報の伝達という機能が消えたのだから、それに合わせて組織の形態も変える必要があるし、組織の形態に依存している評価や報酬の基準も当然変わらなければならない。しかしながら、どのような組織の形になればいいのかというとき、適当な雛型がないのも事実です。当面は情報の伝達を組織の拘束から解いておいて、収まるところを見るということになるでしょう。
判断や決定を早くするということは、レスポンスを早くすると言うことであり、そのためには判断に必要な情報を収集するスピードを早くするということである。出張でその情報に触れるのが３日遅れたと言うのでは話にならないのである。
またレスポンスが遅いということは、判断に必要な情報がその時点で入手できていないと言うことです。そのためにどうしても「会議」を開いてしまう。今や会議は情報の収集の場ではなく、決定の場にならなければ間に合いません。したがって、関係者は会議までに必要な情報の収集を終えていなければなりません。また、それが出来る環境でもあるのです。
情報の収集と発信は表裏一体でもある。情報は発信しないかぎり集まってこない。発信するものを持たないかぎり新たな情報は集まらない。会議に招集され、そこに行けば取りあえず情報が与えられるという姿勢とは一八〇度逆である。
最近、社内のネットワーク環境で個人でホームページを作る動きもあるようですが、継続して発信する情報を持っていなければ続かなくなります。もし発信する情報が途切れると、ホームページを更新する間隔が開いてしまうでしょうから、それを自分に対するシグナルとして捉えることです。
若い人は、今までの組織の壁を破って、素早く情報をやり取りすることです。組織が反応するのを待っていては間に合いません。第一、求められているのは「創造的破壊」であり、そのパワーです。あなた達が次の時代を作るのであり、組織の形はそれに合わせてしまえばいい。
組織は決定のスピーどを支援するものであり、それを阻害するものであってはなりません。 ◆
この国は余りにも歴史を蔑ろにしてきました。自らの歴史を忌み嫌うかのように蓋をして避けてきました。私も戦前の教育については、ここで何か言えるほどには教えられていませんが、少なくとも戦後の教育の中で、「歴史」については蓋をしてきたという印象を受けています。たとえば先日の「三十五円」の問題についても、一体どれだけの人がこのことについて自らの意見を述べることが出来るか疑わしい限りです。私も、そのことについて意見を述べるための材料を持っていないのです。
一般に歴史といえば、政治史のこととして捉えられていますが、文学や思想にも歴史があります。しかしながらどうやら「歴史」と名の付くものは殆ど同じように省みられていないように思われます。
私なりに先の選挙の結果に対する答えを求めて、丸山眞男の「文明論の概略を読む」を読む機会がありましたが、それを見て愕然としました。
選挙の後、多くの評論家と言われる人たちが、したり顔をして論評していますが、そこで展開されている論理は、諭吉の域を一歩も出ていないように思われます。諭吉から一〇〇年過ぎて、この国の国民「nation」は何も変わっていないし、何も変えてこなかった。一〇〇年間、学者も評論家も論評しているだけで、「変える」ことに何ら貢献していません。彼らにとって歴史は単なる知識の一つなのか。それとも諭吉の「文明論の概略」も本気で読んだことが無いのか。
ヴァイツゼッカー氏は、「自らの歴史と取り組もうとしない人は、自分の現在の立場、なぜそこにいるのかが理解できません。過去を否定する人は、過去を繰り返す危険を冒しているのです。」とも言っています。何を背景に氏はこの言葉を吐いたかは説明の必要はないでしょう。