中の人の徒然草377

最近日記を書いていないので書きます。えっと、何を書こうかな・・・
あ、そうそう。近頃、アジャイル開発について書いているから、開発モデルについて思う事を書きます。
アジャイル開発って、開発者にしてみれば、当たり前のことをまとめたものですよね。
だから、アジャイル開発は開発者のうけがいい。
ウオーターフォール開発モデルは不自然すぎます。
でも、そんなアジャイル開発にも不満があります。
それは、開発工程が一定の順序で流れるという概念に縛られている事です。
これは私自身が、交渉から納品までの全開発工程を経験して感じた事ですが、必ずしも情報は一定の順序で流れていません。
現在の開発モデルは、言うなれば直列パイプライン方式です。
しかしながら、別に並列的に仕事をしても何の支障もありません。
いえそれどころか、逆にその方が短納期で仕事が終えられます。
仕事はやれるところから、並列的にやった方が効率的です。
現に他の業種の仕事は、並列的に行われています。
それを考えないのは、先入観に縛られているからです。
こういうと、「順番どおりしないと上手くいかない」という人が登場するでしょう。
でもそれは、「いま何が出来て何が出来ないか」を把握していないから起こる事です。
例えば、テストとプログラミングは設計が終わった部分から出来ます。
ただし、出来るというのは意見を述べる事も含まれています。
つまり、分析が終わるまで待っていないで、分析時にプログラミングやテストに必要な情報を求めるなどの行為は出来ます。
私が思うに、失敗するプロジェクトは情報が足りません。
実装・テスト・設計などと言った、他の工程で必要な情報が欠落しているから、上手くいかないのです。
上流工程の人が全てを把握していて、全情報が足りるのであれば、ずっと待っていてもいいでしょう。
しかしながら、上流工程の人はえてして、下流工程の作業を十分に知らない。
だったら、初めから意見を聞けばいいという単純な話しです。
既存の開発モデルは、そういった視点が欠落しています。
各工程は必要とする情報が違い、それぞれの工程にプロフェッショナルが居ます。
その情報を全てそろえるのは不可能です。
ならば、必要な情報をなるべく早くそろえるのが当然と言えるでしょう。
直列的な開発モデルではなく、パラレルリレーションな開発モデルが必要だと私は思えてなりません。

F#2.0のアクセス修飾子にはFamilyがない！

　ちょっと驚いた事がありましたので書きます。F#のアクセス修飾子には、CLRで言う所のFamilyに相当するものがありません。Familyは、C#ではprotected、VB.NETではProtectedがそれに該当します。またCLRで言う所の、Family or Assembly（C#で言う所のprotected internal）も存在しません。
　F#でFamilyを指定できなくても、CLRには存在します。ですから、他言語で型を定義すれば、定義された型とそのネスト型、およびその派生型しか、Familyのメンバにアクセスできません。
　しかしながら、protectedは予約されており、将来サポートするつもりの様です。う～ん、不思議だ・・・

スレッド数決定問題2

　この記事はスレッド数決定問題1の続きです。引き続き、最適なスレッド数決定問題を語ります。
　前回解説したように、物理的なCPUを超える物理スレッドが生成されるとオーバーヘッドを生みますので、理想的なスレッド数は、物理的なCPUと同じであると言えるでしょう。しかし、昨今は同時マルチスレッディング技術があり、論理プロセッサ数と物理的なCPUの数が合わない事を考慮する必要があります。同時マルチスレッディング技術は、並列処理のパフォーマンスを高めますが、物理的なCPUと同じパフォーマンスの向上は望めません。例えば、同時マルチスレッディング技術である、インテルのハイパースレッディング・テクノロジーは、30％ぐらいの性能向上がみられ、将来的にはさらにパフォーマンスをアップさせるでしょうが、やはり物理的にCPUを搭載した方がパフォーマンスは良くなります。
　以上の事を踏まえると、理想的なのは物理コア数、次に良いのは論理コア数と同数のスレッドが望ましいと言えます。望ましいという表現でとどめているのは、最初で述べた理由から、それで話しが終わらないからです。
　きりがいいので今回はこれで終わります。続く・・・

アジャイル開発と契約13

　この記事は、アジャイル開発と契約12の続きです。今回は、基本契約に於いて重要な要素である、知的財産の取り扱いについて解説します。
　前回少し触れましたが、アジャイル開発を行うと、知的財産の所有者が曖昧になる傾向があります。それ故、知的財産のトラブルが発生しやすいので十分な注意が必要です。
　知的財産の問題は、ユーザーとベンダー間だけの問題はありません。殆どのシステムは共同開発をしており、開発側の会社間で、知的財産の問題が発生する場合があります。ですから、基本契約を結ぶ際に、ある程度のルールを契約という形で取り決める必要があります。開発側がこれを怠ると、権利保障も出来なくなります。
　実体験から言いますと、日本では知的財産の扱いに疎く、曖昧なまま問題が有耶無耶にされる事が多く、時には権力が強い会社が強奪する形で、纏められる事すらあります。多重下請け構造の日本では、知的財産の扱いがなきに等しいのが現状です。また、日本そのものが知的財産について遅れています。
　しかし、これからの時代は、知的財産を重視する海外の会社も参加する機会も多くなります。この時、知的財産を有耶無耶に扱ったり、知的財産の強奪などの非常識な言動をすれば、日本の会社は見限られます。他社や開発者個人の知的財産を認め、常識的な行動を心がけましょう。
　日本では発注者は神様であり、元請けは神の代理人として振舞いますが、それはビジネスではありません。それが通用するのは恐らく日本だけです。共存共栄を目指して、常識的な契約を結びましょう。
続く・・・

スレッド数決定問題1

　この記事は、スレッド数決定問題の続きです。引き続き、最適なスレッド数の決定について語ります。
　話しを進める前に、基礎的な事項を書きます。プログラムは、端末に搭載されたCPUが動作する事により処理されます。昨今のPCは、その多くが複数のCPUが搭載されています。処理速度の向上は、複数のCPUの稼働率を上げる事により行います。処理速度を向上させる方法は他にもありますが、CPUを有効に使うのが基本なので、焦点をCPUに絞って話しを続けます。
　並列処理は複数のCPUを有効に使用し、全体の処理速度をUPさせます。しかし、実行させたい処理の数は、搭載するCPUの数よりも多いのが普通です。従って、如何にして処理単位を振り分けるのかが問題となります。
　OSは処理するプログラムを、スレッドもしくはそれに酷似した概念の単位でスケジューリングします。複数のスレッドが生成されるとOSは、実行するプログラムを選択し、CPUに割り当てます。この時、実行するプログラムを切り替え（コンテキストスイッチ）たり、次の実行するべきスレッドの決定をしたりせねばなりません。それらのスケジューリング処理には、それ相応のコストが必要となります。何故ならば、スケジューリング処理もまた、プログラムで出来ているからです。考えずにスレッドを大量生成すると、これらスケジューリングなどの処理にCPUが占領され、余計にパフォーマンスが下がります。
　続く・・・

強力なfor...in 式と警告について

　F#のfor...in式は、一見C#のforeach文と同じですが、パターンマッチが行われるので非常に強力です。

//Sample
type Foo =
  | One of string
  | Two of string * int
;;
let list = [ One "1"; Two( "2", 2 ); One "2"; ];;

#nowarn "25" //警告が出ないようにする
for One( number ) in list do
  printfn "%s" number
;;

このサンプルが示す様に、リストに格納された、任意の判別共用体の要素だけ出力できます。しかし、残念な事に警告が出ます。警告は無視する事が出来ますが、#nowarnはグローバルなので、他のプログラムの警告25が消されて困ります。
　健全な方法は、#nowarnを使わないで、警告が出力されないようにする事です。

//警告が出ないやり方
for value in list do
  match value with
    | One( str ) -> printfn "%s" str
    | _ -> printf ""
;;

こうすれば警告は出ません。その代わり、生成されたILを調べると20バイト増えていました。それにこの解決法は美しくありません。警告をローカル範囲内で、有効／無効化出来る機能があればいいのに。

スレッド数決定問題

　今回は、並列処理システムに於いて、スレッド数を決定する事が如何に困難なのかを語ります。並行処理システムを設計する際の参考になれば幸いです。
　意外だと思われるでしょうが、スレッド数を決定するのは非常に困難です。どうやら、全ての並列処理に適用できる完璧な答えは存在しないようです。その要因は、大まかに言うと4点あります。
　１つめの要因は、システム設計時に、端末内のスレッド数を算出できない事です。端末は色々なソフトウェアがインストールされていますし、将来新しいソフトウェアがインストールされる事でしょう。端末内で作動するスレッドの合計数が算出できません。
　2つめの要因は、OSごとにスケジューラが異なる事です。複数のOSからなるシステムを構築する場合は、OSごとに最適なスレッドの操作方法を変える必要があるかもしれません。また、OSのスケジューラは、基本的に公平にスケジュールするので、その動作が並列処理のパフォーマンスという観点から見て、最適とは言えない場合があり得ます。
　3つめの要因は、言語や環境などでスレッドのコストが異なる事です。C++やCを使って、ネイティブなスレッドを使って並行プログラミングをすると、ハードウェアで実際に動作する物理的なスレッドと、プログラミングで扱う論理的なスレッド数がほぼ同じになります。しかしながら、他の言語では事情が異なります。例えば、プログラミング言語OZの処理系Mozartでは、スレッドのコストが非常に低く、大量にスレッドを作っても軽快に動作します。これは言語だけに限った話ではなく、ライブラリでも起こる事です。例えば、インテルTBBは、タスクという概念を使って、物理スレッドの生成を管理しています。仮想マシンを使用する言語の処理系も、スレッドのコストを減らす努力をするでしょう。それにより、実際に動作している物理的なスレッドの把握が困難になります。
　4つめの要因は、大局的に考える必要がある事です。各プログラマが、担当するプログラムに大量のスレッドを割り当てると、システム全体のスレッド数が非常に多くなる可能性が十分にあります。また、構築するシステムのソフトだけを考えずに、OSが使用するスレッドや、併用が予想されるアプリケーションが使用するスレッド数も考慮しなくてはなりません。それを考えずに、スレッドを生成すると、大量のコンテキストスイッチが発生し、結果として余計にパフォーマンスが落ちてしまいます。
　長くなるので続く・・・

並列処理と処理時間の測定

　並列処理を行う主な理由は、処理時間の短縮ですので、並列処理の処理時間に関する事柄について解説します。
　並列処理の初心者は、CPUのコア数が2個ならば処理時間は50％という風に、処理能力がコア数倍になると誤解する人が多いと感じます。しかし、残念ながら現実はそう甘くありません。並列処理は必ず、逐次処理にはないオーバーヘッドが存在しますので、コア数倍にならないのが普通です。
　まれに、コア数以上に性能が向上する現象であるスーパリニア高速化（superlinear speedup ）が発生しますが、大概はプログラミングミスの結果です。ですから、スーパリニア高速化が発生した場合、並列処理が正しく行われているか良く確認する必要があります。
　スーパリニア高速化は、測定プログラムのミスの結果生まれる事が多々あります。具体的に言うと、簡単な測定プログラムを組むと、サンプルデータがキャッシュヒットし、実際以上に処理速度がUPしたと報告される場合があります。そういった間違いを犯さない為に、並列処理の高速化率を測定する場合は、並列化に対応したプロファイラを使用するのが得策だと言えます。
　目安として、コア数が2ならば1.998、コア数が4ならば3.996という風に、コア数＊0.999（オーバーヘッド率の仮定値）が理想値だと考えるとよいでしょう。そうすれば、簡単に怪しい測定結果を見抜けます。
　では、スーパリニア高速化率が測定された場合、全てがエラーかというとそうではありません。直列アルゴリズムと並列アルゴリズムに大差がある場合、スーパリニア高速化が実現する可能性があります。逐次処理を前提とした直列アルゴリズムは、現実と乖離した非効率的なアルゴリズムである場合があります。その場合、並列アルゴリズムに書き変える事により、処理速度を大幅に短縮できる事が出来ます。
　並行プログラミングをする際には、処理時間の測定を慎重に行いましょう。

F#と変数

　厳密に言うと、F#は関数型言語なので、Java言語の様に変数というものは存在しません。F#では、値を名前に束縛すると考えます。ですから、F#の値は基本的に不変であり、次のサンプルコードはエラーになります。

//Sample
let x = 0;; 
x = 10;; //変更できないのでエラーが発生

　F#は関数型言語なので、基本的に不可変な値を使ってプログラミングを行います。しかし、F#は純粋関数型言語ではないので、可変値を宣言する方法が用意されています。

//Sample1
let mutable x = 0;; 
x <- 10;; //<-で新しい値を指定

代入文（　=　）ではなく、代入式（　<-　）を使っている点に注意して下さい。文ではなく式なので、unit型の値を返します。
　mutableを使用すれば、変数と同じ感覚でプログラミングが出来るかもしれません。しかし、その誘惑に負けて、代入式を多用してはなりません。可変値を多用すると、バグが発生しやすくなります。

アジャイル開発と契約12

　この記事はアジャイル開発と契約11の続きです。今回は、権利保障におけるアジャイル開発特有の課題について解説します。
　権利保障上のアジャイル特有の課題は、開発参加会社の知的財産の扱い方です。権利保障をするには、知的財産の問題をクリアにする必要がありますが、アジャイル開発ではそれが困難になる場合があります。何故ならば、アジャイル開発は、活発にコミュニケーションをするので、知的財産の所有者が曖昧になる恐れがあるからです。複数の会社が意見を出しあって知的財産が生まれた場合、誰が所有者になるのかが問題となります。
　ウォーターフォール開発モデルの場合、上から下へと工程を明確に区切り、作業が進められるので、比較的知的財産の所有者が明確です。しかし、アジャイル開発の場合、開発工程はあるものの、その区切りはウォーターフォール開発モデルよりも曖昧になる傾向があります。分かり難いと思いますので、具体例を挙げます。
　例えば、エンドユーザーと開発関係者が話し合い、ビジネス特許を取得できるシステムを開発した場合、所有者はどちらになるでしょうか？この場合、エンドユーザーだけでは、この斬新なシステムは発明出来なかったでしょう。しかしながら、業務知識に疎い開発会社が単独で発明する可能性も低いでしょう。従って、合理的に考えるのであれば、両社が知的財産を保有すると考えるとよいでしょうが、両社の都合上公平に分けるのは難しいのが現実です。
　エンドユーザー側の視点から考えると、自社のシステムの権利の一部を開発会社に持たれた場合、運用に差支障が出る恐れがあり、権利保障されていると言い難い状況になります。一方、開発した側にしてみれば、ビジネス特許を取得できるシステムに、自社の技術力を使用しているわけですから、エンドユーザーに全ての権利を譲ってしまうと、今後の開発業務に支障が出る恐れがあります。
　知的財産の問題は難しく、完璧な答えがありませんので、あらかじめ方針だけでも考えておく必要があります。こうした問題は、予想していた方が解決出来る可能性が高くなります。対策例を挙げると、全てのメールを保存しておく、議事録をしっかりとる、ソフトウェアの知的財産に強い弁護士とのコネクションを持つ・・・などがあります。

　続く・・・