この国は、なんでも「自分専用」を作りたがる。社内教育システムはもちろん、作業の分担や役割も、その企業独自のやり方である。独自にこだわっていないのかも知れないが、「他」を研究しないために「独自」になってしまうのかもしれない。使用している書類も、事務処理の流れも、み〜んな独自のものである。
確かに、手作業であればどんな作業の流れも作ることが出来る。だが、コンピュータシステムとなると話は違ってくる。そのシステムはユニュークなため、開発費も高くついてしまう。だから、ソフト会社も日本では客先を掴んでから開発に取り掛かる。そのため、そのシステムは、そのままでは他では使えない。いや、本当は使えるのかも知れない。他の客先が既存のソフトにあわせて作業の流れを変えれば済むのかもしれない。でも、なぜかそうしない。この論法は、ツールの選定の際にも顔を出す。本来なら、ツールに作業を合わせるべきなのに、（現状の）作業にツールを合わせようとするから、「自分たちの作業に合わない」ということになってしまう。
こうして、無駄な開発が繰り返されることになる。たしかに、ソフト会社が仕事にありつく機会は増えるし、ＧＤＰも嵩上げされてしまう。だが、このＧＤＰはムダの上に積み上げられたものである。そしてこの問題は、２１世紀の日本において確実に障害となる。
この問題で、真っ先に引っ掛かるのは銀行である。昨年、鳴り物入りで発表されたみずほファイナンシャル（第一勧業銀行、富士銀行、日本興業銀行）の巨大な事業統合は、予想通りコンピュータシステムの統合で壁にぶち当たっているようだ。銀行に於ける勘定系システムや信託システム、与信システムなどが、どうして統合が困難になるほどに違うのか。全く独自で開発したとしか思えない。看板は違っても所詮は同じ「銀行」という業態はなのだから、やることは同じではないのか。基本的な業務知識や、作業上の技術などは共通するのではないのか。
報道によると、内部では、使い慣れた「自分たちのシステム」を残そうと、早速に「派閥」争いが繰り広げられているという。それも、トップクラスが旗を振っているというから、お粗末な話である。彼らの頭の中には、預金者の利益など全く考えていないとしか思えない。如何に、自分たちの勢力を残すかということだけなのかもしれない。そうなると、現場の当事者も統一に対して「出来ない理由」を山ほど並べる愚挙に出るのは、火を見るよりも明らかである。そして、そのとばっちりを受けるのが預金者である。
カルロス・ゴーン氏が来るまでの日産自動車でも同じであったようだ。プラットフォームを半減しようとすれば、そこに出来ない理由が並んだ。部品業者を整理しようとすると、そこでも出来ない理由が積み上げられた。それなのに、ゴーン氏が来てからは、それまでの「出来ない理由」は、解決すべき課題となり、別案を考える機会に変貌してしまった。そうでないと、自分たちの会社が残らないからだ。「みずほ」にも、ゴーン氏が必要なのか。
それよりも分からないのは、世界の銀行はどうしているのかということである。当時、世界中で銀行の併合や統合が繰り広げられた。そこでも、「みずほ」と同じことが起きているのだろうか。外からはそのようには見えない。「みずほ」のようなことをやっていたら、顧客は逃げるだろうし、株主も黙っていないだろう。第一、いつ他行に飲み込まれるか分かったものではない。
銀行のシステムが「標準」でないということが、ここにきて日本の金融再生を妨げ、結局、日本の経済を根底から揺るがしているのである。当事者は、そのことに気づいていないのだろう。
同じような事がソフトウェアの開発でも言える。きちんとした分析手法や設計手法を身に付けていることを前提とした作業工程を持っている組織は殆どない。その上、プロセスが定義できているということになると、皆無に近い状態だろう。中には、そのような事が出来る「人」が居るかも知れないが、殆どは「個人」の問題であって、組織のレベルにはなっていない。そのため、そこで身に付けた作業の進め方が、他の組織では使えないのである。いくら、設計手法を身に付けていても、要求仕様がそれなりにまとめられていない組織にあっては、身動きが取れなくなる。
このことは、ソフトウェア・エンジニアの流動性を阻害することになる。作業の形やそこでの役割の定義などが、まったく行われていないため、そこで何年経験しても、そのままでは他では通用しないのである。ソフトウェアの開発といっても、業務内容は個々の企業によって異なるので、業務に直接関係する部分の必要な知識は異なるかも知れないが、ソフトウェアを開発するということでは同じはずであり、作業の進め方も、そこに居る人たちの役割分担が明確であれば、おのずと決まってくるし、そこでの経験が他でも通用することになる。
ソフト会社に身を置く人の中には、いろんな客先を経験することで、それぞれの組織のやり方に適応する能力を身に付けている人も居るだろうが、その他の人たちの場合は、ず〜と同じ環境であるため、殆どそのようなスキルを身に付ける機会はないだろう。そうなると、今所属している組織で「標準的な作業の形」が身に付けられるかどうかは、その人にとっては、非常に重要な問題となってくる。
もちろん、ここでは逆のことも言える。他で通用しないということで、他社に出ていかれる可能性が減るのである。だがこれは、反対に外から新しい人を取ってこれないことをも意味していて、差し引きすると得にはならない。一度作業が停滞すると、その組織では解決方法が無くなってしまうだろう。世界が激しく動き、要求が刻々と変化している状況を考えると、非常に危険な選択である。
大事なことは「標準」を手に入れることだ。プロセスを確立し、変化させる方法としての標準である「ＣＭＭ」を片方に置き、もう一方には、構造化手法やオブジェクト指向に基づいた「分析・設計手法」の標準を取り入れることで、全体を「標準」で整えることができる。「手法」というのは、それ自体が共通の言葉である。それらの使い方を知っていることで、初めて会う人とでも会話が出来るのである。ただし、ここで注意しておいて欲しいのは、分析・設計手法だけではうまくいかないということである。分析・設計手法を、あるレベルで手に入れた時には、同時に、「プロセスを設計し修正するスキル」も手に入れておかないと、ある期間の中で破綻を招く。
いずれにしても、これからのＳＥは、「標準」を手に入れておくことが不可欠です。何が「標準」になるのかを見極めて、それを手に入れることです。標準は、一つとは限りません。でも、プロセスの標準であれば、だいたい共通していますので、融通は利きます。分析・設計手法の標準も幾つかあり、場面によって使い分けます。「ツール」も、現状の作業体系の中に取り入れ、作業体系をツールに合わせることで、標準を取り入れることができます。逆に、適切なツールをうまく作業の中に取り込めないということは、「標準」を取り込めないことを意味する可能性があります。
２１世紀には、ソフトウェアの開発会社の選別が始まります。インターネットを介して、世界中のソフトウェア・エンジニアが参加できるようになるからです。そうなると、組織としてどれだけ優れた人を確保しているかが勝負ですが、同時に、人の移動によってサービスの質を落とさないためにも、組織のプロセスレベルを引き上げる動きにでるでしょう。また、そのような組織でないと、優秀なエンジニアやマネージャーを確保出来ないでしょう。
一方、組み込みシステムなどを開発する企業の方でも、生産性などを睨みながら事業の統廃合などを契機として、エンジニアやマネージャーの流動化が始まります。そのとき、組織としても「標準」で作業を構築しておかないと、簡単に崩れてしまい、時代の要請に応えられない事態に陥るでしょう。「標準」を持たないことで、開発効率を上げられないとなると、開発作業そのものが、それ以上続けられなくなる可能性が出てくるのです。
そのためにも、先ずは、目の前の作業に必要なスキルを幾つか手に入れることです。ＣＭＭは、どの時点でどのようなスキルが必要なのかということも教えてくれています。実際に、必要を感じたときには遅いのです。マネージャーが、少しでも不安を感じたら、すぐに動き出すことです。
“オリジナリティ”は、標準を踏まえて、それを越えたところに打ち立てるものである。