ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2016-05-02

[]全社的おんぼろ煙突化(Stovepipe Enterprise)

全社的おんぼろ煙突化(Stovepipe Enterprise)

別名

  • 自動化の孤島(Islands of Automation)

どういうこと?

企業内の複数のシステムが、あらゆるレベルで別個に設計され、共通性が欠知しています。これがシステム間の相互運用性を妨げ、再利用を妨げ、開発費用を高騰させています。これを「全社的おんぼろ煙突化」と呼びます。

最下位のレベルは、規格(スタンダード)と指針(ガイドライン)です。これらは、企業のシステムすべてを貫くアーキテクチャ構築の基準です。その上のレベルが、オペレーティング環境です。これはインフラストラクチャと共通サービスを構成します。さらに上のレベルが、付加価値機能サービスと業務固有サービスです。

これらの技術のすべてが個別に定義されることによって、多数の「自動化の孤島」を作りだすことになります。

どうしてダメ?

社内の複数のシステム間で「用語」「方式」「技術」などの互換性がなくなります。

すると、システム間でソフトウェアの再利用性ができません。システム間の相互運用性もありません。また、ビジネス要件が変わったときのメンテナンス費用が、異様に高くなります。さらに、システムに新製品や新技術を導入して拡張することが非常に難くなります。

どうして起こる?

全社的な技術戦略が欠如しています。中でも、システムの基本形に関する社内規格の不在、システムプロファイルの欠如している場合が深刻です。

システム開発者間に、協力に対するインセンティブがありません。業務分野や部門間に足の引っ張り合いがあります。システム開発プロジェクト間にコミュニケーションも発生しません。

どうすれば?

各レベルにおける基盤的な技術調整を行います。

まず、システムの基本形に関する社内規格を通じて、全社的な基盤となるべき共通技術・共通製品(すなわち全社的な「規格」)の選定を行います。基本形の規格は、各種の一般的・共通的・公共的な規格と、それらに向かっての企業システムの移行方向性を定義します。

続いて、共通のオペレーティング環境を確立します。製品の選択が調整され、また製品の各バージョンに対する構成管理も可能になります。

さらに、システムプロファイルの定義を行います。これにより、製品の使われ方や標準規格を調整します。標準的規格を徹底できれば、再利用性、および相互運用性が実現します。複数のシステムを貫く規約を定義しているシステムプロファイルが、少なくとも一つは存在しなければなりません。

2016-04-28

[]おんぼろ煙突化(Autogenerated Stovepipe)

おんぼろ煙突化(Autogenerated Stovepipe、自動的に生まれるストーブの煙突)

どういうこと?

場当たり的で、いい加減なアーキテクチャのソフトウェアを「おんぼろ煙突」と呼びます。

「おんぼろ煙突」は、既存のソフトウェアを分散環境に移行する場合に発生します。既存のローカルインターフェイスを、分散インターフェイスに変換しますが、この時、ローカルだけで動作していたソフトウェアと同じ設計を、分散環境に対してそのまま適用すると、多くの問題が発生します。

「おんぼろ煙突」という呼び名は、「薪ストーブ」の煙突にその由来があります。「薪ストーブ」は木を燃やすので、金属を腐食させる物質が出ます。そのため、排気管である煙突は、すぐボロボロになります。修理を頻繁に行わなければなりません。その修理は、たまたま手元にあった材料を使って行われます。その結果、薪ストーブの煙突は、度重なる即席修理の痕跡でツギハギだらけになるのです。

どうしてダメ?

ローカル用インターフェイスは、情報転送の粒度が比較的小さくなっています。しかし、分散環境ではやりとりが無駄に多くなり、非効率です。

どうして起こる?

ローカルな操作は、メモリやファイルシステムの場所に関する、さまざまな想定を行っています。ローカルのインターフェイスが大規模分散システムを介して接し合ったときには、過剰な複雑性が生じます。

どうすれば?

既存のソフトウェアに対する分散インターフェイスを設計するときは、インターフェイスを再構築すべきです。分散インターフェイスは、粒度の大きいオブジェクトを検討します。

分散インターフェイスを作ると、単独でコンパイルできていたソフトウェアが、それらの新しい設計に依存します。新たなインターフェイスは安定性がきわめて重要です。慎重に設計する必要があります。

2016-04-27

[]暗室栽培(Mushroom Management)

暗室栽培(Mushroom Management)

別名

  • 分析もどき(Pseudo Analysis)
  • 目隠し開発(Blind Development)

どういうこと?

開発者をエンドユーザから隔離します。この文化を「暗室栽培」と呼びます。

暗室栽培において、要件は「アーキテクト」「管理者」「アナリスト」などの手を介して、間接的に開発者に伝えられます。しかし、この文化は、間違ったソフトウェアを開発してしまう危険性が大きくなります。

どうしてダメ?

開発者は、必要な情報から隔離されることになります。えてして、要件文書は内容が詳細でなく、説明の責任者が誰なのかもはっきりしません。

すると、開発者は勝手に仕事を進め始めます。エンドユーザからのリアルな介入を欠いた、机上の空論的な分析しか行われません。ひどいときは、分析をまったくやらずに、大まかな要件から直接実装に進みます。

このような状態で開発されたソフトウェアが、ユーザの要件に沿うことはありません。受け入れ時にそれが判明するので、そのプロジェクトは立ち行かなくなります。

どうして起こる?

要件について「プロジェクトの着手時に十分に理解されている」「今後不変である」と想定しています。

しかし、この想定は誤りです。現実では、プロジェクト開始時に要件が完全に把握できていることはありませんし、さらに要件は頻繁に変わります。その要件の変更が開発者にうまく伝わらないと、使い物にならないソフトウェアを開発する羽目になります。

どうすれば?

リスク主導開発を行います。

プロトタイピングとユーザフィードバックに基づくスパイラルな開発です。リスク主導開発は、段階的開発手法の特殊形です。この場合、外部へ向かっての段階的な開発が行われます。外部へ向かってとは、「プロジェクトの段階的な進捗が、毎回ユーザからのフィードバックをベースとし、ユーザインターフェイスの機能性の拡張を中心として行われる」という意味です。

その段階的な工程には、ユーザインターフェイスに関する実験、なかでもとくに実ユーザによる実用実験が含まれます。実験により受け入れを評価し、各機能の使いやすさを検証します。その実験結果に基づいて、プロジェクトの今後の方向性および直近次段階作業を決めます。このようにして受け入れを頻繁に評価し、それによってソフトウェア開発をガイドしていくので、受け入れ時のリスクが最小化されます。

2016-04-26

[]切り貼りプログラミング(Cut and Paste Programming)

切り貼りプログラミング(Cut and Paste Programming)

別名

  • クリップボードコーデイング(Clipboard Coding)
  • ソフトウェアクローニング(Software Cloning)
  • 孫悟空的プログラミング*1(Software Propagation、増殖的ソフトウェア)

どういうこと?

既存のソースコードをコピー・ペーストして再利用することを「切り貼りプログラミング」と呼びます。

プロジェクトには、多くのプログラマが参加し、経験者のコードを参考にしながら、ソフトウェア開発を学んでいきます。過去に似たような状況でうまくいったコードを若干変更することによって、新しいデータ型をサポートしたり、動作を新たなニーズに合わせたりします。

ただし、まずいのは、これがコードの「複写」によって行われていることです。

確かに、時間あたりの行数を稼ぎ、プログラマが評価されるなどのメリットがあります。しかも、コードを開発者が自由にいじれるので、コードの拡張が容易であり、新たな要件を満たすための変更なども、素早くやっつけられます。

しかし、これにより、同じようなコードがソフトウェア全体にわたって何箇所もあることになり、メンテナンスの悪夢を招くことになります。

どうしてダメ?

切り貼りプログラミングによるコード再利用は、ソフトウェアのバグが、全体にわたって再生産されます。あるバグについて、それがある場所をすべて見つけて直すことが難しくなります。バグ修正を行ったにもかかわらず、同じバグがソフトウェアの至る所で起きるようになります。

切り貼りプログラミングによるコード再利用は、むやみやたらにコードの行数が増えることになります。コードが大量になるので、コードのメンテナンスに非常に時間がかかるようになります。

切り貼りプログラミングによるコード再利用は、コード共通化による「真の再利用」を阻むことになります。再利用すべきコード資産が、再利用しやすい形式へと整備されません。時間当たりの行数という意味での生産性は上がりますが、再利用性や品質を鑑みた、真の意味での生産性は上がっていません。

どうして起こる?

組織の短期利益重視の文化が影響します。

再利用コードを作るには一定程度の努力が必要なので、組織はそのような長期的な投資よりも、短期的な利益を重視します。開発速度が圧倒的に重視され、再利用コンポーネントが軽視されています。

開発者のスキル不足が影響します。

開発者に抽象化能力が欠如しており、継承、コンポジションなどの戦略をほとんど理解していません。事前に設計することは、ほとんどありません。その結果、現在実際に動いているコードをピックアップして、それに手を加えることによってニーズに合わせようとします。

どうすれば?

ホワイトボックス的な再利用よりも、ブラックボックス的な再利用を促進します。

ホワイトボックス的再利用では、主に継承を使って拡張します。サブクラス作成や拡張には、オブジェクトの実装に関する知識をある程度必要とします。たとえば、継承に用いるベースクラスが前提している制約や、使用を指示されているパターンに関する知識です。言語そのものには制約がほとんどないので、拡張タイプを派生クラスによって実装することが容易にでき、親クラスの制約を満たさない不適切なサブクラスが作られます。また、ホワイトボックス的な再利用はアプリケーションのコンパイル時にのみ可能です。コンパイラ言語の場合、サブクラスがアプリケーションの生成前に完全に定義されていなければならないからです。

ブラックボックス的な再利用では、そのインターフェイスの仕様を通じて、あるがままの姿で利用されます。クライアントは、オブジェクトのインターフェイスの実装方式を変えてはなりません。ブラックボックス的な再利用の重要な利点は、オブジェクトの実装がオブジェクトのインターフェイスから独立することです。これによって、実行時に、インターフェイスを特定の実装にバインドするなど、ランタイム結合の利点を生かせるようになります。将来、同じインターフェイスをサポートするより高度なサービスが作られたとき、クライアントの変更なくその利益を享受できます。

*1:孫悟空が自分の毛から自分の分身をいくつでも作りだすことに由来します。

2016-04-25

[]地雷原(Walking through a Minefield)

地雷原(Walking through a Minefield)

別名

  • 万策尽きた
  • 奇蹟を待とう

どういうこと?

ソフトウェアには、数多くのバグが潜んでいます。これを、「地雷原」と呼びます。今日のソフトウェア技術を利用することは、それだけで既に「ハイテクの地雷原」を歩くことに等しいのです。

どうしてダメ?

ソフトウェアのバグは、些細なものでも破滅を招くことがあります。たとえばオペレーティングシステムには、知られているものといないものを含めて、数多くのセキュリテイ上の欠陥があり、攻撃に弱い体質をもっています。今日のようにすべてが情報化された社会においては、コンピュータ制御の旅客列車や宇宙船の制御システムなども含めて、バグの結果は破滅的です。

エンドユーザは、ソフトウェアのバグに頻繁に遭遇します。クレームが来ますが、その数はソフトウェアのエラーが起きた回数より少ないのです(「ノイジーマイノリティ」「声の大きい少数派」)。潜在的に不満を持っているユーザが数多く存在します(「サイレントマジョリティ」「物言わぬ多数派」)。

ソフトウェアを発売前にテストする目的の一つに、サポート費用を抑えることがあります。しかし、エンドユーザがベンダのテクニカルサポートに電話をしてくるたびに、その対応費用により利益がすり減ってしまいます。

どうして起こる?

ソフトウェアの性質上、バグは完全に駆逐することはできません。

どうすれば?

バグを完全に駆除はできませんが、比較的バグの少ないシステムを完成させるために、テストへの適切な投資を行います。一部の先進的な企業では、試験部門の規模が開発部門の規模より大きいところもあります。

テストケースについては、構成管理を行います。典型的なケースでは、テストケースを実行するソフトウェアは、製品ソフトウェアの5倍程度の大きさになります。バグが検出された場合、製品のバグではなくて試験のバグである可能性もあります。そこで、適切な構成管理を行い、テストケースをコントロールします。それを、回帰試験などで使用します。

テストの実行は、極力自動化します。手作業によるテストは労働集約的であり、テスト結果の客観性が希薄です。これに対して自動テストは、ビルドサイクルと並行して実行することが可能です。回帰テストも手作業を介入させずに実行して、ソフトウェアの変更によって、前にテストした動作にバグが混入する事態(デグレード)を妨ぎます。