2009年2月20日金曜日

2009年2月19日木曜日

最近ていうか昨日買った本。

「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング 」 
http://www.amazon.co.jp/dp/4873113954/

  受託の開発案件でアジャイルを採用するには、、、?
  そんなことを考える今日この頃。これから読みます。


「Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本」
http://www.amazon.co.jp/dp/487311392X/

ノリだね。思わず買ってしまった。そのうち読みます。


「JUDEで学ぶシステムデザイン (oop Foundations)」
http://www.amazon.co.jp/dp/4798114766/

会社の昼休みにちょっとずつやってみることにしました。


私が所属している会社は「RIA」の開発をやっています。
昨日、勉強会にいったこともあるので思うのですが、今後は「クラウド」を使う頻度は高くなるはずです。
開発会社としてはノウハウは必須。
さらにお客さまにとって価値あるシステムをとどけるには「アジャイル」が必要なんだと思います。
受託の開発でアジャイルを採用するにはかなーり閾が高い(お客さまが嫌がるケースが多い)のですが、なんとかしないとならんだろうと。

プロジェクトで利益がでても、お客様にとって無価値なシステムを納めたら、イコール、私たちはお客様にとって無価値だと思うんですよ。





多分ね~。

2009年2月18日水曜日

○aaS

CaaS

このあいだ日経SYSTEMSで"IaaS"ってみたな。
流行か。。。

SaaS
PaaS
IaaS
CaaS ←いまここ

2009年2月10日火曜日

開発プロセスにおける妄想

特に使い道のない妄想を書いたのでblogにはっておく。

【目標】正しいアジャイル型のプロセスをもつ組織になる
【補足】アジャイルの肝は規律である!

【目標】顧客にとって本当に価値のあるシステムを構築しやすいプロセスをもつ組織になる
【補足】単純な人月の論理を顧客に押しつけないこと。顧客の満足をめざし、そこから得られるチームの喜びに執着すること。

実現するためには。。。

1.開発プロセスの標準化について

「プロセス」という上段から入ると収集がつかなくなるか本当に大切なことを見落とすことになる。なぜならプロセスは「概念」レベルだから。まずはプロジェクトを遂行する上で計画や作業の抜け漏れを防ぐために「アクティビティ」の洗い出しを優先する。

(参考までに)
 プロセス     概念。作業手順を抽象化したもの。
 └アクティビティ 論理。動きや振る舞い、活動を表す。
  └タスク    現実、物理的なもの。人やモノに結びつく。対象物が存在する。
 
 プロセスの標準化において、現時点で洗い出すものを「アクティビティ」のレベルとしたのには理由がある。
 プロセスのレベルではあまりにも抽象的すぎて営業レベルで話す分には問題がないかもしれないが、プロジェクトに適用するのは無理。そもそも抽象の度合いが強すぎて解釈が大幅にぶれる。タスクのレベルは実際のプロジェクトでないと決めることが難しく、現実のプロジェクトにおいても日々増減をするものなので、事前に決めるのには無理がある。
 
 
2.アクティビティの洗い出しについて(マッピング)

プロジェクトにおけるアクティビティは多い。そこでPMBOKの5つのプロセスと9つの知識エリアを利用してマッピングをして整理する。

<PMBOK>
http://www.netlaputa.ne.jp/~hijk/study/docs/pmbok_overview.html#AContents
 プロジェクトのプロセス
1.立ち上げのプロセス プロジェクトの次のフェーズの着手を組織としてコミットする。
2.計画のプロセス
3.遂行(実行)のプロセス
4.コントロールのプロセス 計画からの乖離を識別するために、 プロジェクトの進捗は定期的に測定する必要がある。
5.終結のプロセス
 知識エリア
統合マネジメント
スコープマネジメント
タイムマネジメント
コストマネジメント
品質マネジメント
組織マネジメント(リソース)
コミュニケーションマネジメント
リスクマネジメント
調達マネジメント

 なぜPMBOKなのか? それはPMBOKがプロジェクトの「順序」よりも扱わなければならない「事象」に重きおいているからだ。
 順序が間違っていても、扱う事象が正しければプロジェクトはいつかは終わる。逆に順序が正しくても、扱う事象が間違っていればプロジェクトは終わらない。


3.アクティビティの洗い出し(なにから手をつけるか?)

 最初にコミュニケーション、次に品質から洗い出すことをオススメしたい。もちろん理由はある。ちょっと遠回りだが説明をする。
 プロジェクトにおいて「早い、安い、旨い」の3つを実現するのは難しい。何か1つを犠牲にすれば2つは実現できる。しかし3つ全部はそれなりに考える必要があるが優先順位をつけることで打開できはずだ。
 
 「早い」
 逆の視点。遅いはどうだろうか? システム開発において遅いはあらゆる観点で罪だ。遅いは「高い」にもつながる。

 「旨い」
 品質は早いを実現する必須条件である。プロジェクトの進捗を滞らせる原因はあらゆるフェーズに潜むバグである。プログラムのバグもそうだが、プログラムのバグの元になる設計のバグ、設計のバグの元になるコミュニケーションのバグ。これらは手直しに工数を要するため結果として早さと安さを犠牲にしてしまう。
 つまり「旨い」は「早い」につながり、結果として「安い」を導き出す。3要素を高レベルで達成することを目指さないと、これから先の開発ベンダーは生き残っていくことが厳しくなってくる。
 ならば品質から着手するべきではないかと思ってしまうが、結局、品質を下げる原因になるのはコミュニケーションのエラー(バグ)だ。認識の違い、情報共有の拙さがエラーを生み出し貴重な時間を浪費することになる。また顧客が本当に必要とする価値のあるシステムにたいする要求を拾い上げる妨げにもなる。だから洗い出すべき最初のアクティビティはコミュニケーションを中心に行う必要がある。
現実のプロジェクトにおいても、品質要件や非機能要求は顧客とのコミュニケーションから生み出される。目標もはっきりしなければどの程度の品質を確保すればいいのかすらわからないはずだ。



4.モデルプロジェクトの構築

PMBOKへのマッピングが終わったらモデルプロジェクトを構築しレビューを行う。まず手始めに10~20人月程度のプロジェクトを想定してみると良い。10人月未満のプロジェクトではプロセスはそれほど大切ではなく個々人のスキルに依存する割合が高い。20人月を超えるプロジェクトはより厳格なプロセスが必要になり扱いが困難になる。10~20人月のプロジェクトをしっかり運営できるようにすることから始めるのは決して悪い話ではない。
そしてしっかり洗い出されたアクティビティがベースになっていれば、抜けや漏れがあることは考えづらい。今度は「冗長」なアクティビティを省略する作業を行う。これも「早い、安い、旨い」を高レベルで達成するために必要な手段である。


5.注意点

これらの作業を進めていく上で気をつけること。おそらくいろいろな要素が関連し合い、まとめたり洗い出したりする作業が困難になってくる時期がある。そういうときは下記の原則を思い出すこと。

・インプットとアウトプットに着目し、シンプルに考える
・正しい行動は「考える、実行する、確認する」の3つの要素でなりたっていること。迷ったらこれを思いだしシンプルに考える。

アクティビティの洗い出しを進めるとき、序盤でどれくらいの時間がかかったのか記録をしておこう。こうすることであとどれくらいで作業が完了するのか、より正確性の高い見積もりができるはずだ。





多分ね~。

2009年2月8日日曜日

最近買った本

(※ mixiの日記と同じ内容です)

「システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識」 
http://www.amazon.co.jp/dp/482228381X 
→まだ読み途中。ダウンの原因、、、やっぱり行き着くところは「人」だよなぁ、、、と思う。エラーやバグを作り込まないために「コミュニケーション」の品質を上げるっていうことにもうちょっと気を遣いたい、っていうか遣おうよ、ってボソっといってみたんだけど「…?」な感じ。 


「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」 
http://www.amazon.co.jp/dp/4839924023 
→まだ読み途中。開発対象を「作業量」でなく「価値」で見積もり、実際にどれくらいかかるかは組織の「生産性」をもって計画をたてなさい、とかね。これは「初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方(http://www.amazon.co.jp/dp/4822282422/)」における、1.機能量、2.工数、3.期間、4.生産性、5.品質は分離して考えなさい、というのに近いなと。当たり前に思えるかもしれないけど、現場(ウチの会社)はこの辺がごっちゃ。 
あと仮説ベースで機能がどれくらいの経済的な価値をもっているのか算出しましょう、とかもね良い! 読み応えあります。あと装丁が格式高い感じがするのも良い。 


「与信管理の本」※ タイトルぼかしました。 
→まだ読み途中。こういう本を買って読まなきゃならんあたり、つくづくIT雑用係の名に嘘偽りはないな、と。(自称ですけど) 
中身はね、ひどい。こんなに抽象的な表現で、冗長な構成で、日本語そのものの品質がひくく、読んでいてイラっとする本はないね。仕事中にくるヘンなメール並みの腹立たしさ(笑)。 


「Google Gearsスタートガイド」 
http://www.amazon.co.jp/dp/477413287X 
→途中、途中読んだ(しゅんぺいさんごめんなさい) 
すごく、細かいです。 
そのくらいの内容は読み手に調べさせればいーじゃん、ていうところまでしっかり解説。全然、手抜きなし。あと説明が簡潔で具体的。だからGoogle Gearsやらない人が読んでも良いし役に立つ内容。Adobe AIRとかをやっている会社で働いていて、気まぐれなお客さんに「AIRって何?」って聞かれたときに、「そんなもんググレカスとか」とか言い返したい気持ちをぐっとおさえて説明するときに、この本を読んでおくとその説明の裏付けや説明そのものをわかりやすくすることにも役に立ちます。こう書くと理論や概要を説明している本かと思いますが、ちゃんとサンプルプログラムやリファレンスも載ってるから資料的価値も高い。 
お買い得感満載な本です。 


「ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識」 
http://www.amazon.co.jp/dp/4822283119 
→訳あってあとまわし 


「T業界のための『工事進行基準』完全ガイド 基礎と事例と18の特効薬」 
http://www.amazon.co.jp/dp/4822215792/ 
→あとまわし。訳はない。




多分ね~。