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

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方の続きです。前回は導入部分で終わっていましたので、今回はプロジェクトマネージャの役割の基礎について書きます。
　本来行うべきプロジェクトマネージャの仕事は、経営資源を活用しプロジェクトを成功させる事です。経営資源についての考え方は諸説あるようですが、この記事ではプロジェクトに関する事以外は採り上げません。プロジェクトで考慮するべき経営資源は金・物・人・情報・時間です。他のエンジニア（これ以降開発者と表記します）は技術的観点からプロジェクトに貢献しますが、プロジェクトマネージャは、自社に存在する経営資源を適切にコントロールしてプロジェクトに貢献します。従って、開発者とプロジェクトマネージャはものの見方が違います。この点に注意が必要です。開発者と同じ視点では、良いプロジェクトマネージャになれません。また、開発者側もプロジェクトマネージャの視点を知らないと、良いシステムを開発できません。
　専門書に書かれている架空のプロジェクトとは違い、現実のプロジェクトは経営資源を考慮せずに遂行できません。例えば、高級な開発ツールを用意し、最高の技術者を雇えば最高級のシステムを開発できる場合を想定します。
　そのケースで先ず考えなくてはならないのは、お客様がその最高級のシステムを欲しているかどうかです。私たちは商売でシステムを開発しているのですから、売れないものは作れません。また、お客様が欲している場合でも、適切な価格を支払わない状況下でシステムを開発したりしません。利益がないプロジェクトはそもそも開始できません。
　仮にそのシステムが利益を挙げられる場合、次に考えるべき事はどうやってその資源を獲得するかです。その最高級の開発ツールはどうやって入手するのか、そのツールの価格は採算が取れるのか、最高の技術者が自社にいるのか、居ない場合どうやってプロジェクトに参加させるのか・・・といった現実面を考えなくてはなりません。
　その他にもプロジェクトマネージャが考えるべき事は沢山あります。無事プロジェクトが開始しても、それは苦難の始まりにしか過ぎません。プロジェクトを取り巻く状況は常に変化し、プロジェクトマネージャはそれをコントロールし続けねばなりません。開発者の仕事と同様に、プロジェクトマネージャの仕事は非常に困難です。

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

　私がアジャイル開発を推進する際によく聞かれる質問が、プロジェクトマネージャのあるべき姿です。これは、多くの人が疑問に感じている事だと思いますので、記事を書く事にしました。
　先ず理解しなくてはいけないのは、アジャイル開発における工程管理は、人間が見通せる範囲で管理を行うものだという事です。アジャイル開発を開発者の気ままに開発を進める開発論だと誤解している人もいますが、それは大きな間違いです。開発者の本能のおもむくままにプログラミングする方法は、アジャイル開発ではなく悪名高いスラムダンク方式です。アジャイル開発は、変化を受け入れて人間が出来る範囲で行う開発方法です。
　しかしだからと言って、ウォターフォール開発モデルと同じ方法で管理するのは間違いです。ウォターフォール開発モデルが失敗している原因は、人間の本質と現実を考慮していない点にあります。ですから、従来の現実を直視しない方法で管理しようとしても、現実主義の開発者から疎まれるだけです。プロジェクトマネージャは、現実主義でなくてはなりません。これは開発方法論と関係のない揺るぎない真理です。ウォターフォール開発モデルで開発しなくてはならない環境でも、現実を直視しなくてはなりません。
　ではどうすればいいのかといいますと、プロジェクトを成功させる環境作りをするという視点でプロジェクトを管理すると成功します。そもそも、日本人が考えているプロジェクトマネージャの仕事範囲が狭すぎるので、この様な疑問や開発者との摩擦が起きます。
　manageの英語本来の意味は、「物事、特に困難を伴う事を何と...かする」で、そこから色々な意味が派生（英語語義語源辞典を参照）しています。すなわち、プロジェクトを成功させる事を目指して仕事をするのが本来の役割です。日本では残念ながら、「マネージ」は和製英語化し、本来の意味の一部である「責任者もしくは支配者」の意味しか広まっていません。そこが間違いの元です。終身雇用という現実を無視した無茶を、年功序列制度で支えようとした結果、プロジェクトを何とかする人ではなく、責任者＋支配者という側面だけが誇張されてきました。
　日本は仕事の能力ではなく、職位や年齢で報酬が決まる世界的には非常識な文化を持っています。これが悪影響を及ぼし、プロジェクトマネージャは残念ながら、何も知らない支配者になってしまいがちです。しかし、本来プロジェクトマネージャの仕事は、もっと有意義でやりがいのあるものです。決して経営者の責任逃れのためにある肩書きではありません。
　その事を伝えるべく、本来のプロジェクトマネージャの仕事を題材とした記事をアップしていきます。続く...

実践的オブジェクト指向分析入門20

　この記事は、実践的オブジェクト指向分析入門19の続きです。前回は、オブジェクト指向分析とテストの関係について述べました。今回は、オブジェクト指向分析とプログラマの関係について述べます。
　分析段階といえば、実装段階で活躍するプログラマは関係ないと思われがちです。特にウォータフォールな思想が未だに根強い日本では尚の事です。しかし、広義のプログラマの能力は分析段階にも役立ちますし、やるべき事があります。むろん、日本特有のコーダーには無理ですが、海外で言う所のプログラマには分析段階でも活躍できます。
　開発に於いて一番重要なのは、仕様書の妥当性です。仕様書にエラーが含まれている事が多く、仕様書のエラーほど厄介なものはありません>。分析段階では、仕様書を作っていきますので、仕様書の妥当性をチェックしなくてはなりません。
　仕様書の妥当性をチェックする能力はプログラマに備わっています。私自身システム構築際に、セキュリティエンジニア、データベースエンジニア、システム管理者、テスター、プロジェクトマネージャ、開発者の視点で分析を行っていますので断言できます。
　仕様書の妥当性をチェックする能力は、実装作業を行っている時身に付いたものです。実装作業は仕様書に従って行われます。ですから、仕様書に対する目が肥えます。また、プログラミングで培った物事を分析する姿勢も分析段階で役立ちます。すなわち、何をどう分析するべきなのかが大切だと言えるでしょう。
　分析段階で実装段階の事をしてはなりません。そんな事をしてしまうと、視野が狭まって現実世界の分析が出来なくなります。しかしながら、実装が出来ない分析結果を出すのはそれ以上に問題です。実装作業の経験がない人は、現実に存在する情報を、上手くコンピューターの世界の情報へ変換する事が出来ません。それが原因で、実装できないシステムの仕様書が出来上がってしまいます。
　分析段階で必要なのは、実装で必要とされるプログラミングのテクニックではなく、物事を分析する能力である点に注意して下さい。分析段階と実装段階を正しく区別して考えないとプロジェクトは失敗します。オブジェクト指向分析は現実世界を分析する行為を指しています。オブジェクト指向プログラミングは、コンピューターの世界で実現する事です。現実世界とコンピューターの世界はかなりの隔たりがあります。ですから、過程をいきなり飛ばしても失敗します。現実世界の情報をコンピューターの世界の情報へと、少しずつ変換していく事が非常に重要です。

雑談：今時のC++教育を考える

　今からC++を学習する人は、どのように教えたらいいのだろう。そして、どこまで教えたらいいのだろうか？C++を教えて欲しいと言われた時、よく私はこの課題を考えます。C#やJavaなどと比べて、C++を教えるのは難しいと感じています。
　その原因はC++が、Cとの互換性を維持しつつ（C99とはないけどね）、マルチパラダイム言語化しているからです。C#やJavaといった後続言語と比べて、その辺がごちゃごちゃしている印象がぬぐいきれません。それがチャームポイントなのですが、教えるとならば話しは別。やり辛いです。
　ひとまず私は、オブジェクト指向の側面から教えるのがよいと考えています。C++の目的はオブジェクト指向だから、言語設計思想からズレていないと思います。あとは、テンプレートは是非教えたいです。テンプレートはC++の大きな魅力。テンプレート無くしてC++と呼べません！
　しかし、テンプレートはオブジェクト指向以上に教えにくいです。オブジェクト指向は方法論がありますが、メタテンプレートプログラミングや、ジェネリックなテンプレートプログラミングに方法論はありません。テンプレートは、STLや標準ライブラリのソースを読むのが、一番の訓練方法です。自分で実装してみれば、テンプレートプログラミングがよく分かります。でもこれは、万人にお勧めできる方法ではありません。私は未だにテンプレートを上手く教えられません。
　それに加えて、スライスなどのバイナリな落とし穴がC++にはあります。C++の魅力は、こういったダーティな部分にあると思うのですが、それを伝えるのは難しいです。今時の人は、初めての言語がJavaとかC#の人がいるから、そんな安全な言語を知っている人にC++の危険な魅力を言っても「面倒」だと言われそうです。アセンブラとC言語をやった事ない人に、C++の魅力を伝えるのは難しいです。
　C言語やアセンブラをやった人ならば、C++の魅力が分かると思うのですが、偉大なるまつもとゆきひろ氏はC言語を使い続けると言っているし、スーパーハッカーのリーナス氏もC++が好きでないという噂を聞いた事があります。
　ということは、Cやアセンブラをやって、今時の高級言語にない機能が好きな人だけC++を好きになるのかもしれませんね。といっても、最近の.NET言語も教えにくいかもしれません。バージョン1からしている人にとっては普通の事でも、今から学習をする人には敷居が高くなっているかもしれません。どんどんマルチパラダイム化しているからLINQとかラムダ式とかわかるかな？
　もしかしたらC++に限らず、どの言語でも今から学ぶ人は大変かもしれません。そういえば、F#も教えにくそうです。私はプログラミングF# と仕様書で分かりましたが、初心者にはきついかもしれない。F#は初心者にどう見えているのかな？

中の人の徒然草393

昨晩、PEファイルのデバッグ情報まで取得する事に成功しました。
これでよりDUMPBINに近づきました。
実装して分かったのですが、DUMPBINってそこまで難しい処理をしていないんですね。ちょっと意外。
そういえば、VCのデバッグ情報って、PDBファイルに格納されているんだよな。EXEファイルに格納されているのは、PDBファイルのパスだけ。肝心な情報は全てPDBファイルにあります。
嗚呼、知的好奇心が疼く。PDBファイルの解析がしたくなった。

中の人の徒然草392

今晩ピヨ♪今日もプログラミングにはまっているインドリです。
昨日の晩からPEファイルの解析にはまっています。
昔遊びでコンパイラ作った時にやった事ありますが、詳細を忘れていたので改めてしています。
PEファイルの解析というと難しく聞こえますが実は凄く簡単です。
仕様書を読みながらファイルをバイナリ形式で読みとるだけです。
プログラミングとしては簡単で単調な作業ですが、知的興奮が味わえます。
DUMPBINをお供にテストファーストで行っていると、徐々にファイルの秘密が明らかになっていくので、非常に楽しいです♪
PEファイルの解析ツールが出来上がったら、次はリンカの実装に挑戦します。
昔リンカまでやろうと思っていたのですが、仕事に追われてちょっとしか出来なかったorz
ということで、仕事が速くなって余裕が出来た今、再チャレンジしています。
多分3月中にはリンカの実装に移れるはず。
リンカが終わったらアセンブラの実装をします。
アセンブリ言語の実装も昔ちょっとした事あるのですが、当時よりもIntelの機械語フォーマットが複雑になっているから楽しそうです。
アセンブリ言語は使用さえわかれば簡単ですが、マクロがちょっと厄介です。
マクロを導入するとミスしやすくて、当時は難しいと感じました。
でも、当時よりもかなりプログラミング力がレベルアップしたから、今は大丈夫かな？と楽観視しています。
リンカとアセンブリ言語の実装が終わったら、次は本格的なコンパイラの実装をやります。
それが終わったらやっぱりOSです。
仕事用の学習や急用も入るから中々進まないと思いますが、少しずつ自分の知的好奇心を満たしていきます。
それが私にとっての一番のストレス解消法です。
やはり仕事用の学習よりも、自分の知的好奇心を満たす学習の方が楽しいです。

実践的オブジェクト指向分析入門19

　この記事は、実践的オブジェクト指向分析入門18の続きです。前回は、オブジェクト指向分析とシステム管理の関係について解説しました。今回は、オブジェクト指向分析とテストの関係について述べます。
　オブジェクト指向分析時にも、テストに関する情報の分析は必要です。ただしテストと言っても、プログラムの成否を判定するものではありません。プログラムは実装段階で実行します。オブジェクト指向分析の段階でするべき事は、仕事のチェックがどのように行われているかと、何が正しいのかを分析する事です。
　品質のチェックは基準無くして出来ません。品質が悪いシステムが出来上がる理由は、最初から基準が考えていないからです。お客様にとって、何が正しくて何が間違っているのかをはっきりしないと、曖昧なチェックしか出来ないシステムになってしまいます。開発側の人間が自分たちの基準だけで物事の成否を判定するのではなく、お客様の判断基準を取り入れて品質のチェックを行わないとなりません。テストは実装段階以降でするべき作業ではありません。全工程でテストし続けないと駄目なのです。
　システム開発でありがちな間違いは、ウォターフォール開発モデルの発想で、テストを実装段階が終わってから行う事です。納期が近付いている段階で、人は正確にテスト出来ません。そういった過ちをしてしまうと、テストが不十分なまま出荷し、後で不備が発覚してしまいます。これは、ビジネス上非常に大きな損失です。どのようなソフトウェアも、バグが絶対にないとは言い切れませんが、だからと言って始めから品質管理をしない体制はルーズと言わざるをえません。
　また、お客様の仕事のチェック体制に目を向けることも大事です。システムはその作業を妨害してはなりません。業務に於いて仕事のチェック体制は非常に大切で、システムはその体制を補助しなくてはなりません。システムがエラーを出すのは問題ですが、お客様のチェック体制を妨害するのはそれ以上に問題です。システムを導入したために不備が生じたとなれば、最悪の状態だと言えます。
　テストはプログラムだけをチェックするものではありません。システム全体の動きと、開発作業そのものをチェックしなければなりません。オブジェクト指向分析の段階で、その為の情報を積極的に分析しましょう。テストといえば、開発作業終盤のイメージを持つ人が多いですが、エンドユーザーのヒアリングなど、やるべき事が沢山あります。

Win32並行処理プログラミング入門24

　この記事は、Win32並行処理プログラミング入門23の続きです。今回も引き続き、イベントカーネルオブジェクトに関する関数を解説します。
　イベントカーネルオブジェクトは、シグナル状態と非シグナル状態を持ちます。シグナル状態にするにはSetEventを、非シグナル状態にするにはResetEvent関数を使用します。この他にも、イベントカーネルオブジェクトをシグナル状態にした直後、直ちに非シグナル状態にするPulseEvent関数があります。以前にも述べましたが、自動リセットイベントにした場合、ResetEvent関数を使用できません。
　話しは変わりますが、リセットイベントの有無は、イベントカーネルオブジェクトの用途によって使い分けます。細かい制御が必要な場合は、手動リセットイベントを選びます。一方、細かい制御が必要でない場合は、自動リセットイベントを選ぶとよいでしょう。
　イベントカーネルオブジェクトは、非常に単純なオブジェクトです。ですがその分、色々使いどころがあります。イベントカーネルオブジェクトを使用する練習をしておくと、後でその経験が役に立つでしょう。

実践的オブジェクト指向分析入門18

　この記事は、実践的オブジェクト指向分析入門17の続きです。前回は、オブジェクト指向分析とデータベースの関係について解説しました。今回は、オブジェクト指向分析とシステム管理の関係について解説します。
　システム管理はオブジェクト指向分析で漏れやすい分野です。分析はあくまでも現実をモデル化する事なので、設計と運営に結び付きやすいシステム管理を考えてはいけないと誤解している人が多くいるようです。しかし、現状分析には既存のシステムと業務分析が含まれています。その観点から、現在のシステム管理の状態を分析するのは、オブジェクト指向分析の精神に合致しています。
　既存のシステムとそれを扱う体制を分析すると、エンドユーザーが受け入れられるシステムの要件が分かります。人は前よりも面倒なシステムを許容しません。真システム導入後に負担が余りにも増えるのは本末転倒です。システムはあくまでもエンドユーザーの業務を効率化するために構築されるものです。ただシステムを開発するのではなく、それがどう運営されるかまで考えてなくてはなりません。
　既存システムを持たないエンドユーザーであっても、システム管理の視点は重要です。エンドユーザーがどれだけ情報処理に対応できるのか分析する事は大事です。情報機器を上手く使いこなせない人が多い場合は特に、システム開発だけではなく教育にも工夫が必要です。システムが導入されてから教育を行うのではコストが高すぎます。コストが高いシステムの導入は敬遠されますので、導入コストを下げる事は非常に大事です。
　主役はあくまでもエンドユーザーであり、システムや開発者が主役であってはなりません。派手で目立つシステムよりも、地味で効果的なシステムを開発しましょう。開発前の状態ではエンドユーザーは派手さを好みますが、開発後は地味さを求めます。矛盾していますが、それが人間心理です。誰しも生活に負担がかかる電子機器を望みません。例えば、毎日予定どおりの生活を強要される携帯電話を、買う人はまずいないでしょう。携帯電話が根付いたのは、人間の生活を邪魔しないからです。システムも携帯同様、エンドユーザーの業務を邪魔してはなりません。開発者は陰の存在なのです。例えるならば、良い開発者は忍者だといえるでしょう。
　システム管理とセキュリティは対立しやすいので、その辺は十分に注意して下さい。セキュリティを高めると、システムの使い勝手は悪くなります。しかし、だからと言ってセキュリティをないがしろにできる時代ではありません。そのバランスが大事です。

Win32並行処理プログラミング入門23

　この記事は、Win32並行処理プログラミング入門22の続きです。今回は、CreateEventEx関数の解説を行います。
　CreateEventEx関数は、CreateEvent関数とほぼ同じです。第一パラメータはセキュリティ属性、第二パラメータはイベントの名前、第三パラメータはフラグ、第四パラメータはハンドルのアクセス権限です。違いはアクセス権限を設定できる点にあります。
　CreateEvent関数で作られたハンドルは常にフルアクセスですが、CreateEventEx関数は権限を設定してハンドルを作れます。サンプルでは、SetEvent関数・ResetEvent関数・PulseEvent関数・同期用関数のアクセス権限を設定しています。なお、PulseEvent関数は、イベントをシグナル状態にした直後に、直ぐに非シグナル状態にする関数です。
　アクセス権限の効果を確かめたい人は、Win32並行処理プログラミング入門21のサンプルを変更して下さい。

//CreateEventExの場合
hEvent = CreateEventEx( 
    0, 
    _T("piyo"), 
    CREATE_EVENT_MANUAL_RESET, 
    EVENT_MODIFY_STATE ); 

第四パラメータのSYNCHRONIZEを消して実行すると、WaitForSingleObject関数がエラーを返し、メッセージボックスにエラーが表示されます。このエラーは無視出来てしまう点に注意して下さい。戻り値を判定しないと、処理がそのまま進んでしまいます。試しにエラー処理を消してみて下さい。待機関数の意味がなくなり、処理が進んでしまうのが分かります。

//指定されたメッセージをコンソールへ出力し続ける関数
unsigned __stdcall MessageOutput( void* ) 
{
    while( - 1 ) {

        //データが初期化されるまで待つ
        DWORD result = WaitForSingleObject( hEvent, INFINITE );

        //エラーがあれば表示
        /* ここから
        if ( result == WAIT_FAILED ) { 
            LPVOID title = _T( "エラー" );
            LPVOID msg;
            FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER |
                    FORMAT_MESSAGE_FROM_SYSTEM |
                    FORMAT_MESSAGE_IGNORE_INSERTS,
                __nullptr,
                GetLastError(),
                MAKELANGID( LANG_NEUTRAL, SUBLANG_DEFAULT ), 
                reinterpret_cast< LPTSTR >( &msg ),
                0,
                __nullptr
            );
            MessageBox( __nullptr, 
                reinterpret_cast< LPCTSTR >( msg ) , 
                reinterpret_cast< LPCTSTR >( title ), 
                MB_OK | MB_ICONERROR );
            LocalFree( msg );
            return -1;
        } 
        ここまでコメントアウト*/

        //データを出力
        cout << msg.get_Message() << "　";

        //出力スピードを遅くする
        Sleep( 50 );
    }
    return 0;
}

これはWin32プログラミング全般に言える事ですが、エラーに十分な注意を払って下さい。
　エラー処理をするのが面倒で、CreateEventEx関数を使用したくない人が要るかもしれませんが、CreateEventEx関数の使用をお勧めします。Windowsはセキュリティが強化される方向でバージョンアップしています。アクセス権限を正しく設定した方が、将来のバージョンに対応できる可能性が高くなります。