アジャイル開発を元に考えるプロジェクトマネージャのあり方13

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方12の続きです。前回はマネージャの管理方法について解説しました。今回はより具体的に、プロジェクトマネージャが果たすべき役割を解説をします。
　プロジェクトマネージャがするべき事は、精神面および物理面から職場の環境を整え、お客様の要望を叶える事です。開発メンバーに自己管理をさせているからと言って、その間何もしなくてもよいという事ではありません。プロジェクトマネージャは常に仕事を抱えています。
　システム開発でよくある失敗は、開発者達の職場環境を軽視し、期待していた成果が出ないと叱責する事です。システム開発は、どの工程も高度な創造性を必要とするクリエイティブな仕事です。環境を整えないと仕事の成果は望めません。一時的には開発メンバーに鞭を打ち、残業をさせて無理やり補う事は出来ますが、本来クリエイティブな仕事なのでそれは長続きしません。人を犠牲にする根性論は長続きしません。
　人を叱責する前に、プロジェクトマネージャは職場環境を整え、新人でもそれなりに成果が出せる環境を構築しなくてはなりません。大概のプロジェクトは、全員がプロフェッショナルな人材だという事はありません。毎年新入社員は入ってきますし、途中でメンバーが抜けたり、新しいメンバーが追加される事が頻繁にあります。それら人材を最大限に生かすのもプロジェクトマネージャの仕事です。
　

現代からみるBuilderパターン

　今回はBuilderパターンを現代から見つめなおします。Builderパターンは複雑なオブジェクトの生成を、生成プロセスから独立させます。複雑なオブジェクトを作りがちの現代に於いて、非常に重要なオブジェクトだと言えるでしょう。しかし、現代では考えなければならない課題もまた増えています。
　Builderパターンで生成するオブジェクトが複雑な場合や、生成過程の計算量が大きい場合、並行処理で実装する事を検討する必要があるでしょう。Builderパターンを並行処理で扱う事により、パフォーマンスが向上する可能性があります。しかしながら、パフォーマンスは労無くして手に入りません。並行処理を行うようにBuilderパターンを実装するには、検討しなくてはならない事があります。
　課題となるのは、オブジェクトの整合性をどのようにして保つのかという点です。闇雲に並行処理をするとオブジェクトが壊れてしまいます。慎重に設計と実装をしなくてはなりません。
　先ず考えなくてはならないのは、Directorオブジェクトと生成するオブジェクトの性質です。Directorオブジェクトが担当する処理を並行的に行うと、Builderオブジェクトへの指示がランダムに発生するようになります。何故ならば、並行処理では命令を実行する順序が予測できなくなるからです。ですから、生成するオブジェクトがデータの順序に依存するか否かをよく考えなくてはなりません。
　生成するオブジェクトがデータの順序に依存する場合、Directorオブジェクトで並行処理をするのは止めた方が賢明です。並行処理を順番通りに処理させようとすると、多大なオーバーヘッドが生じます。出来ない事ではありませんが、労力とオーバーヘッドに見合うパフォーマンスが得られる可能性は低いでしょう。この場合、Builderオブジェクトの処理を並行化する方法を考えた方が賢明です。
　一方、生成するオブジェクトがデータの順序に依存しない場合、Directorオブジェクトでの並行処理を検討する価値があります。この場合、データの発生源の多重度が重要です。データ発生源が「一つのファイル」などの単数である場合、Directorオブジェクトを複数作成して並行処理をするのは得策だと言えません。共有資源であるファイルをロックする事によりトラブルが発生する可能性があるので、極力単一リソースから同時に読みとるのは避けるべきです。あらかじめデータファイルを分割するなどの工夫が必要です。その逆にデータの発生源が複数ある場合、Directorオブジェクトの並行処理化は比較的簡単です。
　次に考えるべき事はBuilderオブジェクトの並行処理化です。Builderオブジェクトの場合、並行処理を検討する箇所は、個別要素の構築とオブジェクトの生成の2点あります。個別要素の生成が計算量を要する場合、その処理を並行化するとパフォーマンスがアップします。一方、個別要素を纏めてオブジェクトを生成する処理を並行化する場合、処理の切り分けをよく考えて行う必要があります。
　以上、Builderパターンを個別に考えた場合の並行処理化の検討項目を書きました。しかし、並行処理をする場合、より広い視点で物語を見なくてはなりません。一つのオブジェクトの生成に拘るのではなく、オブジェクトの生成そのものの並行化を検討する必要もあります。つまり、1つのオブジェクト生成に拘るのではなく、オブジェクトの生成処理そのものを複数同時に行う事も可能です。システムの性質に応じた方法を採りましょう。
　纏めます。Builderパターンと並行処理の組み合わせは難しく、考えるべき事が沢山あります。しかしながら、その効果は多大です。Builderパターンと並行処理を組み合わせると、オブジェクトの生成過程が隠蔽されているので、利用者は意識することなく並行処理のメリットを得られます。挑戦する価値は十分にあります。

.NET並行処理プログラミング入門3

　この記事は.NET並行処理プログラミング入門2の続きです。前回はスレッドの生成方法および実行方法を解説しました。今回はスレッドの種類と複数のスレッドの実行について解説します。
　前回のサンプルは並行処理をしている実感が得られなかったと思います。そこで、今回は2つのスレッドを実行するサンプルを掲載し、スレッドオブジェクトについての解説を進めます。

using System;
using System.Threading;

class ThreadSample
{
    static void Main( string[] args )
    {
        //カウントスレッドを用意
        ThreadStart start = new ThreadStart( Piyo.Count );
        Thread counter = new Thread( start );

        //ピヨスレッドを用意
        Piyo p = new Piyo();
        ThreadStart piyoStart = new ThreadStart( p.PiyoOut );
        Thread piyopiyo = new Thread( piyoStart );
        piyopiyo.IsBackground = true;

        //二つのスレッドを実行
        counter.Start();
        piyopiyo.Start();
    }
}

class Piyo
{
    public Piyo() { }
    public void PiyoOut()
    {
        while( true ) {
            Console.WriteLine(" ピヨ ");
        }
    }

    public static void Count()
    {
        Console.WriteLine( "数えるピヨ♪" );
        for ( long i = 0; i < 1000; ++i ) {
            Console.Write( "{0} ", i );
        }
        Console.WriteLine();
    }
}

このサンプルは一見すると、ピヨスレッドの処理が終わらないので、永遠に処理が続くように見えます。しかし、実際はちゃんと終了します。その理由は、バックグラウンドスレッドが他の種類のスレッドに強制終了させられるからです。
　非並行処理の.NETのプログラムが動いているのは、メインスレッドが動作しているからです。そして、サンプルのカウントスレッドのようなフォアグラウンドスレッドが動いている間プログラムは終了しません。フォアグラウンドスレッドは、全ての処理が終了すると、全てのバックグラウンドスレッドを停止しプログラムを終了させます。
　フォアグラウンドスレッドとバックグラウンドスレッドの違いは重要なので絶対に覚えて下さい。どういう観点で使い分けるのかの目安を言います。バックグラウンドスレッドは途中で終了しても支障がないサブ処理で使用します。一方、フォアグラウンドスレッドは、途中で終了すると不都合がある処理で使用します。
注意：これはあくまでも目安なので、実務で使用する前にこの連載の続きやMSDNをよく読んで下さい。
　バックグラウンドスレッドは、処理の途中で強制的に終了させられるので十分に注意して使用して下さい。バックグラウンドスレッドで処理をする場合は、いきなり処理が終了させられる可能性があるので扱うデータの整合性を保てるように工夫しましょう。続く...

.NET並行処理プログラミング入門2

　この記事は.NET並行処理プログラミング入門1の続きです。前回は.NETにおけるスレッドモデルについて解説します。今回はスレッドの生成方法および実行方法を解説します。
　何はともあれ、先ずはスレッドを生成して実行してみましょう。スレッドの生成方法と、生成したスレッドの実行方法をサンプルで示します。

using System;
using System.Threading;

class ThreadSample
{
    static void Main( string[] args )
    {
        ThreadStart start = new ThreadStart( Piyo.Count );
        Thread counter = new Thread( start );
        counter.Start();
    }
}

class Piyo
{
    public static void Count()
    {
        Console.WriteLine("数えるピヨ♪");
        for ( long i = 0; i < 100; ++i ) {
            Console.Write( "{0} ", i );
        }
        Console.WriteLine();
    }
}

サンプルを見て、スレッドの生成および実行が意外と簡単な事に驚いた人もいるかと思います。スレッドモデルによる並行処理プログラミングの概念は難しいもののコーディングは簡単です。
　.NETのSystem.Threading.Threadオブジェクトは、System.Threading.ThreadStartデリゲートを引数として受け取るコンストラクタを呼び出す事によりインスタンスを生成します。他にもコンストラクタがあるのですが、ひとまずこの方法を覚えて下さい。
　Threadオブジェクトのインスタンス取得後は、Startメソッドを呼び出すだけで実行できます。これで.NET並行処理プログラミングの第一歩を踏み出した事になります。色々気になる事があるかと思いますが、長くなるので今回は終わります。
　次回へ続く...

ネタつつき94 - プログラミングの未来は宣言的分散並列化指向

　今回はプログラミングの未来予測を書きます。当たるかどうかは分かりませんが、一つの見解として読んで頂ければ幸いです。
　なんの歴史もそうなのですが、未来は過去を知る事により予測できます。過去を振り返れば、プログラミングの歴史は、ハードウェアの進化の歴史とも言えます。何故ならば、進化が速いと言われる情報処理技術ですが、プログラミングの基本的考えそのものは殆ど変っていません。最近のプログラミング言語で最新と言われるものは、ほぼすべてが過去の焼き直しです。命令型言語、関数型言語、論理型言語、並列指向言語、宣言型言語、集合指向言語・・・これらはすべて昔から存在し、昨今の言語のバージョンアップはそれら既存の概念を取り入れる事によりマルチパラダイム化していると言えます。
　プログラミング言語がマルチパラダイム化してきた背景には、ハードウェアの進化が関係しています。プログラミングの世界がハードウェアの進化に影響を受ける理由はパフォーマンスと普及率です。具体例はガベージコレクションです。ガベージコレクションは今どきのプログラマにとって当たり前の存在でしたが、ハードウェアの進化なしには普及しない技術でした。今はなりを潜めていますが、ガベージコレクションを備えたJavaはパフォーマンスが悪いと言われる時代がありました。むろん、ガベージコレクションだけが問題ではないのですが、少なくともメモリは自分で管理するのが当たり前の時代があったのです。
　それを踏まえて未来を予測すると、分散化と並列化および宣言型がキーワードになると私は思います。ハードウェアの進化はとどまる事を知らず、複数コアのCPUが既に一般化しています。さらにGPUを使用する技術が実用化されています。また、通信技術を支える技術およびハードウェアも進化し、どんどん通信速度が高くなっています。それらハードウェアの進化を鑑みれば、それを活かすためにプログラミング言語を宣言型にするのが自明です。
　プログラミング言語は、プログラマの生産性を高めるのを目的としています。ですから、分散と並列化の恩恵を受けるように成長します。それを可能にするには、既存のコンパイラ技術から考えて宣言型にするしかありません。宣言型にするとコンパイラが創意工夫をできます。プログラマが直接分散処理と並列処理をするのは面倒なので、それを解決するには、文法を宣言型にしておきコンパイラと実行環境が面倒をみるという考えが一般的です。ですから、宣言型の方向へ進化するのが目に見えています。
　私はこの抽象化が必ずしも良いとは思いません。利点は計り知れないものがありますが、不利益も計り知れないものがあります。技術者の質は下がる一方なのにもかかわらず、そういった生産性を追求すると技術者の質はさらに低下するでしょう。プログラミング言語の進化による利益を享受し、不利益を避けるには自分が作る側に回るしかありません。一般人にとって未来は明るいかもしれませんが、技術者にとっては暗いと思えてなりません。今からその時代に向けて準備をしましょう。未来が明るいものになるかどうかはあなた次第です。

アジャイル開発を元に考えるプロジェクトマネージャのあり方12

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方11の続きです。前回はマネージャがどうやって管理するのかについて解説しました。今回も引き続きマネージャの管理方法について解説します。
　前回私はマネージャが管理するべきものは結果だと書きました。日本ではよくこの部分が拡大解釈され、「マネージャは情報処理技術を知らなくてもよい」という間違った考えになってしまいます。もちろんそれは違います。何故ならば、マネージャが情報処理技術を知らないと、結果を正確にチェックできないからです。情報処理技術を知らない人間が、情報処理技術の産物である結果を理解できるはずがありません。もしそれが可能ならば、エンドユーザーがマネージメントをすればよい話しになります。それが出来ないのですから、情報処理技術を知らない人間が結果を管理できないのは自明の理だと言えます。
　開発者が出した結果を判定するのは技術力が要ります。開発者が間違っている場合、プログラミングが達者でないとマネージャは見抜けません。しかしだからと言ってプログラミングだけに通じていても駄目です。仕様や設計が間違っているケースも多々あります。仕様や設計が間違っているのにもかかわらず、担当したプログラマを責めると人望は失われますし、本当の間違いが見過ごされてしまいます。マネージャは情報処理技術全般に通じていなくてはなりません。
　それに加えて、マネージャはプロジェクトの背景知識も持たなくてはなりません。システム開発は作るべきものを詳細に理解してないと失敗します。情報処理技術に通じているからと言って、他業種のお客様にとってよいシステムを作れません。システムはお客様にとって心地よいものでなくてはなりません。
　しかしながらマネージャも人間です。情報処理技術の全てを極め、エンドユーザーの業務知識も熟知しているということはありえません。その理想を追い求める姿勢は大事ですが、現実を直視せねばなりません。マネージャは知らないものは知らないと認める度量がなくてはなりません。マネージャは人間性に優れ、人望がないと駄目だという事です。続く...

現代からみるAbstract Factoryパターン

　今回はなじみ深いAbstract Factoryパターンについて現代から考察します。Abstract Factoryパターンもまた、現代のプログラミング言語の進化により表現力がアップします。これから、表現力をアップする方法と、どの様に表現力がアップするのか解説します。
　Abstract Factoryパターンを使用する際に困るのは「新たなオブジェクトが追加された場合の対処」です。Abstract Factoryパターンを教科書通りに実装すると、サブクラスが異常に増えてしまいます。それを防ぐ方法は、関数型プログラミングの考え方を取り入れる事です。Factoryオブジェクトに関数を渡せばサブクラスの数を減らせます。この方法については、現代からみるFactory Methodパターンで解説しているのでそちらを参照して下さい。
　Factory Methodパターンと同様に関数を渡せばクラスの数を減らせますが、それに加えて、Abstract Factoryパターン特有の利点が出来ます。Abstract Factoryパターンの利点は、オブジェクトの集まりを纏めて扱える事です。そこへ関数を取り扱う事により、組み合わせと生成方法を分離できます。
　難しいと思いますので噛み砕いて説明します。Abstract Factoryパターンを関数型プログラミングの考え方を取り入れずに適用すると、個々のオブジェクトの生成方法の違いが影響し、新しいオブジェクトが実装されるたびに対応しなくてはなりません。一方、生成方法を関数として別に扱えば、新しいオブジェクトが実装されても関数を渡せば済み、純粋にオブジェクトの組み合わせだけに注目する事が出来るようになります。この効果は大きいものですが、これだけだとFactory Methodパターンと組み合わせただけです。考えを一歩進めると、さらに表現力をアップさせる事が出来ます。
　先ほど書いた、Abstract FactoryパターンとFactory Methodパターンの組み合わせは一般的なものです。この組み合わせは強力なのですが、生成以外の実装が固定化されるという弱点があります。その弱点もまた、関数型プログラミングの考え方を取り入れれば解決できます。生成以外のプログラムも取り換え可能な関数の集まりとして考えれば、さらなる表現力アップを見込めます。こうすれば、Abstract Factoryパターンはオブジェクトの継承関係から解放され、純粋に組み合わせを決定するテンプレートとして扱う事が出来ます。
　この表現力のアップは素晴らしいものです。ですが、無闇に使用すると抽象化しすぎて保守性が下がるので注意して下さい。表現力は諸刃の剣です。慎重に使用して下さい。

中小企業や零細企業にも情報システムが必要

　私がシステムの販売を行っている際によく聞く言葉があります。それは、「うちは中小企業（または零細企業）だからシステムなんていらない」です。しかし、それは大いなる誤解です。商売をしている限り、どのような規模であろうとシステムが必要です。
　その理由を知るためには情報と何かを改めて考えなくてはなりません。情報とは組織／社会の血液であるどのような動物にも血液が必要です。それと同じで、あらゆる組織は情報システムが必要なのです。情報システムの存在意義は組織の規模とは関係がありません。組織の規模に応じた情報システムが必要なのです。
　抽象的で分かり難いかもしれませんので具体例を挙げます。私は個人商店に情報システムを売り高い評価を頂いた事があります。初め私がシステムを売り込んだ時、店主は渋っていたのですが、私が説明すると興味を示して購入しくてくれました。秘密厳守ですので詳細を述べられませんが、重要なポイントは商売に関係する情報を示し、それをシステムでどう生かすのかです。
　例え個人商店であっても社会に貢献しています。大企業だけが日本を支えているのではありません。日本の場合は特に、日夜努力をしている中小企業／零細企業で支えられています。規模に関係なく、優れたサービスを提供している会社はごまんといます。そういった会社は、その重要さゆえに情報が流動しています。そして、規模に応じた適切な処理の仕方があります。
　大規模な組織の場合、莫大な情報が発生します。しかし、本当に重要な情報を選択せねばならず、多くの決裁が必要となります。一方大規模ではない組織の場合は、情報は大企業と比べて少ないものの、組織にとって重要な情報の割合が高くなり、意思決定の早さが求められるようになります。ですが、小規模な組織は人員が少なく、その重要な情報を処理する時間を取れません。ですから、如何に効率よく情報を処理するかが課題になります。
　効率よく重要な情報を処理するには、小回りのきく情報システムが必要です。情報システムと言うと、大がかりなものというイメージを持つ人が多いのですが、情報システムには様々な形態があります。複数台のパソコンを並べるだけが情報システムの姿ではありません。パソコンを使わない情報システムもありえます。情報システムとは、情報を処理する体制や仕組みの事であり、その形態は固定されていません。想像力次第でどのような形態にもなります。オーダーメイドの靴を思い浮かべると分かりやすいと思います。
　昨今はスピードが求められる時代になりました。それに対応する為には、小規模な組織であっても情報システムが必要です。雑務をさっさと処理し、本当に重要な心がこもったサービスに力を入れる為に情報システムを活用して下さい。

.NET並行処理プログラミング入門1

　この記事は、.NET並行処理プログラミング入門の続きです。前回は並行処理に関する基礎的事柄を解説しました。今回は.NETにおけるスレッドモデルについて解説します。
　.NET Frameworkでのプログラミングは実行環境を提供しており、Win32を使ったネイティブなプログラミングとは異なります。.NET Frameworkにおける並行処理実行環境を知るところから始めるのがベストです。そこで、先ずはWin32のスレッドモデルをおさらいし、次に.NET Frameworkのスレッドモデルを解説します。両方のスレッドモデルを理解する事により、並行処理の理解が深まり、スレッドを自由自在に操れるようになります。
　Windowsが管理しているネイティブなスレッドはプロセス内に存在します。Windowsはプロセス内に、共有リソースと1つ以上のスレッドを保持します。こうする事により、バグを抱えたプログラムの影響を限定化する事が出来ます。もし仮にプロセス内ではなく、全スレッドが同一空間に管理されていると、一つのスレッドの過ちがOS全体に影響を与えてしまいます。プロセス内のプログラムは通常他のプロセスのプログラムにアクセスできないのでその心配がなくなります。
　一方.NET Frameworkでは、プロセス内に1つ以上のアプリケーションドメインを持ちます。そして、アプリケーションドメイン内で共有リソースとスレッドを保持しています。一見複雑化しただけですがこの方式には利点があります。
　アプリケーションドメイン内でスレッドを保持する事により、さらにバグの影響範囲を限定し、プログラムがより一層堅牢になります。それに加えて、アプリケーションドメインごとにセキュリティ等の構成を設定でき、アセンブリのロード＆アンロードも行えます。アプリケーションドメインという概念があるお陰で、プログラムの構成がさらに堅牢かつ柔軟になると言えます。
　先ほどWindowsが管理するスレッドをネイティブなスレッドと表現しました。この理由は、.NET FrameworkのスレッドがOSが管理するスレッドと一対一で対応しなくなる可能性があるからです。.NET Frameworkは今のところ.NETのスレッド＝Windowsのスレッドですが、マイクロソフト社は将来のバージョンでパフォーマンスやセキュリティ上の理由で.NETのスレッドを抽象化するかもしれません。これは重要ですので覚えて下さい。
　覚えるべき事はまだまだ沢山ありますが、一度に沢山解説しても退屈なだけなので今回はひとまず終わりにします。次回からサンプルを交えつつ、.NET並行処理プログラミングの解説を進めます。続く...

Layers（レイヤ）アーキテクトパターン

　オブジェクト指向分析段階に位置するアーキテクトパターンの中で一番有名なのは、Layers（レイヤ）アーキテクトパターンです。Layersアーキテクトパターンは色々な技術やシステムで使用されています。例えば、TCP/IPプロトコル、OS（Unix、Windows）、大規模なシステム、ビジネス系の3階層システムなどがあります。
　Layersアーキテクトパターンとは、機能や役割を階層化して分けるアーキテクトパターンであり、極めて設計よりのアーキテクトパターンです。複雑な物事でも個別に考え場解決できるという発想から考えだされました。複雑な事柄を複数の階層に分ける事により、実装が容易になり保守性と拡張性が高められます。
　Layersアーキテクトパターンは様々な長所があります。機能や役割が階層化されているので、個別機能の交換が可能となります。一枚岩のシステムでは機能の追加や変更は大変ですが、Layersアーキテクトパターンを使用したシステムは、適切な階層に新しいオブジェクトを配置するだけで機能の追加もしくは交換が行えます。TCP/IPプロトコルを考えるとこの長所の凄さが分かると思います。TCP/IPでは、アプリケーション層を選択する事により、メールの送受信、ファイルの転送、ネットワーク機器の管理など様々な事が出来ます。また、階層へ分ける事により依存性が局所化し、一つの作業に集中できるので実装も容易になります。ただし短所も存在します。
　Layersアーキテクトパターンは設計が大変です。役割をどのように分けるのか、階層間のインタフェースをどうするのかなど様々な事を考えなくてはなりません。また、一度決定すると、階層間のインタフェースと階層の役割を変更できません。万が一変更すると、システム全体に多大な影響を与えてしまいます。例えば、ユーザインタフェース、ビジネスロジック、データアクセスの3階層システムの役割を変えると、システムの性質そのものが変わってしまいます。しかし、上手く階層化されていると、影響範囲を隣りの層だけに限定する事が出来ます。また、階層間でのやり取りにより余分な情報処理が増え、パフォーマンスが悪くなります。パフォーマンス低下が問題になる場合は、一部のオブジェクトだけ多層的な役割を持たせるなどの工夫をする必要があります。ただし、こういった工夫は保守性を下げます。十分に注意して下さい。
　Layersアーキテクトパターンは、適切に階層化すると多大な効果を生みます。しかし、失敗するとシステムが破綻します。十分によく考えて採用の有無を決めましょう。そして採用した際には、各層の役割をよく吟味して下さい。