« 2014年5月 | トップページ | 2014年7月 »

2014年6月

2014/06/29

「高専生と取り組むScrum」の資料が素晴らしい

「高専生と取り組むScrum」の資料が素晴らしいのでメモしておく。

【元ネタ】

【参考】

「Ameba流Scrum」を浸透させるために私たちが実践したこと

スクラムを大規模組織へ導入した事例: プログラマの思索

「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」の発表資料が素晴らしい #devsumi: プログラマの思索

PBLのためのScrumとチケット駆動開発を組み合わせた事例: プログラマの思索

Scrumの入門資料リンク: プログラマの思索

Doneの範囲はチームの能力に比例する: プログラマの思索

【感想】
【1】社会に出るまでの教育の現場では、小学生・中学生・高校生・大学生も、実験や体験学習で、プロジェクトに似たような経験をする。
つまり、その場限りで、有期性を持ち、明確な回答が一意に決まっていないプロジェクトに対し、自分たちでどのようにアプローチして解決するか、その内容をレポートする宿題。

しかし、教育の現場では、そのようなレポートは、その中身や結果を正確に評価するのは難しい。

ビジネスなら、売上が上がった、利益が上がった、コストメリットがあった、社員の団結力が上がった、などの効果を見出すことができる。
でも、教育の現場は基本は、生徒に金額を付けて評価することはしないのが前提だ。
あくまでもその生徒の純粋な能力や人格を相対評価するだけで、その生徒が生み出した結果を評価すると、序列がはっきり出てしまい、教育しにくくなるデメリットが大きくなってしまうから。

だから、課題解決のようなプロジェクトをやっただけのレポート提出だけで終わってしまい、そこから得られた経験が蓄積されない弱点があるのだろう。

上記の資料では、Scrumを入れることによって、課題解決のPDCAサイクルを回し、生徒が自発的に学習しながら成長していくフレームワークを提供しようとする意図が見られる。
実際、Scrumのフレームワークに生徒がうまく乗って、アジャイルな開発サイクルを回せたようだ。

【2】一方、「「Ameba流Scrum」を浸透させるために私たちが実践したこと」では、「Scrumはフレームワークとして理解しやすく、開発マニュアルとしての役割にもなるので、現場のエンジニアの理解は早かった」という感想があって、同様な事象を上記の資料にも感じる。

また、PBLのためのScrumとチケット駆動開発を組み合わせた事例索でも、大学のソフトウェア開発の課題研究にも、Scrumのフレームワークが非常に有効だった、という研究成果もあった。

つまり、Scrumは、ソフトウェア開発という文脈では、教育現場やベンチャー企業など、開発プロセスがあまり重視されていない場にスムーズに導入しやすく、成果を出しやすい特徴があるように思える。
その理由はおそらく、次の3点があると思う。

(1)Scrumがフィードバックループを持つらせん状の開発サイクルを持っていること
(2)Scrumで定義するチームとメンバーがうまく役割分担されていること
(3)Scrumが定義する会議体を実践することでスムーズにプロジェクト運営できること

上記の3点さえ理解して運用すれば、チーム運営がうまく回るような仕組みをScrumは提供しているわけだ。

【3】ここで、上記の資料で興味深いのは、Scrumのロールを教育現場にどのようにマッピングしたか、という点だ。
下記のように、Scrumのロールをマッピングしたようだ。

・プロダクトオーナー:専攻科2年の生徒
・スクラムマスター:教師
・チーム:専攻科1年の生徒
・外部のステークホルダー:他の先生

先生がスクラムマスターになり、プロダクトオーナーとチームが生徒同士でチームを組んだならば、生徒が主体的にソフトウェアを設計して開発するとか、アイデアを出しては試す、ということがやりやすくなるだろう。
また、課題が出て困ったときには、先生がチームに助け舟を出すことで、チームが停滞しないように手助けできるだろう。

個人的には、Scrumが一番優れている点は、チームが主体的に進められるように、組織体制にソフトウェア開発の役割をうまくマッピングしてアジャイルに回す仕組みを作っている点だと思っている。

【4】また、上記資料の「ふりかえりと計画ミーティング」の内容がとても良いと思う。
ふりかえりでは、「できていないこと、に自ら気付く。率直な思いが出る: 不安・焦り・不信感・達成感」が出るとのこと。

初めてプロジェクトに携わり、色んな思いを吐き出すことで、また新たな成長を促す。
達成感があると同時に、やり残した感も出てくる。
そういう経験を積んでいくうちに、自分で課題を見つけて、自分なりの目標を掲げて、自ら成長していくわけだ。

【5】そんなことを思うと、教育現場そのものもScrumのフレームワークで回してしまえばいいのでは、と極端な提案がしたくなる。
例えば、こんな組織構造も考えられるのではないだろうか。

・プロダクトオーナー:教員(メイン)
・チーム:生徒数人
・スクラムマスター:各チームを自由に回るファシリテーター役の教員
・外部のステークホルダー:他の先生、教頭、校長

生徒が自発的に学習する環境を整えたいなら、生徒3~7人と教員のスクラムチームを作って、スプリント単位に全教科を学習していけばいい。

校長や教頭などは、ニワトリであり、部外者だ。
彼らはスプリントデモの時だけ参加すればいい。
他の場面で口出しする必要はない。

果たして、他の現場でも回せるのか、興味のある所。

【6】上記資料の最後にはこんな言葉がある。
とても意味深な言葉だと思う。

(引用開始)
高専生が将来、みなさんの「頼れる仲間」として活躍できるようになるには、彼らにどのような出会いの場を、どのように提供すればよいでしょうか?
(引用終了)

| | コメント (0)

2014/06/28

「朝の3分モデリング講座 - UML基本編(番外) なぜモデリングするの?」が分かりやすい

平鍋さんが最近、「朝の3分モデリング講座」をYouTubeで公開されている。
「朝の3分モデリング講座 - UML基本編(番外) なぜモデリングするの?」がとても分かりやすかったのでリンクしておく。

【元ネタ】

Twitter / hatsanhat: 平鍋さんの「なぜモデリングするの?」
https://m.youtube.com/watch?v=PECd-1QY9Z4

何気にDDDのフレームを使った説明。分かったような気にさせるところが素晴らしい。モデルと設計を別のものとして説明しているのがいま風?

「問題→解決」にすんなり問題解決できれば、何も問題はない。
しかし、普通の問題は複雑で、その構造を把握しなければ、解決の糸口も見つからない。

だから、「問題→分析モデル→設計モデル→解決」の流れで、モデル空間に一度変換してから、問題解決を試みる。
この辺りの絵がとても分かりやすい。

@hatsanhatさんが触れられているが、ドメイン駆動設計ならば、分析モデルと設計モデル(実装モデル)はソースレベルで一致しており、ドメインエキスパートと開発者が議論しながら、モデルを洗練させていく。

この時に注意すべき点は、モデル空間は現実から離れた空間であるために、論理的な空間であること。
つまり、見た目やハードに依存しない抽象的な空間であるために、徹底的に論理だけで組み立てられるべきものであること。

だから、モデルに入り込むほど、普通の人にとっては分かりにくくなる場合があると思う。
逆に、現実の制約条件を離れるので、自由に論理を組み立てて、新たなモデルを作り出せる可能性もある。

アジャイル開発に関わる人ならオブジェクト指向設計という形でモデリングは意識しているし、日本でもデータモデリングという形で随分昔からモデリング作業の歴史があった。
でも、日本におけるデータモデリングのノウハウは、肝心の技法が公開されておらず、僕も含めて若い人には全く受け継がれていないと思う。

この辺りを一度綺麗に整理してみたいなと思う。

| | コメント (0)

TortoiseSVNでastahファイルのリビジョン間の差分を表示する方法

TortoiseSVNでastahファイルのリビジョン間の差分を表示する方法を見つけたのでメモ。
これは便利。

【元ネタ】
[Tips] TortoiseSVNで、astahファイルのリビジョン間の差分を表示:astah* Users Community Site - フォーラム

1. [TorsoiseSVN]-[設定]を選択します。2. [外部プログラム]-[差分... | tumblr map

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

僕は、要件定義や分析などで、astahProfessionalを使って、ラフなスケッチをよく描く。
例えば、業務フローを描いたり、ユーザが話す業務の概念をクラス図で描いたり、会計データや業務データの変遷をオブジェクト図やステートマシン図で描いたりする。

その時、退社する前にastahファイルを必ず、ローカルPCにあるSubversionまたはGitリポジトリにコミットしておく。
そうすれば、履歴が残るので、間違ってしまった時にロールバックしたり、過去のモデルを復元したい時に役立つ。

astahでは、Subversionプラグインが既にあるけれど、TortoiseSVNでコミットする時に差分表示できるのは便利。
コミットする時に、今日はどれだけモデルを作ったのか、モデルをどれだけ更新したのか、見たい時があるから。

astahProfessionalはモデリングツールとして、安い割にはとても良くできていると思う。
astahProfessionalの使い方については、今後も気づいた点をアップして、メモしていくつもり。

| | コメント (0)

2014/06/27

Redmineでリソースヒストグラムを実現するアイデア

Redmineでリソースヒストグラムを実現するアイデアについて、ラフなメモ書き。

【参考】
情報システム用語事典:リソースヒストグラム(りそーすひすとぐらむ) - ITmedia エンタープライズ

[ThinkIT] 第6回:組織管理 (2/4)

PMBOK(R)テンプレートの作成 その8 / PMstyleコラム

【1】リソースヒストグラムが必要な背景と問題

【1-1】SIの管理職になれば、彼の仕事の大半は、開発要員の調達管理とシステム提案による営業だ。
システム開発を受注したら、システムを設計し、開発するためのメンバーを一定期間は確保しなければならない。
この時に必要なツールが、リソースヒストグラム。
別名は、山積み表。
あるいは、要員表。

リソースヒストグラムは、縦軸がメンバー、横軸が毎月で、各セルは該当月のメンバーが働く工数を表す。
普通は、1ヶ月働くなら、1.0人月(単位:MM)になる。

【1-2】このリソースヒストグラムを作るのはかなり面倒だ。
その理由はいくつかある。

一つ目は、該当の案件にアサインされた要員が、すべての期間に1人月分働くとは限らないため、調整の手間が発生すること。

例えば、他案件に掛け持ちしているメンバーや、開発・テストなどの特定の工程だけにアサインする派遣の開発要員もいると、リソースヒストグラムはまばらな値になる。
すると、他案件に掛け持ちしているメンバーは、該当案件の稼働工数は0.5MMだったりする。
開発・テスト工程でかき集めた開発者なら、2~3ヶ月だけ1.0MM稼働し、他の月は契約されずにゼロになる。
彼らのようなメンバーや開発者も、考慮したり、契約の手配が必要。

2つ目は、WBSの積み上げ法による見積り工数とリソースヒストグラムで作った見積りが完全に一致しないこと。
WBSの積み上げ法は、システムの機能や成果物ごとに詳細に見積もって積みあげるから、精度は高い。
しかし、システムの機能を誰が作るのか、によって、生産性が違うし、タスクの先行・後続の順序を考えると、工数や納期が当初よりも膨れ上がってしまいがちだ。

だから、リソースヒストグラムを作りながら、実現可能な要員のアサインを考えなければならない。
でも、普通は、積み上げ法とリソースヒストグラムにおける見積り工数は一致せず、多少の誤差が出る。
僕の今まで見てきた案件では、どちらかの見積りのうち、多い見積りを正しいものとして、開発を進めていた。

3つ目は、リソースヒストグラムの保守がとても面倒なこと。
仕様変更や工期の短縮などが発生すると、リソースヒストグラムを保守しないといけないが、この作業がすごく面倒だ。
何も考えずに修正すると、特定のメンバーが1ヶ月で2人月も働く、みたいな非現実的な計画が作られてしまう。

MSProjectには、タスクの先行・後続関係に応じて、リソース(作業負荷)の平準化を行う機能があるので便利だが、最終的には手作業の修正が発生する。

【1-3】そんな面倒な作業が多いリソースヒストグラムが重要なのは、メンバーの作業工数がプロジェクトの原価に直結するからだ。
つまり、リソースヒストグラムの精度が、プロジェクトの利益に大きく依存する。

一括請負案件では、受注した時に契約金額が決まっているから、粗利を確保するためには、メンバーの作業工数の上限は決まっている。
その上限を超えると粗利が減り、損益分岐点を超えれば赤字なる。

SIの受託開発案件では、大規模プロジェクトになるほど、赤字のリスクは大きい。
普通は、当初の計画時点の前提条件がプロジェクト進行中に変わってしまい、リソースヒストグラムも影響を受けて、当初の作業工数よりも増えてしまいがちだからだろうと思う。

「人月の法則」に従うように、開発メンバーの人数が増えるほど、プロジェクトはどんどん遅延していく。
その場合、リソースヒストグラムは、縦軸のメンバーがどんどん増えて、積み上げられた総工数が膨れ上がることになる。

また、リソースヒストグラムは進行中のプロジェクトの原価や利益を見たいだけでなく、今後受注されるであろう提案中の案件に、どれだけの開発要員をアサインできるか、を予測するためにも使われる。
普通は、リソースヒストグラムで3ヶ月先、半年先の見積り中の案件に対し、メンバーがどれだけ必要か、を計算して、システム提案という営業活動を行なっているわけだ。

このように、SIの管理職は常に、リソースヒストグラムをにらめっこしながら、月末に工数締めされる時に、自分の部署の売上や利益が大丈夫か、ハラハラドキドキしているわけだ。

【2】Redmineチケットによるリソースヒストグラムの実現方法

【2-1】そんなリソースヒストグラムもRedmine上で実現することは可能だ。
まず、前提条件として、チケットに開始日・期日・予定工数・実績工数・担当者は入力される運用があるとする。

すると、リソースヒストグラムの仕様は、下記のように、チケットの属性を集計すれば良い。

【例】測定日:6/15

メンバーごとのリソースヒストグラム工数(「RH工数」と略す)
・5月:過去月は、該当月の実績工数の和。
・6月:当月は、当月初めから測定日までの実績工数の和+測定日の翌日から当月末までの予定工数の和
・7月:未来月は、該当月の予定工数の和

上記の仕様の意味は、実績工数が発生した日までは、該当月のRH工数は実績工数の和で計算できる。
まだ実績工数が発生していない将来の日は、該当月のRH工数は、予定工数の和で計算できる。

また、上記の仕様の実現方式としては、日次または月次に工数集計のバッチ処理を動かし、毎日または毎月のRH工数をサマリしたテーブルに保持すればいい。

【2-2】Redmineチケットで実現するメリット

RedmineチケットをWBSのように見なすならば、プロジェクト計画時に全てのチケットに開始日・期日・予定工数・担当者をあらかじめ登録できる。
Redmineへチケットを一括インポートすれば、プロジェクト計画時点のリソースヒストグラムを立てることができる。
そして、日々の実績工数はチケットに記録されるので、バッチ処理で工数集計してサマリテーブルに保持すれば、簡単にリソースヒストグラムを見ることができる。

つまり、リソースヒストグラムは、EVMと同様にRedmineのチケット管理で簡単に実現できる。

【2-3】Redmineによるリソースヒストグラム作成処理で不足している点

しかし、Redmineはあくまでもチケット集計結果から、リソースヒストグラムを生成しているに過ぎない。

例えば、MSProjectのように、リソースの平準化のような気の利いた機能はない。
従って、現状のリソースヒストグラムで、特定のメンバーに作業負荷が大きく偏っていておかしい場合は、手作業でチケットを逐一修正するしか無い。

また、毎月の実績工数は月末に締められて、修正不可として確定され、工数委託の開発者の会社に毎月の委託費を支払わなければならない。
つまり、Redmineチケットからバッチ処理でリソースヒストグラムを生成する場合、月次締め処理が必ず必要で、一度締められたチケットの実績工数は修正不可になる仕様が必要。

そして、Redmineチケット管理に最も不足している機能は、メンバーの人月単価を保持する機能がない点だ。
そのため、実績工数から毎月の委託費を計算する処理は、別の社内システムで実施するしかない。

すなわち、Redmineによるリソースヒストグラムは、あくまでも工数ベースの原価計算機能と割り切るしか無い。

【3】とは言え、Redmineチケットにすべての作業と工数が記録されているならば、チケット集計機能によって、色んな使い方ができる。

普通のSIでは、リソースヒストグラムの他に、毎月のメンバーごとの稼働率と生産性を必ず計算している。
下記の仕様で計算される。

・稼働率=該当月の実績工数(ΣAC)/該当月の予定工数(ΣPV)
・生産性=該当月の出来高工数(ΣEV)/該当月の予定工数(ΣPV)

【3-1】稼働率

「稼働工数」とは、メンバーが、一括請負案件や工数委託案件(つまり準委任または派遣契約の案件)、保守案件など、売上が発生する案件で働いた実績工数の和のこと。
「総工数」とは、メンバーが該当月に働いたすべての実績工数の和。

稼働工数は、売上が発生する案件の実績工数なので、直接人件費になり、仕掛品で計上される。

一方、売上が発生しない案件とは、例えば、社内の研究開発、営業活動、社内会議、教育研修など、売上が0円の活動に相当する。
つまり、これらの実績工数は、間接費として計上され、普通は製造間接費として集計され、すべての部署に按分されて配賦される。
つまり、稼働工数以外の工数は、間接費のため区別しなければならない。

SIの上層部の観点では、稼働率の高いメンバーは、売上への貢献が高い。
逆に、稼働率の低いメンバーが多いという状況は、受注される開発案件が少ない時がほとんどであり、社内の開発者は暇を持て余して、自社のサーバーで作業したり、研究開発したりしていることになる。
だから、SIでは、稼働率が低い社員が多くならないように、常に受注した案件に社員をアサインできるように、注力しているわけだ。

【3-2】生産性

また、生産性は、文字通り、1よりも大きければ、予定された時間よりも短い時間でアウトプットを出せたことを意味する。
つまり、生産性の高い社員が多いほど、数多くの受注した開発案件をこなせることになる。

しかし、SIのソフトウェア開発では、生産性が高いからと言って、開発者のインセンティブが高まる仕組みにはなっていない。
当初の予定工数よりも短い時間で作業が終わったら、見積りが甘いのでは、と逆に詮索されてしまい、次回からの予定工数を減らされてしまう。
あるいは、生産性を高めて、暇な時間ができたとしても、余った時間を別の作業で売上に結びつけるのは難しい。

結局、生産性も稼働率も一つの指標にすぎない。

【3-3】Redmineでは、生産性は、メンバーごとに、「毎月のチケットのPVの和/毎月のチケットのACの和」を計算してバッチ処理でサマリテーブルに保持すればいい。
しかし、稼働率は、稼働工数の対象のプロジェクトかどうか、Redmineプロジェクトにフラグを付けておく必要がある。

【4】リソースヒストグラム、稼働率、生産性などをRedmineで実現することは可能だ。
WF型開発中心に受託案件を回しているSIなら、それらを定期的に集計する仕組みを持つRedmineは一つの有力候補になるかもしれない。

| | コメント (0)

2014/06/26

RedmineとVisualSVNをHTTPSで連携する方法

Windows上に作ったVisualSVNとRedmineをHTTPSで連携する方法についてメモ。
結構はまった。

【参考】
FAQ#I-cant-browse-my-svn-repository-through-redmine - Redmine

redmineでSubversionリポジトリにhttpsでアクセスする|成長の果実

RedmineでSSL自己証明書Subversionリポジトリにアクセスする方法 - TrinityT’s LABO

VisualSVN Server | Subversion Server for Windows

VisualSVN Server certificate key usage violation in Subversion clients built against GnuTLS - VisualSVN Help Center

【1】会社の都合上、SVNサーバーをLinuxではなく、WindowsServer上に作らざるをえない場合がある。
すると、VisualSVNというツールをWindowsServer上にインストールすることになる。

VisualSVNのインストールそのものは簡単だが、HTTPSで接続する設定ができる。
そして、証明書の発行は信頼できる認証局から購入するのではなく、社内WANの中だけなら、オレオレ証明書だけでとりあえず使える。

しかし、別サーバーにあるRedmineからVisualSVNサーバーに作ったSVNリポジトリにアクセスしようとすると、下記のエラーメッセージが表示されて、SVNで接続できない。

svn list --xml https://サーバー名/svn@HEAD --username ユーザ --password パスワード --trust-server-cert --no-auth-cache --non-interactive

SSL handshake failed: SSL error: Key usage violation in certificate has been detected.

【2】対処方法は下記の2つが必要。

【2-1】FAQ#I-cant-browse-my-svn-repository-through-redmine - Redmineの通り、subversion_adapter.rbにあるSVNコマンドのオプションを修正する。

cd {$redmine}/lib/redmine/scm/adapters
diff -u subversion_adapter.rb.org subversion_adapter.rb
@@ -260,7 +260,7 @@
str = ''
str << " --username #{shell_quote(@login)}" unless @login.blank?
str << " --password #{shell_quote(@password)}" unless @login.blank? || @password.blank?
- str << " --no-auth-cache --non-interactive"
+ str << " --no-auth-cache --non-interactive --trust-server-cert"
str
end

【2-2】VisualSVNサーバー上で、下記のレジストリを登録する。

VisualSVN Server certificate key usage violation in Subversion clients built against GnuTLS - VisualSVN Help Center

for 32-bit system:
[HKEY_LOCAL_MACHINE\SOFTWARE\VisualSVN\VisualSVN Server]
"CreateGnuTLSCompatibleCertificate"=dword:00000001

for 64-bit system:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VisualSVN\VisualSVN Server]
"CreateGnuTLSCompatibleCertificate"=dword:00000001

VisualSVN Server Managerで、Action | Properties | Certificate から、証明書を再発行する。

VisualSVN Server を再起動する。

特に、【2-2】の方法を知るまで、試行錯誤した。
WindowsServerでSVNを使うのが間違っているのかな?

| | コメント (0)

RedmineチケットをExcelから一括登録できるアプリ「Redmineチケット★一括★」

RedmineチケットをExcelから一括登録できるアプリ「Redmineチケット★一括★」があったのでメモ。
Windows上でExcelでチケットの元ネタを作成しているなら、このアプリがすごく役立つだろう。

【元ネタ】
Redmineチケット★一括★の詳細情報 : Vector ソフトを探す!

Redmineの一括登録ツール - ICT備忘録

zh/redmine_importer

(引用開始)
タスク管理者向けのツールです。
Redmineのチケット情報を記入したExcelシートを読込み、
REST-API経由で登録/更新を行います。
「データ量が多くて処理エラーが発生」、
「一回の処理でチケットの親子紐づけができない」など
RedmineのImporterプラグインで上手くいかない場面で当ツールをご活用ください。
(引用終了)

CSVからチケットを一括インポートできるプラグインredmine_importerがあるけれど、DBマイグレーションでテーブルが追加されるし、チケットの項目をプルダウンから関連付ける作業が結構面倒だ。

しかし、「Redmineチケット★一括★」なら、Excelでチケットの元ネタを書いておけば、REST-API経由で一括登録できるので、すごく便利。
WBSの元ネタは、Excelで作っておく方が簡単だ。

こういうアプリが実現できるのも、RedmineのREST-APIがオープンソースの割にはすごくよくできているからだと思う。

RedmineのREST APIは素晴らしい~ビッグデータの手法をRedmineにも活用する: プログラマの思索

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

Redmineの外部接続、データ移行の機能: プログラマの思索

WindowsクライアントアプリRedmine Desktop Client: プログラマの思索

| | コメント (0)

親チケットでフィルタできるRedmineプラグイン

親チケットでフィルタできるRedmineプラグインが公開されていたのでメモ。

【参考】
親チケットでフィルタできるRedmineプラグインを作成しました (Parent issue filter plugin for redmine) - Enjoy*Study

onozaty/redmine-parent-issue-filter

(引用開始)
Redmineで親チケットとルートチケット(親チケットをたどって一番上のチケット)を使ってフィルタがかけられるプラグインです。
(引用終了)

使い道としては、2つある。
一つは、ルートチケットを指定して、親チケットの階層の配下にある子チケットを全て抽出する方法。
もう一つは、親チケットを指定して、1階層下の子チケットを全て抽出する方法。

RedmineのチケットをWBSと見なして、階層化している時にこのプラグインが役立つだろう。
WBSのタスクの配下にある成果物や機能が漏れ無く登録されているか、設計レビューや単体テストレビューなどの作業の漏れがないか、を確認する時に使えるだろう。

つまり、WBS駆動のWF型開発、完全チケット方式のWF型開発でこのプラグインが使えるだろう。

できれば、階層化されたチケットの構造をグラフ化して表示できればなお良い。
その場合は、有償製品であるが、Lychee Association Chartがある。

Association Chart | Lychee Enterprise

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

| | コメント (0)

2014/06/23

バランススコアカードの例

バランススコアカード(BSC)について考えたことをメモ。

バランススコアカード概要 BSCnavi

戦略マップ BSCnavi

情報システム用語事典:バランスト・スコアカード(ばらんすと・すこあかーど) - ITmedia エンタープライズ

BSCとSWOT SWOT分析手順 バランススコアカードナビ

施設の将来を見据えた中期経営計画の策定法 - 医療・福祉ソリューションナビ

【1】BSCが必要な背景と問題

超上流工程であるシステム提案では、ビジネスの企画のスキルが問われる。
ITシステムを入れると、業務にどんな利点があるのか、ITシステムを導入した後のビジネスモデルはどのようになるのか、を提示しなくてはいけない。

前者は、ITシステムがどんな問題に対して有効で、導入したらどんな効果が出てくるのか、を定量的に示せればベストだ。
後者は、ITシステムの初期構築費用と保守運用費(いわゆるランニングコスト)がどれだけ発生し、いつになったら損益分岐点に達するのか、を提示する必要がある。

すると、本来の業務のあるべき姿に対し、ITシステムを入れると、どんな問題が解決されて、どのように効果が波及するのか、といった全体像を示さなくてはいけない。
そんな時に、バランススコアカードを使うと、内容をうまく整理できる。

【2】BSCの特徴

【2-1】BSCで最も重要で、最も効果的な成果物は、戦略マップだ。
ゴールを定めた後、「財務の視点(過去)」「顧客の視点(外部)」「内部業務プロセスの視点(内部)」「イノベーションと学習の視点(将来)」の4つの視点から、戦略を抽出して、それらを因果関係で結ぶ。

イメージとしては、SysMLの要求図のDerivedReqの関係のように、A→Bは、「AはBの根拠」「Aの効果がB」になるように戦略をつなげる。

戦略マップの良い点は、「売上の増大」「利益の増大」「原価削減」といった財務の観点の戦略を、顧客・業務プロセス・学習と成長の観点の戦略でつなげることで、戦略のスコープと焦点を明確にしてくれることだ。
戦略マップのような観点のないRFPの提案書は、中身がスカスカで、だから一体何なのだ、とツッコミしたくなる。
もっと壮大でロジカルな話にしないと、取締役や常務のような経営者には響かない。

【2-2】また、BSCでは、戦略マップで洗いだした戦略が重要成功要因(CSF)となり、CSFを測定するメトリクスであるKPI(業績評価指標)と密接に絡んでいる点が良い。
BSCには、KPIというメトリクスを定期的に採取することで、BSCで描いた戦略マップの思惑通りに組織が動いているか、を評価する仕組みがある。
この仕組みによって、KPIのメトリクスを高めるための対策がアクションになり、PDCAというサイクルが回るような仕掛けが動くわけだ。

おそらく、普通の大企業ならば、BSCないしBSCに近い戦略マップとKPTというメトリクスは定義して、それを元に経営しているはずだ。
実際、陰では終身雇用制であっても、業績評価制度を標榜する会社では、各社員の業績を評価する基準として、会社の経営戦略とそれに基づくKPIをブレイクダウンしたものがあるはずだ。
つまり、成果を元に社員を評価する業績評価制度は、BSCの賜物と言ってもよい。

但し、BSCに基づく業績評価制度がいいとは限らない。
人間の集団はおかしなもので、個人ではその行動はおかしいと思うのに、組織の中では、KPIというメトリクスを高めるための行動に偏って、戦略なき局所最適化しやすいからだ。

【3】BSCをITシステムの要求定義に適用する

BSCの特徴であるKPIというメトリクスによる経営戦略の評価という仕組みは、ITシステムと相性が良いと思う。
KPIを採取する仕組みを業務システムの一機能にしてしまえばいいのだ。

小売業や製造業ならば、稼働率・生産性・原価・在庫量などのメトリクスをKPIに当てはめて、業務システムのサブシステムとして情報システムで実現すれば、いくらでもKPIを採取して、集計したりグラフ化したり、分析できる。
KPIを定期的にモニタリングすることで、ある閾値を超えたり下がったりすれば、警告を出すような機能も実装すれば、より気の利いたシステムになるだろう。
よくある実装方法は、警告を通知するメール送信機能などがあるだろう。

【4】BSCの難しさ

しかし、BSCはよく考えられたツールだと思うが、実際に作るのはかなり難しいと思う。

一つは、戦略マップやKPIを作成するのが難しいこと。
戦略マップは一度で完成するわけではなく、何度も書いては書き直し、自分の中でロジックを組み立ていく必要がある。

もう一つは、BSCが吹き込んだ戦略マップを各部署にブレイクダウンして、各人が戦略の意味を自分の業務の範囲内に落としこむようにしなくてはいけないこと。

KPIも、すぐにメトリクスが思いつくわけではなく、KPIが社員の行動を奮い起こすような仕組みにしたい。
人はすぐにKPIに適した局所最適化された行動を取り、KPIの意味を忘れるからだ。

しかし、戦略やKPIを各部署の業務レベルまでブレイクダウンするのには、それなりの労力が必要とされる。
1日くらいの思いつきでできるものではない。
また、一人で考えぬくよりも、複数人で議論しながら戦略をブレイクダウンする方が効果的だ。
なぜなら、ブレイクダウンした戦略を自分の言葉まで落とし込み、自分の部のメンバーに説明して理解してもらえるまで、咀嚼する必要があるからだ。

【5】とは言え、BSCには可能性が秘められていると思う。
今となっては、BSCの本は一時期よりも少なくなっているけれど、そのノウハウは十分に使えると思う。

BSCの本は「キャプランとノートンの戦略バランスト・スコアカード」が原点として有名みたいだが、正直読みにくかった。
10冊ぐらいBSCの本を漁ってみた結果、「バランス・スコアカード経営 なるほどQ&A」が最も読みやすく、とても参考になった。
バランス・スコアカード経営 なるほどQ&A」は既に絶版だけれど、BSCを書くコツ、BSCとABC(活動基準原価計算)、BSCを組織へ広める手法などがQ&A形式で説明されていて、分かりやすい。


| | コメント (0)

2014/06/21

「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題

「納品」をなくせばうまくいく ソフトウェア業界の常識を変えるビジネスモデル」を購入してさっそく読んでいる。
感想を書く前にメモ。

【参考】
Twitter / akipii: ビジネスモデルの劣化コピーは誰も幸せにしない指摘 RT @kuranuki: 岡島さんもブログ書いてくれました。ありがとうございます! link:書評。『「納品」をなくせばうまくいく』を読んで身を引き締める - Happymanブログ http://happyman.hatenablog.jp/entry/2014/06/20/002521

Twitter / akipii:ビジネスモデルの因果ループ図で説明できるはず RT @yasuohosotani: はてなブログに投稿しました 「納品をなくせばうまくいく」を読みました - Yasuo's Notebook http://htn.to/wGcxpe

Twitter / akipii: 発注側の観点が良く分かる RT @_eurk: はてなブログに投稿しました 『「納品」をなくせばうまくいく』というパラダイム - ヘウレーカを廻って http://htn.to/3jYcDg

Twitter / akipii: 同感。縦書きの本なのに脚注が1ページごとにあって読みやすい。 RT @mitsugeek: 「納品」をなくせばうまくいく ~ ソフトウェア業界の"常識"を変えるビジネスモデル - developer's diary http://htn.to/LKcaKb

Twitter / akipii: 凄く良い記事。 RT @mat_aki: ソニックガーデン本(『「納品」をなくせばうまくいく』)は想像以上に熱い本だった - この国では犬がコードを書いています http://enk.hatenablog.com/entry/2014/06/15/153731

【1】IT業界で働き続けてきて、この業界のビジネスモデル「請負契約と準委任契約」にずっと違和感を持ち続けてきた。

【2】普通のSIの開発案件は、一括請負契約が普通。
最初の要件定義で、開発スコープと中身を確定してから請負契約を結び、設計→開発→テストに進んでいく。
一括請負契約は、悪名高いWF型開発とセットで実施するのが普通。

最初に全ての仕様を凍結できなければ、せっかくの見積りが狂い、実行予算や要員表のやり直しが発生する。
それは利益が下がることを意味する。
だから、一度決めた要件や仕様のスコープを拡大解釈させないように、SIは契約という名で縛ろうとする。
顧客も、仕様が確定する前に、要求をどんどん詰め込もうとし、最初の契約を守らせようとする。

【2-1】また、WF型開発では、工程ごとに開発要員の変動が大きいリスクが発生しやすい。
つまり、要件定義や設計などの上流工程では少数精鋭のメンバーで作業するが、その後の開発とテストという下流工程では、大量の開発者を動員して短期間にシステムを作り上げるやり方が多い。

すると、元請けは顧客から請負契約で受注するものの、上流工程は自分たちで設計書を作って、その後の下流工程は下請けやオフショアに流すように持っていく。
その理由は、開発要員の変動が大きいので、そのリスクを下請けに押し付けたいからだ。

つまり、短期間の開発は下請けのSIへ一括請負契約で任せて、開発の原価を自社の開発者の人件費という固定費ではなく、変動費化させようとする。
下流工程で開発工数が自社が抱える要員よりも多くなるのなら、不足した工数は下請けへのスポット対応でカバーさせたい思惑がある。

【2-2】多段階の請負契約は、元請けも下請けも双方ともに不幸な組合せだ。

下請けは、システムの実現可能性や非機能要件の検討もできていない設計書を渡されて、その責任を押し付けられて、開発せざるを得ない。
元請けも、下請けから、納期までにとにかく間に合わせただけのプログラムを納品されて、その検収作業で、ひたすらバグ潰しに追われる。
本番リリースできる品質にまで、システムを持っていくのが元請けも下請けも大変なのだ。

元請けも下請けも、「システムを本番稼動させる」ことだけに注力するから、システムがユーザの業務で長く使われるように運用するまで考慮する余裕は実際はない。
新規顧客のシステム開発ならば、なおさら、納品するだけで精一杯だ。
正直、顧客の業務のあるべき姿をシステムに反映させる所へ持っていくのは至難の業だ。

このような多段階の工程で分断された請負契約の悪しき風習は、昔から今まで、その不合理性をずっと言われ続けている。

【3】かと言って、準委任契約の開発案件が、顧客にもSIにも良い契約とは限らない。
準委任契約では、SIが役務の提供をするだけであり、検収物件が仮にあっても、実際は作業報告書だけで済まされる。

SIには、成果物の完成責任はないから、限られた期間に決められた工数だけ提供すれば、売上がもらえる。
顧客から見れば、要求した検収物件をもっとブラッシュアップして欲しいのに、準委任契約ではそこまで要求できない。

また、SIが下請けに下流工程を準委任契約している場合、成果物の完成責任はないから、事実上の派遣社員の作業と同じ品質ぐらいしか要求できない。
下請けの開発者も、準委任契約なら、残業するほど割増請求できるから、少ない工数で効率の良い作業を実施して品質を高めようとするインセンティブも働きにくい。

この症状は、松原友夫さんが以前書いた記事ですでに指摘されている。

真髄を語る - 日本のソフトウエア産業、衰退の真因:ITpro

【4】従来のSIのビジネスモデルである「請負契約と準委任契約」が本来の姿ではない原因は、顧客も元請けSIも下請けSIも、インセンティブが働かない仕組みにあることだと思う。

【4-1】SIでは、受注した開発案件は時期によって変動があるから、自社で抱えている開発者でまかなえればいいが、仕事がない場合は、人件費を支払うだけで赤字になる。
SIもサービス業なので、小売業の販売員や散髪屋の従業員のように、社員の稼働率が高いほど売上が高くなる。

だから、SIの管理職は、自分の部の社員が暇で遊んでいないように、常に受注した開発案件にアサインした状態にしておきたい。
すると、能力の高い開発者ほど、複数の案件を掛け持ちするようになり、常に忙しくなる。
SEやPGの稼働率で売上が決まるビジネスモデルは、能力のある開発者ほど疲弊させる。

【4-2】そして、受注した案件が自社の開発要員の工数よりも大きくなると、生産性の高い開発チームから人を引きぬかれてしまう。
他の案件でデスマーチで忙しい案件に、君のチームは暇そうだから、ちょっと手伝ってやってくれ、と言われて、チームからメンバーを減らされるのだ。
開発チームの生産性を上げても、逆に必ずデスマーチに巻き込まれてしまう。

だから、日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする

つまり、開発者や開発チームが生産性を上げても、デスマーチに巻き込まれるリスクの方が大きいから、生産性を上げようとするインセンティブが働きにくい。

【5】顧客も開発者もSIも、より良くしていこうというインセンティブが働かない「請負契約と準委任契約」というビジネスモデルはおかしい、とつくづく思ってきた。
だから、アジャイル開発にはずっと興味を持ち続けてきたし、アジャイル開発のビジネスモデルは何か、ということにも興味がある。

「納品」をなくせばうまくいく ソフトウェア業界の常識を変えるビジネスモデル」を注意深く読んでみると、顧客もSIも開発者も、品質の高いシステムを作ろうとするインセンティブが働くような仕組みが整っているように思える。

「納品のない受託開発」のビジネスモデルが絶対正しいとは思わないけど「ソフトウェア開発のビジネスモデルのあるべき姿」を提示しようとする点がすごく良いと思う。
この辺りを分析したいと思う。

【追記】
他のBlogで参考にされたようなのでメモ。
発注者の観点で、従来のソフトウェア開発のビジネスモデルの問題点を上げているのがとても参考になる。

Twitter / kuranuki: 斬新すぎる。 RT @shibu_jp: 読書してない感想文書いた: 「納品をなくせばうまくいく」を読んでません http://blog.shibu.jp/article/100415587.html

| | コメント (0)

2014/06/18

「エッセンシャルスクラム」が出版されるらしい

エッセンシャルスクラム」が出版されるらしいのでメモ。
内容がすごく気になる。

エッセンシャル スクラム - 翔泳社の本

【1】(引用開始)
「スクラムの適用が一番うまくいくのは、関わっている人(深く関わっていな人も含めて)全員が、その本質についてよく理解しているときだ」と言われます。
本書は「スクラムの全体像と詳細の両方を理想的に概観でき、しかも読みやすい」「次世代のスクラム実践者にとって、基礎文献となるに違いない」と、世界中の名だたるスクラムマスタから絶賛された1冊であり、まさしくスクラムの成功を強力に導ける書籍です。
スクラムによるソフトウェア開発に関わるすべての層、特に「スクラムマスター/スクラムコーチ(スクラムのリーダー)」「組織の中での継続的な改善をもっと成熟させたいと思っている人」、また「アジャイル/スクラムに馴染みのない(これから関わる)層」にお薦めです。
(引用終了)

目次が出てないのが気になるけれど、内容はすごく興味津々。
翻訳書の一人に和智右桂さんの名前があるので、翻訳の品質も本の中身の品質も良いだろうと推測する。

なぜなら、和智さんが過去に出版された翻訳本を振り返ると、「エリック・エヴァンスのドメイン駆動設計」「組織パターン」「継続的デリバリー」のように、優れた本がとても多いからだ。

アジャイル関係者なら、いずれかの本は持っていて、読書会にも参加した経験があるのではないだろうか。

【2】「エッセンシャルスクラム」に期待するのは、スクラムに関する原典となるような本かな、という点。
最も古い本は「アジャイルソフトウェア開発スクラム」だけれども、既に絶版になってしまった。

スクラムがアジャイル開発プロセスにおいて主流となった理由の一つは、プロセスが明確であるだけでなく、プロセスに登場する人物のロールと責任範囲が明確で、相互に影響し合いながら、より良いプロダクトを作り出す方向性を持つことだと思っている。
XPが暗黙的に感じ取っていた「持続可能なペース」「小規模リリース」「オンサイト顧客」などのプラクティスが、スクラムでは「Velocity」「スプリント」「プロダクトオーナー」という考え方にうまく昇華されているからだ。

その仕組みを、色んな観点で、理論的に説明してくれるといいなあ、と期待している。


| | コメント (0)

2014/06/16

チケット駆動開発がWF型開発と異なる点

チケット駆動開発について、良い記事があったのでリンクしておく。
Redmine上で実装されたチケット駆動開発について、よく理解されていると思う。

【1】技術士とアジャイル開発について(DAD) - A-JUNのブログ - Yahoo!ブログ

(引用開始)
こうした"計画外に発生したもの"はチケット/BTSでの管理が非常に向いている。なので「計画できることはWBSで。計画できないことはチケットで」というのが私の主張だ。
(引用終了)

WF型開発をベースタにした開発において、「計画できるものはWBSで、計画外のことはチケットで」という発想のチケット駆動開発は、アダプタブルWFと呼ばれる。
WBSによるプロジェクト管理が基本にありながら、そこから漏れた活動はチケット管理する発想。
アジャイル開発を取り入れにくい現場で適用する時が多い。

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索

【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索

【2】技術士とアジャイル開発について(チケット駆動) - A-JUNのブログ - Yahoo!ブログ

【2-1】(引用開始)
 バーンダウンチャート(バックログをグラフで表し、マイルストーンまでの残りの作業量の推移を、理想線、予定線、実績線、3つの右下がりの折れ線グラフで表示)とEVMの違いは、出来高という概念を残工数でみるか、完成した出来高の累積値として捉えるか、の違いだ。つまり、バーンダウンチャートは、イテレーション単位にEVMのグラフからPV-EVの数値だけを時系列に抜き出したものと見なすことができる。

 (WF型開発のEVMとアジャイル開発のバーンダウンチャートの)この観点の違いは重要だ。バーンダウンチャートでは、PVは変動する値と見なすのに対し、WF型開発のEVMではPVは固定値と見なす。そして、EVの考え方も、WF型開発では進捗率で測定するのに対し、アジャイル開発では未完了か完了のどちらかで測定する。

 したがって、アジャイル開発の方がEVの定義が厳しいために、担当する作業の粒度を小さくしてどんどん完了していくペースでなければ、プロジェクトの進捗は遅延しているように見えるだろう。つまり、アジャイル開発では、イテレーションというタイムボックスで管理したり、作業の粒度を小さくするなどの工夫をしなければ、EVMで測定しても変化がほとんどないから意味がない。

 EVMをアジャイル開発に適用できると、EVMの公式を使って、プロジェクトの進捗やコストを予測したり評価する手法を使える。AgileEVM: 製品ライフサイクル全体で費用対効果を計測するでは、SPIを使って進捗度合いをグラフ化して見える化している。CPIを測定すれば、開発チームの開発ペースが分かるから、総コストも予測できるだろう。
(引用終了)

EVMとバーンダウンチャートの見た目の違いは、進捗度合いを、出来高を累積して見るのか、残工数(残作業量)として見るのか、にある。
しかし、根本的な考え方は全く違う。

EVMでは、PVという計画された作業量は事前に決められており、変更することはできない。
予定された作業対し、どれだけ実績の差分が発生するか、という観点で進捗管理を行う。
この方法の弱点は、ソフトウェア開発のように、事前に要件を固めることが難しく、頻繁に要件の変更が発生する場合に使いにくい。

逆に、バーンダウンチャートでは、要件は変化するという前提で、スプリント単位に残工数を測定する。
計画時点の作業が変更されることを考慮するだけでなく、計画時の予定作業の「変動量」に注目し、その変動の揺れ幅を一定範囲内に収めることに注力する。

この方法の利点は、チームの開発能力が安定していて、計画時の作業の分量も大きな揺れ幅にならない前提があれば、変化を許容しながら開発できることだ。

EVMとバーンダウンチャートは本質的に違う: プログラマの思索

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2~RedmineでEVMを実現 Lychee EVM: プログラマの思索

【2-2】(引用開始)
Redmineのロードマップ画面では、該当バージョンの進捗バーは濃緑色の部分が多く、もう少しでリリースできる状況だろう。即ち、チケットをこなす速度も予定よりも早く進み、そのおかげで納期も短くなったことになる。このパターンは、プロジェクトの理想的な展開だといえるだろう。

 実際は、アジャイル開発で小規模リリースを実施すると、初期のイテレーションは非常に苦労するが、後期のイテレーションではこのパターンに当てはまる。最初は、要件や仕様の理解に苦しんだり、新しい技術の習得に時間がかかったり、メンバーの役割分担が不十分だったりして、何とかイテレーションをこなすのが精一杯となるのが通常だ。

 しかし、イテレーションと言うリズムに慣れると、イテレーションに収まりきらないチケットは後回しにしたり、優先順位を付けてチケットを入れ替えるなどのマネジメントがスムーズになるので、結果的にバグが生じにくくなり、手戻り作業も減る。

 システム開発では、学習速度と言う概念が重要だと思う。3ヶ月経てば、新人であろうとも、仕様も技術も慣れてくる。その分、タスクをこなす速度は上がってくる。つまり、開発チームのベロシティ(進捗速度)はほぼ一定になるので、見積もりの精度が高くなり、手戻り作業などのリスク管理も上手に制御できるようになるだろう。
(引用終了)

Redmineのロードマップによる小規模リリースの戦略のお話。
Redmineのバージョンがイテレーションに相当し、イテレーション完了の条件がRedmineのバージョンが進捗率100%で完了する状態と一致するのが、運用のコツ。

チケット駆動開発の戦略: プログラマの思索

【3】技術士が考える見積もり方法について - A-JUNのブログ - Yahoo!ブログ

(引用開始)
 アジャイル開発の利点は機能単位の小刻みな小規模リリースだけではなく、チームの現在の能力に見合った見積りを提示できる点にもある。顧客に、現在のチームの能力ではこれぐらいの期間でこれぐらいの機能(規模)を提供できます、とイテレーションのたびに説明できるのは、ウォーターフォール型開発よりもとても有利だ。

 アジャイル開発の見積りで面白いのは、実績工数よりもVelocityを追跡することに注力することだ。予定していたVelocityと実績のVelocityを各イテレーションで計測しながら、次のイテレーションの見積りに使う。実績工数にこだわると、いかに時間をかけずに仕事するか、に開発者の意識が寄ってしまって、手抜き作業が起きる可能性もあるからだろう。これは、非常に重要な考えだ。

 また、実績工数は規模や難易度によって大きく変わるから、あまり当てにならない。Velocityの計測を追跡することによって、チームの能力をいつも気にかけるようになり、XPの言う「持続可能な開発ペース」を保持するのにも役立つだろう。

 ストーリーポイントやVelocityはアジャイル開発特有の概念であり、その概念の意味はとても奥深い。Redmineによるチケット駆動開発を通じて、WF型開発でよく使われるFP法やEVMとは全く違うことも理解することが必要だ。こういうメトリクスを計測できる環境をチケット駆動開発は提供してくれるからこそ、色々思索することもできる。
(引用終了)

メトリクス採取の観点は、従来のWF型開発とアジャイル開発では全く違うと思う。
WF型開発では、メトリクスを計画と実績の差異比較に使う。
しかし、ソフトウェア開発は案件の独自性が大きいために、計画時にメトリクスの値を想定するのはとても難しい。
実際に設定したとしても、開発チームの生産性、納期と工数のバランス、新技術の実現可能性、メンバーの学習能力などを考慮すると、大きくブレがちだ。

一方、アジャイル開発では、メトリクスを実績ベースの値から採取する。
例えば、Velocityやサイクルタイムなどが相当するだろう。
すると、イテレーションごとに開発チームの実績を定期的に計測することで、その値を直近のイテレーションへの見積りに利用できる。
実際の案件で採取した実績値を元に見積りを行うから、その精度は高いはず。

また、WF型開発のメトリクスの弱点は、採取したメトリクスを開発チームにフィードバックしづらいことだ。
工程単位にメトリクスを採取したとしても、次工程に進んでしまったら、前工程のメトリクスを利用する意味が半減する。
次工程では、前工程のメトリクスはそもそも使えない可能性が高い。
しかも、工程終了・開始前後は大変忙しいから、採取したメトリクスをフィードバックするタイミングも取りにくい。
最悪な場合は、工程単位に多重請負構造になっている時だ。
前工程の下請け・元請の負債を引きずるメトリクスをもらったとしても、正直嬉しくない。

一方、アジャイル開発では、イテレーション単位に取得したメトリクスは、イテレーション終了直後に「ふりかえり」で開発チームにフィードバックするタイミングがある。
開発チームは、そのメトリクスから得られたノウハウを、次のイテレーションに生かすことができる。
この点が最大の違いだと思う。

アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索

チームは加速するのか~Velocityの使い方 #agilesamurai: プログラマの思索

Velocity計測の注意: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索

| | コメント (0)

2014/06/12

astah GSNを使ったゴール指向分析

ゴール指向分析と絡んだastah GSNという製品があるらしい。
以下メモ書き。

【参考】
GSN(Goal Structuring Notation)解説:An Agile Way:ITmedia オルタナティブ・ブログ

ゴール指向分析の「考え方は」WBSに使える - ウィリアムのいたずらの開発日記

Astah GSNが、UML、SysMLと連携してほしい人! - いっぱい!! - ウィリアムのいたずらの開発日記

D-CASE駆動ソフト開発 - ウィリアムのいたずらの開発日記

第5回D-Case研究会のご案内

Astah GSNについて 平鍋健児、岩永寿来(チェンジビジョン)

【1】平鍋さんの資料によると、astah GSNは「昨年発表の新エディション(β)。航空、自動車、鉄道など安全性を保証する「セーフティケース」のグラフィカルな記述(GSN) 」らしい。

使い道としては、組み込みソフト開発の要件定義において、製品の安全性(ISO)の保証と成果物へのトレーサビリティを実現するために使われるみたい。
製品の安全性をどこまで議論して、どの機能へ反映しているのか?を記録し、製品からトレースできるようにすることを目的にしているようだ。

astah GSNのようなモデリングツールが必要になった背景としては、組み込み製品における要求と仕様、要求と成果物のトレーサビリティが必要になったことがあるのだろう。
最近の組み込み製品の開発は、自動車の車載機器、KinectやiPhoneなどのモバイル機器とヘルス機器の組み合わせなどがあり、業務システム開発よりも活発だ。

【2】しかし、組込製品開発特有の事情として、安全性や信頼性という品質要求が業務システムよりもはるかに厳しく、法制度によって制約を受けていることがある。
組込みソフトウェアのバグによって、製品が誤った使い方をされることで、人命や社会に大きな損害を与える危険性があるからだ。

有名な事例としては、トヨタ自動車の大規模リコール (2009年-2010年) - Wikipediaなどがあげられるだろう。

【3】安全性については、フェイルセーフという概念で以前から品質特性として知られていた。
最近は、安全性と信頼性をミックスして、より幅広い意味を持つ概念として、ディペンダビリティが提唱され、そのディペンダビリティの研究と実装がすごく盛んだ。

情報マネジメント用語辞典:ディペンダビリティ(でぃぺんだびりてぃ) - ITmedia エンタープライズ

セーフウェアが必要な理由~ソフトウェアが凶器になる時: プログラマの思索

セーフウェア: プログラマの思索

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索

高信頼化ソフトウェアのための開発手法ガイドブック: プログラマの思索

ゴール指向分析の本来の目的は、組込製品のディペンダビリティを確保するために、ディペンダビリティと製品の間のトレーサビリティを明確にすることで、ディペンダビリティの範囲を定量的に把握したい意図があるように思う。

【4】平鍋さんの会社が出しているモデリングツールは、astah ProfessionalというUMLモデリングツールが有名だけれど、最近は、組込製品のモデリングツールastah SysMLなど、組込製品を意識したモデリングツールが多いように思う。
モデリングというソフトウェア技法が、ソフトウェアそのものの習熟によって大きく変化している事実を示唆しているのかもしれない。

この辺りも追いかけてみたい。

| | コメント (0)

2014/06/10

Redmineでコミットと同時にリポジトリの情報を取得する方法

Redmineでコミットと同時にリポジトリの情報を取得する方法をメモ。

【元ネタ】
小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog

commitが遅い。RedmineとSVNの連携を調整してみる。 ? AH-2

FAQ - Redmine

Speedup svn post-commit hook for redmine or chiliproject ? widerin.org

【1】「refs #123」「fixes #131」のようにチケット番号込みでコミットすると、Redmineリポジトリ画面にリビジョンとチケットがリンクされるようになる。
この運用が「No Ticket, No Commit」であり、トレーサビリティの効果を持つ。

しかし、Redmineのリポジトリ画面を逐一リフレッシュしなければ、リンクされない。

解決方法としては、Redmine.jpに書かれているように、リポジトリ情報取得のAPIキーを使って、HTTP通信で取得するのが簡単だ。

http://Redmineサーバ名/sys/fetch_changesets?key=APIキー&id=プロジェクト識別子

それをpost-commit-hookスクリプトに書くなり、Cronで呼び出すなりすればいい。

【2】しかし、上記の問題点としては、post-commit-hookの処理が遅い時があること、既存リポジトリから大量のリビジョン情報をHTTP通信で取得しようとするとタイムアウトが発生することがある。

前者の問題は、クライアントのコミット通知にタイムラグが発生する場合、すぐにサーバに反映されない時がある。
後者の問題は、既存リポジトリをRedmineリポジトリ画面に追加して、最新リビジョンを表示させようとすると、既存リポジトリの過去のリビジョン全てを取り込まねばならず、それに時間がかかってしまう。

前者の問題解決としては、「 > /dev/null 2>&1 & 」でfetch_changesets への通知をバックグランド処理にする。

/usr/local/bin/ruby -ropen-uri -e 'open("http://Redmineサーバ/sys/fetch_changesets?key=APIキー")' > /dev/null 2>&1 &

後者の問題解決としては、fetch_changesetsをrakeないしrubyでバッチ処理のように呼び出す。

rake -f /path/to/redmine/Rakefile RAILS_ENV=production redmine:fetch_changesets

ruby /path_to_redmine/redmine/script/runner "Repository.fetch_changesets" -e production > /dev/null 2>&1 &

こう見ると、RedmineのAPIはよくできていると思う。


| | コメント (0)

第11回RxTStudy勉強会を7/12土に開催します~Redmineプラグイン活用最前線

第11回RxTStudy勉強会を7/12土に開催します。
今回のテーマは、「Redmineプラグイン活用最前線」です。

第11回RxTstudy「Redmine Plugin 活用最前線」 : ATND

【1】基調講演は、@haru_iidaさんに「Redmineをプラグインで拡張しよう!」というタイトルでお話して頂きます。
また、野田さんには、「優しいプラグイン開発」というタイトルで「プラグイン開発時に気にしたいことをテスト関連メインで話す予定です。」

今回のテーマになった発端は、Redmineプラグインについて情報交換したいね、という話題がスタッフからあがったことでした。
RedmineのVer2.0以前はたくさんのプラグインがあるものの、Ver2.0以降は、RubyやRailsのバージョン、JavaScriptライブラリが変更されたことによって、対応しているプラグインがかなり少ないです。
元々、RedmineはRailsアプリゆえ、プログラミングしやすい開発基盤を持っているので、@haru_iidaさんにお聞きすれば、色々な話が聞けるでしょう。

私自身の興味としては、Redmineを開発基盤とみなした場合、Redmineをどのように機能拡張できるか、という観点で考えてみたいということがあります。
そのアイデアについては、品川Redmineで既に話しました。

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」 #47redmine: プログラマの思索

テーブルを追加したり、新たな機能を追加する場合に相当するので、Redmineプラグインの開発は、パッケージ製品のアドオン開発に相当します。
その場合、プログラミングやテストでどんな注意点があるのか、を聞いてみたいと思います。

【2】また、最近の傾向として、Redmineの有償・無償のパッケージ製品がチラホラ見られる。
私がWatchしているRedmineパッケージ製品としては、EPM-X、Lychee Enterprise、Redmine for ITILの3つだ。

【2-1】定量的プロジェクト管理ツール(EPM-X):IPA 独立行政法人 情報処理推進機構

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

チケット駆動開発を紹介した書籍一覧: プログラマの思索

【2-2】Lychee Enterpriseシリーズ

Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2~RedmineでEVMを実現 Lychee EVM: プログラマの思索


Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

【2-3】Redmine for ITILの特長|株式会社ホロンテクノロジー

Redmine for ITILが解決するもの: プログラマの思索

【2-4】この3つの製品に興味を持っている理由は、いずれもRedmineに不足した機能をカバーしようとする意図がある。

EPM-Xは、WF型開発で品質管理や工数管理などのメトリクスを厳密に分析したい場合に有効だろう。
EPM-Xの詳細な使い方は「チケット&計測でITプロジェクト運営の体質改善」の本を読むと良いだろう。

Lychee Enterpriseシリーズは、WF型開発で、ガントチャートやEVMを使いやすくし、要件と検収物件のトレーサビリティをチェックする運用ができる。
RedmineでEVMを実現する方法は、「Redmineによるタスクマネジメント実践技法」の第7章に記載している

Redmine for ITILは、障害・リリース管理や本番問い合わせ対応をITILプロセスで運用している時、Redmine上でも運用したい場合に有効だ。
RedmineでITILを実現する方法は、「Redmineによるタスクマネジメント実践技法」の第7章に記載している。

【3】もう一つ注意すべき点は、上記の3つのパッケージ製品はいずれも、WF型開発の運用を前提としていることだ。
私が「Redmineによるタスクマネジメント実践技法」を出版した時、Redmineをアジャイル開発で運用することを前提としてそのノウハウを詰め込みんだが、日本のSIで使われるRedmineはどうやらWF型開発を前提とする場合が多いように思う。

WF型開発でチケット駆動を実践する場合、完全チケット方式の運用はおそらくかなり難しいだろう。
その理由は下記で書いた。

チケット駆動開発がWF型開発と相性が悪い理由: プログラマの思索

WF型開発でチケット駆動を実践する場合、@sakaba37さんが提唱している「アダプタブルWF」くらいしか実践できていないのではないかと思う。

Twitter / akipii: 日本のチケット駆動開発の大半はWF型開発をベースにしたアダプタブルWFばかりだと思う。それぐらい標準プロセスが強すぎて柔軟性がない。 [#TiDD] アダプタブルな開発を実現するチケット駆動の3要素 http://sakaba.cocolog-nifty.com/sakaba/2014/02/tidd-3-e7d9.html

Twitter / akipii: アダプタブルWF RT @holypp: 考え結構近い。>「計画できることはWBSで。計画できないことはチケットで」というのが僕の主張です。 / “チケット駆動開発で作業管理はしないほうがいい - arclamp” http://htn.to/vrCybgY5k

その理由は、WF型開発では、プロジェクト立上げフェーズですべての作業をWBSで洗い出し、そのWBSを元に作業の進捗を計測していく運用になるが、「チケット管理は予実管理しにくい」特徴があり、相反するためだ。
そのため、「アダプタブルWF」のように、WBS管理からはみ出た突発的な課題、障害、レビューをチケット管理で補完する運用ばかりになるだろう。

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索

但し、アダプタブルWF以外の事例もあると思うので、色々聞いてみたい。

【4】今回の勉強会のパネルディスカッションでは、Redmineプラグインの開発以外にも、その運用方法についても議論する予定でいる。
なぜ、そのプラグインが必要になったのか、その背景をパネラーから引き出し、実際のあるべき運用方法を議論してみたいと思う。

| | コメント (0)

2014/06/05

BABOKの4つの要求

BABOKの4つの要求について考えたことをメモ。

【参考】
BABOKで“超上流”を強化する - Part2 4種類の要求を区別する:ITpro

(2/4)BABOKで“超上流”を強化する - Part3 “超上流”の標準化にBABOKを活用する:ITpro

要求の分類方法について|ザ・プロジェクトマネジャーズ

【プロジェクトマネジメントを成功に導くビジネスアナリシス】(その1、2)

BABOKR2.0 知識エリア: 要求アナリシス

【1】発注者がベンダーにシステム開発を依頼する時、RFPにシステムの要求や要件を載せる。
しかし、RFPに何をどこまで書くべきか、あいまいな時が多い。

最悪な発注者は、自分たちが欲しいシステムの要求をRFPに書けない。
その理由は、色んな利用部門の要望を収集するうちに、どんなシステムを作るべきか、「システムのあるべき姿」を想像できないからだ。
たくさんの利用部門の要望を集めただけの要求一覧は、スコープクリープを引き起こし、コスト超過と納期遅延の結果に終わる。

そして、「システムのあるべき姿」は、発注企業の経営戦略に大きく依存する。
システムを使って何を実現したいのか、を理由付けなければ、「動かないシステム」を作るだけ。

では、それら要求をどのようにまとめればよいのか?

【2】BABOKには、4つの要求の種類がある。

・ビジネス要求
・ステークホルダー要求
・ソリューション要求
・移行要求

理解するために、絵にまとめてみた。

【2-1】ビジネス要求は、組織全体としてのビジネス目標、ニーズ、戦略目標。
プロジェクトを開始した理由、プロジェクトを達成しようとする目標、成功度を測定するメトリクスなど。
例:来年度の第1四半期末までに、販売管理業務のコストを2割削減したい

【2-2】ステークホルダー要求は、利用部門などのステークホルダーの個別のニーズ。
ステークホルダーのニーズとソリューションとの関わり。
例:取り扱い品目の変更に伴う作業の手間を減らしたい

【2-3】ソリューション要求は、機能要求と非機能要求がある。

・機能要求
ビジネス要求やステークホルダー要求を具体化するのに必要な機能、業務、システムが実現すべき機能。
例:すべての社内システムの品目マスターを一括変更できるようにしたい

・非機能要求
ビジネス要求やステークホルダー要求を具体化するのに必要な機能、業務、システムが実現すべきキャパシティ、性能、セキュリティ、可用性、ユーザビリティなど。
例:毎週月曜日の朝9時に、前日まで1週間分の売り上げや在庫のデータを分析できるようにしたい

【2-4】移行要求は、現状(AsIs)からあるべき姿(ToBe)への移行を円滑に進めるためにソリューションが満たすべき条件。
ソリューションのアセスメントと妥当性確認を通じて作成し、定義する。
スケジュールに関する要求が多い。
例:今年度の第3四半期中に組織の体制を見直し、第4四半期に新しい業務とシステムを試行する

【3】RFPに書くべき要求は、ビジネス要求とステークホルダー要求だ。
経営戦略に基づくビジネス要求が根本にある。
ビジネス要求を満たすべく、ステークホルダー要求やソリューション要求などがある。

そして、利用部門や情報システム部などの各ステークホルダーからの要求は、ステークホルダー要求にまとめる。
但し、何でもかんでも乗せると、見積りが高くなってしまい、予算をオーバーしがち。
いかにスコープを確定して、ステークホルダー要求を絞り込むか、が必要になる。

システムで実現すべきソリューション要求、現状の業務を新システムへ移行する移行要求は特に書く必要はない。
但し、移行スケジュールを提示するなら、移行要求は書いた方が、ベンダーもスケジュールに沿った見積を作ってくれる。

要求を4種類に分けて書くように意識したら、RFPも書きやすくなるような気がする。

【3】4種類の要求のうち一番難しいのは、ビジネス要求だ。

BABOK 2.0 エンタープライズアナリシス

(引用開始)
ビジネスアナリシスの真骨頂です。この知識エリアがBAの価値を決めると言っても過言ではありません。
ソリューションを開発する真の理由(ビジネスニーズをベースにしたものでWHYに相当します)を明確にします。
ビジネス機会(または課題/問題)を明確にし、競合との差別化、理想の状態(ToBe)と現状(As_Is)とのGAP、GAPを解消するソリューション、ビジネスの収入増、コスト(ソリューション開発による)、そして最終利益を明確にし、ソリューション開発の最終判断の材料(をまとめたものをビジネスケースといいます)をスポンサーに提供します。
そしてスポンサーは必要なソリューションへの投資を決断するのです。
どれだけ魅力的なビジネスケースを書けるかはビジネスアナリストの腕前次第と言えます。

他の知識エリアとの決定的な違いがあります。
他の知識エリアのタスクは、一定以上のレベルのビジネスアナリストなら似た結果が出てきます。
しかしこの知識エリア(エンタープライズ分析)では、ビジネスアナリスト個人への依存度がかなり高いという特徴があります。
同じ現状を分析した結果、効果予測が収益30%増のソリューションもあれば、100%増のソリューションもありえます。必要な投資額も異なります。
スポンサー/組織にもよります。
ハイリスクハイリターンを好むスポンサー/組織もあれば、ローリスク・ローリターンを好む堅実的なスポンサー/組織もあります。
スポンサー/組織によってソリューション内容(アプローチを含めて)を柔軟に考える必要があります。ビジネスアナリストはそれらに柔軟に対応できなければいけません。
(引用終了)

組織が目指すべき経営戦略とその実現方法には、たくさんの観点がある。
どれが正しいというわけでもない。
ハイリスクハイリターンを好む組織もいれば、ローリスク・ローリターンを好む組織もいる。
スタートアップ企業やWebサービス企業なら全社だろうし、製造業や農業のような業界なら後者が多いだろう。

すると、その経営戦略に基づくビジネス要求も変わってくる。
ハイリスクハイリターンならば、最新の技術にチャレンジするやり方を取る時もあるだろう。
ローリスクローリターンならば、枯れた技術で安く仕上げるやり方を選ぶ時もあるだろう。

ビジネス要求を見定めるのは、アナリストの腕で相当に変わってしまうわけだ。

| | コメント (0)

DevOps時代の必読本「チーム開発実践入門」

チーム開発実践入門」の感想記事をメモ。

【元ネタ】
DevOps時代の必読本?「チーム開発実践入門」を読んだよ! - シスアーキ in はてな

(引用開始)
チーム開発はSIerこその課題
僕は過去に大手SIerで常駐、今では自社で請負の開発に従事しています。その経験からも、ツールを活用したチーム開発はSIerの大きな課題と考えています。
SIerは大きな資本金を背景に、大規模システムを一人では到底仕上げれない期間で開発するお仕事です。そのため、開発チームは急造かつ大人数という特性があります。

その中で、

要求/要件/課題/品質の管理
スケジュール/タスク/納期管理
品質管理
質問管理
コスト管理
変更/バージョン管理
構成管理

といった様々な管理をチームリーダーは行う必要があります。

今までの開発では、Excelなどの表計算ソフトにより手作業によりこれらの管理作業をカバーしてきました。大規模チームで人のリソースは豊富にあるので、開発時はマンパワーでどうにか賄うことも可能です。
しかし、このような属人性に依存した管理方法は時間経過と共に必ず崩壊します。
「チーム実践開発入門」にはそういった崩壊を防ぐヒントが多数記述されています。
(引用終了)

SIほど、開発プロセスやプロジェクト管理を補完するようなツール、開発基盤が必要な場所はないだろうと思う。
受託開発案件は、繁忙期と閑散期でリソースの変動が大きいために、どうしてもプロジェクト管理を上手く切り抜けなければならない使命がある。
SIでは、プログラミング技術よりも、大量の要員を適材適所に配置し、彼らの進捗や成果物をうまく管理していくスキルの方が重視される。
だから、日本のIT企業では今でも、優秀なプログラマよりも優秀なプロジェクトマネージャを欲しがっている傾向がある。

しかし、日本のSIは、開発プロセスの基盤に事前に投資するという発想がない。
売上が立たない時点で、開発環境に投資する、とか、モデリングツールに投資する、という決定ができないみたいだ。
管理職は、目先の売上しか見ていないのだろう。
つまり、彼らは、経営戦略に基づいた行動ではなく、局所最適化された行動しか取れていないのだ。

2010年頃から、ソフトウェア開発の環境や開発プロセスが急激に進化しているのに、その流れにのっている会社とそうでない会社の違いが大きくなってきているように思える。

僕は「チーム開発実践入門」を立ち読みでしか読んでいないけれど、バージョン管理・チケット管理・継続的インテグレーション・テスト自動化・仮想環境など、開発プロセスに関する技術が幅広く網羅されている点が良いと思う。
チケット駆動開発も紹介されている点もすごく良かった。


| | コメント (0)

スクラムを大規模組織へ導入した事例

アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまでという記事が素晴らしかったのでメモ。

【元ネタ】
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。QCon Tokyo 2014 - Publickey

アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(後編)。QCon Tokyo 2014 - Publickey

『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』 - delirious thoughts

(引用開始)
組織の課題としては、増え続けるサービスの品質を担保したい、そして中央集権的な管理から自律的なチームにすることで改善スピードをどんどん上げていきたい、ということがありました。
そこで出てきたのが、「スクラム」という言葉です。
この頃には役員陣も興味を持ち始めてくれるようになり、ブログで「ハッカーと画家」とか「アジャイルサムライ」といった本を読んだことを書いたりしていて、アジャイル開発を議論できる空気になってきました。
(引用終了)

社長のような経営トップがアジャイル開発に興味を持ってくれるとすごく導入しやすい。
アジャイル開発とは何か、アジャイル開発を入れるとどんな利点があるか、を逐一説明する手間を省ける。
アジャイル開発を自社に入れる場合、ゴールをどこに置くか、どんな戦略で入れるか、という議論へすぐにたどり着ける。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』の「将軍の耳にささやく」パターンを連想させる。

個人的に思うのは、経営トップほど最新の情報を知っているので、アジャイル開発も当然知っていること。
むしろ、管理職の方が最新の開発トレンドを全く知っておらず、10年前の技術や管理手法で対応しようとして、少しずつ現状とずれてきている。

上記資料で興味深った点は、組織へ導入するTipsだ。

【Tips1】組織を丸ごと変えてやるのは失敗する。真似てもらう。

アジャイル開発は、メンバーの自立化を前提にしている。
だから、強制するのはアジャイル開発と自己矛盾している。
しかし、そのままの状態で放置しても、アジャイル開発は導入されない。

そこで、一つの組織でScrumを導入して成功させ、その成功事例を口コミで広げて、他チームに真似てもらうようにしたこと。
そして、勉強会で広げたこと。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』のエバンジェリスト、イノベーター、正式な推進担当者、アーリーマジョリティ、勉強会のパターンを連想させる。

【Tips2】また、組織の目標とアジャイル開発が競合するという課題もある。
組織には、売上目標や戦略的な目標があり、それによって成績評価される。
組織目標にアジャイル開発が役立つという説明理由を持っておかなくてはならない。

そのために、アジャイル開発を導入すると、開発の生産性も上がるし、社員の技術力向上やマネジメント能力向上にもなりますよ、とアピールするための準備が必要になる。
成功したと結果が出れば、風見鶏のように管理職も応援してくれる。

その準備の一つがパターンを用意すること。
自動化、チーム内での分割、タスクの粒度とWIP(Work in Progress:仕掛かり)の制限、ストーリーの直列化、ペアプログラミング、バックログ、バーンダウンチャートなど。

チーム内の分割は、『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』の「正式な推進担当者」に相当するだろう。

留意すべき点は、それらパターンが全てのチームに当てはまるわけではないこと。
自動化は開発環境の整備なので、全チームに当てはまるだろうが、チームの種類に応じて、パターンの適用を変えてみるわけだ。

チームには、営業マンもいれば、デザイナー、Webディレクター、インフラ担当者など、それぞれの作業内容は異なるし、チームのカラーも違う。
試行錯誤しながらパターンを試して、改善していく。

こんな事例を見ると、Webサービスなど最新のIT技術や開発プロセスを取り入れなければいけない危機感を持つ会社と、日本の製造業や農業のように古い装置産業の会社は全然違うのだろうと思ったりする。

そして、『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』のように、大規模組織にどのようにアジャイル開発を取り入れると上手くいくのか、成果が出るのか、というノウハウもパターン化されて公開されている。
その意味では、アジャイル開発導入の敷居はすごく下がってきているような気がしている。

| | コメント (0)

2014/06/02

日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする

日本のSI企業で、Redmineによるチケット駆動開発をチームで運用し始めると、次第にタスクはスムーズに流れていく。
自然にアジャイル開発が取り入れられ、メンバーも自発的にタスクをこなしてくれる。
そして、仕事をうまく振って自分もタスクをこなして、チームのタスクを上手く回して、僕も早帰りする。

するとしばらくすると、他の火を噴いている案件にヘルプを手伝わされたり、チームの開発者を引き抜かれたりする。
「人が余っているなら、ちょっとよこせ」と部課長クラスから思われてしまうのだ。

生産性の良いチームほど、他のデスマーチ・プロジェクトのチームに足を引っ張られる。
だから、たとえ仕事がはかどっていても、あまりはかどっていない雰囲気を醸し出したり、無意味に残業したりする。

日本人の「和を尊ぶ」雰囲気は正直嫌なこと、この上ない。

| | コメント (0)

2014/06/01

第7回ドメイン駆動設計勉強会の感想 #dddosaka

第7回ドメイン駆動設計勉強会に参加してきた。
第4章「ドメインを隔離する」を皆で輪読して議論して、自分の浅い理解を深めることができて有意義だった。
議論した内容を質問回答形式で記載しておく。

【参考】
第7回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper

vol7_20140601_事前疑問質問 ・ dddosaka/reading_ddd_report Wiki

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回

[ 技術講座 ] Domain-Driven Designのエッセンス 第2回

[ 技術講座 ] Domain-Driven Designのエッセンス 第3回

[ 技術講座 ] Domain-Driven Designのエッセンス -目次-

【Q1】「ドメイン駆動設計は、伝統的ないくつかの考え方を基に、強調する点をずらしているのだ」という意味は?

【A1】伝統的な考え方はオブジェクト指向設計やデータモデリングなどの技法。
一方、ドメイン駆動設計は、それらを包含して、ドメインモデルをユビキタス言語で、ドメインエキスパートや開発者も共通理解できるような仕組みを提供する。

オブジェクト指向設計のように、オブジェクトの抽出とその関連に注力するのではなく、モデルの背後にあるドメイン(業務知識、ビジネスモデル)に注力する。

ドメイン駆動設計は、メタモデルのような感じ。
ソースコードで書かれた実装モデルだけでなく、その実装モデルは、ドメインという業務知識が埋め込まれて、ユビキタス言語という共通用語で表現される。

【Q2】「それによって道を外れることなく、折衷案を考え出すことができるのだ」という意味は?

【A2】ドメインエキスパートが描く分析モデルと開発者が実装する実装モデルの間にドメインモデルがある。
それらの折衷案である。

【Q3】P.66のレイヤ化アーキテクチャの図には「→」「△--」のような矢印がある。その意味は?

【A3】「→」は参照関係、「△--」は継承関係ではないか。

普通は、UI層→アプリケーション層→ドメイン層→インフラ層のように、上位レイヤが下位レイヤに依存する構造になる。
継承関係を使う場合は、例えば、ActiveRecordのように、インフラ層を継承したドメイン層があるだろう。
つまり、ORマッピングに関する処理はインフラ層にあるが、そのエンティティ特有の処理はドメイン層にある。
「インフラ層△--ドメイン層」の関係になる。

他に、ガジェットのように、「インフラ層△--UI層」の例もあるだろう。

別チームの議論では、上位レイヤが下位レイヤを継承する場合は、IoCを使いたい時があるらしい。
つまり、依存関係の逆転によって、下位レイヤが上位レイヤを呼び出すのではなく、上位レイヤが下位レイヤを呼び出すように、参照関係の向きを変える時に、継承関係を使う場合がある。

P.72の「アーキテクチャフレームワーク」でその内容の説明がある。
実装例としては、Javaのアノテーションが相当する。

Javaのアノテーションを使うフレームワークの例では、SeasarにおけるFormクラスのアノテーションによるValidatationチェック処理などがある。
RubyならMixinを使う事例もあるだろう。

Pythonにも同じような実装例があるらしい。

アーキテクチャフレームワークの失敗例としては、JavaのEJBがあるだろう。
ドメインオブジェクトをEJBとして実装すると、巨大な実装になりやすいし、ドメインを再利用しにくい。
しかも性能も悪い。

他の失敗例として、Hibernateもあげられていた。

【Q4】サービスクラスは、アプリケーション層なのか? ドメイン層なのか?

【A5】ドメイン駆動設計では、アプリケーション層のサービスもあれば、ドメイン層のサービスもあるし、インフラ層のサービスもある。
「サービス」の意味によって、存在するレイヤが異なる。

【Q5】ユースケースは、アプリケーション層なのか? ドメイン層なのか?

関西IT勉強会で聞いたとき、ドメイン駆動設計では、ユースケースはドメイン層に含まれると聞いた。

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想: プログラマの思索

【A5】Yes。
ユースケースは、ビジネスルールを表現するという意味で、ドメイン層に置かれる。
この点は、従来のオブジェクト指向設計とは違う観点になる。

【Q6】「アプリケーション層のレイヤは薄く保たれる」という意味は?

【A6】VBならコマンドボタンのFormクラス、StrutsならActionクラスがアプリケーション層に含まれることに相当する。
アプリケーション層は、UI層とドメイン層でデータをやり取りする場所であり、ビジネスロジックはドメイン層にへ委譲(Delegate)されるようにコーディングする。
これによって、ドメイン層が明確に分離されるだけでなく、凝集度も高まる。

【Q7】図4.1では、口座振り込み処理における資金振替クラスのCommitメソッドはアプリケーション層であるのに、注釈で「振り込みの引き落としが失敗したらトランザクションが失敗する」というビジネスルールが書かれている。
この内容は、ドメイン層で表現すべきではないか?

【A7】否。トランザクション処理は、アプリケーション層に配置すべき。
トランザクション処理の責務はアプリケーション層にある。

ただし、トランザクションの単位や粒度をどれくらいにすべきか、という点は、業務や方式設計に大きく依存する。
トランザクションの単位が大きければ、ロックがかかりやすく、処理も遅くなる。
トランザクションの単位が小さければ、障害が起きた時に、ロールバックやバッチのリランの手順が複雑になる。

【Q8】サーバー側から見れば、RIAはUI層だが、RIAのようなリッチクライアントでも、クライアント側にはドメイン層が含まれるか?

【A8】Yes。
クライアントにもMVCモデルを作ることはある。
Backborn.jsのように、クライアント側でJavaScript内にMVCモデルをコーディングする場合もある。
VBやC#のクライアントアプリも同様。
あるいは、Node.jsのように、サーバーサイドでクライアントアプリのドメインモデルを自動生成する場合もあるかもしれない。

クライアント側でドメイン駆動設計する場合、以下のような実装例もあるだろう。

・UI層=画面のコントロールボタンなど
・アプリ層=VBのFormクラスなど
・ドメイン層=画面表示する項目のValidationチェックなど

その場合、インフラ層は、JSONやXMLで表現されるデータになる。
つまり、インフラ層はサーバー側であり、HTTP通信でJSONPなりSOAP、RESTなどで、クライアントとデータをやり取りする。

この時、DBのトランザクション処理でCommitやRollbackがあるように、HTTP通信でもタイムアウト処理やセッション保持などのトランザクション処理が必要になる。
それらの処理はインフラ層に含まれ、ドメイン層は関知しない。

同様な事例として、複数の業務システムが連携するようなSOAもあるだろう。
例えば、販売管理システムと会計システムがSOA連携している場合があるだろう。
つまり、販売管理システムのインフラ層には、会計システムが含まれ、そのデータのやり取りは、SOAPメッセージによる通信処理になる。

すると、販売管理システムのドメインと会計システムのドメインは、使われるユビキタス言語が異なる。
すなわち、それぞれのドメインのコンテキストは異なる。
販売管理のドメインと会計のドメインは「コンテキストマップ」に配置され、それぞれのドメインは「境界づけられたドメイン」で区別される。

この発想は、System of Systems にもつながるだろう。
各ドメインは一つのサブシステムとして独自で動作し、そのサブシステム同士が関連して一つの大きなシステムをなす。
以下のWebページでは、System of Systemsの例として、デジタルカメラとカラープリンタを統合した家電製品があげられている。
最近なら、車載機器などの組み込み機器、IoTのようにネットワーク機能を持つ家電製品の部品、複数の業務を統合パッケージ製品として売り出すERPも相当するだろう。

System of Systems : システムオブシステムズとは: システム思考xデザイン思考xマネジメントで自己成長

System of Systemsの各サブシステムは「境界づけられたドメイン」として区別され、サブシステム同士が関連した一つのシステムは「コンテキストマップ」になる。
「コンテキストマップ」の中に、それぞれのサブシステムの関係が表現されている。

【Q9】「ドメイン駆動設計が最も効果があるのは、大掛かりなプロジェクトに対してである」という意味は?

「大掛かりなプロジェクト」の対象は、大規模プロジェクトだけでない、という意見があった。
ドメインの複雑度の観点もあるだろう。
また、当初は単純なドメインであっても、ライフサイクルの長い業務であれば、運用するうちに改善要望がどんどん反映されてドメインが複雑になっていく場合もあるだろう。

その場合、第4部以降では、そのような大規模なプロジェクトにおけるドメイン駆動設計のパターンとして、「腐敗防止層」「コアドメイン」「蒸留」などがあげられている。
例えば、大規模プロジェクトにおいて、モデルの整合性を維持するために、複雑なインフラ層の間に腐敗防止層というI/Fを配置してドメインモデルを隔離したりする。

【Q10】「利口なUI」と「トランザクションスクリプト」の違いは何か?

「利口なUI」は、UI層にビジネスロジックを埋め込んでしまい、ドメインモデルを抽出していないアンチパターン。
「トランザクションスクリプト」は、アプリケーション層にビジネスロジックを埋め込んでしまい、ドメインモデル貧血症になってしまうアンチパターン。
すなわち、両方ともドメインモデル貧血症だが、その症状のレイヤが異なる。

「利口なUI」の解決パターンとしては、ドメインモデルを分離するだけでなく、「レイヤ化アーキテクチャ」を用いて、アプリケーション層にドメインモデルを委譲する「トランザクションスクリプト」もある。

【感想】
最近、ドメイン駆動設計が注目を浴びる理由は、クラウド技術が普及したことによって、業務システムの移植性の品質要求が高まったこともあるだろうと考える。
クラウドにある業務システムは、サーバーというハードウェアに依存せず、どのサーバーでも移植できなければならない。
すると、ドメイン駆動設計の思想で構築された業務システムならば、ドメインモデルが隔離されているので、クラウド環境というインフラ層を変えても、簡単に移植できて、稼働できるようになるはずだ。

その意味では、クラウド技術とドメイン駆動設計は相性が良いのではないか。

【まとめ】
僕は、ドメイン駆動設計が実現されたシステム設計の経験はない。
だから、ドメイン駆動設計は、いつも桃源郷、理想郷のように感じる。

本来あるべき業務モデルの設計は、ドメイン駆動設計なのだ、と思うが、そのために必要な手法が自分の頭で把握できていない。
今後も勉強会で議論してみる。

【追記】
Twitter / akipii: ドメイン知識が顧客でなくSIに流れていくのも凄く同感。@kawakawaさんによるドメイン駆動設計読書会@大阪第6回までの感想とドメイン駆動設計の基本についてのまとめ http://goo.gl/Lv71Xd #dddosaka

Twitter / akipii: 日本ではSIの方が顧客よりドメインエキスパートになる時がある指摘は凄く同感 @kawakawa さんによるドメイン駆動設計読書会@大阪第6回までの感想とドメイン駆動設計の基本についてのまとめ http://goo.gl/Lv71Xd #dddosaka

| | コメント (0)

« 2014年5月 | トップページ | 2014年7月 »