「データサイエンティスト」の感想～データマイニングが自然科学を再定義し直す

最近、R言語や統計学、データマイニングに興味を持っている。
「データサイエンティスト データ分析で会社を動かす知的仕事人 (ソフトバンク新書)」を読んだ感想をメモ。

【元ネタ】
SBクリエイティブ:データサイエンティスト

ASSIOMA(アショーマ) ≫ 書評:データサイエンティスト データ分析で会社を動かす知的仕事人

データサイエンティスト（１）データサイエンティストとは？：『ビジネス2.0』の視点：ITmedia オルタナティブ・ブログ

ビッグデータ活用が進まない3つの理由、データを成果につなげるデータサイエンティストの役割とは／ソフトバンク・テクノロジー | Web担当者Forum

科学研究手法の「第四のパラダイム」としてのData-intensive Computing | JOURNAL | FERMAT

むしろ数式が苦手だけど統計を勉強したいという人はRをやるといいかもしれない - Line 1: Error: Invalid Blog('by Esehara' )

【連載】「変わる」広告会社：第1回　エージェンシーのビッグデータ“ドリブン”マーケティング（前編） - ITmedia マーケティング

【1】データサイエンティストが必要になる背景

IT技術が世の中に普及して、当たり前の時代になった今、大量データが溢れている。
その大量データを分析することで、意味ある法則を導き出せるのではないか、という発想。

今までの統計学は、おそらく、机上の空論に近い理論だったのだろう。
実際、コンピュータがなければ、大量データを処理する計算は、手作業でやるしかなく、それは有限の時間で有限のコストでやるには、限界値が低すぎた。

「完全独習 統計学入門」によれば、昔の統計学は、いかに少ない計算量で、統計学の意味ある原理原則を導き出すか、というテクニックに走っていたらしい。
でも、現代の強力なコンピュータ技術を使えば、大量データを並列で処理させれば、かなりのことができる。

【2】データサイエンティストに必要な3つの思考パターン

【2－1】オッカムの剃刀

シンプルに考える。
必要以上に多くの過程をしない。
複雑なモデルにしない。

この言葉の発端は、プラトンに由来する実在論に反対し、モノそれ自体とは別に普遍概念が存在する彼らの主張を批判すること。
「プラトンの髭をオッカムの剃刀で剃り落とす」ことから由来している。

オッカムの剃刀 - Wikipedia

データサイエンスなら、前提となる条件はできるだけシンプルにし、大量のデータからシンプルで有効なモデルを作り出すこと。
そのための前提となる考え方。

【2－2】フェルミ推定

フェルミ推定 - Wikipedia

限られた情報からざっくりと答えを出す。

データサイエンスなら、仮説で置いたモデルないし公式に、大量データからデータマイニングして得られた数値を当てはめて、答えを導き出す。
「地頭力を鍛える 問題解決に活かす「フェルミ推定」」が読みやすい。

【2－3】アブダクション

アブダクション とは - コトバンク

アブダクションとは、仮説と発見の論理。
演繹法、帰納法の次に来る3番目の論理。

論理の流れは以下になる。

a)驚くべき事実Cが観察される
b)しかし、もしHが真であれば、Cは当然の帰結であろう
c)よって、Hが真であると考えるべき理由がある

たくさんの仮説からもっともらしいものを選び出す論理。
帰納法＋推論。

データサイエンスは、帰納法を発展させた考え方と言える。
つまり、大量データという事例を元に、それら事例に共通する原理原則を導き出す手法。

だが、いくらデータマイニングが強力といっても、帰納法ですべての事例が同じような振る舞いや原理原則に従うとは限らない。

そこで、統計学における仮説検定という手法を使う。
「Rによるやさしい統計学」によれば、たとえば、「母集団から一部の抽出した標本に対して○○の相関関係を見つけた」という研究論文の主張に対し、「その主張は、母集団から都合の良い標本を見つけ出したのに過ぎないのではないか。本当はそんな相関関係はあると限定できないはずだ」と反論を受けたとする。

すると、そのライバルの指摘した事象が起こることは現実的にほとんどありえない、という主張で反論し返す。
つまり、母集団に我々が主張する相関関係が全くないとしたら、我々が見つけた標本が得られる可能性は非常に小さい、ということを示す方向で反論する。

この反論の仕方は、母集団から全ての標本を集めた証明に比べると、説得力は弱いが、限られた標本データからある程度の合理性を持って、コストや納期の観点による検証可能性から見れば、かなり強力といえる。

すなわち、データサイエンスは、統計学の仮説検定という手法を使って、データマイニングで見つけた相関関係という原理原則はほぼ確からしい、という統計学の理論的基盤によって、その正当性を示しているわけだ。

【3】データサイエンスは第4のパラダイム

【3－1】第1のパラダイム～経験科学

観察・観測によって自然現象の原因を解明する。

【3－2】第2のパラダイム～理論科学

既知の法則に基づく新たな現象の予測。
実験による仮説検証。

【3－3】第3のパラダイム～計算科学

理論的解が得られない複雑な現象を近似解として、ITのシミュレーションで予測する。

【3－4】第4のパラダイム～データサイエンス

膨大な一次データを収集・分析し、関係性を見出す。
コンピュータによる経験科学の再定義。

科学の「第4のパラダイム」 データ集約型科学が人類の危機を救う | トニー・ヘイ | 2011年11月号｜DIAMOND ハーバード・ビジネス・レビュー

【4】データサイエンティストは計算可能な定量モデルを提示する

「その数学が戦略を決める」では、ワインの質の方程式を統計学の手法から定量的に求めた式がある。
品質が高いワインは、収穫期に雨が少なく、夏の平均気温が高いという経験則をもとに、ワインの質の定義をソムリエから奪った。
ワインの質は、舌よりもデータで決まる。

ワインの質の方程式のおかげで、生産者やワイン売買業者も、数年から数十年経って質が決まるワインをある程度予測できるようになり、その分、助かったという話がある。

【5】データサイエンティストはグロースハッカー

データサイエンティストは、プログラミングとマーケティングの二つの技術を兼ね備える人。
Webサービスの世界で増えてきた。

グロースハッカーとは何か？―シリコンバレーで急増する、WEB業界の新たなキャリアを定義する［1］│CAREER HACK

1990年代は、Apacheアクセスログから、PVやユニークユーザ数などを解析した。
2000年代は、GoogleAnalyticsを使えば、だれでも手軽に解析できる。
しかも、技術的知識がなくても、マーケティング知識があれば、いろんな使い方ができる。

グロースハッカーの出現は、リーンスタートアップの発想に似ている。
ビジネス＞プログラミングから、プログラミング＞ビジネスの時代への転換。

【6】マーケティングモデルはAIDMA、AISASモデルからAARRRモデルへ

AIDMAは、1920年代のアメリカで生まれたマーケティング手法。

AIDMA - Wikipedia

日本の広告代理店の電通等によるWebマーケティング手法として、AISASモデルが提唱された。
そして、ECやクラウドサービスの見込み客を優良顧客へ変えて収益を上げるマーケティング手法として、AARRRモデルが提唱されている。

「AARRR」　今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

AARRRモデルを使えば、コンバージョンを追跡することで、Webサイトのどこに問題があるのかを分析できる。
Twitter、Instagramを導いたグロースハッカーの仕事とは―グロースハッカー徹底解明［2］│CAREER HACKには、下記の例がある。

(引用開始)
例えば、同じアイテムを取り扱っているECサイトが2つあるとします。
Aのサイトは一日に100人の訪問者があり、50人が会員登録してくれた。
ただ、実際に買物してくれたのは、そのうちの5人。
50%がサインアップしてくれたが、
そのうちの10%しか課金してくれなかったということになります。

Bのサイトも同様に一日に100人の訪問者があるものの、会員登録してくれたのはわずか10人。
しかし、その半数の5人が買物をしてくれた。
サインアップしてくれたのは10%でも、その50%が課金してくれた。

AとBともに100人の訪問があり、
5人のユーザーが課金してくれたという事実は同じですが、
それぞれが抱えている問題は全く異なります。
この違いは、PVとコンバージョンだけ見ていても絶対に分からないでしょう。
アクイジションやアクティベーション、リテンションなど、
どのプロセスに課題があるのかをまず見つけること。
そこからアイデアに優先順位をつけて、実際に改善をしていく必要があります。
(引用終了)

つまり、サイトAは、訪問者を集めるプロセスは良いが、課金プロセスを改善するのが課題になる。
サイトBは、課金プロセスは良いが、訪問者が会員登録するプロセスを改善するのが課題になる。

グロースハッカーは、データマイニングを使って、そのような問題を洗い出し、問題解決の対策を打ち出して、実行して結果を上げる役割を担うわけだ。

【7】データサイエンティストが育つ場所

データサイエンティストが育つ場所は、新領域での実践の現場。
ビジネス側とソフトウェア開発側の協同作業。

統計学の理論だけでは机上の空論。
マーケティングの手法を知っていたとしても、実際にプログラミングして、Webサイトからフィードバックをすぐに得られる仕組みがなければ、机上の空論。
プログラミングだけできても、ビジネス上の問題を解決する手法でなければ、単なる技術の持ち腐れ。

データサイエンティストはグロースハッカーであるならば、ビジネスもプログラミングも両方知っている。

【8】プログラマがデータサイエンティストになるための方法

「データサイエンティスト」には、どんな言語を選べばよいかは書いていない。
個人的には、R言語が面白いと思う。

オープンソースだし、情報はネット上にいくらでもある。

はじめての「R」 from Masahiro Hayashi

データマイニングが自然科学を再定義し直す。
すごくワクワクする。

Redmine導入でいつも問題なること～ワークフロー管理とDoneの条件

あちこちの現場に行くたびに、僕がRedmineのサーバーを立てて、運用を開始して、チケット駆動の運用を軌道に乗せる。
僕がいなくても運用は回るようになるが、導入後にいつも問題になることがある。
ラフなメモ書き。

【1】Redmineは、特に小規模なSI案件のプロジェクト管理に使いやすいらしい。
僕はRedmineとチケット駆動開発を組み合わせた運用をベースにアジャイル開発を導入したい動機で、Redmineを使っているが、他のプロジェクトリーダーは、チームの進捗管理を見える化するのを目的としているらしい。

そんな要望を受けて、Redmineをインストールして、チケット駆動の運用ルールを作り、チケット駆動開発を始める。
すると、いつも問題になることが2つある。
それは、ワークフロー管理とDoneの条件。

【2】開発現場の運用をスムーズに回すことをRedmineの目的の一つにしているので、リーダーや開発者からヒヤリングして、現状のワークフローを洗い出す。
その現状のワークフローをRedmineで実現して、運用を開始する。

すると、使っているうちに、ステータスを増やしたいとか、ワークフローの種類を増やしたいなどのフィードバックを受けて、Redmineのワークフローをカスタマイズする。
運用しながら、少しずつRedmine自体を改善していき、チームの作業管理はスムーズに流れるようになる。
そこまではいい。

そんな運用事例を後で上司に報告する機会があり、僕は、Redmineのワークフローによる運用ルールとその成果(チケット集計によるメトリクスやKPTのヒヤリング結果)を報告した時がある。
自分としては、どうだ、チケット駆動開発は現場のチームをかなり改善させているんだぞ、という思いがあった。

しかし、上司から言われたのは、現状のワークフローをそのまま実現して、それが本当に正しいものなのか？
本来のあるべきワークフローから考えて、Redmineの運用ルールを考えるべきではないのか？
現状のワークフローには、無駄が多いのではないか？
現状のワークフローをそのままRedmineに乗せて、運用がうまくいった、というのは、単に効率化しただけであり、現状の課題をそのまま置き去りにしているのではないか、と。

アジャイル開発は、ボトムアップ志向が強いと思う。
チケット駆動開発も、あるべきモデルやワークフローを考えて、綿密に計画してから実行するよりも、まずは運用しながら少しずつ改善する方が向いている。
チケット駆動開発は、ボトムアップ志向の方がやりやすい。

でも、本来は、現場の課題に対して、Redmineをどのように導入すれば解決できるのか、という観点をもっと入れるべきなのだろう。
そうでなければ、現場の課題が残ったまま、局所最適化しているに過ぎない。

しかし、ワークフローのあるべき姿を決めたとしても、その運用はそう簡単には回らないと思う。
ワークフローは、開発チームの体制や役割に大きく依存している。

例えば、ワークフローにあるステータスを減らすとしよう。
すると、減らされたステータスのロールの人の作業は不要になる。
つまり、ワークフローを整理して、あるべきワークフローにシンプルにすると、不要なロールの人はチケットに出てこなくなるので、チームから除去しても良いことになる。
すなわち、チームの組織体制が大きく変えることを意味している。

Redmineのあるべき姿のワークフローにチームを合わせるべきなのか？
それとも現場のチームに合わせてRedmineをカスタマイズすべきなのか？

ケース・バイ・ケースとは言え、この問題は根本的な問いであると思う。

【3】Redmineの親子チケットを用いて、ストーリーカード(親チケット)とタスクカード(子チケット)を実現して運用したとする。
この運用ルールは、元請けの設計チームと下請けの開発チーム、または、プロジェクトリーダー・サブリーダーと開発者という関係のように、ストーリーカードとタスクカードのロールが違う時に運用しやすい。

Redmine Backlogsプラグインで、スクラムを用いて、実行注のスプリントで当初見積もったストーリーを実施し、スプリント最後にストーリー内の殆どのタスクは終わったものの、たった一つのタスクが未完了になったとする。
その場合、そのストーリーは一旦完了にして、その残タスクのみを次のスプリントに持ち越しにしたい時がある。

さほど優先度の高いタスクでもないし、顧客に見せるほどのタスクでもなく、すぐに終わりそうなタスクならば、そのストーリーは完了にして、残った一つのタスクは次のスプリントに持ち越しにしたいのだ。

すると、Redmine Backlogsプラグインでは、ストーリー無しのタスクはチケット登録できないのだ。
どう運用すればいいのか？

Redmine Backlogs :: Home

backlogs/redmine_backlogs

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（3）：「スクラムやるならRedmineとALMinium！」～新キャラ登場！ 無表情なあの人が笑う日は来るのか？ (1/3) - ＠IT

その答えは以下に書いた。
つまり、「その他」「管理」などのようなストーリーを作り、それにタスクを入れて管理すればいい。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

この問いの本質は、ストーリーやタスクの完了条件は何か？という問題につながる。

ストーリーの完了条件は普通は、全ての子チケットであるタスクが完了することだ。
しかし、実際の運用では、運用中に優先度が変わったりして、実行中のスプリントでタスクが未完了でもよい場合もある。
そうならば、そのタスクをストーリーから切り離すか、そのタスクを一端却下とし、次スプリントに「管理」「その他」などのストーリーと共にタスクを起票すればいいだろう。

もしチケット駆動開発で工数管理を厳格にやっている場合、未完了のチケットで実績工数が発生していれば、そのチケットは仕掛中を意味する。
だから、そのスプリント終了時に、未完了チケットは全て却下とし、次スプリントで新たに起票し直す運用が本来は正しいだろう。
そうしなければ、バーンダウンチャートの予定・実績工数の表示はおかしくなるだろう。

チケットのDoneの条件は、チームの成長に伴って変わる。
スクラムでは、スプリントレトロスペクティブで、Doneの条件を見直す。
最初はDoneの条件は緩く狭いだろうが、チームが成長し、フレームワークに慣れて、ドメイン知識を身につけるようになれば、Doneの条件はどんどん追加されていくようになるだろう。

例えば、機能を実装しただけではなく、自動テストを実施し、ビルドが通り、リリースできた、とか、原因結果グラフのテストケースも残す、などの条件が加わる、とか。

Doneの条件は案件やチームによって大きく変わる。
Doneの条件を見ると、チームの成熟度がよく分かる。

成熟したチームは、Doneの条件が厳しくても運用できる。
逆に未熟なチームほど、Doneの条件があいまいだったりするので、ワークフローにレビューや検証のステータスがたくさん加わり、ワークフローが複雑になりがち。
つまり、未熟なチームほど、Doneの条件の不備をワークフローの複雑さでカバーしようとする傾向が見られる。

【4】Redmineを導入すると、そのチームの開発プロセスがチケットのワークフローで見える化されるため、そのチームの組織構造やプロセスの構造がとてもよく見える。
だが、Redmineを導入したとしても、現場の課題をうまく解決できなければ、現状の課題を残したまま運用して、ごまかしながら何とか回していることになる。

本来は、Redmineというツールを業務改革のためのERPのように用いて、現場のソフトウェア開発プロセスをあるべき姿に変えたいのだ。
でも、チケット駆動開発はボトムアップ志向なので、あるべき論から攻める方針は、僕の経験上あまり成功していないように思う。

この辺りは今後も考えてみる。

第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」の感想

第56回　SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」に参加したので感想をメモ。
自分用メモをそのまま貼り付けたので、適当に書く。

【元ネタ】
3月29日 第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」

Xtext - Language Development Made Easy!

ベータパブリッシュ - テキスト型DSL開発フレームワーク Xtext 入門

最初は、細合さんのお話。

【1】DSLのメリット

　生産性の向上
　　コードの自動生成
　ドメイン分析
　　プログラムを第三者視点で表現して分析
　特定のモデルしか書けない
　　プログラミングの知識があまり必要ない
　　ドメインを明確にする
　プログラミングというプログラマの暗黙知を形式知にする

DSLを使いたい最大の理由は、暗黙知にあるドメイン知識を形式知にすること。
DSL文法を使うことによって、例えば業務ドメインの言葉を定義することで、どんな概念が必要で、どんな文法(つまり制約条件)が必要なのか、を明確にする。

DSLで書かれたモデルから、XtextはすぐにJavaソースへ自動生成できる。
昔のモデル駆動開発は、本来はXtextで書かれたモデルからソースを自動生成すべきではなかったのか。

【2】DSLの種類

Internal(言語内・内部)・External(外部)と、テキスト形式・グラフィカル形式で分類された4種類がある。

・Rake：Internal(言語内)＋テキスト形式

・Make、SQL、Ant：外部DSL＋テキスト形式
　→XTextもココに入る

・UML、SysML：外部(独自処理系)＋図形式

・VisualStudio：内部＋図形式

AntやSQLは外部DSL。
Rakeは内部DSL。

UMLやSysMLも、グラフィカルなDSLの1種ととらえる発想は面白い。
確かに、業務モデルや組み込み機器のモデルをUML文法やSysML文法に従って、図に書いているわけだ。

【3】DSL環境
　DSL定義→メタモデル→コード

DSLの作り方
　ドメイン知識が必要なので、新規開発に向かない
　既存資産からパターンを抽出し、ドメインモデルと変換規則を生成する

XText
　OSSのEclipseのDSL支援環境

昔に比べると、言語生成がすごく楽になった
　XTextなら、DSL定義とメタモデルさえ書けば、コードを自動生成してくれる
　　コードアシスト、シンタックスカラーリング、バリデーションなどの開発環境もある
　　Javaのライブラリを参照できる
　　Eclipse上で、テキスト形式とグラフィカル形式を連動できる

XText
　DSL定義

XTend2
　Javaを生成する軽量言語が内蔵されている
　XTextで作られたJavaを生成する軽量言語
　Javaの痒い所に手が届く便利な言語
　書いたそばから自動生成
　　コンパイルまで行なってくれるので、Javaとシームレスに利用可能
　　動的型付け
　　　但し、コンパイル時に型決定なので安心
　　ラムダ形式、拡張関数、拡張Switch(型に応じて条件分岐)
　　テンプレート記述
　　　Javaを自動生成するためのコードテンプレート
　　　　テンプレートにある変数にクラス名、変数名、メソッド名などが、メタモデルから設定されて、自動生成される

MWE2
　DSLからモデル、コード生成までのモデルワークフローエンジンが組み込まれている
　ワークフローエンジン
　　XTextで書かれている
　モデル駆動開発の主要な作業をワークフローの形で記述できる
　　状態遷移図みたいなもの
　　State、Transitionを定義する
　Xtextの言語生成を行う際もこのMWE2のスクリプトを起動して言語環境の生成を行う
　DIのような機能もある
　　ワークフローの途中にポイントがあり、動的にロジックを挿入できる？

Xtextの最大の利点は、DSLの文法を定義するプロセス、自動生成するソースのテンプレートをXtextだけで書けること。
つまり、Xtextさえ覚えれば、DSLを自前で定義できる。

使い道としては、フレームワーク開発を担当する上級SEや上級プログラマがXtextでDSLを定義する。
設計SEは、自前で定義されたDSLに基づき、業務のモデルをDSL文法に従って書く。
すると、即座にモデルに従ったJavaソースが自動生成される。
さらに、テストソースも自動生成されるので、設計SEが開発者の役割も兼ねて、自分でプログラムを書いてしまえばいい。

【3】Xtextを使ったDSLの使い道としては、下記のような業務システムの内部設計があるだろう。

【3－1】業務システムのCRUD表からJavaソースのスケルトンを作成
　機能とテーブルのCRUDマトリクスを、DSLに基づくモデルを書いて、ソースを自動生成する。
　画面やバッチが、どのテーブルからどんなデータを使って、どのテーブルへデータを更新しているのか
　機能をいじると、影響するテーブル、そのテーブルを使う機能に影響が出るのが分かるようにならないか？

【3－2】モデルからソースを自動生成
　モデルベース要件定義に相当する。
　例えば、オブジェクトの状態遷移図をDSL文法で書いて、ソースを自動生成する。

【3－3】既存システムのリバース・エンジニアリングは使えないか？
　既存システムの保守の過程で、パッチで継ぎ接ぎされて、ドキュメントが実際の仕様を反映していない
　誰も既存システムの仕様を知らない
　そんなときに、DSLを使ってソースを解析し、モデルを自動作成とかできないか？

【3－4】ワークフローエンジンを作る
　例えば、ユーザ企業の経費申請、工場の製造・出荷の作業フローなど。
　DSLで状態遷移図の文法を定義し、モデルにワークフローを書き、ソースを自動生成する。

　Xtextでは、トランジション(条件分岐)にDI(Dependency Injection)が使えるらしいので、BRMS(ビジネスルール管理システム)を理論上実装できるはず。
　例えば、出張申請のワークフローをXtextのモデルで書いておき、「出張旅費5万円以上なら、処理Bを実行する」のような業務ロジックをトランジションに挿入して呼び出しできるようにすればいい。

【4】次は、細谷さんの事例の話。

【4－1】Xtext導入の経緯
　SNSで聞いていた
　アジャイル開発で、通信プロトコルの解析処理の実装が電文解析しながら、単純作業になっている
　電子仕様を形式化して、コード生成手段とマッチング
　Xtextは15分でやれると聞いて試した
　チュートリアルの試行
　独自のコードジェネレータを実装

Xtext以前のコード生成
　Excelマクロでコード生成
　　Excelで設計書を作る
　Rubyによるコード生成

より良い手段としてXtext導入を検討

Xtextの適用
　バイナリファイルのパーサー

　製品に対抗する装置のシミュレータ
　　100種類の信号に対応する電文
　　製品とシミュレータがTCP/IP通信
　様々な装置に対抗する装置のシミュレータ
　コード生成のツールとして利用
　既に規定されている構造を処理するコードを生成する
　通信プロトコルを定義するための文法を設計、実装し、未来のプロジェクトで利用可能なDSLを定義する

Xtextの気づき
　ドメイン知識の形式化
　　文法を定義する過程で、ドメイン知識が形式知になる
　　定義された文法を読めば、非常に少ない情報量で、モデル化の範囲や内容を理解することができる

　　70％をカバーする製品に適用した
　　　マニアックな製品仕様は除く
　　　コストが割に合わない

　モデルの改善
　　一つの言語要素から1つの対応するクラスを生成する
　　　ジェネレータの実装が簡単になる
　　自動生成範囲が派生クラス、共通部分が基底クラスとなり、実装の重複がなくなる

効果的な導入ポイント
　最初から全てのモデル化は困難
　容易に効果が出るポイントに着目する
　　コストや時間のトレードオフ
　分析して言語を決めるのは、初心者ならXtextは時間がかかる
　　最初は単一プロジェクトから
　行数の多い表に注目する
　　Xtextに適用すると効果的
　　表は一つの型
　一つのデータ定義が複数の箇所で実装される部分に注目する
　　例：機器の監視項目
　　　　　監視項目は電文の仕様に近い
　　　　　　電文の定義をDSLでモデルとして表現する
　　　　　監視項目は画面で表示して、担当者がチェックする
　同じ概念を複数のソフトウェアで共有している部分に注目する
　　例：複数の機器の間の通信
　　　　　通信されている機器のI/Fは共通の電文仕様を持っている

【4－2】細谷さんの話を聞くと、Xtextを組み込み機器の通信プロトコルに使われる電文や制御処理の自動生成に使われていたらしい。
DSLで通信プロトコルの制御仕様を書くことで、100種類以上の電文の仕様(ドメイン)が明確になり、そのドメインを他の開発者も共有できる。

興味深かったのは、DSLが万能といっても、すべての電文をDSLの対象はならないこと。
複雑な仕様の電文は、コストや納期などの都合上割にあわないので、効果が出る部分のみにXtextを導入した、とのこと。

【5】Xtextの実演習では、Eclipseを使って、サンプルソースを書きながら動かしてみた。
初心者なので、開発環境Eclipseの使い方にはまる。

慣れると、Eclipse上でDSLのコード補完、バリデーション、Import文の自動追加、コードハイライトなどがあるので、すごく書きやすい。
フレームワークを開発、保守するプログラマなら、Xtextを覚えれば、かなり生産性が上がるのではないだろうか？

また、細谷さんから聞いた所によると、XtextのDSL文法はEclipseのプラグインにできるらしい。
すると、ある特定の実装モデルを記述するDSLをXtextで書いてEclipseプラグインにしておき、開発工程でプログラマにプラグインを読み込ませて、実装モデルの設計をDSLというプログラミングで書いてもらえばいい。

すなわち、上級プログラマがDSL文法を定義して、それをEclipseプラグインにして設計SEに配布しておけば、設計SEはDSL文法に基づくモデルを書くと、ソースないしスケルトンを自動生成できる。
つまり、上級プログラマが、システムの方式設計と、システムの設計内容を記述するモデル言語としてDSLの文法を作っておけばいい。

他に、DSLに基づくモデルとして、UMLのクラス図やシーケンス図、状態遷移図があるだろう。
設計SEは、業務をそれらUMLのダイアグラムを絵で書くのではなく、DSLの文法に従ってテキストで書けばいい。
設計書はモデルを表すテキストなので、Gitの配下でバージョン管理でき、その変更履歴をいくらでも追跡できる。
また、モデルをグラフィカルに表現するようなツール(例えばPlantUML)に食わせれば、顧客などのエンドユーザも理解できるはずだから、要件定義や仕様変更で議論しやすくなる。

色々試してみる。

Redmineで予定／実績レポートを表示するプラグインredmine_estimate_timelogがVer2.4でも対応できている

Redmineで予定／実績レポートを表示するプラグインredmine_estimate_timelogがVer2.4でも対応できていたのでメモ。

【参考】
Redmine で予定/実績レポートを表示するプラグイン(estimate_timelog v0.5.0)を Redmine 2.x に対応させた ? suVeneのアレ

Redmineで予定／実績レポートを表示するプラグイン【estimate_timelog】を作ってみた - アルパカDiary

estimate_timelogの0.2.1をリリースしました - アルパカDiary

toritori0318/redmine_estimate_timelog

suvene/redmine_estimate_timelog

【1】Redmineは工数入力の機能は以外に優れていると思う。
実績工数をチケット画面から入力できるI/Fがあり、予定工数や進捗率やステータスと連動させれば、予実管理の強化もできる。
また、実績工数を「作業分類」で色付けできるので、活動基準原価計算(ABC：Activity Baced Costing)の発想を取り入れることもできるだろう。

【2】但し、Redmineの工数集計の「経過時間」画面の仕様は正直イケてない。

Redmine で予定/実績レポートを表示するプラグイン(estimate_timelog v0.5.0)を Redmine 2.x に対応させた ? suVeneのアレにも書かかれているように、予定工数が存在していても実績工数が0のレコードは表示されない。
つまり、あくまでも「実績ベース」でしか表示しない。

実際のプロジェクト管理では、予実管理が基本なので、予定工数のあるチケットに対し、実績工数が0であろうが、予定工数をオーバーしていようが、どちらも表示させて、チェックしたいのだ。
もちろん、実績工数＝0の場合、現在日が開始日以前のチケットなら問題ないが、既に作業実施すべきチケットでは、なぜ作業に着手できていないのか、原因を探ることになる。

redmine_estimate_timelogプラグインでは、「予定ベース」は「予定工数が存在するチケットはすべて表示する。さらに予定工数＝0でも、実績工数＞0のチケットも表示する」仕様である。

「実績ベース」は「実績工数＞0のチケットのみ表示する」仕様である。
つまり、予定工数＞0なのに、実績工数＝0のチケットは、「実績ベース」では表示されない。

(引用開始)
チケット#1 予定 8h
チケット#2 予定 4h 実績 4h
チケット#3 　　　　 実績 4h

という状態の時に、今までの「予定ベース」の仕様では

チケット#1 予定 8h
チケット#2 予定 4h 実績4h

と表示されていたのだが、

チケット#1 予定 8h
チケット#2 予定 4h 実績4h
チケット#3 　　　　実績4h

と表示されるようにした。

これにより、「予定ベース」と「実績ベース」を二度表示させなくてよくなる。
(引用終了)

【3】redmine_estimate_timelogプラグインのインストールは若干注意が必要。

インストールログ　Infinite Loop　-SE奮闘記-

Railsのverificationを事前にインストールしておく必要がある。

cd ${redmine_root}/plugins

git clone https://github.com/rails/verification.git

git clone https://github.com/suvene/redmine_estimate_timelog.git
↓
Passengerをインストールしているなら、下記コマンドを使えば、設定ファイルを読み込むだけで、Redmine再起動は不要。

service httpd reload

Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date

Redmine2.4.xで、ガントチャート画面に暦週や日付を表示するプラグインを見つけたのでメモ。

【参考】
Redmineのガントチャート機能改善の要望チケット: プログラマの思索

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

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

【環境】Redmine2.4.2、CentOS6.5

【1】ガントチャート画面に暦週を表示する。

Redmine プラグイン: Gantt with date

yoshidayo/redmine_gantt_with_date

(引用開始)
ガントチャートの表示画面で、週の表示をcweek(1月1日から何週目か)から週頭の日付に変更します。
(引用終了)

例えば、2014/3の第2週なら、3/8が月曜日で開始日になるので「8」を表示する。
以前は、元旦から何週目であるかを表示していて、ガントチャートの開始日や終了日がいつなのか、が分かりにくかった。
ただし、暦週でも分かりやすいかどうかはケースバイケース。

【2】ガントチャート画面に日付を表示する。

Gantt with date - Plugins - Redmine

vividtone/redmine_gantt_with_date

ガントチャートの表示画面で、週の表示をcweek(1月1日から何週目か)から日付に変更している。
これは便利。

@g_maedaさんが作成されているので、今後のRedmineのバージョンアップにも追随してもらえるのではないか、と期待している。

但し、上記2つのプラグイン共に、DBマイグレーションはなくRedmine再起動だけで反映できるお手軽さはあるが、プラグイン名が同じなのでどちらか片方しか反映できないので注意。

ソースコードからモデルの絵を自動生成する

ソースコードからモデルの絵を自動生成するツール(Graphviz、PlantUML)についてメモ。
アイデアをラフなメモ書き。

【元ネタ】
Graphvizの簡単なサンプル

Graphvizメモ(Hishidama's Graphviz Memo)

AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)

PlantUML の使い方 | プログラマーズ雑記帳

PlantUML

【1】クラス図、あるいは単なるネットワーク図を手書きではなく、ツール上のGUIでもなく、ソースで書きたい時がある。
ちょうど僕は、「アイデアを組織に広めるための48のパターン」の本を読んでいて、その内容にすごく惹かれて、それらパターンの一覧であるナビゲーションマップが欲しくなった。
ナビゲーションマップがあれば、パターンの間でどのような関連があり、どのようにパターンが生成されていく(generative)のかを見ることができると考えたからだ。

「アイデアを組織に広めるための48のパターン」には、48個のパターンと、それらパターンの関係は本文に書かれている。
「パターンA→パターンB」というデータを本文から抜粋すれば、ナビゲーションマップを作ることができる。

つまり、パターン一覧があり、パターンの関連も決定されているので、それらの仕様をソースコードに落とし込めばいい。
そこで、Graphviz の dot コマンドを使って、簡単な有向グラフを生成できるのではないか、と考えた。

アイデアはこんな感じ。
但し、作成途中なので中途半端な絵になっている。

「アイデアを組織に広めるための48のパターン」のナビゲーションマップ(作成中)

デザインパターン、ドメイン駆動設計、組織パターン、XPのプラクティスなどのナビゲーションマップは、Graphviz の dot コマンドで描けるソースコードに落とし込めば、すぐに生成できるはず。

【2】他にも、ソースコードで有向グラフを生成したい時がある。
例えば、バッチのジョブフロー図もそうだ。

AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)によれば、Javaで書かれたオープンソースのHadoopのフレームワークであり、業務系バッチに特化しているものだが、バッチソースだけでなく、そのジョブフロー図も自動生成してくれるらしい。

バッチ処理は汎用機＋Cobol時代からずっとあるけれど、その設計技法の中で、ジョブフロー図が一番重要な成果物だ。
ジョブフロー図がなければ、本番障害が起きた時に、どのジョブからリランして復旧すればよいか、などが分からなくなる。
しかし、お金のないSIや技術力のないSIでは、ジョブフロー図をExcelで書いているものの、その最新化を怠っている所も多い。
普通のお金のあるSIは、Visioでジョブフロー図を書いて都度更新しているが、バイナリファイルなのでバージョン管理もやりにくい。

しかし、バッチ処理のソースからジョブフロー図を自動生成できれば、ジョブフロー図を最新化する必要もない。
それができなくても、ジョブフロー図の元ネタをテキストファイルで書いておき、自動生成できるようにしておけば、そのテキストファイルをバージョン管理することで、変更管理の配下に置くこともできる。

ソースと設計書のトレーサビリティにもつながる。

【3】PlantUML の使い方 | プログラマーズ雑記帳によれば、UMLのクラス図やシーケンス図なども、テキストファイルから自動生成できるようだ。
JavaDoc上に書いておくようにしておけば、ソースコードに設計書が埋め込まれているので、ソースコードからUMLの各種ダイアグラムを自動生成する手法も選択できる。

【4】他にも、ガントチャートをRubyソースから自動生成するツールもある。

Rubyのガントチャート生成ツールTaskJuggler: プログラマの思索

【5】本来やりたいことは、ソースと設計書、報告書とのトレーサビリティだ。
ソースはバージョン管理にあり、チケットの作業履歴と紐づけている。
しかし、設計書や報告書はExcel、WordなどのOfficeファイルであり、バージョン管理したとしても、ソースの変更に追いつけていない。
本来なら、ソースコードを直せば、ソースコードから設計書を作り出すべき。

要件定義書、設計書、ソース、テストケース、障害などの間のトレーサビリティは、今後のソフトウェア開発で重要になってくる。
アジャイル開発でやっているとしても、その背後では、SCMやITSなどでトレーサビリティを確保できるようにしたいのだ。

時間に余裕ができたら、色々試してみたい。

「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想～エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集

「アジャイルに効く アイデアを組織に広めるための48のパターン」を読んだ感想をラフなメモ書き。

【参考】
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン一覧: プログラマの思索

「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」予約開始 - Yasuo's Notebook

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

Fearless Changeアジャイルに効く アイデアを組織に広めるための48のパターンを熟読中 - 未来のいつか/hyoshiokの日記

【1】背景、動機

自分が新しいツール、新しいプロセスを導入したい時、うまくいく場合とうまくいかない場合がある。
例えば、Redmineによるチケット駆動開発を導入したい時、あるいは、アジャイル開発を導入したい時、その結果は、やり方に応じて失敗する時もある。

僕はRedmineのエバンジェリストと思われる時が多く、Redmineの導入によってプロジェクト支援を期待される役割が多い。
僕は過去の経験から、アジャイル開発へ発展させるパターン・アンチパターンを貯めてきたので、どのプロジェクトもそれなりに成功してきたと思っている。
でも、他の人が同様に成功するとは限らないだろう。

2000年代前半、XPユーザグループでは、XPを通じたアジャイル開発をいかに現場に導入するか、という事例とノウハウの議論がたくさん行われた。
実情は、アジャイル開発は日本のSIに導入しづらい、という苦労話ばかりで、たくさんの失敗例ばかりだった。
でも、Scrumが世界で普及し始めた後を追うように、日本でもScrumをベースにしたアジャイル開発の成功事例が少しずつ増えてきているように思う。

「アジャイルに効く アイデアを組織に広めるための48のパターン」は、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストが、そのアイデアを組織へ導入するためのノウハウ集だ。
この本の内容をもっと以前に知っていたら、僕もこのテクニックを使って、もっと容易にRedmineを導入できただろうと思った。

アジャイル開発を実際の現場に導入したいと思う人がいるなら、まずは「アジャイルに効く アイデアを組織に広めるための48のパターン」を読んで、どのように組織へ展開すべきか、構想を巡らすと成功率が高まるだろう。

【2】「アジャイルに効く アイデアを組織に広めるための48のパターン」を適用できる状況

「アジャイルに効く アイデアを組織に広めるための48のパターン」のアイデアは、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストだけでなく、次の人達にも使えると思う。

(1)PMOや品質管理部(SEPG)の立場で、個別プロジェクトや組織を支援する人達

PMOやSEPGは、普通は火消し役でプロジェクトを支援する立場が多い。
すると、火を噴いているプロジェクトで既に作業しているメンバーやリーダーが、実は抵抗勢力になってしまう場合もある。
現場の問題点を把握せずに、頭ごなしの命令や作業指示をいきなり実施すると、反発されてしまうのだ。

(2)プロジェクトリーダーとして、新しいツールや新しいプロセスを導入したいと考える人達

新しもの好きなアーリーアダプター、イノベーターの精神を持つプロジェクトリーダーは、新しい案件で新しいツールやプロセスを試したくなる場合がある。
新しい技術を試して、新しいノウハウを得たいのだ。
でも、メンバーが新しい技術に付いていけなかったり、上司が予算やコストを理由に圧力をかけてくる時もある。

(3)業務改善のためのシステム提案、要件定義を行う人達

SIがシステムを提案する場合、ユーザ企業にシステムを導入するだけでなく、ユーザ企業の業務プロセスも変わってしまうことも合わせて提案する時が多い。
業務のIT化とは本来、今まで労働集約的だった作業を自動化して、人減らしに使う一つの手法だから。
すると、ユーザ企業の組織構造も変わる事になり、従来の仕事を持つ人達は役割が変わるだけでなく、権限が廃止される場合もあるので、抵抗勢力になってしまう時がある。

【3】プラクティスをパターンとしてまとめる意義

「アジャイルに効く アイデアを組織に広めるための48のパターン」が優れている点の一つは、エバンジェリストが使えるような道具として、パターン形式でまとめていることだ。
パターン形式なので、どんな状況でどんな問題に対してどんな解決策を実施すればよいか、が明確に理解しやすい。
また、パターンの概念はパターン名で名前付けられているので、会話の中でパターン名を呼ぶだけで、その背景や問題意識、パターンを適用した効果についても、他人と共有できる利点がある。

欧米人が日本人よりも優れている点は、PMBOKやCMMIのように、既に知られている経験知を知識体系として抽象的に普遍的な概念としてまとめる能力がある点だと思う。
関西IT勉強会でも、谷島さんが同じようにことを指摘されていた。

過去から今までの日本人も、プロジェクト管理や開発プロセスについて、たくさんの経験を持っているし、たくさんの書籍も出している。
しかし、それらの知識はバラバラであり、他人が使えるような知識や概念になっていない。
そもそも、それらの概念に名前が付けられていないので、他人との会話で流通できるような普遍性を持っていない時が多い。

パターンの良い点は、BOKのような知識体系よりも、帰納的であり、たくさんの経験を元に普遍化されているので、理解しやすい点にあるだろう。

僕は、パターン言語というアイデアが好きだ。
パターン形式で自分の体験に基づくプラクティスを作り出せるし、そのパターンを他人に広めやすくしてくれる。

パターン、Wiki、XPは良書: プログラマの思索

パターン言語のアイデア: プログラマの思索

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

「アジャイルに効く アイデアを組織に広めるための48のパターン」でパターンに関する興味深い指摘がある。
P.16の「パターンの利用方法」に「初めてパターンを読んだ人は、情報が多すぎると感じるかもしれない」という指摘がある。
つまり、パターン形式には、状況・問題・解決策の3つで十分で、フォースや結果状況、使用例は不要ではないか、ということだ。

しかし、実際にグループでパターン化する議論をしていると、すぐに暗礁に乗りかかった。
ある解決策を用いた時に、副作用として発生する問題はどこに描くのか？
パターンの前提条件となる制約条件はどこに書くのか？
という質問がどんどん出てきた。

ほどなくして、結局、フォースや結果状況などの全てのパターン項目が追加された。
「問題解決に向けて議論していくと、いずれ全てのパターン項目が必要になることを、まさに目の当たりにした」という。

この逸話はとても重要な内容を示唆していると思う。
つまり、アレグザンダーのパターン項目は、単なる思いつきで作られたパラメータではなく、パターンを語る時に必然的に出てくるパラメータなのだ、ということだ。

そして、パターン項目のうち「フォース」がかなり重要であると、最近思うようになった。
以下にもその理由が書かれている。

パターンとフォースとぎゃー！ - 反言子

(引用開始)
8. フォースが問題を定義する
形式上、問題がまず初めに来るので、作者は時折、解法を書く前に問題を記述する。
だが、これもまた問題を含んでいる。
解法をよく理解しないままに、問題を衝動的に記述する。
しかし、作者が解法について詳細に考え抜かない限り、そのような問題の記述はあいまいで、非常に大雑把なもになりがちだ。

問題と解決の結びつきが重要であることはわかっている。
僕はこの手の話が好きなので「問題こそ重要である」という考え方にはなじんでいる。
しかし問題を定義することは難しい。
なるほど、解法がわからない、衝動的に考えられた問題なのだ。

ゆえに問題を記述するためにフォース、そして問題とフォースの関係を考え抜くことが重要になる。
パターンが単なるマニュアルでない理由としてフォースの存在が語れることにも納得がいった。
(引用終了)

【4】各パターンのメモ

「アジャイルに効く アイデアを組織に広めるための48のパターン」の各パターンを読むと、ああそういう意味だったのだな、と経験が整理される気がする。
以下、本の文章を踏まえて、自分の理解と体験を踏まえてメモしてみる。

◆全体に関わるパターン

(1)Evangelist : エバンジェリスト(1)
新しいアイデアを持ち、熱意を持って普及させたいと思う人。

(2)Small Successes : 小さな成功(2)
チームに小さな成功を植えつけて、意気を上げる。
チケット駆動開発なら、完了したチケットが必ず記録されるので、後から自分の実績をふりかえれば自信になる。

(3)Step by Step : ステップバイステップ(3)
トップダウンで一気にやらない。
ボトムアップで少しずつ広めていく。
お試し期間(47)や便乗(21)を使う。

Redmineによるチケット駆動開発は、ステップバイステップで実行しやすい。
運用しながら、ワークフローを修正したり、チケットの項目を追加したり、運用ルールを変えていくことは柔軟に可能。

(4)Test the Waters : 予備調査(4)
あなたは新しいアイデアに興奮して、エバンジェリストになりたいが、新しいアイデアが組織に合うかどうかまだ分からない時に使う。

(5)Time for Reflection : ふりかえりの時間(5)
定期的に評価し、フィードバックを得る。

「なぜ、ふりかえりが必須なのか、自明ではないかもしれない」。
しかし「走りながら考えればいい、経験からの学びは無意識のうちに積み重ねられていく」という考え方は、現実にはうまくいかない。
定期的に活動を評価し、学びの機会を作らなければ、同じような間違いを何度も繰り返す。

◆序盤の活動に関わるパターン

(6)Ask for Help : 協力を求める(6)

(7)Brown Bag : ブラウンバッグ・ミーティング(7)
ランチミーティングのこと。
日本なら、ノミニュケーションに相当するだろうか。

(8)Connector : コネクター(8)
(9)Do Food : 何か食べながら(9)
(10)e-Forum : 電子フォーラム(10)

(11)Early Adopter : アーリーアダプター(11)
新しいアイデアのオピニオンリーダーになりうる人々。

(12)External Validation : 外部のお墨付き(12)

(13)Group Identity : グループのアイデンティティ(13)
チームや活動に名前をつけること。
例えば、@daipresentsさんは自分のチームに「特攻野郎Aチーム」という名前をつけていたのを思い出す。
また、スティーブ・ジョブズも、Macチームに海賊の旗を掲げていた。

(14)Guru on Your Side : 達人を味方に(14)
組織のメンバーに尊敬されているシニアレベルの人々を味方にする。

(15)In Your Space : 空間を演出する(15)
「見える化」のこと。

(16)Innovator : イノベーター(16)
新しもの好きの同僚。
新しいというだけで好奇心をそそられ、興奮する人々。

(17)Just Do It : やってみる(17)
新しいアイデアの利点や限界は、自分自身の経験から情報を集める。
自分が今やっている仕事にそのアイデアを試して、評価してみる。

(18)Just Say Thanks : 感謝を伝える(18)
協力してくれた人々に感謝の気持を伝える。

僕が過去にKPTによるふりかえりを実施した時、女性SEや女性PGから、Keep欄に、他メンバーに感謝の気持を伝えるPostItが貼られた時がある。
感謝された人はさぞかし嬉しかっただろうと思う。
そんな表現だけでも、チームは和むし、一体感が高まる。

(19)Next Steps : 次のアクション(19)
アイデアをToDoリストに落とすこと。

(20)Personal Touch : 個人的な接触(20)
新しいアイデアの価値を伝えるために、技術的な利点よりも、個人や組織のニーズを理解する。

(21)Piggyback : 便乗(21)
自分のアイデアを既存の慣習に追加機能として載せることで、コストやリソースを減らす。
新しい取り組みよりも、改善として導入する。

Redmineによるチケット駆動開発では、普通、現場の作業ルールをそのままワークフローに当てはめて、運用を開始する。
つまり、AsIsのワークフローから開始して、少しずつ改修しながら、あるべき姿(ToBe)のワークフローへ変えていく。

(22)Plant the Seeds : 種をまく(22)
勝間和代氏が提唱している「Giveの5乗」と同じ。

(23)The Right Time : 適切な時期(23)
イベントの時期や助けを求める時は、タイミングを考慮する。

アジャイル開発では、イテレーションごとに、ふりかえりでフィードバックを得たり、次のアクションを考えるタイミングが取りやすい。
しかし、WF型開発は、実際は、ふりかえりや改善実施のタイミングが取りにくい。
なぜなら、工程単位に前工程のふりかえりやそれをうけた対策を考えたいが、普通は仕様変更や五月雨式のWF開発が多いので、メンバーが常に忙しく、まとまった時間を取るのが非常に難しいから。
結局、プロジェクト完了時の1回だけしか、ふりかえりが行われず、チームが解散するために、せっかく得られた知見や改善案も生かされない。

(24)Stay in Touch : 定期的な連絡(24)
(25)Study Group : 勉強会(25)

(26)Tailor Made : テイラーメイド(26)
新しいアイデアを採用する時、組織のプロセスとゴールを事前調査して、イノベーションが解決できるニーズや問題に適用する。

(27)Big Jolt : 著名人を招く(27)
今なら、アジャイル開発の有名人やアジャイルコーチを呼んで、組織変革を支援してもらうようにする。

◆中盤以降の活動に関わるパターン

(28)Corporate Angel : 経営層の支持者(28)

(29)Dedicated Champion : 正式な推進担当者(29)
組織で認められて、予算と権限を与えられたエバンジェリスト。
新しいアイデアの組織導入を効果的に進めたいなら、ボランティア活動だけでは身が重い。

(30)Early Majority : アーリーマジョリティ(30)
組織内に強力な足場を構築してくれる「より慎重なマジョリティ」。
門番(ゲートキーパー)であるイノベーターやアーリーアダプターだけでは、組織変革は不十分。

(31)Guru Review : 達人のレビュー(31)
組織のメンバーに尊敬されているシニアレベルの人々によるレビューチームを作り、新しいアイデアを評価してもらい、他の聴衆に影響させる。

(32)Hometown Story : 体験談の共有(32)
新しいアイデアの有用性を体験談で共有し、形式知として表出化する。
体験談という暗黙知の共有。
SECIモデルの一例。

僕の現場では、KPTによるふりかえりで、成功や失敗の体験談を共有する場合が多い。

(33)Involve Everyone : みんなを巻き込む(33)
イノベーションが一人の人や小さい集団のためだけではなく、組織全体のためにある。
より多くの人に新しいアイデアを「自分ごと」として認識してもらう。
それによって、心から取り組んでくれるだけでなく、貢献したいという力強い感情を生み出し、組織と個人のつながりも強化する。

(34)Just Enough : ちょうど十分(34)
新しいアイデアを学んでもらうには、学習曲線を考慮する。
段階を経て正しく理解してもらう。

Redmineによるチケット駆動開発では、運用ルールを1回説明すれば、その後は細かい説明は不要で運用できる利点がある。

(35)Local Sponsor : 身近な支援者(35)
現場のマネージャに協力を求める。
経営層や下々の人々よりも、中間層のマネジメント職の支援があってこそ、新しいアイデアは現場での仕事のやり方として正式に認められる。
パトロンに近い。
実は、プロジェクトリーダーやプロジェクトマネージャが、組織変革の抵抗勢力になってしまう場合が多い。

(36)Location, Location, Location : 場所重要(36)
半日以上かかるイベントは、仕事の現場を離れて、別の場所で開催する。

(37)Mentor : メンター(37)
新しいアイデアを理解して、チームを手助けできる人。
守護者、ファイアーウォールに近い。

(38)Royal Audience : 謁見(38)
(39)Shoulder to Cry On : 相談できる同志(39)

(40)Smell of Success : 成功の匂い(40)
新しいアイデアが成功し始めると、新参者がイノベーションについてエバンジェリストに尋ねてくるようになる。
そんなときは、教えるタイミングとして捉えよう。

(41)Sustained Momentum : 勢いの持続(41)

(42)Token : トークン(42)
名札のこと。
新しいアイデアを思い出させる小さな名札。
例えば、マグネット、ボタン、カップ、鉛筆、リングノート、クイックリファレンス、記事のコピーなど。
他にも、アバター、ツールのロゴ、ニコニコカレンダーなどが挙げられるだろう。

Redmineにもアバタープラグインがある。
担当者のアバターがあるだけでも、ツールへの関わり方は違ってくる。

◆抵抗と付き合うためのパターン

(43)Bridge-Builder : 橋渡し役(43)
新しいアイデアを受け入れた人を、まだ受け入れてない人に引きあわせて、イノベーションの有用性を受け入れてもらう。

(44)Champion Skeptic : 懐疑派代表(44)
エバンジェリストのアイデアに懐疑的なオピニオンリーダーに、公式な懐疑派の役割を演じさせる。
新しいアイデアの問題点を指摘するように促し、その問題に対処する。
但し、結果状況が悪くならないように注意が必要。

(45)Corridor Politics : 根回し(45)
重要な決議の前に、影響のある意思決定者に非公式に接触して、承認へのストーリーを作る。
文字通り、根回し、腹芸のこと。

(46)Fear Less : 怖れは無用(46)
抵抗勢力を新しいアイデアの強みに変える。

(47)Trial Run : お試し期間(47)
新しいアイデアのトライアル期間。
新しいアイデアを検証する。

(48)Whisper in the General’s Ear : 将軍の耳元でささやく(48)
集団の前でマネージャを説得できない時、非公式な場所でマネージャに懸念点を教えてもらう。

【5】「アジャイルに効く アイデアを組織に広めるための48のパターン」で面白いのは、エバンジェリストをサポートする人々の役割にたくさんのパターン名が付けられていること。

エバンジェリスト(1)、正式な推進担当者(29)がこのパターン言語の主役。
組織内には、コネクター(8)、アーリーアダプター(11)、達人、イノベーター(16)、経営層の支持者(28)、アーリーマジョリティ(30)がいて、彼らに働きかける。

エバンジェリストの味方には、著名人、身近な支援者(35)、メンター(37)、相談できる同志(39)、橋渡し役(43)がいる。
抵抗勢力には、懐疑派代表(44)がいる。

それら役割に相当する人は組織内の誰なのか、をマッピングしておけば、組織変革のどの時点ではキーマンは誰か、を考えるきっかけになりうる。

役割に相当するパターン名を調べてみると、非常によく考えられているなあ、と思う。
他にも色々考えてみる。

ドメイン駆動設計に出てくる概念モデルと分析モデルの違い

ドメイン駆動設計に出てくる概念モデルと分析モデルの違いについて、良い記事があったのでメモ。

【元ネタ】
ドメイン・フレームワークのススメ(第1回)

ドメイン・フレームワークのススメ(第2回)

【1】概念モデル、分析モデル、設計モデルを以下で定義している。
これは分かりやすい。

(引用開始)
概念モデル：問題領域に対する「理解のしやすさ」を重視したモデル。
実現手段の詳細によらない、問題領域の本質的な構造/特性を素直に表現したもの。

分析モデル：概念モデルをベースに、抽象化/一般化を加えてドメイン・フレームワークを分離/再構成したモデル。より広い範囲での再利用性/拡張性の向上を狙う。

設計モデル：分析モデルをベースに、特定のアーキテクチャ/ライブラリ/プログラミング言語等を想定して具体的な実現手段を組み込んで詳細化したモデル。
(引用終了)

ドメイン・フレームワークのススメ(第1回)では、Greedというゲームを概念モデルで描いている。
Greedというゲームの概念をそのままクラス図に落とし込んだだけのものが概念モデル。

つまり、概念モデルはAsIsモデルであり、あるべきモデル(ToBe)ではない。
だから、概念モデルに出てくるドメインを再利用するのは難しい。

あるべきモデル(ToBe)こそが分析モデル。
すなわち、概念モデルからドメインを抽出(蒸留)し、より抽象度を高めることで、仕様変更しやすくし、再利用を高める。

(引用開始)
概念モデルは対象領域(問題領域)の本質的な構造や特性を捉えて理解を深めるために有効です。
この段階では、実現手段(HOW)の詳細にとらわれず、そもそも「どんなもの(WHAT)を相手にしなければならないのか」を整理しながら理解を深めることに注力します。システム開発の早い段階で問題領域に対する理解をしっかり深めておくことは、後のさまざまな工程に良い影響をもたらします。
そのため、概念モデルは「理解のしやすさ」を最も重視して作成されます。
一方で、概念モデルは現在対象となっている世界「そのままの姿」を素直に捉えたモデルであるため、基本的に抽象化/一般化や類似の問題領域に対する再利用性や拡張性の考慮などは薄くなります。
(中略)
ドメイン・フレームワーク化されていない概念モデルをベースに(概念モデルを「分析モデル」と呼んで)、設計、実装…といった詳細化の工程に進んで行ってしまう開発プロジェクトも多く見かけます。
この場合、大きな問題が無ければそれなりの期間/工数で正しく動作するシステムが出来上がってしまうので、一見するとその開発プロジェクトは成功したかのように思えてしまうのですが、そのようにして作られたモジュール群は後に類似の問題領域の別システムの開発のために流用(再利用)してみようとしてもあまり上手くいきません。
再利用性や拡張性が活かせないのであれば、オブジェクト指向で開発する意義の半分ほどを失うと言ってもオーバーではないでしょう。
オブジェクト指向は魔法ではないので、単に「クラス」という単位でモジュールをまとめれば自然に再利用性や拡張性が上がる…というわけではないのです。
(引用終了)

ドメイン・フレームワークのススメ(第2回)では、Greedゲームを抽象化したゲームの分析モデルを提示している。
ゲームの分析モデルでは、「ゲームフレームワーク」というパッケージにドメインモデルがパッケージングされて、再利用できるコンポーネントになっている。
そして、「ゲームフレームワーク」を継承することで、Greedゲームを実装できるように設計されている。

つまり、ドメインモデルという分析モデルへ蒸留させたことで、ドメインの再利用性が高まった利点がある。
しかし、分析モデルにも欠点はある。
分析モデルは抽象化しすぎるために、理解しにくいのだ。

(引用開始)
Greedゲームの分析モデルでは、Greedゲームに限らず他のゲームにも適用可能な部分(ドメイン・フレームワーク部分)とGreedゲーム固有の都合に左右される具象部分とが、モジュール(クラス)としても明確に分離/整理されています。
そのため、このようなモデルをベースに設計/実装されるソース・コードのうち、少なくともドメイン・フレームワーク部分については他のゲームを実装する場合にもそのまま再利用できる可能性が高くなります。
まとめ方(抽象化や一般化の方法)を工夫してなるべく多くの部分をドメイン・フレームワークとして抽出できれば、それだけ再利用率を上げることができるでしょう。
一方で、抽象化/一般化による変形/分離が施された分析モデルはある意味「素直な構造」ではなくなっているので、「問題領域の構造/特性を理解する」という目的にはあまり向いていない(理解するのが難しい)モデルになります。
たとえば、図 2 に示した分析モデルだけを見て、Greedゲームが「ゲーム」「ラウンド」「ターン」「ロール」の階層構造を持つということをパッと読み切るのは困難です。
ドメイン・フレームワーク化はドメイン・レベルでの再利用性/拡張性を確保するために必要なのですが、抽象化/一般化と理解のしやすさはトレードオフの関係にあります。
新たにモデルを見る人がそもそもの問題領域を素直に理解できるように、分析モデルの元になった概念モデルも対にして残しておく(抽象度の異なる目的別のモデルを作成する)のが良いでしょう。
(引用終了)

【2】上記のドメインフレームワークの考え方は、概念モデル(AsIs)→分析モデル(ToBe)へ蒸留させていくやり方だが、同じような経験がRedmineのワークフロー抽出にもある。

ある現場にRedmineを導入するとしよう。
すると、まず真っ先に行うのは、メンバー全員からヒヤリングして、その現場の現状のワークフローを抽出することだ。
抽出されたワークフローがRedmineのトラッカーの候補になる。
この作業は、あるべきワークフローではなく、現状運用されているワークフローなので、概念モデル(AsIs)と同等だ。

しかし、現状運用されているワークフロー(AsIs)があるべきワークフロー(ToBe)とは限らない。
無駄なステータスがあるかもしれないし、本来は別のワークフローで厳格に運用すべきかもしれない。

だから、あるべきワークフローのイメージを描いて、Redmineのワークフローを決定し、Redmineのトラッカーに登録する。
この作業は、現状のワークフローをモデルチェンジしてあるべきワークフローへ変えたので、分析モデル(ToBe)と同等になる。

【3】そんなことを考えると、設計という作業は、あるべき姿(ToBe)をイメージするのが重要であり、ドメイン駆動設計は進化的設計(反復的設計)によってAsIsからToBeを導き出そうとする手法であると思える。
最初から、正しいモデルを描くのではなく、リファクタリングしながら、より良いモデルへブラッシュアップしていく。
そのための技法やノウハウが「ドメイン駆動設計」にたくさん埋め込まれているわけだ。

色々考えてみる。

【追記】確かに、ドメイン駆動設計では、モデルとソースコードは一致するから、分析モデルと概念モデルの間に違いはない。

Twitter / j5ik2o: ドメインという言葉があるからといってすぐにDDDと紐づけて考えるのはよくない。DDDでは分析と概念のモデルは分けて考えないので。要注意。 / “ドメイン駆動設計に出てくる概念モデルと分析モデルの違い: プログラマの思索” http://htn.to/tXUEvR

でも、「ドメイン駆動設計」には、「浅いモデル」「深いモデル」という区別が出てくる。
おそらく、「浅いモデル」は「概念モデル」、「深いモデル」は「分析モデル」を示しているのだろうと思う。

プログラマが「モデルのあるべき姿」をいち早く理解できれば、単純に現状の業務を写しただけの概念モデルではなく、より汎用性の高い分析モデルをあまり苦労せずに作ることもできるだろう。
例えば、「ドメイン駆動設計」の貨物輸送モデルに出てくる船荷証券、利息計算モデルに出てくる発生主義会計（経過勘定科目）について業務知識をプログラマが持っていれば、業務の専門家と議論しているうちに、その存在に気づけるだろう。

パターン指向リファクタリングのワークフローはドメイン駆動設計のアイデアに似ている

Martin Fowler氏によるリファクタリングのワークフローの記事が面白かったのでメモ。

【元ネタ】
Martin Fowler氏によるリファクタリングのワークフロー

TDDには黄金律(Red→Green→Refactoring)というワークフローがある。
つまり、テスト駆動開発とリファクタリングは密接に関連している。

テスト駆動開発・実践編01・黄金の回転 - Strategic Choice

実践テスト駆動開発第1回

テスト駆動開発の概要とメリット ? 実践テスト駆動開発一人読書会(1) ? mizoguche.info

リファクタリングは、反復的な設計手法でもある。
最初から完璧な設計ではなく、動くコードを徐々に洗練させながら、より良いコードへ変えていく。
つまり、進化的設計の手法の中にリファクタリングが組み込まれている。

「パターン指向リファクタリング入門」は、GoFのデザインパターンとファラーのリファクタリングを結びつけた本だ。
アイデアとしては、パターンを、新しい設計の初期段階ではなく、既存の設計を改善するのに用いる。
さらに、パターンを使って設計を改善する時に、コードレベルの設計の変換、つまり、リファクタリングを使う。

(引用開始)
Joshua Kerievsky氏は著書「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法」の中でこう提案した。

継続的にコードの設計を改善していくことで、どんどんそのコードを扱いやすくなる。
これは、ほとんどリファクタリングせず、便宜上新しい機能を追加する際に多大な注意を払う、というようなよくある状況とは雲泥の差だ。
もしあなたに継続的リファクタリングの衛生的習慣が身についたなら、いかに拡張や維持が容易になるかよく分かるだろう。
リファクタリングは今や周知の手法だとFowler氏は述べているが、多くのチームはリファクタリングの際に使用できる様々なワークフローをより良く理解する必要がある、と彼は示唆している。
そうすることで、それぞれの状況に一番合ったものを適応出来るからだ。
(引用終了)

「リファクタリング」によれば、ファウラーは、パターンは目指そうとする所であり、リファクタリングは、どこか別のところからそこへ到達する方法、と言っている。
これは、リファクタリングの結果出てきた構造が実はパターンである、ということを意味していると思う。

この話はドメイン駆動設計の話に似ている。
ドメイン駆動設計において、浅いモデルを洗練させていくと、ある時、ブレイスクルーが起きて、深いモデルに変わる瞬間がある。
すると、深いモデルでは、ドメインエキスパートと開発者はユビキタス言語で会話できるようになる。

つまり、動くけれども汚いコードをリファクタリングしていくうちに、シンプルな構造になり、ブレイクスルーが起きた時、パターンが自然に現れてくることを意味しているのだろう。

パターン指向リファクタリング入門を突き詰めると、下記の3つのワークフローに集約されるらしい。

(1)新しいタスクを始める際に適応する"Preparatory（予備の）リファクタリング"
(2)広範囲において多大な注意を払う必要があるような問題のあるコードが存在する場合に適応する"Planned（計画的）リファクタリング"
(3)複数回の反復を通して大きなモジュールをリプレースする際に適応する"Long-Term（長期の）リファクタリング"

上記の3つのリファクタリングのワークフローは、ドメイン駆動設計の蒸留プロセスの連想させる。
「パターン指向リファクタリング入門」は実際のコードを使って、リファクタリングとデザインパターンを絡めたパターン集になっているが、そのアイデアを突き詰めて抽象化させると、上記3種類のワークフローに収斂させるのだろうと思う。

他にも色々考えてみる。

法規制と業務システムの関係

法規制と業務システムの関係についてラフなメモ書き。

【1】問題意識

業務システムの要件定義では、ユーザから要件をヒヤリングするのが大切ではあるが、それだけでは不十分。
業務システムを縛る法規制の要件も考慮しなければならない。
SEがそんなことまで知らないといけないのがおかしいと感じる時もある。

【2】システム監査、会計監査に関する法規制(特にJ-SOX)において、業務システムが持つべき必須要件は何か。
　特に、内部統制におけるITの観点。

J-SOXのような内部統制の仕組みを業務システムは反映しているか。
例えば、申請承認フローなどの変更管理に改ざんはないか。

会計監査やシステム監査でも同様。
損益計算書や貸借対照表などの会計帳票が悪意を持った改ざんはされていないか。

最近の業務システムは、システム監査や会計監査の要件を知らないと作れない。
システムの妥当性を保証する人がSEではなく、税理士や会計士であるのは、何となくおかしい気がする。
税理士や会計士は、システムの要件定義やシステムの実現性に詳しいのか？

【3】個人情報保護法の観点で、業務システムに必要な法的要件は何か。
　特に、2016年度から施行されるマイナンバー制度、Suica事件で有名になったビッグデータ活用、電子政府とオープンデータなど。

個人情報保護法の観点で、受入テストのテストデータにある顧客名やクレジットカード番号はマスクされているか。

マイナンバー制度は中身がとても複雑で分かりにくい。
マイナンバーを税金対策以外にも、医療履歴や住基カード、年金などと連携して、もっと使いやすい公的サービスを作れないか。

マイナンバー、その「複雑さ」の真相

記者の眼 - マイナンバーで個人情報は漏洩するのか？：ITpro

業務システムに蓄積されたビッグデータから、意味ある情報を抽出して、そのノウハウを売り出すビジネスモデルはあってもいい。
しかし、自分の行動履歴が知らぬ所で販売されているのは気持ち悪いだろう。

Suicaのデータ販売中止騒動、個人特定不可なのになぜ問題？　ビッグデータの難点 | ビジネスジャーナル

気持ち悪い…批判殺到！日立が「Suica履歴」をビッグデータとして活用開始 - NAVER まとめ

でも、クレジットカードを使う人ほど、自分の購買情報を特定の会社に渡して、他の信用機関が参照できるように利用されている。
CICやテラネットという言葉で調べればいくらでも出てくる。

個人情報の開示 CIC・テラネット・CCBはそれぞれ何を調べることができるのでしょ... - Yahoo!知恵袋

信用情報機関と自分の信用情報の確認方法 - ブラックリスト＆信用情報 完全ガイド

現代は、個人情報がいくらでも漏れてしまう危険がいつもついて回る。

【4】パッケージ製品開発で考慮すべき著作権の範囲はどれくらいあるか。
　特に、開発基盤(フレームワーク)と、開発基盤上に他SIがカスタマイズしたアプリ基盤との違い。
　他に、GNUのOSS製品を、自社のパッケージ製品でカスタマイズして販売したい場合、どのように売ると著作権を保持しながら販売できるか。

ベンダーから一括請負契約で発注したシステムを納品してもらい、運用中に、ユーザ企業自身がそのシステムに手を入れてソースを修正してバグが出たら、ベンダーとユーザ企業のどちらが責任を持つのか。

ユーザ企業が、開発基盤であるパッケージ製品をベンダーから購入して、そのパッケージ製品の一つ上のアプリ層をスクラッチで開発した場合、開発基盤のライセンスはベンダー、アプリ層のライセンスはユーザ企業で分けても大丈夫か。

GNUライセンスのオープンソースの製品を自社で販売したい場合、カスタマイズしたソースは全てGNUになってしまい、著作権を保持して販売できないらしい。
だから、ビジネスモデルとしては、OSSの製品を販売するのではなく、OSSの製品の導入支援や、保守サポートで売上を稼ぐビジネスモデルになる。

【5】発注者と元請けと下請けの間に存在する、請負契約・準委任契約・派遣契約の3つにおいて、
最近の傾向はあるか？
例えば、アジャイル開発したいなら、準委任契約ないし、一定期間ごとの請負契約にする、など。

アジャイル開発と請負契約については過去に色々考えた。
僕はまだこの回答を知らない。

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

アジャイルな契約と請負契約の比較: プログラマの思索

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

【6】我々IT技術者は法律の専門家でないのだから、法律の専門家を必要な時に呼んで、彼らの知恵を借りるだけでいいと思っている。
我々の本来の仕事は、顧客があいまいに思っている要望から、あるべき業務像を定義し、業務システムを導入することで、業務に変革をもたらすこと。

でも、最近の日本は、内部統制のように法制度を細かく決めるほど、管理業務が肥大化し、ビジネスのスピードをどんどん落としているように思える。
世界を見渡せば、アジアや欧米のように、どんどんビジネスのスピードを上げている光景と真逆の方向に進んでいるように思える。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン一覧

「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」のパターン名リストが公開されていたのでメモ。
まだ「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」を買っていないけど、読みたくなってきた。

【元ネタ】
「Fearless Change」日本語版パターン名リスト - kawaguti の日記　(id:wayaguchi)

48のパターンのチートシートを作りました。 - kawaguti の日記　(id:wayaguchi)

「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」予約開始 - Yasuo's Notebook

Fearless Changeアジャイルに効く アイデアを組織に広めるための48のパターンを熟読中 - 未来のいつか/hyoshiokの日記

[早版] Agile Japan 2011 ? レポート「Fearless Change ? 不安を乗り越えて組織改革を推進するには」 (美谷 広海) | ManasLink ONLINE

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

2014/02/14 デブサミ2014【14-D-1】Team GeekによるFearless Change #devsumiD - Togetterまとめ

(引用開始)
あなたのアイデアが組織に受け入れられないのは、単に上司が頑固者で物わかりが悪いからではない。優秀なマネージャでも新しいアイデアを試す事には躊躇がある。どんなに論理的な理論を組み立てても、多くの人は感情で物事を判断したりする。
組織には文脈がある。文化がある。それを理解しない事には、組織の中で生きていく事は難しい。
会社のような営利組織であろうが、コミュニティーのような非営利の組織であろうが、その動作原理には共通性がある。
そのような共通性をパターン言語の形式で紹介したのが本書である。
パターンを読む方法論として、先頭からずんずん読んでいくというのがあるが、それだけだと、アタマを右から左へ素通りするだけなので、一工夫してみたい。
例えば、本書を読みながら、自分が試してみたことがある、パターンを列挙してみよう。そして、それを試してみた時の、状況、問題、試してみた結果などを記してみる。一人ワークショップでもいいし、組織の同僚と話をしながら行うのもいい。
同じパターンなのに、ある人はうまく行ったり、別の人はうまく行かなかったりとか、いろいろな発見があるかもしれない。それを議論することによって新たな発見、気づきがあると思う。
例えば、わたしは会社の中でオープンソースソフトウェア(OSS)を普及推進するためにエバンジェリスト(1)として活動している。情熱をもっていろいろな人に働きかける。
あるいは、自ら学んでいく人を増やすために、社内勉強会(25)を開催したり、仲間を見つけるために、ブラウンバック・ミーティング(7)を行う。
まだ全部のパターンを読通していないので、一つ一つ噛み締めるように熟読したい。そして、この本について、同僚や知人たちとお話をしたいと強く思っている。ぜひあなたも読書会に参加して欲しい。そして議論をしよう。
(引用終了)

fearless-change-pub/patterns.csv at master ・ kawaguti/fearless-change-pub

(引用開始)
◆全体に関わるパターン

Evangelist : エバンジェリスト(1)
Small Successes : 小さな成功(2)
Step by Step : ステップバイステップ(3)
Test the Waters : 予備調査(4)
Time for Reflection : ふりかえりの時間(5)

◆序盤の活動に関わるパターン

Ask for Help : 協力を求める(6)
Brown Bag : ブラウンバッグ・ミーティング(7)
Connector : コネクター(8)
Do Food : 何か食べながら(9)
e-Forum : 電子フォーラム(10)
Early Adopter : アーリーアダプター(11)
External Validation : 外部のお墨付き(12)
Group Identity : グループのアイデンティティ(13)
Guru on Your Side : 達人を味方に(14)
In Your Space : 空間を演出する(15)
Innovator : イノベーター(16)
Just Do It : やってみる(17)
Just Say Thanks : 感謝を伝える(18)
Next Steps : 次のアクション(19)
Personal Touch : 個人的な接触(20)
Piggyback : 便乗(21)
Plant the Seeds : 種をまく(22)
The Right Time : 適切な時期(23)
Stay in Touch : 定期的な連絡(24)
Study Group : 勉強会(25)
Tailor Made : テイラーメイド(26)
Big Jolt : 著名人を招く(27)

◆中盤以降の活動に関わるパターン

Corporate Angel : 経営層の支持者(28)
Dedicated Champion : 正式な推進担当者(29)
Early Majority : アーリーマジョリティ(30)
Guru Review : 達人のレビュー(31)
Hometown Story : 体験談の共有(32)
Involve Everyone : みんなを巻き込む(33)
Just Enough : ちょうど十分(34)
Local Sponsor : 身近な支援者(35)
Location, Location, Location : 場所重要(36)
Mentor : メンター(37)
Royal Audience : 謁見(38)
Shoulder to Cry On : 相談できる同志(39)
Smell of Success : 成功の匂い(40)
Sustained Momentum : 勢いの持続(41)
Token : トークン(42)

◆抵抗と付き合うためのパターン

Bridge-Builder : 橋渡し役(43)
Champion Skeptic : 懐疑派代表(44)
Corridor Politics : 根回し(45)
Fear Less : 怖れは無用(46)
Trial Run : お試し期間(47)
Whisper in the General’s Ear : 将軍の耳元でささやく(48)
(引用終了)

僕も、Redmine＋チケット駆動開発を導入推進する役割が多いので、色んな立場の人達から賛成や反発、意外な人達からの声援やひがみを感じてきた。
自分の考えを現場の人達、管理職や経営者に理解してもらい、導入促進するには、プログラミング技術以外の政治能力を必要とする。
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」はその政治能力のヒントを教えてくれる本なのかもしれないと期待している。

また、そういう政治能力のノウハウがパターン形式で書かれているのも良い。
自分が必要なパターンだけ先に読んで、実際に試し、その効果を得ていけばいい。
全てのパターンを実践する必要はないし、現状に合わせて逐次導入していけばいい。

ビットコインと貨幣進化論

ビットコインの取引会社の破綻の新聞記事で、「貨幣進化論」という本の解説があったので、購入してみた。
すごく面白い。
以下、自分の憶測と感想をメモ。

【１】単なる紙切れに過ぎない紙幣になぜ価値があるのか？
ビットコインの話はないけれど、アダム・スミスの国富論から通貨の歴史を分かりやすく説明している。

経済学の今般問題とは「貨幣とは何か」。
単なる紙切れや金属にすぎない貨幣に、何故、それほどの価値があり、人は皆、貨幣に執着するのか？

貨幣が信ずるに足る価値があると思わせるために、どのような工夫や概念装置がいるのか？

【２】「貨幣進化論」の序章に「パンの木の島の物語」というSFチックな話がある。

ある孤島に、人が入植し、パンの木の実を食料として生活していた。
最初は自給自足生活だったが、じきに海辺に転がっている宝貝を貨幣として用いて、色んなモノを交換するようになった。
そして、その貨幣発行を独占し、貨幣の価値を保証する人が王家として出現した。

貨幣経済が発達して、貨幣となる宝貝が不足した時、王家は粘土で作られた宝貝を貨幣として流通させた。
この時、貨幣の貸し出しは色んな都合で、銀行が出現し、銀行がその役割を担った。
さらに、政府は住民の生活を安定させるための各種土木事業などを行うために、国債の発行を行い、財政活動を行い始めた。

しかし、黒船が孤島にやってきて、黒船の船員が持っている金貨を粘土で作られた宝貝の貨幣の代わりに使う、と王家も住民も決めた。

最後に、王家は、１年の猶予期間の中で、粘土で作られた宝貝の貨幣を金貨に置き換える作業をやり遂げた後、王は退位して、普通の住民になった、というお話。

【３】「貨幣進化論」は、イングランド銀行による金本位制のお話、アメリカによる固定相場制と変動相場制の話に続くが、序章の「パンの木の島の物語」で経済学上、重要な概念がいくつか出てくる。
僕はまだ完全理解していないが、あげておく。

【３－１】自然利子率 とは - コトバンク

自然利子率とは、現在のモノと将来のモノを交換する時に現れる利子率。
自然利子率は普通は認識されない。

今の日本はデフレと言われているが、その原因は、自然利子率がゼロないしマイナスだからと推測することもできる。
だから、今の政治家は、故意にインフレを起こして、自然利子率をプラスに持って行こうとしている。
それが本当に良いかどうかは分からない。

自然科学者として考えれば、本来の自然の姿（デフレになる状態）を故意に壊してインフレを起こす状態は、相当無理があるのではないか、と思ったりもする。

【３－２】シニョレッジとは｜金融経済用語集

シニョレッジとは貨幣発行益。
普通は、政府のみがその利益を所有する。

悪い独裁者ならば、その利益を独占したいがために、紙幣をどんどん発行して、インフレを起こすだろう。

【４】国家という信用があるからこそ成り立つ通貨制度に対し、ネット上でピアツーピアのような仕組みで信用を保証するビットコイン。

ビットコインはある意味、金本位制に似ているのではないか。
皆が、ビットコインには国家が発行する紙幣と同じくらいの価値がある、と信じるから、通用する。

国家が発行する紙幣は、いつかはIT技術が前提で、Web上の民主主義の上で成り立つビットコインのような仮想通貨に変わるような気もする。

ビットコインの技術的な細かい話、経済学における位置づけは僕は分からないが、IT技術が人同士のコミュニケーションだけでなく、政治や経済の構造そのものに大きく関わり、政治的影響力を大きく発揮しつつある点が興味深い。

第10回 RxTstudy／第57回 SEA関西プロセス分科会 #RxTStudy #SEAKANSAI

第10回 RxTstudy／第57回 SEA関西プロセス分科会が4/5(土)に開催されます。
私もパネルディスカッションで、@sakaba37さんたちと「チケット駆動開発とメトリクス」の観点でお話します。

【元ネタ】
4月5日 第10回 RxTstudy／第57回 SEA関西プロセス分科会

タイトル：チケット駆動開発とメトリクス

講師

大杉 直樹（株式会社NTTデータ 技術開発本部）
神谷 芳樹（みたに先端研合同会社代表）
主催　：

ソフトウェア技術者協会 関西支部 プロセス分科会
RxTstudy（Redmineやタスク管理を考える勉強会＠大阪）
日時　：2014年4月5日(土) 13:30～17:30 (13:00 開場)

会場　： 株式会社SRA 関西事業部 会議室
　　　　〒541-0058 大阪市中央区南久宝寺町3-1-8
　　　　本町クロスビル2F
内容　：

13:30
軽量開発プロセスにおけるTracを利用したメトリクスの収集とプロジェクト管理
講師：大杉 直樹（ 株式会社NTTデータ 技術開発本部）

　開発要員20名未満の中小規模のエンタープライズシステム開発において、Tracを用いてプロジェクト管理を実施する場合のメトリクスの収集と利用事例を紹介する。
　信頼性の高いメトリクスを収集し、有効に実務利用するためには計測・蓄積ツールとルールの準備、ルール遵守を担保する監視活動が必要であり、無視できない大きさのコストが必要となる。
　一方、多くの中小規模開発ではプロジェクト管理に割ける要員や工数が限られているため、メトリクスの収集と利用に大きなコストを確保し難いという問題がある。
　できるだけ小さいコストでメトリクスを収集・蓄積・利用した事例として、プロジェクトの体制や背景、用いたツールと実施手順、メトリクスの分析結果や利用について紹介することで、同様の課題を抱えるプロジェクトの管理担当者に課題解決に向けた参考情報を提供することがねらいである。

14:40
「チケット＆計測」書籍で訴えたいこと、語り尽くせなかったこと
講師： 神谷 芳樹（みたに先端研合同会社代表）

　筆者は数十年間の職歴においてずっとソフトウェア開発環境の研究・実用化に関わってきた。特にこの10年、奈良先端大やIPA/SECに於いて、進行中のソフトウェア開発プロジェクトの可視化に焦点を合わせた開発管理環境の調査・研究を進めてきた。
　今回その経験を反映して、ここ数年格段の進歩が見られる「ソフトウェア開発管理環境」について、最先端の姿を紹介し、普及の一助にしようと一冊の書籍を出版した。(※)
　今回はそこで訴えたいことのエッセンスと、同時に、語り尽くせなかったことについて述べたい。 焦点をあてた環境は、チケット駆動開発と構成管理システムと自動計測による開発管理データの収集を組み合わせたもので、さらにクラウド環境での実装を推奨している。

※「チケット&計測でITプロジェクト運営の体質改善」オーム社

15:50
パネルディスカッション「チケット駆動開発とメトリクス」

パネリスト：
神谷 芳樹（みたに先端研合同会社代表）
大杉 直樹（株式会社NTTデータ 技術開発本部）
あきぴー（SEA関西 ＆ RxTstudy & XPJUG関西）
（司会：阪井 誠（株式会社SRA））

参加費用：

学生：500円
一般：2,000円
※ 今回は、「会員料金」無しの一律2,000円とさせていただきます。
※ 懇親会参加費は別途実費負担
定員　：40名

オブジェクト指向設計の４つの流派からドメイン駆動設計へ

先日の大阪DDD勉強会に刺激を受けて、「ユースケース駆動開発実践ガイド」と「オブジェクト開発の神髄」と「アジャイルソフトウェア開発の奥義」「実践UML」を読み直している。
ラフなメモ書き。

【元ネタ】
【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper

vol2_20140309 · dddosaka/reading_ddd_report Wiki

【１】個人的には、オブジェクト指向設計という考え方は好き。
データモデリングはDB設計でも業務の設計でも必須だが、データだけではシステムは動かない。プログラムも作る必要があるけれど、DOAにこだわると、なぜかソースの自動生成に走ってしまうように思える。

オブジェクト指向設計は、アジャイル開発と相性がよい。
また、開発チームの構造解析にもオブジェクト指向設計にある責任駆動の考え方をそのまま適用できる。
つまり、プログラミング志向だし、開発プロセスを実装する時にもオブジェクト指向設計の発想を応用できる利点がある。

また、UMLというモデリング記法も個人的には好き。
一つのモデルを静的な側面、動的な側面から複数の観点で表現できるので、モデルを徹底的に分析したい時に使える。
いわゆる４＋１ビュー。

UMLがデータモデリングよりも使いやすいと思う点は、モデルの動的側面を複数のダイアグラムで表現できることだ。
僕は、Redmineのワークフローにソフトウェア開発プロセスを実装する時に、ひとつの業務をastahを使って、アクティビティ図とステートチャート図、シーケンス図を描いている。
すると、誰がどんなタスクをして誰に渡すのか、自分が持っているタスクはどんなステータスなのか、が分かってくる。
そして描きながら、冗長なタスクやステータスを削除したりして、ワークフローを洗練させていく。

一つのモデルを複数の観点で徹底的に分析する時に、UMLは重宝する。

【２】今までオブジェクト指向設計の本はたくさん読んできた。
オブジェクト指向設計には4つの流派があるように思える。

【２－１】クラス図を重視する。

いわゆる「概念モデル」「ドメインモデル」と呼ばれるクラス図。
業務分析レベルの粗いクラス図。
ER図に近い。

「ドメイン駆動設計」では、ドメインを表すクラスが実装可能なクラスと一致するため、ドメインエキスパートと開発者が指すクラスは一致する。
すなわちユビキタス言語になっている。

実装モデルレベルのクラス設計のプラクティスとしては、下記が挙げられている。
「プログラマのためのJava設計ベストプラクティス」「アジャイルソフトウェア開発の奥義」でも紹介されている。

・単一責任の原則(SRP:The Single Responsibility Principle)
・オープン・クローズドの原則(OCP:The Open Closed Principle)
・リスコフの置換原則(LSP:The Liskov Substitution Principle)
・依存関係逆転の原則(DIP:The Dependency Inversion Principle)
・インタフェース分離の原則(ISP:The Interface Segregation Principle)

第２回【IT技術系コラム】オブジェクト指向設計原則－(1)クラス設計に関する原則｜ウェブコラム｜プライマル株式会社

【２－２】ロバストネス図を重視する。

「ユースケース駆動開発実践ガイド」が有名。
ユースケース→ロバストネス図→シーケンス図に詳細化する過程で、要件からプログラムへ変換していく。

ロバストネス図は「ユースケースをオブジェクトの絵として表現したダイアグラム」。
ユースケースという要件分析と、シーケンス図という詳細設計の間のギャップを埋めるダイアグラムがロバストネス図。

UMLを描こう - Vol.5 ICONIXロバストネス図 : アシアルブログ

UMLを描こう - Vol.6 ロバストネス図からシーケンス図を描く : アシアルブログ

ロバストネス図の利点は、手書きで書きやすいこと。
そして、バウンダリがシステムの外部I/Fに対応するように書けるので、システム間連携も表現しやすい。

「ユースケース駆動開発実践ガイド」は、EnterpriseArchitectというモデリングツールと一体化した開発プロセスとして、ICONIXプロセスが紹介されている。

個人的には、ロバストネス図は好き。
ホワイトボードの手書きの図で、画面設計やバッチ設計もロバストネス図で表現できる。
設計者が開発者に、設計の意図を伝える時に使えると思う。

ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記

【２－３】コンポーネント図を重視する。

「オブジェクト開発の神髄」「アジャイルソフトウェア開発の奥義」が有名。
「オブジェクト開発の神髄」では、コンポーネント図はシステムのアーキテクチャを示すダイアグラムになる。

コンポーネント図は、そのコンポーネントのインターフェイスをモデリングしたダイアグラム。
コンポーネント図はアーキテクチャレベルの成果物である。

ここで、コンポーネントは何か？
実際は、DLLやJar、Exeなどのバイナリの部品に相当する。
外部へのI/Fは公開されているが、その中身は隠蔽されている。

コンポーネント設計は、大規模システムにおいて、数多くの共通部品を再利用できるように使い回すためにとても重要。
インターフェイスが公開されることで、中身は空実装でも、インターフェイスを利用する他チームはモックオブジェクトとして代用して、開発を先に進めることができる。

コンポーネント設計のベストプラクティスとしては、「オブジェクト開発の神髄」では「コンポーネントの設計原則」、「アジャイルソフトウェア開発の奥義」では「パッケージ凝縮度に関する原則」「パッケージ結合度に関する原則」として、６つの原則が挙げられている。

・再利用・リリース等価の原則（REP:Reuse-Release Equivalency Principle）
・全再利用の原則（CRP:Common Reuse Principle）
・閉鎖性共通の原則（CCP:Common Closure Principle）

・非循環依存関係の原則（ADP:Acyclic Dependencies Principle）
・安定依存の原則（SDP:Stable Dependencies Principle）
・安定度・抽象度等価の原則（SAP:Stable Absstractions Principle）

随分昔の話だが、Javaプログラムで、複数のJarをキックする時に、クラスパスのJarファイルの順番を入れ替えると正常動作しなくなる時があった。
その原因は、Jarに依存関係があったために、Jarを読み込む順序に依存していたからだ。
つまり、非循環依存関係の原則に反していたのだろうと想像する。

パッケージ設計の原則 - Strategic Choice

オブジェクト指向設計の原則 - パッケージ設計の原則 - brfrn169の日記

第３回【IT技術系コラム】オブジェクト指向設計原則－(2)パッケージ凝縮度に関する原則｜ウェブコラム｜プライマル株式会社

第４回【IT技術系コラム】オブジェクト指向設計原則－(3)パッケージ結合度に関する原則｜ウェブコラム｜プライマル株式会社

【２－４】コラボレーション図（UML2.0ではコミュニケーション図）を重視する。

「実践UML」が有名。
コラボレーション図は、オブジェクト同士の相互作用を表した図。
シーケンス図と同等。

コラボレーション図がオブジェクト指向設計で最も重要なダイアグラムであるという主張の理由は、クラスに責務を割り当て、オブジェクトの協調を設計することが重要であると認識させてくれるから。
つまり、クラス設計で最も重要な責務駆動設計を実践できるから。

駄目なクラス設計の例として、太ったクラス(Fat Class)というアンチパターンがある。
太ったクラスは数多くのメソッドや属性を持ち、他のクラスと関係していて、複雑なソースになっている状況。
普通は、太ったクラスは「メソッドの抽出」「メソッドの移動」「インターフェイスの抽出」「メソッドの引き上げ」「クラスの移動」などでリファクタリングして、スマートなクラスにする。

僕がオブジェクト指向設計に初めて触れた時、RUPを教える先生から「実践UML」が最もオブジェクト指向設計らしい書籍であると教わった記憶がある。
「実践UML」も初版から第３版まで長く出版されたから、愛された書籍だったのだろう。

【３】クラス図、ロバストネス図、コンポーネント図、コミュニケーション図のいずれも、どれがオブジェクト指向設計として正しいわけではないけれど、どの流派にもそれなりの理由があり、その考え方が面白い。

クラス設計のベストプラクティスはC++の頃から有名だった。

コミュニケーション図を使う人は、CRCカードやクラス設計が好きな人には有用だろう。
責務という処理をどのクラスに割り当てるべきか、という責任駆動設計を考える時に使えるから。
ただし、シーケンス図でも代用できる。

パッケージの凝集度・結合度のベストプラクティスは、コンポーネント設計に今でも使える。
今なら、リリース対象のモジュールであるWar、Ear、Jar、Exe、DLLをどんな粒度で、どんなインターフェイスで作るべきか、という指針として使えるだろう。

ロバストネス図は、ユースケースをラフな絵として描く時に使える。
画面設計、バッチ設計で、画面や処理を通じて、オブジェクトがどのように協調されるのか、がラフな絵を通じて分かる。

「ドメイン駆動設計」を読んでいると、過去のオブジェクト指向設計のベストプラクティスを全て踏まえた上で、得られたノウハウをうまく蒸留している気がする。
同じような概念なのに、別の名前を付与して、新たな意味を付与している気がする。
その観点を持ちながら「ドメイン駆動設計」を読み直そうと思う。

プログラマに必要なスキル

プログラマに必要なスキルについて、良い記事があったのでリンクしておく。

【元ネタ】
プログラマが勉強すること - きしだのはてな

上記のBlogで紹介されている本をあげておく。
（自分が参考にするために）

【プログラミングの基礎】

【ソフトウェア工学】
ソフトウェア工学（玉井哲雄）

【ネットワーク知識】

【ハードウェア知識】

【データベース知識】

【数学・論理学の知識】

【統計学】

【アルゴリズム】
アルゴリズムの勉強のしかた - きしだのはてな

「最強最速アルゴリズマー養成講座」最新記事一覧 - ITmedia Keywords

【告知】XP祭り関西2014で「KPTによるプロセス改善～あなたはPDCAを回したことがありますか？」を講演します #xpjugkansai

4/26(土)に開催されるXP祭り関西2014で「KPTによるプロセス改善～あなたはPDCAを回したことがありますか？」を講演します。

【参考】
XP祭り関西2014 - XPJUG関西wiki

XP祭り関西2014 ~やってみよう！XP~ - 日本XPユーザーグループ関西 | Doorkeeper

【内容】
--- * --- * --- * --- * --- * --- * --- * --- * --- * --- * --- * ---

・タイトル　： 「XP祭り関西2014　～やってみよう！XP～」

・開催日時　： 2014年4月26日(土) 10:45～17:00 （受付開始10:00）

・開催場所　： 大阪市鶴見区民センター

・定員　　　： 200名

・参加費　　： 無料です。カンパ(書籍　または　ワンコイン500円)受け付け中。
　 是非よろしくお願いします。
　 ※ 懇親会は有料。

・懇親会　　： お一人様4,500円
　 （素敵な景品が当たるかも！？「大ジャンケン大会」開催！）

--- * --- * --- * --- * --- * --- * --- * --- * --- * --- * --- * ---

■メイン会場　－　定員200名

【オープニングセッション　（タイトル未定）】

　・前川　直也氏
　・西河　誠氏
　・細谷　泰夫氏

昨年出版されました、「わかりやすいアジャイル開発の教科書」の著者のお3名に
ご登壇頂きます。

当日、皆様からのご質問にお答えする時間を設けますので、アンケートに書籍の
内容や、アジャイルに関するご質問、お悩み、課題など、ご記入願います。

【講演１　今日から始めようXP】

　・稲田　信平氏

　　開発の現場でどのようにXPに取り組んだかとこれから始める方、
　　再チャレンジされる方へのメッセージ

【講演２　ビジネスモデル・キャンバス入門】

　・山中　美智子氏

　　翔泳社刊「ビジネスモデル・ジェネレーション」をベースに組織や
　　個人のビジネスモデルを見える化し、共有・分析する「ビジネスモデル
　　・キャンバス」についてお話します。
　　ちょっと毛色の違うセッションですが、ビジネスアイディアを持っている方も、
　　独立を考えている方も、何かを企んでいる方も、そうでない方も、時代の
　　「変化ヲ抱擁」するために。必聴です！

【講演３　XP入門と導入の壁についての話】

　・平田　大作氏

　　ウォーターフォールをダシに、XPがどんな問題をどんな考え方で解決
　　しようとしているか、という見方でもってXPの入門的な話をします。
　　また仕事で導入する際の壁について、これまでの経験からいくつか話を
　　したいと思います。

【講演４　KPTによるプロセス改善～あなたはPDCAを回したことがありますか？】

　・あきぴー氏

　　プログラマから現場のプロジェクトリーダーへ役割が変わった時、チームを
　　スムーズに運営できないタイプの人がいます。
　　第三者から眺めてみると、その原因は、プロジェクトリーダーがチームで
　　プロセス改善を実施した経験が1回もないパターンが多いように見受けられました。
　　本講演では、PDCAによるプロセス改善にKPTというシンプルなフレームワークが
　　大変有効であること、さらに、メンバーの自発的行動を促進する効果とその仕組み
　　についてお話します。

【ライトニング・トークス】（３名）

　*募集中

　*ライトニング・トーク希望者はLT応募ページから応募してください。
　（※先着順とさせて頂きます）

■アジャイル和室

【アジャイル和室】　－　常時開催

　・世界初「アジャイルかるた」開催。
　・皆様からカンパ頂きました書籍の閲覧コーナーを設置します。
　・ピアソンを偲ぶ会
　・UST中継(実施予定）
　　など。
--- * --- * --- * --- * --- * --- * --- * --- * --- * --- * --- * ---

【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」

第30回IT勉強宴会で発表した資料を公開します。

【元ネタ】
第30回 IT勉強宴会ｉｎ新大阪 : ATND

関西ＩＴ勉強宴会のブログです: 第30回IT勉強宴会in新大阪　【 ソフトを他人に作らせる日本、自分で作る米国 】を語ろう

「ソフトを他人に作らせる日本、 自分で作る米国」を読んで: ソフトウェアさかば

最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで from akipii Oga

【1】「ソフトを他人に作らせる日本、自分で作る米国」の著者である谷島さんが来阪されたのを記念に勉強会が開催されました。
数人が本の感想をメインに発表し、谷島さんに感想を述べてもらうという緩い勉強会でした。
いろんな議論がありましたが、詰まる所、「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」というテーマを巡る話だったと思います。

僕は、SIとユーザ企業の両方を経験した立場から、現状の日本のIT企業(SIとユーザ企業の両方)について、話しました。

【2】「日本企業はロールが多すぎる」という問題

【2-1】SIにしても、ユーザ企業にしても、日本企業は役職が多すぎる。
特に、管理職は部長、課長だけでなく、事業部長、PMO、○管理長、主査など色んな肩書きがある。
さらに、○部、△部などたくさんの部署もある。
つまり、組織がフラットではなく、縦長のピラミッド階層になっていて、ロールがすごく多い。

ロールが多すぎる弊害は、特にユーザ企業で顕著。
業務システムを正式受注する前に、ユーザ企業の情報システム部門にヒヤリングしながらまずは要件定義するのが普通だが、誰が最終決定者なのか分からない場合が多い。

@hatsanhatさんは、意思決定の最終責任者はMANで探すとアドバイスされた時があった。
Money(予算)、Authority(仕様)、Needs(要求)を持つ人の略。

実際のヒヤリングで聞いてみると、予算を持つ人は情報システム部門にはおらず、経営企画部の部長が握っていたりする。
あるいは、既存の業務システムの仕様を知っている人は、ユーザ企業のプロパー社員にはおらず、協力会社の社員だったりする。
あるいは、業務システムの要望をあげる人は、情報システム部門ではなく、総務部や経理部、経営企画部の事務の女性や管理職など、たくさんの部署に散らばっていたりする。

その結果、あちこちの人と打合せのアポを取り、実際に愚痴のような要望や課題を聞き取り、その内容をまとめる作業が発生する。
その作業はかなり膨大な工数になってしまう。

【2-2】また、MANのロールが3つに分割しているだけでなく、予算の権限を持つ人が複数人のように、MANの1要素が複数人に対応してしまっている場合もある。
誰が本当の最終責任者であり、決定してくれるのか分からないのだ。
つまり、日本の組織はあまりにも権限が現場に分散してしまっている弊害がある。

そして、最終決定者が1人と判明していても、彼一人では判断できない場合が多い。
例えば、事業部長や取締役は忙しくて、既存の業務システムの仕様やあるべきシステム像の詳細が判らないために、決断できないのだ。
すると、最終決定者の一つ下の管理職が、最終決定者から委託されて、システム提案の中身を最終判断している場合が多い。
つまり、日本企業では、トップは権限はあっても本来の権力を行使しておらず、一つ下の参謀役が好き勝手に動いて決断している場合が多い。
本来の組織のエスカレーションではないし、こういう現象を下克上というのかもしれない。

【2-3】更に最悪な場合は、ユーザ企業における上記のような調整作業を情報システム部門がやるべき役割なのに、その役割を果たす能力がないので、SIやベンダー企業にその調整作業を丸投げしてしまうケースだ。
すると、SIはユーザ企業のコンサルのような立場で、ユーザ企業内部のレポートラインをどのように設計しておくと、自分たちが作ったシステム提案が稟議しやすくなり予算を獲得できるか、という「根回し」に力を注ぐようになる。

つまり、どのルートで誰に承認してもらえると、すぐに合意が取れて、プロジェクトが先に進むか、という根回しばかりに注力するようになってしまう。
こういう作業は日本社会特有の症状なのかもしれない。

個人的には、日本のユーザ企業の情報システム部門はだらしない、と思う。

【2-4】また、日本企業では決定できない会議が多すぎる。
日本企業には、ナントカ委員会という会議がやたらと多い。

すると、利害関係者が多いので、意見を集約しにくいのだ。
だから、プロジェクトマネージャ以上の人達は、1日中打合せに拘束され、しかもそれらの打合せではなかなか結論が出ないという悪循環に陥っている。

だから、司会者であるプロジェクトマネージャは会議のプロセスを事前設計するのが重要になってくる。
事前設計の内容は、どんな話で進めるかというストーリーと、会議の結論である落とし所を作ることだ。
これを「根回し」というのではないか、と最近は思っている。

この時、会議の根回しで重要なスキルは、TOCの「クラウド」(対立解消図)だと思う。
対立する意見が出た場合、その仮定や前提条件を対立解消図で明確にし、その前提条件を崩すことで、新たな提案を導き、Win-Winの関係を導き出す。
ちょうど、TOCの対立解消図から解決を図るのに似ているように思えるのだ。

TOCの思考プロセスの使い道～プロマネの説明責任に応用する: プログラマの思索

【2-5】そんな問題に対し、ロールはIT化で削減できることで解決できると思っている。
組織のプロジェクトマネジメント能力よりも組織内のロールを重視した開発へ: プログラマの思索に書いたように、論理的な業務データを扱うDA(データ管理者)、物理的なDBサーバーの保守担当者(DBA)、Webサーバの保守担当者、フレームワーク設計者、品質管理者のようなロールは、プログラマないしプロジェクトリーダーのロールに集約できる。
IT化によって作業内容が自動化されて作業コストが減った分、わざわざ、そのようなロールに分割して複雑化するほどもない。

また、Scrumは「SW開発は3つのロールで十分」と言い切っている。
スクラムの新しさ: プログラマの思索に書いたが、PO・SM・チームに期待されている役割が明確なので、それ以外のロールは不要であったり、PO・SM・チームに吸収されてしまう。

ロールが少なくなれば、その分、もっと速い開発が可能になる。
無駄なコミュニケーションをなくせるから。

【3】「開発プロセスがIT化されていない」という問題

【3-1】日本では、SIもユーザ企業もExcelによる管理作業が、まだたくさん残っている。
特に、「WF型開発で管理しきれない作業」「WF型開発で管理しきれない内部プロセス」をExcelで管理している場合が多い。

例えば、課題管理や障害管理のように、当初の計画では、課題や障害がどれくらい発生して抑制できるか、を正確に予測するのは正直無理だ。
だから、そのプロセスで発生する成果物の管理が、WBSから漏れて、その作業工数を追跡できなくなる。

あるいは、紙芝居のような画面モック、機能の実現可能性を調査するためのプロトタイプ作成、ビルド環境やテスト環境構築のような「WF型開発で管理しきれない内部プロセス」も、当初の計画で正確に予測するのは難しい。

WF型開発に固執していると、WF型開発で監視しれきない作業やプロセスが漏れてしまい、そこからリスクが顕在化してくる。

このようなWF型開発で管理しきれない作業や内部プロセスをチケット駆動で管理したい時、アダプタブルWFという補完型チケット駆動で対応する場合が多い。

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

【3-2】そんな問題に対し、先日の品川Redmine勉強会で、日経BP編集者の中山さんの講演で「今、ツール革命が起きている」という発言を聞いた。
95年頃はITで追いかけるべき対象は米国にあったが、現代は日本のWeb企業やSNSやゲームなどのネット企業だ。
彼らはツールによる技術革新の成果を利用して、開発プロセスがかなり進化している。
それに比べて、エンタープライズ系のSI、特にユーザ企業がすごく遅れている、と。
まさにそうだと思う。

ツール革命でソフトウェア開発が変わる: プログラマの思索

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

SIやユーザ企業は、日本の製造業の成功体験が強すぎて、プロセスの標準化に注力しがち。
だが、頑張って標準化した技術やプロセスは、外部環境の変化に追いつけず、すぐに陳腐化してしまい、役立たなくなる。
標準化した技術やプロセスに外部環境の変化を取り入れて、標準化を守ろうとすると、そのコストがあまりにも大きすぎ、大量の無駄なドキュメントを作るだけになってしまう。
CMMIやISOに追随する企業は特にそうだろう。

それに対し、最近はツール革命を利用して、プログラマ主体の軽量な開発プロセスが主流になりつつある。
チケット駆動開発、Infrastructure as Code、継続的デリバリー、Social Codingなどのキーワードがそうだ。
いずれも、開発プロセスの自動化ないしコミュニケーションの活性化に注力しており、それによって、新たな効果が生まれている。
今もなお、ツール革命でどこまで可能なのか、試行している最中だと言える。

ただし、PMの観点のツールの機能はまだ弱いと思う。
プロジェクトマネージャになれば、利益を確保できるプロマネが良いプロマネなので、EVM、原価管理、要員管理がとても重要な作業になる。
しかし、それらの作業がまだExcelベースで、過去の経験則で判断している場合が多い。
EVM、原価管理、要員管理についても、PMBOKで既に理論として仕様は提示されているのだから、ツールでIT化できるはずと思っている。

【4】「導入したERPが陳腐化しやすい」という問題

【4-1】最近思うのは、ERPという名の業務システムは5年経つと必ずリプレース作業が発生する。
その理由は様々だ。
パッケージ製品の保守サポート切れ。
サーバーの保守期限切れ。
ミドルウェアのVerUp対応、セキュリティパッチ対応など。

最近はもっと速くなり、せっかく導入したシステムを3年くらいでリプレースする場合がある。
そして、サーバー交換時にミドルウェアも一気にVerUpして、デスマーチ案件が発生するパターンが非常に多い。

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

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

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

普通のプログラマは、新規開発案件よりもリプレースという名の案件の経験が多いのでないだろうか？

【4-2】その場合、設計技法はリバース・エンジニアリングが多い。
つまり、既存システムの要件や仕様をリバースして設計書を書き起こし、その内容からあるべきシステム像を提案して、最新技術を使ったシステムでスクラッチで開発するパターン。

普通は、運用保守していくうちに、設計書も保守されなくなり、設計書が本番システムの仕様と違ってくる。
だから、リバースエンジニアリングという無駄な設計作業が発生する

最近思うのは、新規開発の設計技法よりも、既存システムを理解するための設計技法の方が業務システム開発では重要な気がする。
すると、既存のUMLなどのオブジェクト指向の手法は実はあまり役立たない。
むしろ、DOAの技法を使って、既存の画面や帳票からI/F項目を抽出し、ER図を書き出し、機能とテーブルのCRUD表を作る方が、その後の開発にはるかに役立つ。

つまり、DOAという枯れた技法の方が役立つように思える。

【4-3】また、最近は特に、仕様凍結して開発する手法が取りづらい。
WF型開発の典型定期な開発手法は、要件定義で固めた要件をFix(仕様凍結)し、1年後にリリースするというパターンが多いが、外部環境の変化が速すぎるために、この手法が通用しなくなってきた。

だから、受注直後の見積内容で、要件定義工程は準委任契約で要件を抽出し、設計工程直前に再見積りして、設計以後の工程は請負契約を結ぶというパターンが多い。
つまり、2段構えで見積りするので、純粋なWF型開発よりも見積の精度はよくなる。

あるいは、要件定義で抽出した要件をサブシステム単位に分割して 五月雨式に開発するパターンも多い。
このパターンならば、要件のブレも小さく、リリース時期も早めに行える利点がある。

【4-4】さらに最近つくづく感じるのは、システム提案書が書きにくいことだ。
新しい技術を使ったアーキテクチャ設計が難しい。

例えば、最近のシステム提案では、クラウド、モバイル、データマイニングのキーワードは必須だ。
顧客も日経新聞などで最近のIT事情は知っているので、それらのキーワードがなければ、逆に古臭い提案のように思われる。

しかし、クラウドやモバイルを使ったアーキテクチャ設計は、汎用機の頃や、JavaによるWebシステムの設計ノウハウとは全く違う。
かなり癖があるし、技術も枯れておらず、どの場面で有効なのか、見極めにくい。

すると、プロジェクトマネージャの過去の経験が有効でない場合が多い。
普通のプロジェクトマネージャは40代、50代であり、彼らは汎用機＋Cobolの成功体験に固執しすぎている。
彼らの経験は全く通用しない。
だから、彼らはシステム提案書を書くのにかなり苦労している。
実際は彼らはもはや書くことができず、部下であるプロジェクトリーダーに書かせている場合が多い。

【4-5】いわゆる超上流工程における最近の課題は、ウォーター・スクラム・フォールから脱却できないか？という問題だ。
開発工程がアジャイル開発であっても、肝心の要件定義は従来のWF型開発の延長であり、仕様凍結している。

つまり、仕様凍結した要件の範囲内で、アジャイル開発をしているに過ぎない事例が多い。
「ハイブリッドアジャイル開発」もその事例に相当するだろう。

本来のアジャイル開発では、要件定義も変化を取り入れて、要件を入れ替えたり、不要な要件は削除して除く。
そのような柔軟な要件定義があれば、外部環境の変化に合わせて、ユーザの要求をより速く反映しやすくなる。

だから、超上流工程をアジャイル化するために、アジャイルコミュニティから数多くの手法が試行されている。
リーンソフトウエア開発、リーンスタートアップがそうだし、平鍋さんが最近提唱している「IMPACT MAPPING」もそうだ。
これらはいずれも、要件定義も軽量かつ反復的なプロセスを志向している。

【5】他の方々のお話のほとんどは「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」がテーマだった。
いわく、昔は、欲しいシステムを実現するには、自分たちで作るしかなかった。
内製化しか手段がなかった。

でも、今は、パッケージ製品を買うとか、特注でシステムをSIに発注するとか、SaaSで使う、とか、いろいろな選択肢がある。
内製化は一つの手段に過ぎない。

本来はユーザ企業でも内製化したい。
自分たちの業務システムを作りこむことで、自分たちの業務をスピーディに強化できる。
自分たちの業務システムの技術や運用ノウハウも社外に流出しない。

しかし、自社で内製化しようとするとハードルが高い。
ユーザ企業が若い社員にプログラム開発をさせるが、ある程度育つと設計や運用に回り、プログラム開発しなくなる。
若い社員も、単価の高い設計や管理などに向いてしまう。
プログラム開発の楽しさが伝わらない、など。

皆さんは色々話されていたけど、僕は違う意見を持っている。
おそらく、ユーザ企業に限らず、日本のIT企業はプログラミング技術を軽視している文化があるから、人が育たないのだ。

プログラミングを重視する文化にしたいなら、最終的には、オープンソースへの理解やアジャイル開発の推進に向かうだろうと直感している。
実際、プログラマが生き生きとしている職場では、オープンソースに関わる技術者が多く、彼らはアジャイル開発の好きな人たちが多いはず。

しかし、日本企業は、自社を作業場にした開発は自社のコストだから、オープンソースで公開するのはご法度だろうし、そもそもアジャイル開発のことも知らない。
だから、そんな文化を生み出せない土壌がある。

しかも、汎用機からクラサバ、そしてWeb、さらにモバイルとクラウドへ技術が変遷した今、プログラミング技術から離れた人ほど、新しい技術で設計するのは困難だ。
システム提案書が作りにくいと嘆くPMがまさにそうだ。

アジャイル開発は常識だ: プログラマの思索にも書いたが、ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。

そういう問題意識とソフトウェア開発の特徴を持ち続けることが重要だろう。

【追記】
My Aha! (or maybe sometimes blah) Moments In San Francisco: 『「ソフトを他人に作らせる日本、自分で作る米国」を読んで」』を読んで

L'eclat des jours(2014-03-10)　日本型ソフトウェア開発

エンジニアリングの話と、ビジネスの話を混ぜるとよくわからなくなるよね - おろかな日々

統合執筆環境Scrivenerのリンク

統合執筆環境Scrivenerについてメモ。

【元ネタ】
「書く」ためのツール、選んでいますか？ Mac の文章作成支援ツールの魅力 | シゴタノ！

LAB. & PEACE: Scrivenerがアツい！

R-style ≫ Scrivenerへの散歩道#002 そもそもScrivenerとは何か？

Scrivenerを使って一日で小説を書き上げる仕組み | Lifehacking.jp

文章を推敲するには Scrivener - 感じ通信

(引用開始)
ある程度長い文章を書くのにScrivenerは手放せません。

Scrivenerは単なる原稿エディタではなく、まだどのように何を書けばいいのかわからない段階からアイデアを放り込み、文章を醸成することが可能な思考ツールといってもいい機能を満載しているからです。

たとえば書きかけたアイデアをカードの形にしてコルクボード上で一覧表示したり、とりあえずの章立てや項目を複数の断片として書き散らしておいて、あとで自由自在に並べ替えたりといったことがScrivenerでは簡単にできます。

Scrivenerは脚本や小説を書く人にとっても便利で、たとえば登場人物の誰と誰がどの項目に登場していたかといったタグ付けが可能です。400枚近い小説を書いたことがある人なら、バランスよく登場人物が動き回るのを原稿の分量で調整するのがどれだけ面倒で見当を見失いやすいものか知っていると思います。
(引用終了)

(引用開始)
普通は、ある「作品」が一つの著者の名前とつながっていることが多いのでこうした試みは異常に思えるかもしれませんが、歴史上こうしたことは思った以上に例が多いものです。あのホメロスも、一人の人間の作品なのか、複数なのか、あるいはそれまでの口承文学の総仕上げとしてホメロスが登場したのかといった論争があるのですが、論争にかかわらずあのすばらしいイーリアスは何度読んでも胸が熱くなります。

一人の人間の創造性だけでなく、管理された偶発性を組み込むことは前衛音楽にも見られる手法で、新しい作品を数多く生み出しています。

もうすこしこの考え方を進めると、「もし20人の著者で手分けして本を書いたらどうなるだろう？」「文章を書く人、絵を描く人、全体の流れを統括する人に分けて書くことで、いわゆる『アマチュア』でもプロ並みの作品が作れないか？」という面白い発想がわいてきます。

そもそもこれ、表には見えませんけれども現在の本作りの分業制そのものですよね。

本を書きたいという人はどんどん増えているようですが、出版社や編集者に頼らなくても面白い作品を作るしくみも、もうほとんどそろっています。

こうした仕組みを使ってみて、世界に新しい作品を生み出してみるのはいかがでしょう？
(引用終了)

Scrivenerの画面を見ると、単なるエディタではなく、執筆に必要な資料(PDF、画像など)を放り込んでリンクさせたり、アウトラインプロセッサのように見せたり、アイデアをカードに並べてその順序関係を入れ替えたり、色々できるみたい。
こういう開発環境を使いこなせれば、執筆する分量が多くても、アイデアを膨らませながら、章単位に書きやすくなるかもしれない。

プログラマならば、markdownでテキストファイルに書いて、GitHubで管理して、SphinxないしPandocでWordなりPDFなりEPubに出力する手法のほうが多いかもしれない。
でも、自分が書いた文章の構造をグラフィカルに表示できれば、もっと楽に書けるのではないか。

色んなツールで試してみる。

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

デブサミ2014の発表資料を読んでいて、僕の中では「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」が一番心に残った。
ラフなメモ書き。
以下の発表資料の文章を引用している。

【元ネタ】
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog

Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」 from Yoshimura Soichiro

2014/02/14 デブサミ2014【14-A-6】Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所 #devsumiA - Togetterまとめ

【0】背景

この発表資料は、「Scalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向け」。

ニコニコ動画のPHPソースがレガシー遺産という負債となっていた。
リファクタリングしたものの、抜本的な対策が必要と痛感。
そこで、ニコ生動画を書き直すニコ生2プロジェクトが発足した。

目的は、スケーラビリティ・フォールトトレランス・保守性・パフォーマンスの品質を担保すること。
チームは4人から始まった。

【1】Scala

Scalaの利点は、静的型付けを持ち、保守性も高そう。
そして、関数プログラミングによる並列処理も実装可能。

但し、PHPプログラマからScalaへ移る場合、アルゴリズムとデータ構造、関数型プログラミングの考え方などのサポートが必要。
社内で勉強会を開く、など。

【2】PlayFramework＋ドメイン駆動開発

ドメイン駆動設計で、UI層→アプリケーション層→ドメイン層→インフラ層の4層構造というレイヤードアーキテクチャ。
ユビキタス言語を使ったドメインという業務知識の共有。

コアの蒸留、汎用サブドメインの分離によるモジュール化。

Play2/Scalaはドメイン駆動設計を実践するのにとても良いフレームワーク。

・CoCがきつくなく好き勝手フォルダが掘れる。
・マルチプロジェクト機能でサブモジュールの依存関係を作れ、レイヤー ドアーキテクチャの強制できる。ドメイン層、インフラ層はplayに依存しないただのjar。
・case classがエンティティと値オブジェクトの作成のコストを下げる。例えば、インフラ層ORMのマッピングクラスとドメイン層のエンティティを分けることなどが苦にならない。
・play2を捨てられるように開発することが可能。

僕の感想としては、この部分が一番なるほど、と感じた所。
ドメイン駆動設計では、ドメインが明確になるために、オブジェクト指向設計の長所を適用できる。
更に、ドメイン駆動設計は小規模リリースと相性の良い設計手法なので、新しいフレームワークの基盤の上に機能を少しずつ追加していく時に役立つだろう。

但し、ドメイン駆動設計は敷居が高い。
「リファクタリング」「UMLモデリングの本質」「アナリシスパターン」「エンタープライズ アプリケーションアーキテクチャパターン」の4冊を読んでおかないと、「ドメイン駆動設計」の凄さが分からない。

この点も僕も同感。
振り返ってみれば、僕も、Javaの勉強のために「リファクタリング」、オブジェクト指向設計の勉強のために「UMLモデリングの本質」「アナリシスパターン」、アーキテクチャ設計のために「エンタープライズ アプリケーションアーキテクチャパターン」を読んでいたから、「ドメイン駆動設計」に出てくるたいていのパターン名が何を意味していてどんな背景から生まれたのか、はすぐに分かった。
つまり、ドメイン駆動設計は、先人の設計手法の積み重ねの上にある。

ドメイン駆動設計をいち早く理解するには、下記のYouTube資料が良いらしい。
視聴してみると、確かに「何がドメインであり、何がドメインでないか」はよく分かるのでお勧め。

20110409_DevLOVE「Building Blocks」_都元ダイスケさん - YouTube

また、ScalaのWebフレームワークであるPlayフレームワークを使っている点も上手い。
Struts→Seasar、Spring→Wicket、Playへ発展した経緯を考えると、RailsのようなPlayフレームワークは、今後のJavaプログラマには必須のフレームワークになるだろう。

Javaの常識を変えるPlay framework入門

ScalaのWebアプリケーションフレームワーク「Play Framework」入門　～（1）環境構築とスタートアップアプリの作成 （1/6）：CodeZine

但し、Play2/Scalaの弱点として、下記が挙げられていた。
今後のPlay2/Scalaの改善点になるだろう。

1. sbtが遅すぎる。
　　→proxyを作ったり、良いマシンを使うぐらいしかない
2. Play2のscalaテンプレートが、コンパイル遅く、文法がデザイナー にやさしくない仕様。
　　→Groovyテンプレートで作成。 github/dwangoでフォークしたも のを公開中
3. テストで困るobjectとtraitと関数引数。
　　→specs2のmockitoの制約。objectのモック作れない、traitはmixin が必要、ジェネリクスパラメーターが付いた関数引数のメソッド を拡張できない。

【3】Scrumはリーダーを育てる

「自身のウォーターフォール開発とアジャイル開発のプロジェクトマネージャ経験」として、以下の苦い経験があった。

1. 過去4度のフォーターフォール開発と、大失敗の経験。
　→要求が変更されてしまうと地獄。不確定要素に対応するためのバッファ重要。最後のしわ寄せは品質に。
2. 要件が確定できない、また、要求の優先順位が日々変わる場合、アジャイルとスクラムの考えが良い
　→日々変わるチームの目標への柔軟な対応が必要なWeb開発

「Scrumはリーダーを育てるのにすばらしい手法である」理由は下記の通り。

・会議体が固定
・JIRA/GreenHopperなどのサポートツール
・書籍が充実している
・プランニングポーカーでの見積もりが、スクラムマスターを孤立させない
・全員が全ての帽子をかぶるので段階的にスクラムマスターにさせ ることが可能

この点は、すごく納得した。
開発チームを運営する役割であるプロジェクトリーダーには、アジャイル開発やWF型開発に限らず、最低限3つのスキルが必要だと思っている。

一つ目は、体制図。
つまり、案件に出てくる利害関係者の関係をグラフにまとめたもの。
普通は、プロジェクト立上げ時に真っ先に書くべきもの。パワポやVisioなどで書く。
WF型開発の大規模プロジェクトほど、利害関係者が多くなり、誰がどんな役割で動くべきか、をきちんと定義しないと、無駄なコミュニケーションばかり増えて、プロジェクトが進まなくなる。

Scrumの良い点は、アジャイルなスクラムチームには、プロダクトオーナー・スクラムマスター・チームの3つだけでロールが十分であると定義していること。
更には、「ニワトリとブタ」の話のように、スクラムチームに所属していない利害関係者から開発チームを守る仕組みが提供されていること。
これによって、体制図はとても簡単な構造になり、コミュニケーションを取りやすくなれる。
また、それぞれの役割が明確なので、Scrumのフレームワークに従って行動すればいい。

2つ目は、概要スケジュール。
つまり、タスクの詳細を書いたガントチャートではなく、各工程、各プロセスの前後関係を明確にしたPERT図。
普通は、プロジェクト立上げ時に、マイルストーンを意識しながら、どんな工程が必要かを洗い出し、各工程のInとOutをつなげて書くので、自然にPERT図になる。
この概要スケジュールを元に、概算で見積りし、詳細なスケジュールを落としこんでいく。

Scrumでは、大まかなリリース計画(ロードマップ)をプロダクトオーナーが決めて、それを実現するためにストーリーに分割してバックログへ優先順位ごとに並べる。
開発チームは、バックログのストーリーの順に従って開発していくだけでいい。
また、スプリントごとに出荷してデモするから、利害関係者も定期的にソフトウェアを評価して、ロードマップ通りに進んでいるかをチェックすることもできる。

3つ目は、コミュニケーション計画。
つまり、体制図に書かれた利害関係者といつどこでどんな会議をするのか、という会議体の構成図。
普通は、顧客との月次進捗定例、複数の開発チームリーダー同士の週次の課題管理定例、開発チーム内の毎日の朝会、などがコミュニケーション計画になるだろう。
これらの会議体がスムーズに運営されなければ、プロジェクトの障害や課題がスムーズにエスカレーションされず、納期が遅れたり、品質悪化の原因になる。

しかし、たいていは、会議の運営コストが大きすぎて、プロジェクトリーダーは常に会議の資料の準備に追われたり、1日が打合せだけで終わってしまう時も多い。

Scrumの良い点は、デイリースクラムという毎朝の15分の朝会が会議体として決まっていて、その会議だけで十分であること。
デイリースクラムで進捗を確認できるだけでなく、メンバーが抱える課題を早期に見つけ出すこともできる。
更に、スプリントの最後には、製品評価であるスプリントデモや、スプリントをふりかえるスプリントレビューがフレームワークとして準備されているので、定期的に直近のスプリントを評価し、改善策を考えるきっかけにもなる。
「スクラムマスターはScrumプロセスの守護神」という考え方は、この会議体のスムーズな運営によって支えられているわけだ。

発表資料では、上記以外にも、「スクラムマスターも常にプレーイングマネージャーであれるようにする」「ユーザの要求理解に時間をかける」「企画と相談する時は、重要度ではなく常に要件の優先度で議論する」「インフラチームや他チームとの共同作業は合流バッファを考える」など、プロマネがプロジェクト管理で気を付けるべき点について、たくさんの経験談が含まれていて、とても参考になった。

Stackoverflowの日本版Qiita～知識の共有が自己の知識を成長させる

プログラミング言語やRedmineなどの情報を収集する時、Stackoverflowの日本版Qiitaを最近参考にすることが多い。
ラフなメモ書き。

【元ネタ】
「プログラマーは怠惰であれ」『Qiita』海野弘成氏【連載:Hackers】 - エンジニアtype

ニュース - 「プログラマの役に立つものを提供していきたい」、情報共有サービス「Qiita」の挑戦：ITpro

（2/5）ニュース - 「プログラマの役に立つものを提供していきたい」、情報共有サービス「Qiita」の挑戦　日本人は質問下手？：ITpro

日本のプログラマの50%が利用ーー急成長する技術情報共有サイト「Qiita」とそのビジネスとは - THE BRIDGE

自分が何かクリエイティブなことを考えたとしよう。
自分の考えを一人の中に閉まっていても、何も始まらない。
自分の考えをまとめて、中途半端でもいいから公開しよう。

具体的には、GitHubのプログラムなり、Blogの文章なり、Slideshareのプレゼン資料に公開すればいい。
プログラミングの知識の共有なら、Qiitaを使えばいい。

最初は誰も見ないかもしれない。
誰の役に立つかどうかも分からない。
でも、自分なりの論理を組み立てて自分の考えをまとめる作業には意味がある。
もし、誰かがコメントしてくれたら、その内容を洗練させる元ネタになる。

他人との有意義な議論は、自分の考えを強化し、第三者にも通用できるように流布させることに役立つ。
ヨーロッパで生まれた自然科学の発展は、そのような雰囲気の中で生まれた。
自然科学がここまで発展したのは、その自由な議論の雰囲気にあるのではないか。

現代では、自分の知識を公開して、議論して、補強していくのがとても簡単になった。
GitHubが提唱する「ソーシャルコーディング」は、プログラムのパッチのやり取りをまるでSNSのチャットのやり取りのように感情も込めてやり取りしてくれる。
それによって、誰もがプログラムを我流で自分のアイデアを試したり、実験したり、育てたりすることができる。

Qiitaというプログラミングの知識を共有するサイトはとても面白い。
日本人の特徴をうまく使っているように思える。

（2/5）ニュース - 「プログラマの役に立つものを提供していきたい」、情報共有サービス「Qiita」の挑戦　日本人は質問下手？：ITproを読むと、日本人は自分が知識不足であることを表明するのが恥ずかしいけれど、逆に質問に対して教えることは好き、という傾向があるという仮説から、QiitaというWebサービスを生み出した。

Qiitaが面白い点は、「Qiitaの情報は「時間が経っても質を保ちやすい」という特徴がある」。
例えば、Blogの情報も検索エンジンに引っかかるぐらい有用な情報はあるが、ソフトウェアのバージョンを古かったりして、今では使えない時がある。

しかし、「Qiitaではコメントだけでなく「編集リクエスト」を送ることができる。記事の内容が間違っていたり、最新バージョンに対応していなかったりした場合、修正を要望できるのだ。投稿が共有されていることで、最新の情報にアップデートしようという圧力が働くのである。」
つまり、GithubにおけるPullRequestのように、自分が書いた情報について別の人から更新して欲しいというパッチが送られる時もあるわけだ。

個人的には、GitHub、Slideshare、Blog、Qiitaなど、自分のアイデアを公開したWeb情報を集約してくれる所があればいいなと思う。
一つのポータルからあちこちのサービスにリンクできれば、より便利になる。
さらに、過去の資料やプログラムを読み直すと、また新しいアイデアが生まれる時もある。
そのような相乗効果が、思索ではとても楽しい。

色々考えてみる。