今月になって、アメリカ次期大統領選がヒートアップして来て、アメリカ人たちはかなり盛り上がっております。
傍目には、非常に楽しそうであり、知り合いのアメリカ人に、ストレートに、「楽しそうだな？」と聞いてみた所、ちょっと渋い表情になり、「楽しいんではなく、これ以外にアメリカの将来に期待できる事がないからだ」と呻いていました。
この発言に、果たして、日本人として同情すべきか、あるいは、羨むべきかは意見の分かれる所でしょうが、１つ言える事は、アメリカの組織は、それが政府や会社であろうと、あるいは、もっと小さなセクションであろうと、トップが変わると、がらりと内容も変わる事ができる点です。
管見では、イギリスの組織もそういう傾向があり、それに対し、日本は言うまでもなく、フランス・ドイツの組織もなかなかトップの言う事を聞きません。
ドイツやフランスでは、意思決定は、ある程度、組織的コンセンサスを経て行われる傾向があるのに対し、歴史的に最も早く議会制民主主義が発達した国、イギリスは、かえって、トップの独断的決断を尊重する傾向があるようです。
従って、英米系の組織では、トップの決断にそった移行が素早く行われる事が特長的で、周りも、しばらくの間は、変化を静観する傾向があります。そして、この特長が、素早い変化が要求される分野やタイミングには、英米型組織の強みとなっているようです。
しかしながら、組織が巨大化してくると、英米型組織でも、変化が素早く行えなくなってきており、俊敏さ（アジリティ）をいかに維持し、高めるかは、大きな課題になってきています。
日本においても、アジリティは重要な課題ですが、英米系で議論される方法論に加え、文化的障壁も考える必要があります。
かつて、第二次大戦後の最初の首相、吉田茂氏は、きわめてワンマンであったという悪評がありますが、その基準でいくと、アメリカの大統領を含め、大部分のアメリカ型の組織のトップは、大ワンマンになります。
また、ワンマンという言葉が、悪い意味になるのも、かなり文化的判断が入っています。果たして、吉田茂氏が、あの当時、ワンマン以外の方法で、難局を乗り切れたかどうかは、かなり疑問です。
現在、日本型組織、特に官僚組織は、かなり時代遅れなものになってきてるのは、誰の目にも明らかになってきていますが（ただし、当事者である役人たちの目は除いた方が良いかもしれませんが）、おそらく、方法論だけの議論では不十分でしょう。文化的側面にメスを入れ、この分野での議論を行う必要がありそうです。
アジリティと組込み系開発
組込み系開発は、要求される品質水準も高い上に、頻繁な更改を必要とする局面が多く、メンテナンスの品質と言う問題は、多くの企業にとり、非常に頭の痛い問題です。
組織によっては、大部分のエンジニアが、メンテナンス作業に張り付き、新しい技術の研究開発が全く行えなくなったり、また、ソースコードを担当別に分けた結果、担当者以外には誰も分からないものになってしまっているといった事態は、けっして珍しいことではありません。
また、変更を直接ソースコードに行う事も、それほど珍しくありません。
設計図を用いたメンテナンス
あえてオブジェクト指向とかUMLとか言う言葉出さなくても、歴史的には、こういった問題は設計図を用いたアプローチ、つまりモデルを用いた方法で、かなり状況が改善される事が知られていました。
オブジェクト指向という言葉がない時代から、ソフトウエア・アーキテクチャという言葉は存在し、その頃から、設計者たちは、図形や表を用いてソフトウエアの構造を設計していました。
そして、メンテナンスの際も、設計図にあたりながら、問題が、設計上のバグなのか、コーディング上のバグなのかを峻別し、前者であれば、設計変更を行う形で問題をフィックスして行きました。一見、回りくどいやり方ですが、最終的には、この方法が品質的にもコスト的にも最前である事が、知られてきています。
そして、フィックスしたコードのテストも、設計図を元に行います。今はやりの、モデル・ドリブン・テストの原型が、オブジェクト指向以前からありました。
設計図を利用しないテストでは、テストそのものがブラックボックス型になりやすく、テスト・カバレッジが悪い傾向があります。
また、リリースアップ等の場合も、直接ソースをいじるのではなく、設計図を書いて行う方が、最終的には、素早く安全に行える事が知られていました。
オブジェクト指向／UML化
オブジェクト指向以前のソフトウエア設計図を用いた方法でも、いきなりソースコードのみをメンテナンスするよりは、一定の効果が得られますが、問題も残っています。
一つは、設計者ごとに書き方がバラバラで、他の人が非常に読みにくい事で、これはメンテナンスをチームで行う上での大きな障害となっていました。また、２つ目は、設計方法にばらつきがあり、ソフトウエアの強度の水準の維持が難しい事です。
また、書き方がバラバラなために、設計ツールがなく、必要なら自分で作らなければなりませんでした。
９０年代以降、欧米の開発現場で、オブジェクト指向が急速に受け入れられてきた背景には、この種の問題に解決策を提供する事が明白になってきた事が、挙げられます。
UMLを使う事により、モデリングおよび表記法が統一され、また、自分で開発ツールを作らなくても、市販のツールを利用する事ができます。
そして、オブジェクト指向設計のアプローチにより、モジュラー構造やコンポーネント構造が半ば自然にとられ、ソフトウエア強度が上がり、品質も格段にあがる事が、明白になってきました。
そして、企業の生命線であるアジリティも、品質を確保した上で、向上する事が、広く認められるようになってきました。
