« 2014年4月 | トップページ | 2014年6月 »

2014年5月

2014/05/30

チケット駆動開発によるチーム力向上の事例 #Redmine

最近、Redmineの運用事例をSlideshareでたくさん見かける。
その中でも、参考になった資料をリンクしておく。

【1】

チーム力向上のために、取り組んだ活動は3つ。

①チーム力向上活動
②Redmineの活用
③信頼貯金の蓄積

そのうち、Redmineの活用では、次の3つを実施。

a)Wikiでノウハウ蓄積
b)チケットでコミュニケーション
c)フォーラムで見積り根拠

参考になったのは、フォーラム機能を使って、顧客とのやり取りや仕様変更のやり取りを記録するだけでなく、見積り根拠も残すようにした運用だ。
SIならば、顧客からの要望に対して、必ず見積もりし、その見積り工数と金額で同意を取ってから、作業を開始する。

しかし、顧客から、過去に同じような仕様変更を頼んだのに、なぜ今回はこんなにお金がかかるのか、とよく質問される場合が多い。
その時、過去の案件の見積もり根拠は普通は記録されていない場合が多いので、交渉に手間取りやすい。
小規模案件ほど、見積もり根拠となる資料はきちんと作成せず、口頭やメモ、他人の頭にしか残っていない。

興味深いのは、顧客とのやり取りをチケットではなくフォーラム機能を使った点だ。
顧客の要望をチケットで登録すると煩雑になると考えたのだろう。
フォーラム機能は、チャットのようにラフにやり取りを記録できる点がいい。

Redmineフォーラムからチケットを起票するプラグインもあるので、例えば、フォーラムで議論したり、やり取りしている最中に、タスクが発生したらチケットを起票する、という運用も可能だろう。

Redmineプラグインあれこれメモ: プログラマの思索

Issue from message - Plugins - Redmine

それから、信頼貯金を蓄積するという発想もすごくいい。
最近のSIでは、受注前の営業活動で、開発チームのSEが自由に問合せ対応できない運用が多くなっている。
その理由は、内部統制上セクションごとに担当を分けるべき、とか、開発SEの工数が無駄になる、とか、様々だ。
その分、顧客の満足度は落ちるし、顧客への対応も遅くなってしまう。

最近のソフトウェア開発の流れは、DevOpsや自己組織化のように、組織のセクショナリズムを廃止し、組織を横断して技術者が自由に行動できるようにする方向へ発展している。
それなのに、今の日本企業は、ビジネスプロセスを複雑化し、サイロのような組織構造にこだわり過ぎている。
日本の企業は、世界の流れから遅れている。

【2】

チケット管理について的確な表現をしている。

(引用開始)
・チケットはワークフローで制御される開発プロセス
・開発プロセスは問題を発見してくれる
・自動化や見える化の促進にITS を利用出来る
※開発プロセスやツールは問題を解決してくれない点に注意!
(引用終了)

チケット駆動開発の利点は、開発プロセスや製品の健康診断を実施してくれることだ。
例えば、チームのパフォーマンス、工数の予実管理、チーム状態の消化率や達成率や見積もりなどを表示できる。

このチームは、個人の残りチケット一覧、チームの一週間の予定工数、チームの曜日毎の終了工数合計、 バーンダウンチャート(理想値 現在値)、チケットの内訳と終了数、などをレポートで見ているようだ。
そのたびに、棚卸しして、対策を実施している。
他のチームがどんなレポートを使っているのか、を見るのはすごく参考になる。

しかし、チケット駆動開発は、問題を見える化するだけであり、問題を解決してくれるわけではない。
問題解決の方法はチームによって様々だ。

チケット管理ツールが見つけた問題を、チームがどのように解決していくべきか?
成熟したチームは、問題が発見されると同時に、どんな対策を取ればよいか、すぐに判断できて、すぐに実行できる。
未熟なチームは、経験者からコーチングを受けなければ、何が問題なのかも把握できず、どんな対策があるのか、も思いつかない。
つまり、逐一指導を受ける必要がある。

「(チケット駆動開発は)有名なプロセスの良い所が活用出来る」指摘で、デブサミ2013の私と@sakaba37さんの発表資料を紹介してくれているのは嬉しい。
少しは役に立てただろうか。

【3】

Redmine+Git+GitLab+Jenkinsを使って、障害修正や仕様変更などの小規模開発をトピックブランチで実施した運用例。
資料を見ると、Redmineはmasterのソース管理、GitLabはソース修正が完了していない状態でのマージ作業と役割を変えているようだ。
普通はRedmine+Gitだけで運用しているだろうが、GitLabを運用フローに入れた点が興味深い。

では、RedmineだけでなくGitLabを入れている理由は何なのか?

おそらく、トピックブランチをチケット単位で作業する時、Redmineチケットには、最後の完成したパッチのみをコミットするようにしたいのだろう。
masterがパッチをPullで取り込むとき、それまでのパッチ作成の経緯は記録が不要なのだろう。
パッチ作成に至るまでの修正やフィードバックの経緯があると、チケットのに内容が煩雑になると判断したのだろう。

チケットは最終パッチの記録だけでいい、という運用は、例えば、結合テストで元請けがmasterを管理していて、下請けが障害修正している場合、元請けは最終パッチだけ受入すればよく、最終パッチの修正の経緯は不要な場合もあるだろう。
つまり、Redmineの運用で、2つの役割の違うチームがチケット管理している場合が当てはまるだろうと思う。

この辺りは、それぞれの運用プロセスに依存すると思う。

【4】

「放置されたチケット」「停滞したチケット」が多くなった状況をどのように解決したのか、という運用事例。
読んでみると分かるが、Redmineに問題があるのではなく、Redmineのチケットをどのように運用すれば作業がサクサク進むのか、という方向で対策を実施している。

僕は、チケット駆動開発を効果的に運用するにはアジャイル開発と組み合わせるのが良い、と思っているので、アジャイル開発のプラクティスを実践する方が良いと思っている。
WF型開発でもチケット管理できるが、チケット駆動開発の利点が十分に出ないのだ。
その理由は以前たくさん書いた。

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

「「チケット駆動開発とメトリクス」の感想」の感想 - Some Days You Get the Bear

他にもあれば探してみる。

| | コメント (0)

2014/05/28

チケット駆動開発のナビゲーションマップ #Redmine

Redmineによるチケット駆動開発のプラクティスをパターン言語で表現したら、ナビゲーションマップでどう描けるか、試してみた。
Slideshareにアップして、ダウンロードできるようにしたので、ご参考下さい。

【参考】
パターン言語の構造と事例集: プログラマの思索

【1】チケット駆動開発のナビゲーションマップを作成した意図

「デザインパターン」や「ドメイン駆動設計」や「組織パターン」を読んでみると、最初のページにパターンの関連を表した地図のようなものが出てくる。
それがナビゲーションマップ。
パターンの全体像みたいなもの。

僕は、Redmineによるチケット駆動開発がアジャイル開発ととても相性が良いことを経験した後、そのノウハウを他人に説明し、共有できる方法はないか、とずっと思索していた。
その方法として、パターン言語が一番有効ではないかと思い続けてきた。

元々、XPやScrumを代表とするアジャイル開発はパターンコミュニティと密接に絡んでいる。
XPやScrumでは、重要なプラクティスをパターンという形式でその概念で呼ぶことで、その内容を他人に共有しやすくするだけでなく、こうすれば実践できるよ、というHowも一緒に伝えている。

たとえば、テスト駆動、ペアプロ、継続的インテグレーション、デイリースクラム、小規模リリースなど、そのプラクティスを連呼するだけで、その概念の実体もメンバーで共有できる。

しかし、これがCMMI、PMBOKやBABOK、ITILのような知識体系では、うまく説明できないように思っていた。
アジャイル開発もチケット駆動開発も、理論から生まれたアイデアではない。
現場で試行錯誤しながら、こんな方法でやればうまくいくよ、というプラクティスを抽出し、体系化づけたもの。
決してトップダウンではない。
でも、ボトムアップで生み出された概念は、それを綺麗にまとめる手法があまりないのも事実。

パターン言語は、経験から生み出された暗黙知を形式知に変換する上でとても有効な手法だと思っている。
チケット駆動開発も、XPやScrumのように、パターン言語で表現できたら、もっと伝わりやすくなるのに、とずっと思い続けてきた。

そこで、自分の考えを元にナビゲーションマップで描いてみた。

【2】チケット駆動開発のナビゲーションマップに出てくるプラクティスは下記の通り。(順不同)

1)Ticket First
 チケットから始めよう。
 チケットはタスクカードと同じ。(@sakaba37)

2)No Ticket, No commit
 チケット無しのコミット不可。(@machu)
 トレーサビリティの実現。

3)No Ticket, No Work
 チケット無しの作業不可。(@mrgoofy33)
 チケットに書かれていない作業をやっている人は、「ヤミ作業」している。

4)チケットで分割統治
 タスクはチケットに分割して統治せよ。
 「肥大化したチケット」「停滞したチケット」は分割しよう。

5)チケットはワークフローに従う
 作業手順は、アクティビティ図・チケットの状態遷移図・ステータスのデシジョンマトリクスと同じ。
 ワークフローが1種類しかなければ、「問合せはバグ修正なり」というアンチパターン。
 「モンスターチケット」は、チケットが頻繁に差し戻しされて復活してしまうアンチパターン。

6)チケット集計はワークフローに従う
 進捗一覧、障害一覧、課題一覧などの帳票は、ワークフロー(Redmineならトラッカー)ごとに集計される。

7)棚卸し
 「放置されたチケット」は定期的に棚卸ししよう。
 店舗や工場、倉庫における商品や製品の実地棚卸しと同じ。

8)ペア作業
 チケットはふたり以上のメンバーのやり取りを通してCloseされる。
 チケットは作業のキャッチボール。

9)チケットはシンプルに
 アジャイルに作業したいなら、チケットのカスタムフィールドは最低限にする。

10)ロールでビューを切り替える
 顧客、リーダー、開発者のロールごとに、見たいチケット集計結果は違う。

11)私に聞くな、チケットに聞け
 担当の作業、過去の情報はチケット管理システムに全て記録されている。
 RSS、更新メールで担当の作業は通知される。

12)バックログ
 リリース時期不明のチケットは、バックログや内部課題のような特別なイテレーションで保留する。
 PivotalTrackerならアイスボックス(冷蔵庫)になる。

13)プロジェクトは製品に従う
 プロジェクト(チケットの集合)は、製品単位・顧客単位に分けて管理する。

14)イテレーション・リリースバージョン・マイルストーン一致の原則
 XPのイテレーション、ブランチのリリースタグ、工程のマイルストーンは同期する。
 「Version is Iteration」でもある。
 Redmineのロードマップで実現される。
 バージョンやロードマップ機能を使っていない「空っぽのロードマップ」というアンチパターン。
 手戻りが発生するたびにバージョンがReOpenされる「工程単位のバージョン」というアンチパターン。

15)小規模リリース
 バージョン単位にチケットをグループ化して、定期的に小刻みにリリースしていく。
 開発のリズムが生まれる。
 リリースされるチケット数はVelocityとほぼ同じ。

16)プロジェクトとブランチ一致の原則
 プロジェクトは、リリース可能なブランチと同期する。
 リリース可能なブランチは製品単位になる。

 Conwayの法則、派生開発、ソフトウェアプロダクトラインに通じる考え。
 工程単位のプロジェクト、セクショナリズム、サイロというアンチパターン。

17)No Ticket, No fork
 masterからフォークされた「トピックブランチ」は、チケット単位に作る。
 「トピックブランチ」をマージするタイミングで、チケットはCloseされる。

18)Scrum of scrum
 大規模プロジェクトにおける複数チームの課題管理は、プロジェクトを2層構造にする。
 第1階層を課題管理プロジェクト、第2階層を各チームのタスク管理プロジェクトにする。
 CCB(変更管理委員会・PMBOK)、CAB(変更諮問委員会・ITIL)と同じ。

19)朝会
 XPの朝会、Scrumのデイリースクラム。

20)ふりかえり
 リリース後にKPTでふりかえり。
 得られた知見は、次のイテレーション計画へ反映する。

21)No Ticket, No Release
 チケット無しのリリース不可。(@kuranuki)

22)進捗率・ステータス一致の原則
 進捗率とステータスは連動させる。
 チケットの完了基準を明確にする。
 停滞したチケットというアンチパターン。
 進捗率が90%のまま停滞したチケットは、90%シンドロームと呼ばれる。

23)プロジェクトで分割統治
 複数チームのタスク管理、複数の製品における派生開発は、プロジェクトで分割して統治せよ。
 一つのプロジェクトにまとめると、「肥大化したプロジェクト」というアンチパターン。

多分、チケット駆動開発のプラクティスは他にもあるだろう。
上記はあくまでも一つの案。
今後ブラッシュアップしていきたい。

| | コメント (0)

2014/05/22

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

Redmineのアドオン製品 Lychee Association ChartとLychee Actual Dateのデモ画面を触ってみた。
感想をラフなメモ書き。

【参考】
Lychee Enterprise

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

【1】Association Chart | Lychee Enterprise

【1-1】チケット関連図を提供する製品。
チケットを画面の右横欄にある「チケット関連図」のリンクを押すと遷移する。

デモ画面を見ると、チケットの配下にある子チケット・関連チケットを画面上に全て表示される。
使い道としては、親子チケットでWBSを実現している場合、親チケットを要件やストーリー、子チケットをタスクに分割しているから、作業漏れや仕様漏れのチェックに使える。

例えば、機能Aの親チケットに対し、開発やテストの作業以外にも、別ライブラリを用意するタスクが必要というレビューがやりやすくなるだろう。

また、チケットに関連付けられたリビジョンも表示するので、成果物の網羅性を点検するのにも使えるだろう。
タスクのチケットに紐づけられたリビジョンがなければ、成果物が漏れている可能性があるわけだ。

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」 #47redmine: プログラマの思索で聞いた話だが、品質管理部の方が、リリース前の出荷時に、LycheeAssociationChartを使って、チケットと成果物のチェックに使われているらしい。

利用場面としては、例えば、プロジェクト計画時に、プロジェクトリーダーがWBSをチケットで全て書いた時に、作業漏れや要件漏れがないかを品質管理部がレビューする時に使える。
あるいは、本番リリース前、次のテスト工程前に、必要な成果物が作られているか、全て網羅されているか、を品質管理部がレビューする時に使えるだろう。

【1-2】Lychee Association Chartの関連線を見ると、先行・後続・ブロック・重複などの関連チケットを表示制御できる。
フィルタで「親子チケット」「関連するチケット」「関係しているリビジョン」のチェックをON/OFFすればいい。

例えば、MSProjectのガントチャートのような感覚でスケジュールの先行・後続・ブロックの関係を見たい時は、「関連するチケット」をチェックする。
すると、先行・後続・ブロック元・ブロック先の関連線が矢印の向きで表示してくれるので、分かりやすい。

あるいは、WBSのような階層構造で見たい時は、「親子チケット」をチェックする。
すると、要件→仕様→タスク→子タスクのような階層構造で表示されるので、要件漏れ、仕様漏れ、タスク漏れのチェックに使える。
「関連するチケット」をOFFにすれば、不要な先行・後続・ブロックの関連線を表示しないので、見やすくなる。

成果物がきちんと作られているかをチェックするなら、「関係しているリビジョン」をチェックすればいい。

【1-3】ダウンロードボタンを押すと、A4だけでなく、A0・A1・A2・A3サイズでもPDF出力できるようだ。

品質管理部がレビューする場合、プロジェクタで見るよりも、紙に印刷して鉛筆をナメナメしながらチェックする方が作業しやすい。
また、1プロジェクトのチケットは数百枚、数千枚にのぼるだろうから、できるだけ大きな紙に印刷できる方が作業しやすいだろう。

A0~A2で印刷するプリンタを持っているSIはあるのか、興味もある笑。

【1-4】Lychee Association Chartを効果的に使う注意点としては、チケットの精度を高めておく必要があるだろう。

プロジェクト計画時に、チケットにWBSを全て登録しておけば、Lychee Association Chartで点検する意味も出てくる。

日々のタスクの変更をチケットに反映するような運用が徹底できれば、Lychee Association Chart上で、要件から派生されたタスク漏れ、成果物の作成漏れをチェックできる。

逆に、日々のチケット管理が運用できていなければ、最新の作業状況や成果物がチケットに反映されていないので、Lychee Association Chartによるレビューが有効に効かない。

チケット駆動開発が馴染んでいるチームならば、有効に使えるだろう。

【2】Actual Date | Lychee Enterprise

【2-1】Redmineのチケット管理の運用で、マネージャからよく聞かれる質問の一つは、チケットで予実管理はできるのか、という問題がある。

マネージャは、計画時に作業予定日と予定工数を作り、担当者の作業実績日と実績工数と進捗率をマスタスケジュールに反映して、計画と実績の差分を分析する。
WF型開発では、計画と実績の差異ができるだけ発生しないようにコントロールするのが基本だからだ。

しかし、Redmineのチケットでは、開始日・終了日は、作業予定日に相当する。
実績としての作業開始日・作業終了日を保持する標準機能はない。
したがって、カスタムフィールドを使って、作業開始日・作業終了日を作成して運用する方法が多い。

でも、カスタムフィールドを使った方法では、ガントチャート画面に作業実績日が表示されない。
結局、チケットを一括出力して、Excelで集計しなければ、予実管理できない。

【2-2】Lychee Actual Dateでは、実績としての実開始日・実終了日のI/Fを用意してくれる。
また、Lychee Actual Dateで提供された実開始日・実終了日は、Redmine Lychee Gantt Chartで、実績の期間を実践で表示してくれる。

すなわち、MSProjectのガントチャートと同じく、タスクの予定と実績をRedmineのガントチャート上で表示してくれる。
Redmine Lychee Gantt Chartを使っているユーザは、Lychee Actual Dateも一緒に導入した方が使い勝手が増すだろう。

また、LycheeEVMのリリースノートを見ると、Lychee Actual Dateを導入しておくと、EVの計算に作業実績日も考慮してくれるようだ。
だから、EVMをもっと厳格に運用したい場合、Lychee Actual Dateもセットで導入すると効果的だろう。

【3】Lychee製品の使い道

Lychee Enterpriseを見ると、4つの製品が提供されている。
それぞれの利用場面としては、開発者よりもマネージャがプロジェクト管理の観点でチケット管理を運用したい時に効果的だろうと思う。

【3-1】Lychee Gantt Chart
マネージャがスケジュール管理に使う。
例えば、プロジェクト計画時に、全体スケジュールを鳥瞰する時に使う。

普通は、日々のチケット管理が運用されていれば、日々の進捗管理はLychee Gantt Chart画面上の操作だけでいい。

【3-2】Lychee EVM
マネージャがコスト管理に使う。
日々の工数入力がチケット管理の運用として徹底されていれば、EVMを履歴表示・リアルタイム表示してくれるので非常に便利。

現在の開発ペースなら、予算よりもコスト超過になるかどうか、即座に判定できる。
また、ベースライン比較を使えば、リスケ・仕様変更・メンバー増員のタイミングで生産性にどれだけ変化が生じたのか、をチェックできる。

なお、Redmineの工数入力をサポートするプラグインとして、WorkTimeプラグインは必須。

Redmine pluginで工数管理:WorkTime

【3-3】Lychee Association Chart
品質管理部門が、プロジェクト計画のレビューや、工程通過の判定、リリース判定基準に使う。
要件漏れ、作業漏れ、成果物の作成漏れがないか点検に使う。

プロジェクトの全ての作業がチケット管理で運用できていれば、作業や成果物の品質確保に大きく役立つだろうと思う。

【3-4】Lychee Actual Date
マネージャが予実管理する時に必須のプラグイン。
Lychee Gantt Chartを使っているなら、併用すれば、Lychee Gantt ChartがMSProjectのガントチャート機能の代替になりうる。

【4】このように見ると、Lychee製品はRedmineで不足していた機能、使い勝手が足りない機能をうまく補完しているように思える。

元々、Redmineはプロジェクト管理ツールとしてかなり優秀だし、作業者ベースではとても使いやすい。
だからこそ、マネージャが使っても便利だよ、とアピールできれば、Redmineをもっと普及するきっかけにもなりうるだろう。

【4-1】但し、Lychee製品であえて欲しい機能があるとすれば、PERT図や要員表(リソースヒストグラム)を実現する機能だろう。

MSProjectでは、ガントチャートの情報をPERT図やリソースヒストグラム、EVMで別のビューとして表示する機能がある。

スケジュール管理に熟練してくると、PERT図でタスクの依存関係を書いて、納期を短縮するための方策を考えることがある。
タスクを入れ替えたり、タスクを並行実行したり、いろんな対策を考える時、ゴチャゴチャしたガントチャートよりも、タスクの依存関係を一目で把握できるPERT図の方が便利だ。

PERT図を実現するには、選択したチケットの後続チケットをすべて表示する機能が必要だ。
実は、Lychee Association Chartでは一つのチケットの配下にある親子チケットや関連チケット、リビジョンを表示する機能があるので、PERT図を実現する機能はほぼそろっている。
おそらく開発は容易だろうと推測する。

また、要員表はマネージャのコスト管理で重要な成果物の一つだ。
受注前に、要員表を作り、月ごとに誰がどの工程を作業するか、工数を当てはめて、見積りに使う。
つまり、見積り用の要員表は、計画時の作業になる。

そして、プロジェクト開始後、要員表へ日々の実績工数を記録して、月末に工数集計した結果が、協力会社の開発者の作業報告書になる。
つまり、SIerの下請け会社にとって、要員表から出力される作業報告書は、元請けに費用請求する重要な資料なのだ。
だから、MSProjcetのような要員表の機能がRedmineで実現できれば、MSProjectにある機能はほとんど実現されると考えている。

【4-2】このように考えてみると、MSProjectで実現されているプロジェクト管理のベストプラクティスをRedmineにも実現すれば、Redmineが本来持っているアジャイル開発の利点だけでなく、PMBOKなどで既に知られているプロジェクト管理技法も扱えるようになる。

ツールの一機能としてプロジェクト管理技法を使えるようになれば、ツールを使いこなすだけで、プロジェクトリーダーのマネジメントスキルも上がっていくのではないか、と考えている。
特に、プログラマ上がりで経験の浅いプロジェクトリーダーは、マネジメントスキルを直感や経験でカバーするのではなく、ツールのカスタマイズや運用でカバーする方が容易だろうと思う。

マネジメントスキルは、技術力でカバーしていくのだ。
それが、ITによる技術革新の恩恵だろうと思う。

| | コメント (0)

Redmine Lychee Enterpriseシリーズの解剖part2~RedmineでEVMを実現 Lychee EVM

Redmineのアドオン製品 Lychee EVMのデモ画面を触ってみた。
感想をラフなメモ書き。

【参考】
Lychee Enterprise~マネージャのためのRedmine

【1】EVM Plugin | Lychee Enterpriseは、Redmine上でEVMを表示してくれるアドオン製品。
Redmineによるタスクマネジメント実践技法」の第8.1節「PMBOKのEVM」に、Redmine上でEVMを実現できるはずだ、と書いたけれど、まさにその機能を実現してくれた製品になる。
だから、僕にとって一番気になる製品。

【1-1】EVMはなぜ必要なのか?

SI案件でも、工事進行基準が適用されたために、プロジェクトの進捗状況に応じて、プロジェクトの売上を確定する必要が出てきたからだ。
かつてのように、システムの検収後に売上を一括計上するやり方は、大規模案件になるほど不可能。
そんな丼勘定をしていると、会計監査でツッコミが入ってくる。

これから始める進ちょく管理(1):工事進行基準が進ちょく管理に変化をもたらす (1/2) - ITmedia エンタープライズ

EVM を活用したIT サービス調達の進化モデル~情報処理振興事業協会

しかし、ITプロジェクトの進捗は、土建業界のようなビルの構築のように明確に判断できない弱点がある。
WF型開発ならまさにそうだ。

要件定義書、設計書が納品されたとしても、プログラムはないから、肝心のシステムは稼働されていない。
ユーザにシステムを納品できていないのに、その状況では果たして、売上が確定できると言えるのか?

設計書が完成したとしても、レビューによる手戻り作業があれば、100%完成とは言えないのでは?
完了基準の定義はいったい何なのか?

EVMでは、当初の計画工数に対して、今どれだけのコストが発生し、今の出来高(アウトプット)がどこまであるのか、を把握できる。
EVMはPMBOKできちんと理論化されているので、運用できれば、かなり強力なツールだ。

Redmine Lychee EVMは、Redmine上でEVMを実現してくれる画期的な製品。
なお、MSProjectには、EVMの機能がすでに実現されている。

その意味でも、Lychee製品シリーズは、MSProjectの機能をRedmineで実現しようとしている意図が込められているように思える。

これから始める進ちょく管理(4):Microsoft ProjectでEVMに挑戦! (1/2) - ITmedia エンタープライズ

【1-2】しかし、EVMの運用は至難の業だ。
運用上の課題はいくつかある。

一つ目は、タスクの完了基準をどのように決めるのか、という点。
進捗率がステータスと連動していなければ、計算された出来高の正当性が失われてしまう。
その完了基準をメンバーに徹底させるにもそれなりのコストがかかる。

2つ目は、工数入力と工数集計にかなりの手間がかかること。

プロジェクト計画時にWBSを作る最大の理由は、見積りしたいためだ。
そのWBSの見積り工数が予定工数になり、その総額が予算になる。
そして、タスクの実績工数と進捗率がWBSに反映されて、EVMが確定する。

しかし、日々の工数入力を徹底できなければ、EVMは得られない。
しかも、日々の工数をExcelで集計し直すのはかなりの手間だ。

ちょっとした案件でさえ、WBSは数百~数千にものぼるからだ。
1億円以上の案件なら、WBSは数万レベルになるだろう。
そうなると、もはやExcelでEVMを運用するのは事実上不可能に近い。

3つ目は、リスケが発生した場合、EVMをどのように再計算し直すのか?
仕様変更、スコープ増大、要員増加などが途中で発生したら、WBSもその予定工数も全て更新し直さなければならない。
炎上プロジェクトほど、要員が大量に増えるので、スケジュール変更もままならず、EVMの運用まで手が回らない。

【1-3】EVMをRedmineで実現する基本的アイデアは、WBSをチケットで表現すれば、PV・AC・EVがチケットの属性で表現できること。
チケット管理の運用さえ徹底できれば、工数データはチケットとして蓄積されているから、EVMの仕掛けは事実上整っている。

過去にもたくさんのアイデアを書いてきた。

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

EVMはアジャイル開発に適用できるか: プログラマの思索

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

RedmineのEVMプラグイン: プログラマの思索

RedmineにおけるEVMの考え方: プログラマの思索

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

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

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

運用上の課題は、Redmineでは下記で解消される。

1・タスクの完了基準は、チケットの進捗率を作業ステータスと連動させる。
2・工数入力と工数集計は、チケットの工数管理のI/Fを使う。
3・EVMの再計算は、チケット集計機能をバッチ処理で実行し、EVMの履歴を残す。


【2】EVM Plugin | Lychee Enterpriseを見ると、主に3つの機能がある。

【2-1】EVMの表示

Lychee Enterprise - Redmineを見るとよい。

【2-1-1】EVMにフォーカスを当てると、PV・AC・EVがポップアップ表示される。
履歴や測定日で、今どれだけのコストがかかっているのか、どれだけのアウトプットが出ているのか、がすぐに分かるのは便利。

チケットの情報を見ると、EV=PV * 進捗率 で計算しているようだ。
つまり、アジャイル開発ではなくWF型開発を想定しているようで、進捗率をステータスと連動する運用を想定しているのだろう。
アジャイル開発ならば、Doneの基準が厳格なので、進捗率は0%か100%の2つしかないからだ。

また、PVは、チケットの開始日・終了日で補正計算されている。
そのため、当日時点の正確な予定工数を把握できるので、当初の計画通りに進んでいるかどうかを判別できる。
EVMの計算で面倒な点の一つは、EVの計算だけでなく、日付を考慮したPVの計算もあるからだ。

PV・AC・EVの配置によって、プロジェクトの進捗度合いやコスト増加傾向が一目で分かる。

ITレポート(動向/解説) - EVMによる進ちょく管理の基本と勘どころ(2):ITpro

但し、PV・AC・EVの単位は、時間単位であるのに注意。
人日や人月で把握するには、再計算する必要がある。
SIerによって、1人日=8時間だったり、7時間だったりバラつきがあるので、人月の計算は大きく違ってくる。

【2-1-2】過去の履歴だけでなく、測定日以後の将来に向けて、実績工数が点線で表示されている。
チケットの情報を見ると、点線の実績工数はEACの傾向を表している。

下側のメニューにある「EAC」にフォーカスを当てると、
EAC=AC+(BACーEV)/CPI
という計算式が表示される。
この計算式は、EAC=BAC/CPIと同じ。

つまり、現在の開発ペースをCPIとみなして、現在の開発ペースなら、これくらいのコストが予測されることを意味している。

マネージャなら、EACは常に把握しておきたい数値だ。
なぜなら、現在の開発ペースなら、プロジェクトが赤字で終わるのか、黒字で終わるのか、を早めに予測したいからだ。
普通は、開発ペースが計画時点よりも悪い場合が多いので、赤字にならないための対策を早めに作り、上司の報告する必要が出てくる。

【2-1-3】ユーザインターフェイスを見ると、タイプ=EVMを選択後、バージョン・プルダウンで、全てのバージョンや各バージョン、子プロジェクトのバージョンを選択することができる。
また、各バージョンを複数選択することもできるようだ。

マネージャの使い方としては、プロジェクト全体を見たい時は、全バージョンを選択して、予算と総コスト見積り(EAC)を把握する。
WF型開発なら、バージョンを工程で区切ることが多いから、設計バージョンや開発バージョンごとに、計画工数と実績工数を細かく比較分析する運用になる。

また、子プロジェクトは各チームのタスク管理に対応していれば、例えば、設計チームや開発チーム、画面チームやバッチチームごとの開発ペースを分析できる。

基準日や単位=月毎・週毎・日毎を選択できるので、見たいメッシュを変えれば良いので便利。

但し、注意点としては、サマリされたEVMの結果が表示されているだけで、EVMの値からドリルダウンできないこと。
つまり、過去の履歴のPV・AC・EVの値では、チケットがどんな状況だったのか、を調べることはできない。
あくまでも、現時点のチケットの状況しかドリルダウンできない点は注意。

このような仕様になった理由は、過去の履歴のEVMの指標はバッチ処理でサマリされているため、過去のチケットの状況を表示する機能が現状のRedmineでは実現できないことがあるのだろう。

【2-1-4】また、細かいUIがとても使いやすい。

下側にあるメニュー項目(PV~EAC)をクリックすると、EVMからクリックした項目の線が消える
例えば、過去の履歴だけ見たい場合は、EACをクリックして非表示にすればいい。

エクスポート機能を見ると、CSVだけでなく、PNG・JPG・PDF・SVGで出力できる。
特にマネージャ会議では、印刷物としてEVMを配布する時が多いだろうから、PDF出力されるのは便利。

また、特定の期間をドラッグして拡大表示もできる。
つまり、EVM上で、細かな値を見たい時に便利。

【2-2】SPI・CPIの表示

スケジュールやコストのペースを表示してくれる。
SPI、CPIの理解は下記を参考。

[ThinkIT] 第3回:データの推移からつかめる傾向とベースラインの作成・出来高計上基準 (3/4)

LycheeEVMでは、背景色に赤色・黄色・青色がある。
背景色の意味は、赤色が危険ゾーン、青色が正常ゾーン、黄色が要注意ゾーンに相当する。

つまり、SPIやCPIが赤色ゾーンに入っていたら、すぐに対策を打つ必要がある。
既に進捗遅れ、コスト増が発生しているのだから。

黄色ゾーンになるなら、SPIやCPIが増えないように監視していくことになる。

EVMの理論では、CPIが一番重要だと思う。
CPIはチームの開発ペース、または、生産性を表しており、アジャイル開発のVelocityの傾向に近い概念だからだ。
CPIが大きいほど、作業実績以上にアウトプットが出ていて、効率が良いことを意味する。
だから、CPIの過去の履歴を見れば、チームの生産性がよく分かる。

普通のプロジェクトでは、前半はチームとして有機的に機能していないためにCPIが赤色ゾーンにある。
その後、メンバーの特徴を把握できて技術や仕様に慣れてくると、チームが機能し始めてアウトプットが安定して出せるようになり、CPIが上昇していく傾向にあると思う。

【2-3】ベースライン比較

タイプ=ベースライン比較 を選択し、基準日を2つ設定する。
ベースライン比較とは、バージョン・プルダウンでEVM計測対象のチケットを絞り込んでおき、2つの基準日でEVMを比較する機能だ。

使い道としては2つあると思う。

1つ目は、工程の最初の日と最後の日を設定して、EVMの傾向を分析すること。
WF型開発なら、バージョン=工程で区切っているので、バージョンの最初の日と最後の日を設定して、EVMの傾向を分析できるだろう。
あるいは、要件定義、設計、開発、単体テスト、結合テストなどの工程ごとの進捗・コスト、生産性を比較する時に使える。

また、上流工程は元請け、下流工程は下請け、あるいは、設計チームと開発チームのように工程ごとにチームが違う場合、ベースライン比較で進捗・コスト、生産性を比較分析できる。
生産性の低いチームには、メンバーを増員したり、配置換えしたりする対策もあるだろう。

2つ目は、仕様変更でスコープが変わってリスケした時、開発・テスト工程からメンバーが増員された時などで、変化の前後で比較する場合に使う。

顧客要望で仕様が追加されて、設計を大幅に書き直して、開発工数が増えた場合もあるだろう。
その時、変更前と変更後でベースライン比較して、現在のチームの生産性ならば、どれくらいのコスト増になるのかを予測することができるだろう。

あるいは、当初の計画通り、開発・テスト工程からメンバーが増員された場合、普通は生産性が落ちる。
人月の神話で知られている通り、人数が増えるほど無駄なコミュニケーションパスが発生し、新規メンバーに説明したり教育するコストが発生するので、既存メンバーの生産性も落ちる。
もちろん新規メンバーも、計画通りの生産性で作業してくれるとは限らない。

だから、特にメンバー増員の場合は、チームの生産性を日々監視していく必要があるだろう。

【3】OSSのEVMプラグインとの違い

LycheeEVM以外にも、OSSで既にEVMプラグインが公開されている。
その内容は以前書いた。

RedmineのEVMプラグイン: プログラマの思索

imaginary-cloud/redmine_evm ・ GitHub

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

EVMプラグインでは、チケットの予定・実績工数と進捗率を元に、EVMをリアルタイムに表示している。
だから、「Redmineによるタスクマネジメント実践技法」に書いたEVMの実現方法をそのまま提供していると思っていい。
実際にソースを見れば、どのように計算しているのか、よく分かるだろう。

但し、EVMプラグインの弱点は、ACやEVの履歴を保持していないので、EVMの履歴を表示してくれない。
EVMをリアルタイムに表示する機能しか持っていないので、プロジェクト完了時に、PV=EVになってしまうのだ。
だから、EVMを本当に運用する場合には、残念ながら適用できないだろう。

一方、LycheeEVMでは、AC・EVの履歴をバッチ処理で保持しているようだ。
だから、EVMの履歴がきちんと残るので、本格的な運用に適用できる。

【4】LycheeEVMのリリースノートを見ると、こんな表記がある。

EVM Plugin リリースノート| Lychee Enterprise

(引用開始)
・当日のEVMを即時計算・描画
・スナップショットがない日付のEVMを描画可能に(描画時点での計算値)
・EV計算に使用する進捗率の履歴を広義単調増加するように補正計算
・EVの増加を日割り加算(設定休業日考慮)
・日割りの範囲に、Lychee Actual Dateの実開始日・実終了日を考慮
(引用終了)

ここから類推すると、LycheeEVMには下記の機能が実現されていると考えられる。

【4-1】バッチ処理で前日のEVMをサマリする前に、当日中のチケット情報を元に、当日のEVMも即時計算・描画している。
 つまり、リアルタイムにEVMを表示する機能がある。
 例えば、EVMのリアルタイム表示の利用場面としては、結合テストや総合テスト工程で、障害の発生と修正が頻繁に発生している時、日々のコストやアウトプットを把握したい時に使いたいだろう。
 あるいは、既にコスト超過の案件で、これ以上の工数増加が許されない場合、リアルタイムに工数をチェックして、残業を禁止する運用もあるかもしれない。

【4-2】バッチ処理でEVMのサマリをスナップショットで保持する時、チケットが更新されない日はEVMがサマリされないので、EVMが確定しない。
 だが、LycheeEVMでは、チケットの最新更新日時点のEVMで補正表示してる。

【4-3】EV=PV*進捗率で計算されるが、進捗率が減少した場合、EVも減少する症状が発生する。
 EVMの理論では、PV・AC・EVが減少することはありえない。
 PVは計画時点で確定してベースラインになるし、ACやEVは日々の作業結果の積み重ねだからだ。
 
 しかし、チケット管理の運用では、リスケしたり、適宜補正したり、差し戻される時に、PV・AC・EVが減少する場合が発生すると考えられる。
 例えば、リスケして予定工数を減らしたり、月末に実績工数を減らして修正したり、進捗率を差し戻しステータスで減らしたり、とか。
 そんな症状が発生しないように、LycheeEVMでは、「EV計算に使用する進捗率の履歴を広義単調増加するように補正計算」していると思われる。

【4-4】SIerでも、日祝日以外にも非営業日でお休みの時もある。
 例えば、創立記念日とかメーデーとか。
 LycheeEVMでは、EVの計算に「設定休業日も考慮」しているらしい。
 
【4-4】別製品Lychee Actual Dateを入れておくと、EVの計算に実開始日・実終了日も考慮しているようだ。
 つまり、チケットの予定日と実績日を厳密に管理している場合、実績日を元にEVを計算してくれているようだ。
 この機能は、OSSのEVMプラグインでは実現できていない。

以上を見ると、LycheeEVMは、OSSのEVMプラグインの単なる焼き直しではなく、SIerにおける実際のEVMの運用ノウハウを相当埋め込んでいると思われる。

| | コメント (0)

Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart

Redmineのアドオン製品 Lychee Gantt Chartのデモ画面を触ってみた。
感想をラフなメモ書き。

【参考】
Lychee Enterprise~マネージャのためのRedmine

shinagawa.redmine 第6回勉強会に参加してきた - njuntechのブログ

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

【1】Lychee Gantt Chart Plugin | Lychee Enterprise

Lychee Gantt Chartは、Redmineのガントチャート画面を機能強化したプラグイン。
Redmine Lychee Gantt Chartはどんな状況で使えるか?

マネージャの立場なら、RedmineのガントチャートをMS Projectのように操作したい。

だが、MSProjcetはライセンス料がすごく高い。
社内の全員にMSProjectを使えるようにすると、途方も無いライセンス料がかかってしまう。

だから、普通は、一部のマネージャがMSProjectを使い、その内容をExcelで公開したりする。
でも、スケジュールはチームのメンバー全員が常に共有すべき情報だから、MSProjectを使えないのは辛い。
また、最新化されていないスケジュールで情報共有していると、マネージャとメンバーの間で、プロジェクトの現状認識に差異が出てくる。
マネージャはすごく遅れていると認識しているのに、リスケされていないスケジュールを見ているメンバーは、自分のタスクはずっと後だから大丈夫、と思ってしまうのだ。

だから、RedmineへWBSをチケットで一括インポート後、計画時点でスケジュールを微修正する時に使いたい。
また、プロジェクト進行中は、状況に合わせて、リスケする時に、ガントチャート上で各タスクを微修正したい。

しかし、通常のRedmineのガントチャート画面はViewにすぎないので、期間を変更したい時は、逐一チケットを別画面で開いて修正し、さらにガントチャート画面をリフレッシュしなくてはいけない。
元々のRedmineの思想では、ガントチャート画面で変更操作することを想定していないのだ。

したがって、Redmine Lychee Gantt Chartは、Redmineの弱い部分である「マネージャが利用しにくい」場面を想定して、使いやすくしているようだ。

MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmine Lychee Gantt Chartのデモ画面を触ってみると、主に4つの機能がある。

【1-1】ガントバーをドラッグ&ドロップで移動したり、伸縮できる。

MSProjectでは、タスクをドラッグ&ドロップして移動したり、短縮できるので、同様の機能を実現している。

Lychee Enterprise - Redmine

でも、マネージャがRedmineでよく使う場面は、やはりガントチャート画面でタスクの状況を確認したり、進捗の遅れがあればタスクを入れ替えるなどをよくやるだろう。
一つのチケットを見たいのではなく、プロジェクト全体のタスクを鳥瞰的に見て、判断したいのだ。

【1-2】先行・後続の関連をクリック操作で簡単に設定できる。

MSProjectでは、タスク間のリンクを貼ることで、FS関係を簡単に設定できる。
同様の機能をRedmineガントチャート上で実現している。

Project 内部でタスクがスケジュールされる方法 - project-help

但し、クリック操作方法としては、ガントバー上でワンクリックした後、+ボタンをドラッグして、後続のガントバーへ線を引く操作になる。
+ボタンの表示はワンクリックするのがコツ。

タスクの先行・後続の関係を表現するFS関係は、スケジュール作成ではとても重要だ。
タスクの依存関係は、先行・後続で表現される時が多い。

PMBOKでは、スケジュール変更の技法として、クラッシングとファスト・トラッキングがよく使われる。

クラッシングとファスト・トラッキングのスケジュール短縮技法 / PMstyleコラム

クラッシングは、リソースを追加投入して、タスクの期間を縮めること。
PMBOKの技法では、クリティカルパス上のタスクに対し、追加投資して、タスクを縮める。

チケット駆動開発なら、担当者を入れ替えたり、タスクの先行・後続関係を入れ替えてリスケするだろう。

ファスト・トラッキングは、直列のタスクを並行で作業させること。
チケット駆動開発なら、直列のチケットを並列にチケットの期間を並び替えるだろう。
あるいは、1枚のチケットを2枚以上に分割し、複数チケットを平行作業で期間短縮を図るだろう。

以上のような操作が、Redmineのガントチャート画面上だけで操作できるので、マネージャはスケジュールをにらめっこしながらリスケできるようになる。

【1-3】ガントチャート画面上で、チケットの属性変更ができる。

ガントバーをワンクリックすると、ポップアップメニューが表示され、チケットを編集できる。
チケットのリンクをワンクリックすると同様。

ガントチャート画面の改修要望として、担当者を表示したい、あるいは、担当者を簡単に入れ替えたい、という要望が多い。
このタスクは誰が担当していて、どんな進捗状況にあるのか、をマネージャは知りたいのだ。
遅れているタスクは、その原因を突き止めて、タスクを入れ替えたり、担当者を入れ替えたりする。

ソフトウェア開発では、品質の悪化やコスト増加の症状は、真っ先に進捗遅延で現れる。
進捗遅延の症状が出始める前に、先手を打って対処したいのだ。

【1-4】ガントチャート画面上で、親子チケットの階層を変更できる。

チケット名を右クリックすると、ポップアップメニューの最後に「親子関係」というメニューが表示され、「一つ上へ移動」「最上位へ移動」を選択できる。
ガントチャート画面上で、チケットの階層構造を入れ替えたい時に便利。

できれば、「一つ下へ移動」のメニューもあると良いかな?

【2】Redmine Lychee Gantt Chartは今後、どのような方向へ発展すべきか?
Redmine Lychee Gantt Chartはどんな利用状況で威力を発揮するのか?

Redmine Lychee Gantt Chartは、MSProjectの代替製品になっていくのが自然な傾向だろう。
MSProjectのような使いやすいユーザインターフェイスをかなり実現している。

【2-1】MSProjectは毀誉褒貶が多いけれど、プロジェクト計画の作業ではとても有用た、とよく言われる。
プロジェクト立上げフェーズで、成果物と作業をWBSでまず洗い出す作業では、とても使いやすい。

Excelで納品物とそれを作るための作業を一覧化し、その関連性をMSProjectでプロットするわけだ。
つまり、納品物を作る作業を先行・後続の関係で表現し、直列作業を並行にしたり、作業を入れ替えたりしながら、納期に間に合わせるようにする。

MSProjectはExcelからそのままコピーできるし、ガントチャートを一覧表示できる。
また、ガントチャートとは別に、PERT図でタスクの依存関係を見ることもできる。
クリティカルパスも表示してくれる。

つまり、作成されたガントチャートの整合性を、PERT図やクリティカルパスなどでチェックする機能もRedmine上でできるとなお良い。

【2-2】MSProjectよりもRedmineの方が優れている点は、タスクの実績管理がやりやすいことだ。
MSProjectは、計画フェーズで使いやすくても、その後の実績管理は使いにくい、とよく言われる。

仕様変更、スコープ増加、担当者変更、リスケなど、当初のスケジュールはどんどん変更されていく。
その内容を逐一反映していくのはかなり面倒だ。
スケジュールの整合性はどんどん取れなくなっていく。

Redmineによるチケット駆動開発では、スケジュールの整合性を取るよりも、アジャイル開発のように、イテレーション単位にチケットをグループ化して消化していく戦略を取る。
直近の目標に合わせてチームが一体化して作業する方が、メンバーの認識相違も生じにくい。
何よりも、開発のリズムが生まれて、チームの作業が楽しくなる。

確実に成果物を作成しながら、品質も機能も拡張していく戦略を取るので、そもそもWF型開発によるガントチャート管理とは相容れない。
でも、Redmineは多種多様なビューを持っているので、ガントチャートなど他のビューで進捗管理してもいい。

チケットは変更に強い。
リスケの内容はチケットに反映すればいい。
その特徴をRedmineは大いに活かしている。
Lychee Gantt Chartは、Redmineに足りない機能をうまくサポートしているように思える。

| | コメント (0)

WebディレクターによるRedmine運用事例

WebディレクターによるRedmine運用事例が2つあったのでメモ。

【参考1】
プロジェクト管理(タスク管理)について考える1 (はじめに) | OTSUKARE-TION (おつかレーション)

プロジェクト管理(タスク管理)について考える2 (現状調査、課題) | OTSUKARE-TION (おつかレーション)

プロジェクト管理(タスク管理)について考える3 (解決策の検討) | OTSUKARE-TION (おつかレーション)

プロジェクト管理(タスク管理)について考える4 (各種プロジェクト管理ツールを使ってみて) | OTSUKARE-TION (おつかレーション)

プロジェクト管理(タスク管理)について考える5 (で、結局何を使うことにしたの?) | OTSUKARE-TION (おつかレーション)

プロジェクト管理(タスク管理)について考える6 (Redmineのカスタマイズ) | OTSUKARE-TION (おつかレーション)

【1】Webディレクターのお仕事は、営業とマネジメントの両方を担当している感じ。
毎日がかなり大変だろうと思う。

(引用開始)
今僕は某サイトのWebディレクターとして、運用業務に従事しており、

進捗管理
リソース管理
制作ディレクション

を主に担当しています。
(引用終了)

(引用開始)
今どうやってプロジェクト管理してる?
メールとエクセルです、はい・・・。

もうこの時点でみなさん察してください・・・グッチャグチャです・・・。現場は混乱を極めています。
(チームのみんな・・・ほんと毎日ごめん)

日々、

メーリングリスト宛の依頼メール(大量)
僕個人宛の依頼メール(大量)
口頭での依頼(大量)
大小個別プロジェクト単位の打ち合わせでの依頼
週に1回、各部署の担当者を集めて開催する「案件エントリー大会」

の5方向から飛んでくる依頼を、都度こまめにエクセルの「スケジュール管理シート」なるものに一つ一つ手作業で愛情をこめて入力していきます。
(引用終了)

【2】そこから、こんな課題を抱えている。
どこの業界の仕事も同じなのだろう。

(引用開始)
・案件のエントリーチャネルが一本化されておらず、ヌケ・モレ・間違いが発生している
・案件名と案件カテゴリーだけでは、どれぐらい規模で、どれだけ大変な案件なのかがさっぱり分からない
・エクセルでの差し込み、順番変更がめんどくさい
・更新のリアルタイム性がない
・「え!?その案件、僕が制作担当にアサインされてたんですか!?明日リリースですよね?」
・制作リソースのつまり具合(空き具合)が把握がしづらい
・タイムマネジメントができていない
・部署をまたいでの共有、連携がやりづらい
(引用終了)

【3】そこで、色々検討してRedmineを導入した、とのこと。
Redmineを選択した理由は『カスタマイズ性』とのこと。
ここはちょっと意外だった。

(引用開始)
「Redmineってバグトラッキングツールでしょ?そんなの日々の案件管理に使えるわけないじゃん」
って食わず嫌いしてたんですが、使ってみたら…あれ?…便利じゃね?…って(笑)

バグ(チケット)=案件としてとらえた瞬間、一気に雲が晴れたというか、納得できたんです。

Redmineにした決め手は『カスタマイズ性』です。
(引用終了)

Redmineを選択後、以下の様な運用を行っているらしい。

(引用開始)
その点、Redmineは

・社内のサーバーに導入して、いじり放題
・その気になればRubyで元からいじれる
・プラグインもいろいろある
・APIで、みんな大好きExcel(笑)とも簡単に連携できる
・カスタムクエリーが超便利
 ・今日リリースされる案件一覧 とか
 ・今週リリースされる案件一覧
 ・明日が原稿入稿締切の案件一覧
 ・制作Aさんにお願いしている案件一覧
・定例会議用に成形した一覧 とかもクリック一発
・カレンダーで「その日に何の案件がリリースされるのか?」がわかる
・各案件オーナー部署ごとにアカウントを発行して、各部署ごとにRedmineに直接案件(チケット)を入力してもらえる
・タイムマネジメントもできる
・どこの会議室からでも、どのお偉いさんのPCからでもブラウザで開けば現状が見れる

などなど、「プロジェクト管理(タスク管理)について考える3 (解決策の検討)」で抱えていた課題をことごとく解決してくれました。

あえて難があるとすれば、
Redmine2.x系に対応したプラグインが異様に少ないことと、僕がRubyを覚えなきゃいけないってところですかね…。
(引用終了)

Rubyを知らないWebディレクターでも、Redmineをいじくり倒すことで、自分のチームに合ったタスク管理を運用できる。
ソフトウェア開発案件のタスク管理だけでなく、Webサイト制作のタスク管理にももちろん適用できる。
上記の方は、解決すべき課題を把握しているから、カスタマイズや運用もスムーズだったのだろうと推測する。

【参考2】

【4】女性のWeb制作のプロジェクトマネージャの方によるRedmineのチケット管理の事例だ。
オムライスを作るタスクを元に、チケットの切り方を説明している。

「Ticket First」「No Tikect, No Commit」のプラクティスも紹介している。
(たぶん、「No Tikect, No Commit」ではなく「No Tikect, No Work」を意味していると思う)

「ツールを使うディレクターやマネージャーがすべきこと」として、「プロジェクトが発足するたび、自分がいつ死んでもRedmineさえみれば案件が共倒れしないように情報を充実させる。」主張は素晴らしい。

リーダーがいなくてもプロジェクトが回るようなチーム運営が理想。
Scrumの自己組織化は本来そのような意味なのだろうと、僕もチケット駆動開発を経験して理解した。
その基盤の一つがツールであり、ツールが支える運用プロセスなのだろう。
ツールがプロセスを透明化し、緩やかにプロセスを支える所が、チケット駆動開発の利点。

【5】Webサイトのタスク管理は、ソフトウェア開発のタスク管理に近い。
HTMLやCSSなどのソースをバージョン管理したり、顧客や他チームの依頼を受け付けた後に作業が発生する点はすごく似ている。
だからこそ、チケット駆動開発のアイデアを活かしやすいのだろう。

| | コメント (0)

2014/05/21

「統計学が最強の学問である」の感想

統計学が最強の学問である」本を読んだ。
とても面白い!

今まで統計学の本を10冊ほど乱読したものの、統計学の思想は何なのか、さっぱり分からなかった。
でも、「統計学が最強の学問である」本を読んで、今までずっと疑問に思ってきたこと「統計学の背後にある思想は何か?」「統計学が抱える根本問題は何か?」が詳しく書かれていた。

そして、「統計学を疫学・社会学・心理学・データマイニング・経済学などに適用した場合、どんな違いがあるのか?」という問いにも的確に答えてくれている。
しかも、統計学の異端児であるベイズ統計が最近なぜ注目されているのか、という問いも解説してくれている。

以下、理解したことをメモ書き。
間違っていたら後で直す。

【参考】
なぜ、統計学が最強の学問なのか? 『統計学が最強の学問である』ビジネス書大賞2014「大賞」受賞記念記事|統計学が最強の学問である|ダイヤモンド・オンライン

「統計学が最強の学問である」で学ぶ 統計学で見える新しい世界 - 酒と泪とRubyとRailsと

書評:「統計学が最強の学問である」、データをビジネスに使う人のための知識が凝縮 - Publickey

漢(オトコ)のコンピュータ道: 書評:「統計学が最強の学問である」→ はい。

『統計学が最強の学問である』感想 - 社会学者の研究メモ

【1】統計学の根本思想、統計学の根本問題

統計学の根本思想は「データから帰納法で因果関係を導き出す」。
統計学の根本問題は「サンプルデータは偏りがないということをどうやって保証しているのか」。
この2つさえ知っておけば、真値、p値、カイ二乗検定、t検定などの概念も多分分かるはず。

その思想を支え、その問題を解決するために、たくさんの用語や概念が出てくるわけだ。

【1-1】本来は、全てのサンプルを抽出して分析すべきだが、コストや時間などの制約で、一部のデータしか採取できないとする。
その時、得られたサンプルデータ(標本)は、全てのサンプル(母数)の一部から抜き出したものと見なせる、と判断できるようにしたい、という意図がある。

【1-2】「統計学が最強の学問である」本で得た知識の一つは、サンプルデータのp値に着目すること。
p値が5%(つまり0.05)未満なら、そのサンプルデータは偏りがなく、そこから得られた因果関係は確からしい、ということ。

例えば、下記の記事では、「誕生月によってJリーガーになりにくくなるのか?」という命題を統計データから分析している。

実践! Rで学ぶ統計解析の基礎(1):Rは統計解析のブッシュナイフだ (2/4) - @IT

R言語で計算した結果、p-value(p値)は2.031e-14(10のマイナス14乗)という値なので、「Jリーガーの月別出生数分布は日本人の月別出生数分布と同じである」確率がその値ぐらい小さい。
そこで、「誕生月によってJリーガーになりにくいということがありそうだ」という命題がかなり高い確率で言える、と指摘している。

【1-3】また、「統計学が最強の学問である」本では、データマイニングでよく出てくるバスケット分析は、カイ二乗検定の方がもっと精度が高い、という指摘も載せている。
その指摘は、グーグルのCEOの過去の論文に掲載されているらしい。

そういう内容を読むと、すごくワクワクドキドキする。
統計学という理論は既にあるのだから、その理論を使って、プログラムを書いて実行してしまえばいい。

【2】統計学を他分野へ応用した場合の注意点

統計学は帰納法で因果関係を導く手法として使えるので、特に人文・社会科学に適用すると、新しい知見が得られる。
人文・社会科学は、自然科学のような演繹法が有効でない場面が多いからだ。

(引用開始)
1) 実態把握を行う社会学調査法
=> 可能な限り偏りを減らして、求める誤差に収まる推定値を効率よく算出する

2) 原因究明のための疫学・生物統計学
=> 原因を見つけることに重視。母集団への当てはまりにはこだわらない

3) 抽象的なものを測定する心理統計学
=> いくつかの測定方法から相関性を出して、数値化したのが知能指数(IQ)

4) 機械的分類のためのデータマイニング
=> マーケティングを目的にクラスタ分析や相関を調べる。ニューラル・ネットワークやサポートベクターマシンなどのような機械学習は、予測に役立つデータマイニングのための手法

5) 自然言語処理のためのテキストマイニング
=> 大量のテキストデータから目的にマッチしたデータを抽出・集計する。形態素解析として辞書を使うMeCabや辞書を使わずに重複する単語を探しだすN-Gramなどがある

6) 演繹に感心を寄せる計量経済学
=>経済学分野で統計学を用いる。相互作用を含む説明変数の選択について慎重な検討を行う

番外) 確率に対する考え方の違うベイズ派
=> 事前確率と事後確率を使う。限られた情報と仮定を組み合わせることで、迅速に答えを出す。
(引用終了)

【2-1】一番興味深いのは、計量経済学。
統計学の基本は、エビデンスとなるデータから帰納法で因果関係を見出す手法。
逆に、自然科学は、ニュートン力学のように少ない仮定から演繹法で理論を導き出す。
自然科学の手法を人文・社会科学へ適用して成功した数少ない事例が、経済学。

計量経済学では、経済データから統計学で分析して得られた因果関係を、過去100年の経済学で得られた理論体系に当てはめて、より良いモデルを作ったり、影響度合いを推定したりする。
つまり、計量経済学は、帰納法と演繹法を組み合わせることで、経済理論を強化する。

国勢調査や経済指標が常に採取されて公開されるので、そのデータを扱って、数多くの理論が今も編み出されている。
「理論なき計測」と見下されるように言われるが、計量経済学の比重は最近高まってきているらしい。

【2-2】ベイズ統計学がなぜ役立つのかも面白い。
ベイズ統計学は、事前確率という仮定を置いて、事後確率を導き出す。
計量経済学のように、既に統計データがあり分析するだけでなく、事前確率という仮定を過去の経済学の理論から持ち出せば、演繹的に導き出せる。

疫学や社会学のように、分析した結果が得られるだけでなく、理論に当てはめて、推定まで行える方が経済学では重要らしい。
だから、経済学者はベイズ統計学を駆使しているわけだ。

【2-3】また、「統計学が最強の学問である」本には、社会心理学に適用した事例として、「学習塾に通った・通わない子供の成績の比較」などもあげられている。
p値が5%未満の数値なので、その結果は正しいだろうと見なせる。
すると、「学校の宿題をやるよりも、学習塾に通った方が子供の成績が良い」という傾向が見られるらしい。

あるいは、「統計学が最強の学問である」本によれば、知的専門家のモチベーションと金銭の関係についてもデータから分析した結果、「既に成功した知的専門家には、動機付けよりも、より良い報酬を与える方が効果的」という傾向が見られるらしい。

そういう因果関係が統計データとして得られるのが面白い。
心理学や社会学は、統計学を使えば、人間の本性について、かなりの部分を解明できるのではないだろうか。

データさえあれば、データを分析するプログラムさえ書ければ、新しい理論を見出すことができる。

| | コメント (0)

2014/05/18

エンタープライズアジャイルは「アジャイル開発が大人になった姿」らしい

日経コンピュータ2014年5月号の記事にエンタープライズアジャイルの記事があったのでメモ。
ラフなメモ書き。

【参考】
日経コンピュータ2014.05.15|HATのブログ

リックテレコム 書籍情報「ハイブリッドアジャイルの実践」

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

【1】日本でもアジャイル開発の流れが来ている、という記事。
平鍋さんが「エンタープライズアジャイルについて、アジャイル開発が成熟した大人になったことの現れ」と評価している文章が興味深かった。

事例はいくつかあがっていた。
但し、佐野さんがおっしゃるように、IBMのRUP発のDADとSAFeの話が中心で、「ハイブリッドアジャイルの実践」本にあるような日本発の事例や運用ノウハウが紹介されていなかったのは残念かな。

僕は、RUPの案件に開発者として携わった経験があるが、正直、WF型開発と何ら変わらない印象を持っているので、RUPそのままでは日本には受け入れ難いだろうと思っている。

【2】記事を読んで、エンタープライズアジャイル、つまり、基幹系業務システムの開発にアジャイル開発を導入して成功させるには、少なくとも2点は抑えるべきポイントがあると思う。

一つ目は、全体見積りや開発スコープが未確定になりやすい問題をどのように解決するか。
もう一つは、請負契約と委任契約の2つの契約スタイルをどのように使い分けて契約すべきか。

【2-1】前者は、アジャイル開発では、頻繁にVerUpしながら機能を拡張し、品質を改善していく開発スタイルなので、全体見積りができず、開発スコープが未確定になりやすいこと。

普通は、ユーザ企業が年間の予算を立てて、その予算枠内で開発するから、最初に全体見積りが必要になる。
しかし、リーンスタートアップのように、まずはWebサービスをとにかく作って提供し、ユーザの反応を見ながら機能拡張していく開発スタイルは、基幹系業務システムの開発には流石に合わない。
ユーザ企業の情報システム部門からは、必ず、システムの全体見積りを問われるからだ。

また、最初に要件定義で、システム全体の開発スコープを確定させるわけではないので、開発スコープがあいまいになりやすい。
すると、スコープクリープという問題が発生しやすい。

そして、リーンスタートアップでは、最初にシステムのゴールを確定せず、状況に応じてゴールを変える。
しかし、基幹系業務システム開発では、ゴール不明のシステムは、投資対効果(ROI)を計測しにくい。
投資対効果を考え、数年先を見据えたビジネスモデルを提示しなければ、そのままでは受け入れ難い。

【2-2】前者の問題については、ハイブリッドアジャイル開発やウォータースクラムフォールという開発スタイルである程度解決されている。
すなわち、要件定義や外部設計のレベルまできちんとモデリングして、見積りや開発スコープを確定してから、アジャイル開発を実践する方が安全だ。

ウォータースクラムフォールのような手法は、大規模なWF型開発において、要件定義~外部設計や委任契約で作業して、外部設計終了後に再見積し、開発工程以降は請負契約で進めていく手法の考えとほぼ同じだと思う。
つまり、外部設計レベルまで実施しなければ、開発スコープの確定はできないのだ。

ディシプリンド・アジャイル・デリバリー」「アジャイルソフトウェア要求」の本を立ち読みしただけにすぎないので完全に理解していないけれど、DADもSAFeも、ウォータースクラムフォールに似た開発スタイルのように感じた。

【2-3】後者の問題の本質は、アジャイル開発は本来、請負契約が向いているのか、委任契約が向いているのか、という話だと思う。

請負契約はSIに成果物責任があり、瑕疵担保責任も負う。
委任契約は、SIに成果物責任はなく、工数ベースの作業に過ぎず、作業報告書だけでSIがお金をもらえる。

普通は、アジャイル開発は委任契約が向いていて、成果物を明確に定義する請負契約は相容れないと言われていた。
日経コンピュータの事例でも、すべての開発作業を委任契約している事例もあった。

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

しかし、僕は、本来はアジャイル開発は請負契約が向いていると思う。
つまり、1~数ヶ月のサイクルで請負契約を結んで、順次リリースしていくスタイルが向いていると思う。

アジャイル開発は工事進行基準と相性が良いという仮説: プログラマの思索

元々、アジャイル開発は現物主義だ。
1イテレーションないし1スプリントが完了した後には、必ず「出荷可能な成果物」が作られる前提だ。

イテレーションのサイクルで次々にリリースしていく「小規模リリース」こそがアジャイル開発の本質だ、と僕は思っている。
だから、1ヶ月で成果の出ない開発は、アジャイルではない。
つまり、1ヶ月でリリース対象の成果物が作れない開発はアジャイルではない、と思う。

リリースできる成果物があるからそ、ユーザもスプリントデモでレビューできるし、開発チームも、自分たちの作業や技術のフィードバックを得て、次のイテレーションへ改善していくことができる。

すると、1スプリントの単位で作る対象をスプリント計画時に立てて、開発スコープを確定しておけば、成果物責任のある請負契約を実現することもできるはずだ。
実際、Scrumでも、スプリント実行中の期間は、スコープは固定だ。途中からの割り込みは受け付けられないのが基本だ。

すると、1ヶ月単位の請負契約を小刻みに契約している開発スタイルがアジャイル開発に向いているのではないか、と思う。

しかし、「最初にシステム全体の見積りや開発スコープを確定できない」問題があるので、最初の数イテレーションは、要件定義と外部設計を行う期間を別途設けるのが現実的だと思う。

XPやScrumでも、新しいフレームワークなどの技術を検証したり、開発環境を整えるだけで成果物を出さないという、Zeroリリースないしアーキテクチャスパイクという特別なイテレーションを持つ。
だから、最初の数イテレーションは、新しいフレームワークやクラウド環境でプロトタイピング開発したり、要件スコープを概算見積もりできるレベルまで要件定義と設計を行うようにすると良いと思う。


【3】いわゆるハイブリッドアジャイル開発については、以前Blogで、考えられるパターンについて書いてみた。

アジャイル開発とWF型開発をハイブリッドにしたマネジメント・デザインパターン: プログラマの思索

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

ハイブリッドアジャイル開発の中でも、ウォータースクラムフォールは一番使われる開発スタイル。
また、保守作業でも、上限となる工数をあらかじめ決めておき、実施中に要件の優先順位を入れ替えながら順次リリースしていく「リーンWF」というやり方もある。
「リーンWF」も請負契約でやりやすい開発スタイルだ。

他にも色々考えられると思う。

| | コメント (0)

2014/05/17

Redmineでアイドルソング制作の工程管理を使った事例

Redmineでアイドルソング制作の工程管理を使った事例があったのでメモ。

平日はIT技術者、週末は音楽家という方が、アイドルソング制作のタスク管理にRedmineを使ったらしい。
資料を見ると面白い。

アイドルの作曲は受託開発に近いらしい。
タイトルだけ来たり、曲のイメージだけ来たり、彼女たちの要望を受けて作曲しているらしい。
たくさんのアイドルの作曲は仕様があいまいで、仕様変更はオンパレードなのだろう。

しかも、納期は厳しい。
お披露目ライブに間に合わない、ニューシングルに曲が入っていない、振り付けに間に合わなくて棒立ちで歌う、などの影響が出る。

Redmineのタスク管理に適用したルールが興味深い。

まず、プロジェクト名=アイドル名または事務所名にしている。
つまり、依頼元でチケットの集合の器を作っている。
理由は、曲の中身が決まっていないのでアイドル名にしたり、誰が歌うか決まっていない時があるから事務所名にする、など。

このやり方なら、アイドルごとに特徴があるだろうから、以前のチケットを参考にすれば仕事しやすくなるだろう。

また、曲を親チケット、作曲や政策などのタスクを子チケットで管理している。
この方法なら、親チケットに進捗率や工数が集計されるので、便利だろう。

でも、僕なら、バージョンを曲、曲に紐付くタスクをバージョンに紐付くチケットにするかもしれない。。
バージョンはマイルストーンまたはリリース、つまり納期なので、納期を明確に意識したいからだ。

Redmineによるチケット駆動開発が、製造業や製薬業、営業だけでなく、アイドルの作曲タスクの管理まで応用している事例は面白い。

| | コメント (0)

2014/05/09

システムのあるべき姿はどのように創りだすのか~ITガバナンスの実現方法は何か

システム開発からシステム提案の作業に移ると、その作業の中身も変わってくる。
ラフなメモ書き。

【1】ユーザ企業が、何かしらの問題意識を持って、システムを導入する計画を立てようとして、提案作業を依頼されたとする。
実際に提案作業に関わって感じたことは、「システムのあるべき姿」を描く能力がとても必要であること。

システム導入前に、関係者にヒヤリングして問題点や課題を聞いてみると、たくさんの不平不満、要望が出てくる。
現状に何らかの不満があること、それが起点になる。

しかし、それらの問題を集めて、こんな解決策があります、だからこんなシステムを導入しましょう、だけでは重役たちに提案は通らない。

なぜ、あなたはその解決策を思いついたのか。
本当に、その解決策で問題が解消されるのか。違うのではないか。
問題と課題が混同されていないか。

それが本当に目的なのか。
戦略と目標と目的、ねらいが混同されていないか。

今回の提案では、開発のスコープはどの範囲か。
全てをカバーすると、予算がオーバーするのではないか。
納期も間に合わないのではないか。

投資したコストは回収できるのか。
システム導入の初期費用と、システムという資産を数年かけて減価償却していく費用、導入後の数年かけたランニングコストは、どれくらいか。
ビジネスモデルは作れているのか?

【2】それらの質問の背後にある本質は何か?
それは、「システムのあるべき姿が見えているのか」という点だと思う。

「システムを導入した後の姿」がイメージできていれば、重役たちに向けたこんな提案になるだろう。

現状の問題に対し、「あるべき姿」はこれこれだ。
そのギャップに、ヒヤリングした問題がプロットされる。

「あるべき姿」を実現するには、解決すべき課題として、これこれのテーマがある。
このテーマを詳細化すると、このような戦略で考えるべきであり、それぞれの戦略はこのような目標に置き換えられる。

そこで、我々は、今回の予算と納期の制約から、これらの目標のうち、この部分だけをスコープとして開発する。
「あるべき姿」に持っていくには、今回の開発だけでは終わらない。
「あるべき姿」を実現するロードマップはこれこれで、今回の開発は、この部分に相当する。

ロードマップに従うと、初期費用とランニングコストはこれだけの額になり、数年先には元が取れる予定になります、と。

【3】では、「システムのあるべき姿」とは何だろうか?
キーワードは、ITガバナンス。

情報マネジメント用語辞典:ITガバナンス(あいてぃーがばなんす) - ITmedia エンタープライズ

ITガバナンスとは「企業が競争優位性構築を目的に、IT戦略の策定・実行をコントロールし、あるべき方向へ導く組織能力」を指す。
つまり、企業が置かれている立場を直視し、競争優位を確保することを目的とするために、ITシステムの導入と運用を長期的視点で計画・実行・コントロールする。
そして、企業を「あるべき方向へ導く」。
その「あるべき姿を作り出す」組織能力を確立することを指す。

「システムのあるべき姿」は、時代と環境に大きく依存する。
20年前なら、そもそもWindows95すら発売されておらず、クライアントPCは社員全員に渡されていなかった。
10年前には、スマートフォンやタブレットすら無かった。

今なら、サーバー構築にクラウドを使うのは選択肢に入っているし、スマートフォンやタブレットで業務システムを使える要件も入っているだろう。
さらに、BYODやMDM、リモートワークのような要件も先進的企業なら入っているだろう。

それらの要件を加味した「システムのあるべき姿」を、その時々に応じて企画しなければならない。

【4】ITガバナンスの実現には、提示した「システムのあるべき姿」を論理的に補強するフレームワークを必要とする。

「システムのあるべき姿」を実現するには、このゴールが必要だ。
このゴールを達成するには、これだけの戦略が必要だ。

これらの戦略を成功させるには、この目標(重要成功要因:CSF)がいる。
この目標を実行するには、このようなアクションプランが必要で、システムの機能ないし運用ルールで実現できる。

この目標(CSF)を達成するには、目的を達成具合をはかる指標(重要目標達成指標(KGI))と手段の進捗状況をはかる指標(重要業績評価指標:KPI)が必要だ。

こんな流れを提案書に含めて、重役たちに説明して、「システムのあるべき姿」がどれだけの効果があり、どのように達成していくのか、を明示しなければならない。

では、このような提案のフレームワークは何があるのか?
おそらく、バランス・スコアカードになるだろう。

BSCとは 〔 バランストスコアカード 〕 【 Balanced Scorecard 】 - 意味/解説/説明/定義 : マネー用語辞典

「システムのあるべき姿」とゴール、ゴールと戦略の関係は、戦略マップで表現される。
つまり、システムのビジョン(システムのあるべき姿から導かれたゴール)と戦略の遂行は、「財務的視点」「顧客の視点」「社内ビジネス・プロセスの視点」「学習と成長の視点」の4つの側面から、戦略の因果関係図として、戦略マップになる。

戦略マップに書かれた要素である戦略は、目標へ詳細化され、重要成功要因:CSFになる。
つまり、戦略が達成されるべき条件を具体化した内容がCSFだ。
CSFが明確化されなければ、戦略を達成できたのか、評価できない。

それらを測定できるようにした指標が、KGIないしKPIになる。
目標に達成できたのか、測定できなければ、いつまで経っても、システム投資というお金を溝に捨てることにある。
KPIは、つまりメトリクスのことだ。
今は、業務や運用のログをゆるやかに収集して集計する仕組みをシステム化するのはとても簡単なので、メトリクスを提示しやすい利点がある。

【5】バランス・スコアカードは10年以上前から提唱されている経営戦略の手法だが、改めてよくできていると思う。
特に、戦略の因果関係を図で表現できるのが良い。
また、戦略マップで、単に財務の観点だけでなく、お金に直接ならない「学習や成長の観点」も大切にする点が良い。

このバランス・スコアカードについては、まだ使いこなせていないが、色々試してみたいと思う。


| | コメント (0)

2014/05/07

第6回ドメイン駆動設計読書会の感想

第6回ドメイン駆動設計読書会に行ってきた。
感想をメモ書き。

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

Pages ・ dddosaka/reading_ddd_report Wiki

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

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

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

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

【1】今回の勉強会は、ちょっと難しいと感じた。
おそらくその理由は、第5回に参加できなかったため、DDDの基本パターン「モデル駆動設計」をきちんと読み込めていなかったからだろうと思う。

DDDの基本パターンは、[ 技術講座 ] Domain-Driven Designのエッセンス 第1回に書かれているように3つある。

1・ユビキタス言語
2・モデル駆動設計
3・実践的モデラー

【2】モデル駆動設計が意味するもの

(引用開始)
● Model-Driven Design(モデル駆動設計)パターン

ユビキタス言語を実現するには、プログラムコードにおいてもドメインモデルが正確に表現されていなければならない。
ドメインモデルとプログラムコードとが常にお互いを反映するように保つことで、ドメインモデルの変更がそのままコードの修正を促し、逆にコーディングの中で得られた新たなドメイン知識が即座にドメインモデルに反映されるようになる。
このようにモデルとコードを緊密に結びつけるのがモデル駆動設計(MDD)である。
MDDを実践するには、開発ツールやオブジェクト指向プログラミング(OOP)のようなプログラミングパラダイムが必要になる。
(引用終了)

モデル駆動設計では、モデルとソースは一致する。
つまり、「コードを変えるとモデルも変わる」。
モデラーと開発者は、ユビキタス言語でモデルの意味を共有する。
だから、プログラマもモデルの意味をユビキタス言語として理解して、プログラミングする必要がある。

ここで、モデル駆動設計が言う「モデルとソースは一致する」主張には2つの実現方法がある。

【2-1】モデルからソースを生成する場合は、モデリングツールによるフォワードエンジニアリング

この方法は、かつてのMDAが目指していたもの。
「WF型開発の上流工程だけ腕を上げれば、プログラミングは設計モデルから自動生成されたソースで置き換えられる」という考え方が好きな人がこだわる。

最近は、BPMやBRMSのように、ワークフローエンジンないしビジネスルールエンジンも自動生成できる製品が出てきたので、この手法が最注目されているように思える。

BPMとワークフロー: プログラマの思索

なぜ超高速開発が話題になるのか~キーワードはビジネスルール管理システム(BRMS): プログラマの思索

【2-2】ソースからモデルを生成する場合は、リバースエンジニアリング

業務システムの開発案件で非常に多いリプレース案件でよく出てくる。
既存の古いシステムを捨てて、新しいシステムへ置き換えるというレガシーマイグレーションで、この設計手法がよく使われる。
普通は、既存の仕様書が保守されていないために使い物にならず、本番稼動中の画面や帳票からER図や機能をリバースエンジニアリングする。
リプレース案件とレガシーマイグレーションについては、過去にたくさん書いてきた。

システムのリプレース案件が最も危険な理由: プログラマの思索

ERPの落とし穴part4~システム移行という名のデスマーチ: プログラマの思索

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

このリバースエンジニアリングでよく使われる設計手法がデータモデリング(DOA)。
データベース定義書がなければ、データ移行もできない。

そして、機能仕様書とER図から、CRUD表も作る時が多い。
CRUD表があれば、リバースした設計書を理解しやすいし、その後のテスト仕様書にも流用できる。

個人的には、データモデリング技法としては、T字形ERが一番有効だと思う。
T字形ERでは、既存の画面や帳票からリバースしてモデリングする技法として確立されているからだ。

【2-3】リバースエンジニアリングによるモデル駆動設計のアンチパターンとして、勉強会の議論で「最新の建材を用いて築かれた竪穴式住居」というアンチパターンが紹介された。

発端は、渡部幸三さん著「業務システムのための上流工程入門」にあるアンチパターン。

リプレース案件で、旧モデルをそのまま新モデルにマッピングしてしまい、あるべきモデルになっていない。
現実の業務の焼き直しに過ぎず、従来の課題が解決されないまま、新システムが作られてしまう。

「最新の建材を用いて築かれた竪穴式住居」というパターン名には、石器時代の竪穴式住居をコンクリートの建材で作り直した時、その建材の特徴や最新の機能を利用せず、例えば、高床式倉庫のまま作ってしまったり、ねずみ返しのように不要な機能までそのまま再現してしまった、という意味が込められている。

レガシーマイグレーションのアンチパターンとして「最新の建材を用いて築かれた竪穴式住居」は覚えておくと良いと思う。

【2-4】但し、モデル駆動設計の実装方法については「ドメイン駆動設計」では何も語られていない。
今後の課題なのだろう。

【3】実践的モデラーが意味するもの

(引用開始)
● Hands-On Modeler(実践的モデラー)パターン

もしモデラーがプログラムを書けなかったり、プログラマがドメインモデルに興味を示さなかったら、MDDの利点であるモデリングとプログラミングの好循環は生まれない。
また、チームのコミュニケーションもそこで停滞してしまう。MDDを通してユビキタス言語を実現するには、モデラーが動くプログラムを書けなければいけないし、同時にプログラマがドメインモデルを理解し、修正できなければならない。
つまり、チームのすべての開発者は、プログラムを書くモデラーでなければならない。
(引用終了)

【3-1】実践的モデラーパターンは、Coplienの組織パターンにある「アーキテクチャ設計者もソフトウエア実装に参加する」に相当すると思う。
アーキテクトもモデルとソースを行き来しないといけない。
アーキテクト(モデラー)もモデルの実現可能性を調べる必要がある。

パターン15:アーキテクチャ設計者もソフトウエア実装に参加する

(引用開始)
・問題:どのようにしてアーキテクチャ的なビジョンを実装の段階も持つ続けるのか?

・コンテキスト:開発者の組織が、戦略的な技術的方針を必要としている。

・影響する事柄:全体主義的な統制は、多くの開発チームで、厳格さの程度として観察される。正しい情報は、正しい役割を経由して流れなければならない。

・解決策:アーキテクチャ設計者は、開発者にアドバイスしたり情報交換するだけでなく、ソフトウエア実装にも参加すべきである。
(引用終了)

アーキテクトは単にモデルとして設計するだけでなく、ソースとしての実現方法も考慮しなければならない事実を意味している。
ITの技術革新によって、従来の課題であった「実現可能性の制約」の壁はかなり下がってきている。
特に、クラウドの技術によって、システムの実装方法や配置方法は、従来と比べてかなり変わってきている。
そんな面も考慮して、ベターなシステムを作る必要があるのだろう。

| | コメント (0)

ドメイン駆動設計の読書メモ

ドメイン駆動設計の読書メモの画像が分かりやすのでメモ。

【参考】
いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経

Twitter / akipii: 後で読む RT @hatsanhat: いまさら「ドメイン駆動設計」を読み終えた http://agnozingdays.hatenablog.com/entry/2014/04/29/223310 … この方、タダモノじゃないですね。読書ノート公開なんて出来るものじゃない! 大阪で語りたい方は5/6に読書会があります。まだ数名募集中

instagramにアップされた読書メモを見ると、ナビゲーションマップを中心に、内容がコンパクトにまとまっている。
参考にしやすい。

| | コメント (0)

2014/05/05

SysMLの使い道

最近、SysMLに興味を持っている。
SysMLの資料をリンクしておく。
SysMLについてメモ書き。

【参考】
astah* SysML 1.2 をリリースしました。:An Agile Way:ITmedia オルタナティブ・ブログ

SysML勉強会:SysMLコトハジメ 第1回 | 豆蔵ソフト工学ラボ

第2回 SysMLを利用可能なモデリング・ツール「Enterprise Architect」 | Think IT

要求と構造を分析するためのシステム要求設計技法

SysMLから学ぶシステム設計手法

モデルベースシステムズエンジニアリングとSysMLの活用

モデルベースシステムズエンジニアリング 導入の手引き(IPA)

モデルベースで考えるための SysML

SysMLの概説と動向

システムエンジニアリングプロセスへのSysML適用のポイント

モデルベースシステムズエンジニアリングとSysML活用

SysML_overview-Japanese-balmelli.pdf

SysMLの使い道は2つあると思う。
一つは、組込みシステムにおける設計のスケッチ。
もう一つは、モデル同士のトレーサビリティ。

前者は、組込みシステム開発では、ハードウェア技術者、回路のエンジニアなどソフトウェアとは違う人種の技術者がいる。
彼らとコミュニケーションする時、自然語だけでの要件定義書や設計書では、意思疎通が難しい。
やはり、絵を描いて、イメージで話す方が分かりやすい。
その場合、UMLのように、ダイアグラムであっても記法が決まっている方が、正確に表現しやすい。

SysMLで面白いのは、パラメトリック図。
物理法則のような制約条件と部品の関係を表現する事で、非機能要件を表現しようとする。
UMLはあくまでも機能要件しか表現できなかったから、この部分は面白い。

更に面白い点は、SysMLパラメトリック図のシミュレーション 機能ガイドによれば、EnterpriseArchitectを使うと、パラメトリック図を元にモデルをシミュレーションできるらしい。
OOAが目指していたモデル駆動開発は、おそらくこのようなイメージだったのだろうと推測する。

後者は、SysMLの各ダイアグラム同士で関連付けが、SysMLの仕様として埋め込まれていること。
ロボット開発におけるSysMLの活用によれば、SysMLには、構造と振る舞いの観点があり、ブロック図・要求図・アクティビティ図・パラメトリック図の要素がそれぞれ対応するように描けるらしい。

つまり、各モデルのトレーサビリティが保証されているので、ある仕様変更が発生した場合、影響するモデルがどれであるかを把握しやすくなる。
設計作業で一番面倒なのは、一つの仕様変更による影響調査だ。
その部分を手作業ではあるが、SysMLはUMLよりも意識しているように思える。

他にも、SysMLからソースを自動生成したり、VDMのような形式手法のソースを出力してモデル検査やモデル検証を行う手法もあるらしい。

他にも探してみる。

| | コメント (0)

2014/05/04

開発トレンドはスマートフォンからスマートフォンの外へ

最近のソフトウェア開発のトレンドはスマートフォンからスマートフォンの外へ向かっているように思える。
記事をメモ。

【元ネタ】
開発トレンドは「スマホの外」へ。それでもプログラマーのやることは1つ【連載:中島聡】 - エンジニアtype

なぜ今、クルマのスマート化が話題なのか。“自動車版iPhone”テスラが生み出す新市場【連載:中島聡】 - エンジニアtype

独立して最初の3ヵ月間にやったお仕事のまとめ - Over&Out その後

コンピュータを操作する人のマジョリティが、PCからスマフォ・タブレットへ移りつつある。
それに従って、従来の業務アプリの開発方法も、Webアプリ主体だけでなく、スマフォ・タブレットを意識した開発スタイルへ広がって進化している。

スマフォ・タブレットなどのモバイル端末のソフトウェア開発は、従来のようなガチガチのWF型開発はありえない。
短期間で次々にリリースしながら、品質も機能も改善していくのが普通なので、アジャイル開発にならざるを得ない。
だから、従来のWF型開発にこだわりがある企業ほど、モバイルの流れに乗って行くのは難しいと思う。

技術的には、使いやすいユーザインターフェイスへのこだわり、アプリやROMをVerUpできる仕組みづくりに特徴があると思う。
アジャイルUXやソフトウェアアップデート機能はそんな流れにある。

そんな中、上記の記事では、スマフォだけでなく、スマフォを構成する組み込み機器とソフトウェアを組み合わせたビジネスが今後発展していくだろうと示唆している。
つまり、ソフトウェアの範囲が広がるにつれて、ソフトウェア技術者もハードを理解する必要があることだ。

それは、単にハードウェアの仕組みを理解するだけでない。
ハードウェア技術者や製造業と協調しながら、コラボして、一つの製品をつくり出していく開発手法を身につけるべき、という方向性を示唆している。

これは重要な点だと思う。
なぜなら、ハードウェア技術者や製造業は独自の文化を持っており、ソフトウェア技術者の発想や開発手法と異なるからだ。
彼らは厳格な品質管理技法を持っており、WF型開発に近い工程管理も持っている。
そんな彼らとアジャイル開発に近い試行錯誤を許すような開発手法を共有しなければならない課題があるわけだ。

とは言え、組込みエンジニアに聞くと、ハードウェア技術者の方がアジャイル開発に近い開発手法を持っているとも聞く。
実際、ハードウェアが設計書通りに作られるわけではなく、試行錯誤しながらよりよいものを作っていくから、と。

また、組込みエンジニアから聞いて興味深かったことは、ハードウェアは著作権が絡むので、メーカーはブラックボックスにして囲い込みするやり方が多い。
一方、ソフトウェアは外注して安上がりに作れるように発注するパターンが多い、と。
このやり方で問題なのは、納入されたソフトウェアをハードウェアに組合せて結合テストを実施すると、設計漏れや考慮漏れが原因でたくさんのバグが多発して収拾しなくなることだろう。
本来は、ハードウェア技術者とソフトウェア技術者が一体化されたチームとなって開発すべきなのだ。

ソフトウェア技術者とは違う異質な人や組織とどうやって折り合って、ゴールを達成していくのか。
そんな課題が今後重要になってくるように思える。

| | コメント (0)

« 2014年4月 | トップページ | 2014年6月 »