Doneの範囲はチームの能力に比例する

認定スクラムマスタ研修を受けた時に、感銘を受けた考え方の一つに、「Doneの範囲はチームの能力に比例する」という内容がある。
ラフなメモ書き。

【元ネタ】
Doneの定義を共有する「Doneの定義シート」 BIGLOBEエンジニアブログ

メモ帳: スクラム道バーストに参加した感想＆doneの定義の話

【1】チームがタスクやプロダクトのDoneの条件を決めるスプリント計画ミーティングがある。
その時、納品可能(shippable)なモジュールというDoneの条件はどのような内容になるか？
実際にラフにブレーンストーミングしながら書き上げてみたら、以下のようにたくさん出てきた。

プログラムの単体テストが終わった。
システムテスト、受け入れテストが終わった。
バグが無くなった。
負荷テストをやって、性能やスケーラビリティに問題がない。
レビューが終わった。
リリースノートを書く。
モジュールのパッケージングが終わった。
リリース計画や障害復旧の計画を作った。
デプロイ用スクリプトを作った。
ソフトウェア製品の値段を決めた。
ユーザマニュアルを作った。
契約が締結された。

つまり、システムが納品可能とチームが決定するには、たくさんのDoneの条件をクリアする必要がある。
普通のチームならば、最後のDoneの条件まで辿り着かないかもしれない。
全てのDoneの条件を満たさずにリリースしていたならば、リスバーガーの例え話のように、品質不良の商品を顧客へそのまま押し付けていたことになる。

チームが達成可能なDoneの範囲は、チームの開発能力、生産性に比例しているのだ。
例えば、せいぜい受入テストまでがそのチームのDoneの定義になっているならば、それ以外のDoneの条件を満たすだけの能力を持っていないことを意味する。
実際、負荷テストの方法を知らなければ、性能改善やスケーラビリティ向上の計画や作業を見積もることもできないだろう。
そして、製品の値段の付け方やソフトウェアの契約方法を知らなければ、どれだけの作業が必要なのか、も想像することができないだろう。

【2】AgileTourOsaka2012で、藤原さんは、チームのふりかえりでたびたび、Doneの条件に関する議論が出てきたと言っていた。

AgileTourOsaka2012の感想　#agileto2012: プログラマの思索

その発言の文脈では、チームやメンバーの能力が低いために、当初はDoneの条件の範囲がとても小さかったけれども、スプリントを経るごとにメンバーが経験を積んでチームで作業できる範囲が広がったために、Doneの条件の範囲が広がり、Doneの条件を再定義しなくてはならなかったことを意味しているのだろうと思う。

その話から類推すると、ふりかえりでDoneの条件を再定義する議論が生まれたならば、チームが経験を積んでDoneの条件の範囲を広げようとするタイミングであると推測することもできる。
Doneの条件の範囲を広げることで、作業できる範囲を広げるだけでなく、システムの品質をどんどん上げることができるし、プロセスを拡張して生産性が上がってきていることを意味している。

経験的には、最初のスプリントではDoneの範囲は狭いのが普通。
初めてのチーム、初めての技術でプロジェクト運営しているならば、尚更だ。
いわゆる「Doneの拡張」は、スプリント後にチームが経験値を増やすことで、可能になってくるわけだ。

全てのDoneが達成可能になるという意味は「組織（会社）の柔軟性が増している」と同義。
つまり、顧客の変化、市場の変化に対し、組織がDoneの条件の範囲をコントロールすることで状況に対処できることを示している。

【3】逆にDoneの定義をスプリント途中で減らしてもいいのか？
それは駄目だ。
Doneの範囲を減らせば、チームが作業の手抜きをしてもいいと学習してしまう。

未完了の作業、つまりUndone作業が増えると、スケジュールが遅延したり、想定しないリスクが増える。
スケジュールの遅延は、組織の柔軟性を妨害する。
リスクの増加は、作業結果やチーム間のコミュニケーションの透明化（オープン、Transparency）を少なくする。

Undone作業が増えてスプリント内で完了できる見込みがなくなると、次のスプリントへ延期することになる。
すると、定期的に、Undone作業のみを実施するためだけの「Releaseスプリント」という特殊なスプリントを実施せざるを得なくなる。
例えば、最後の結合テストのバグが未解決のまま残ったり、致命的な性能劣化の症状が残ったままになった場合など。

「Releaseスプリント」は、プロダクトオーナーから見れば、何の価値も産まない。
本来ならば、Releaseスプリントの前に完了させておくべき作業がUndone作業として残っているからだ。

だから、Googleの80％ルールのように、チームの作業負荷は故意に80％にしておき、20％の余裕時間で、リファクタリングや更なるテスト追加、性能テストなどを実施して品質向上に努めておく戦略が勧められるのだろう。

【4】チケット駆動開発でよく聞かれる質問として、「チケットの粒度」だけでなく「チケットの完了条件」もよく出てくる。
その理由の一つは、Doneの条件の範囲がチームの経験値やチームの能力の向上によって、変わってくることもあげられるだろう。

Scrumに関しては今後も色々考えてみる。

論文作成の技法part3～論文作成のIT技術

「勝つための論文の書き方」「創造的論文の書き方」「これから論文を書く若者のために」「学術論文の技法」を読んでみて、論文作成の技法をまとめたみた。
ラフなメモ書き。

【6】特に人文科学・社会科学系では、学術論文の特異な特徴があると思う。
それは、脚注の書き方。
「学術論文の技法」や「１勝１００敗！　あるキャリア官僚の転職記」によれば、脚注だけ読んで論文が優れているかどうか判断するときもあるらしい。
例えば、マックス・ウェーバーの「プロテスタンティズムの倫理と資本主義の精神」は、論文よりも注の方が多くて、一つの注が論文1本分の内容を持っているらしい。

「学術論文の技法」によれば、注のタイプには2種類ある。
一つは、補足説明。
例えば、本論とは直接関係しない事象の説明は、注という形式で省略する。
あるは、論証を省略するために注を使うこともあるらしい。
もう一つは、引用元や出典を明確にすること。

注の形式は、「学術論文の技法」によれば、日本独特の種類がある。
縦書きの文章に多いのは、後注。
節の一番最後に、注をまとめる形式。
人文科学や社会科学で多いが、本文と注が離れているので分かりにくい。
後注がよく用いられた理由は、論文を手書きで書いている場合は、注を文中に入れるとレイアウトが崩れてしまったり、どれだけのスペースを確保して良いか事前に分からなかったからだと思う。

傍注は縦書きの文章の左側に注を書く形式。
縦書きではあまり用いられない。
横書きの文章ならば、一ページの下部(フッタ)に配置する脚注と同じ形式。

割注は、縦書きの本文中に()付きで小さい文字で書く形式。
小説で多いが、正直読みづらい。
文章を読むリズムを狂わされる。

頭注は、縦書きの一ページの上部に配置する形式。
国文学の古典などで、本文で分かりにくい箇所を説明する時によく用いられるらしい。

底注は、縦書きの一ページの下部に配置する形式。
高校までの教科書でよく見かけた。

でも、現代では、論文を執筆するためのIT技術が整ったおかげで、随分書きやすくなっている。

そして、論文の独特のスタイルとして、脚注・引用文献・索引が必要だが、それらも自動生成できるツールがある。
LaTexを使えば、引用文献や索引はBibtexで自動生成できるし、脚注などのレイアウトも自動で整形してくれる。
Wordですら、目次や脚注も自動生成してくれる。

いずれも、注は今となっては、Wordで自動整形してくれるので、レイアウトは気にしないで良い。
むしろ、脚注で、本文の補足説明になることに専念すればいい。

【7】論文作成で使えるIT技術

昔は手書きの論文しかなかったから、書き直しがとても大変だったろうと思う。
今なら、TexやWordを使えば、論文の原稿を何度でも推敲しながら書き直せる。
論文執筆は、反復型開発の一種と思って実施できるようになった。
つまり、IT技術をフルに使えば、思考実験しやすい。

アウトラインが重要という点も、アウトライン・プロセッサというエディタの一機能を使えば改善できる。
「論理的に思考する技術―みるみる企画力が高まる「アウトライン発想法」 (PHP文庫)」では、Wordをアウトライン・プロセッサとして使う方法が詳しく書かれている。
サクラエディタや秀丸でも、アウトライン・プロセッサとして使える。

アウトライン解析と秀丸 | Takazudo Clipping*

サクラエディタのアウトライン解析

また、マインドマップでアイデアを発散し、アウトライン・プロセッサでアイデアを収束するやり方も可能。
FreeMindならば、階層化した形式でマインドマップからテキストファイルに出力することもできる。

また、SphinxやREView、Pandocなどの文書作成ツールを使えば、テキストファイルにそのまま書けば、PDFやepubなど、数多くの媒体に出力できる。
PDFにすれば、印刷レイアウトを確認できる。
HTMLにすれば、Webで即公開できる。
epubにすれば、iPhoneなどのスマートフォンに入れて携帯すれば、隙間時間で読み直すことができるので便利。
WordやExcelよりも、テキストの方が色んな媒体に変換できるので好都合だ。

そして、執筆中の論文はバージョン管理ツールで履歴管理し、RedmineやTracでレビューやタスクを管理し、Jenkinsでデイリービルドできるようにすればいいだろう。
バージョン管理に入れれば、執筆中のテキストを紛失する危険がなくなる。
課題管理ツールを使えば、関係者とやり取りした履歴を全て記録でき、後から参照できる。
Jenkinsを使えば、定期的にPDFやepubを配布する仕組みを実現できるので、逐一連絡する必要もない。

書籍執筆で継続的デリバリー: プログラマの思索

論文作成の技法part2～論文作成の観点

「勝つための論文の書き方」「創造的論文の書き方」「これから論文を書く若者のために」を読んでみて、論文作成の技法をまとめたみた。
ラフなメモ書き。

【4】論文作成の観点

論文のアウトラインが重要と言っても、論文が作文と違う観点がある。
「勝つための論文の書き方」「創造的論文の書き方」「これから論文を書く若者のために」を読んでみて、「問題の正当性」「問題解決の着眼点」「方法の妥当性」「方法と結果の再現性」「結論の有用性」の観点があると感じた。

【4-1】問題の正当性

「勝つための論文の書き方」では、序論で問題提起して、読者を驚かすのは良いが、その問いを正当化する根拠を述べるのが必要と言う。
「正当化」とは「justify」という言葉に相当し、己の言動にしかるべき根拠を与え、己の言動が正しいことを保証するという意味。
つまり、何故その問題をやるのか、その問題が本質的かつ核心的である理由を述べて、問題を明確化すること。

この正当化の説明がないと、なぜそんなくだらない論文を書いたのか、研究テーマに意義がない、問題解決しても役立たない、などの批判や評価にさらされる。
問題を正当化できれば、この問題はとても重要な意味を持っていて、解決できたらこんなに役立つんですよ、と言えるようになる。

日本語の「正当化」は、自分が誤っているのに認めず、主張を曲げない屁理屈ばかり言う悪い意味に取られがちだが、「問題の正当化」は序論の問題提起でとても重要な役割を持つ。

【4-2】問題解決の着眼点

問題解決の着眼点とは、問題をどのような観点ないし着眼点で解決するのか、どんな観点で問題を分析していくのか、を提示すること。
著者なりの問題解決の観点に相当する。

着眼点を提示しなければ、問題をどのように解決しているのか、本論を読まないと分からないので、想像しづらく読みにくい。

着眼点のよくある例は、別の分野の手法を当てはめてみることだ。
「勝つための論文の書き方」では、フロイトの精神分析では、無意識の構造を発見するために、フロイトが趣味としていた先史考古学の手法を使ったと言う。

自然科学ならば、例えば、「生物は負のエントロピーを食べて生命を維持している」と主張したシュレディンガーの考えを発展させて、物理の量子力学の手法を生物学へ応用して分子生物学の学問が生まれた。

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

他に、「恐竜はなぜ鳥に進化したのか―絶滅も進化も酸素濃度が決めた」という本では、恐竜が生きた時代の酸素濃度や二酸化炭素濃度の推移に着目して、その問題を解決しようと説明している。

「勝つための論文の書き方」では、レヴィ=ストロースが、未開拓の学問分野に他の既知の学問分野から方法を借用するやり方をブリコラージュ(素人大工仕事)と呼んでいるらしい。
すなわち、問題解決の着眼点は、従来の手法を新しい分野に適用してみるというやり方が論文を書く方法の一つとしてとても多いのだろうと思う。

だが、以上のように、着眼点が優れていれば独創性につながる。
そして、問題解決にとても有用であることも言えるから、問題の正当性にもつながる。

【4-3】方法の妥当性、方法と結果の再現性

方法の妥当性とは、問題を実験ないし調査する上で、その方法が適切であるかどうかを提示すること。
実験方法や調査方法が適切だからこそ、得られたデータは信用できるのであり、信用できるからこそ論文の主張に説得力が出てくる。
問題解決に提示した方法が適切でなければ、論文の主張に根拠がないように思えてくる。

そして、方法の妥当性に関わる観点として、方法と結果の再現性も重要だ。
つまり、誰がやっても同じ方法で同じ結果が得られるという再現性は、自然科学の論文の正当性そのものに当たる。
iPS細胞に関わる論文捏造事件は、この再現性に問題があったとも言える。

方法の妥当性は、特に社会科学やソフトウェア工学においてとても重要な問題を提起する。
「創造的論文の書き方」では、そもそも、社会科学では、人間の集団に対する実験が極めて難しいために、データの収集や再現性に疑問点があり、しかも、多くの社会現象が1回限りの歴史性を持っている特徴から、統計技法のような厳密な数値データを採取して論理を進める手法に疑問を投げかけている。

社会科学の多くの論文が使う手法は、ある集団に対するアンケート調査や経済データを用いることだが、その方法で得られた結果は、どの範囲まで有意義なのか、を示さなければ、論理の飛躍になり、論理的根拠を失う。

例えば、ソフトウェア工学でも、あるSIのA社の少人数チームのWeb開発で得られた知見が、他の組込企業の大人数チームの製品開発へ適用できるとは限らない。
むしろ、異論反論が続出する方が普通だ。

「創造的論文の書き方」では、社会科学の論文に多い仮説検証スタイルでは、「言い過ぎる」ことに問題があると言う。
仮説検証スタイルでは、ある理論に基づいて仮説を作り、その仮説が現実のデータで支持できるか、を検証する。
すると、仮説や理論からこういう説明ができるはずと言った内容が否定される現実のデータは出てこなかった、という結果(Result)が得られると、「理論によって説明できた」「仮説は支持された」と論理の飛躍ができあがる。
その事象は、単に「理論を否定する事実は出なかった」だけであり、他の調査なら別の結果が出たかもしれないし、理論を否定する結果が出てくるかもしれない。

統計技法という精度の高い技法を持つ研究者が問題の前提条件や他のデータの制度を無視して、強引に結論を導くとしたら、その方法の妥当性に疑問符がつく。
「創造的論文の書き方」では、このような論理の飛躍は「過大一般化(オーバー・ジェネラライゼーション)」と呼ばれるらしい。
だから、偉大な社会科学の論文は、幾つかの調査結果と過去の理論から得られた結果を元にして、一つのモデル(理論)を徹底的に批判分析して、モデルを精密にしていく。

日本の巷の論説が役立たないのは、論理の飛躍があったり、方法の妥当性に疑問があったりして、説得力がなく、主張の根拠がないように思えるからだ。

社会科学やソフトウェア工学では、実証主義的な研究方法が適切であるかどうか、は論文の説得力や主張の根拠に大きな影響を与えるのでとても重要なのだ。

【4-4】結論の有用性

調査結果を元に考察し、その結論が学術的意義があるかどうか、を意味する。
例えば、その論文が新しい問題を提起していたり、新しい仮説・理論・手法・概念を提示していれば、今までにない新しい知見をもたらしたとして、とても有用性があるだろう。
特に、新しい概念や新しい理論を提唱できれば、研究結果の独創性があると評価されるだろう。

「創造的論文の書き方」では、良い理論の例として、ケインズの「有効需要」、マルクスの「剰余価値」をあげている。
つまり、論文で提唱された新しい概念が、提起された問題だけでなく、他の問題や社会現象もうまく説明してくれる点があるということ。

ソフトウェア工学でも、信頼度成長曲線という手法が品質管理で新しい知見をもたらしたし、6つの品質特性という概念が品質管理を考察する上でとても重要な役割を持っている。

でも、論文の独創性を出すのはとても難しい。
だが、「創造的論文の書き方」で述べているように、論文で議論した本質を突き詰めると、こういう説明ができるはずだ、という深い洞察につながる示唆が得られる時がある。
その時は、その洞察の適用可能性の問題を脇において、一般化するのではなく、過大概念化(オーバー・コンセプチャリゼーション)を行なってもいいのでは、と言う。
つまり、論理の飛躍を自覚しながら、新しい概念を提唱してもいいのでは、という指摘。

例えば、チケット駆動開発が広く普及した理由の一つは、分かりやすい概念(チケット駆動、No Ticket, No Commit)が開発現場の問題に上手く適用できた点があったのだろうと思っている。
でも、チケット駆動開発が開発現場の全ての問題に適用できるわけではなく、その適用範囲について、皆がケンケンガクガク議論している真っ最中。
むしろ、新しい概念を提示したおかげで、概念を知った読者が刺激されて、適用してみようと試行錯誤している最中と言える。

僕自身の経験からして、新しい言葉や概念を故意に提唱できれば、独創的な結論へ導けるだろうと思っている。

【5】論文を書きやすいタイプ

論文を書きやすいタイプはいると思う。
自分の経験や他人を見たりしてみて思うのは、自分なりの仮説を持っている人、現場でたくさんの疑問を持つ人は、論文のネタをたくさん持っている。

ビジネスの現場で苦労している人ほど、理論通りに現実が動いていないことが分かっている。
経営学の論文を書きたいなら、自分で事業を起こして、どうやったらビジネスで儲かるのか？という問題を自ら実証すればいい。
ソフトウェア工学の論文を書きたいなら、高品質で高効率な開発方法は何だろうか？という問題をいつも持ちながら、プロジェクトを運営してみればいい。

自分の経験という実証例を持っている人は、論文で書きたい問題をすぐに見つけられるし、その問題解決の方法を自分の経験から探し出せる。
後は、あいまいに感じている確信をどれだけ論理的に説明して、新しい言葉や概念までまとめられるか、が問題なだけだ。

逆に言えば、経験値が少ない学生は論文を書きにくいと思う。
そもそも実証したい仮説というネタ、疑問に思う問題に出会っていないからだ。

僕がチケット駆動開発を偶然見つけたのは、CMMI・ウォーターフォール型開発・アジャイル開発・RUPなどを適用して失敗した例をたくさん見てきたからだ。
チケット駆動開発は、僕がやっていた開発現場で見つけた解決方法の一つ。
だから、自分の経験をベースに説明できるので、他人の批判に対して論理的に説明する自信はある。

最近、IT勉強会が日本中であちこち開かれていて、発表者は自分の経験を元に事例を発表されている。
彼らの講演資料のアウトラインを見れば、現状の問題に対し、自分なりに考えた方法で試してみて、こんな結果が出た、という流れが多い。
すると、その講演資料の流れは仮説検証スタイル又はIMRAD形式に近いので、論文の元ネタそのものになっている。
だから、IT勉強会という場で発表する機会が多い人は、自分の体験談をうまくまとめるコツさえ身に付ければ、独創的な論文を書ける可能性があるだろう。

論文作成の技法part1～論文の構造

「勝つための論文の書き方」「創造的論文の書き方」「これから論文を書く若者のために」を読んでみて、論文作成の技法をまとめたみた。
但し、僕は優れた学術論文を書いた経験はないので、想像の部分がある。
ラフなメモ書き。

【元ネタ】
われわれはどのように論文を書いているか（1/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（2/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（3/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（4/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（5/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（6/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（7/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（8/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（9/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（10/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（11/12）: 主体性確立のための「弁証法・認識論」講義

われわれはどのように論文を書いているか（12/12）: 主体性確立のための「弁証法・認識論」講義

【1】論文が必要な理由

論文にも種類がある。
大学卒業に必要な学士論文や修士論文、博士論文などの学術的論文もあれば、特定のテーマに関する経験をまとめた経験論文や特定のテーマで既に知られている知識を紹介するなどの小論文がある。

歴史をたどれば、19世紀のヨーロッパで、それぞれの学問の分野で得た知識を同じ研究仲間でやり取りしあうための技法として論文が生まれたみたい。
だから、論文の書き方には流儀があるようだ。
論文は作文ではない。

論文作成の技術が必要と最近感じているのは、中間管理職やコンサルタントに近い職業では、他人に自分の考えやソリューションを売り込むために必要だから。
あるいは、自分の能力をアピールするために必要だから。
つまり、自分が正しいと考えていることを他人に説明する時に、論理的に正当性があるように説明する必要があるから。

【2】論文は「？」で始まり「！」で終わる

論文の形式は、序論・本論・結論の3部作。
日本語教育で言われる起承転結は、元々、漢詩から生まれた小説の技術であり、論理的な文章を書くのに向いていない。
多分、普通の日本人は論文の書き方をきちんと習っていないのではないだろうか？

「勝つための論文の書き方」では、良い論文は、「？」で始まり「！」で終わる。
つまり、良い問い(クエスチョン)から始まり、それを論理的に回答して、独創的な結論(驚くほど優れた理論)を導くプロセスを書いたもの。
序論が問題を提起する部分、本論が問題に対する解決策を提示し、それを検証する部分、結論がそれまでの結果をまとめて考察し、回答を提示する部分。
だから、論文を書く一番の条件は、良い問題を定める点にある。

「勝つための論文の書き方」では、序論で読者を驚かすような問題の立て方が重要と言う。
例えば、ダーウィンが「種の起源」を書いた時、人間は神が創造したという常識に対して、人間は猿から進化したのではないか、という非常識を対置して問題提起した。
マックス・ウェーバーが「プロテスタンティズムの倫理と資本主義の精神」という名著を書いた時、序論では、資本主義を作ったのは己の利益を追求する欲深い人間ではなく、金銭に対して禁欲的で労働と貯蓄を重んじる真面目な人達(プロテスタント)ではないか、という逆説から問題提起をした。

あるいは、誰もが常識と思っている内容から本質的な問題を導く方法もある。
例えば、カール・マルクスは、ダイヤモンドは何故高価なのか、という誰もが不思議に思わないが、よくよく考えると理由がわからない問題から、「資本論」を書き始めた。

僕が似たような感想を持った本は、ウォルフレン氏の名著「日本 権力構造の謎」。
その本も日本の政治権力の構造や歴史について、これでもかと言わんばかりにたくさんの証拠や著作を引用して、一つのモデルを書き上げようとしていた。

過去の特にヨーロッパ人が書いた論文を読むと、そういう問題提起の仕方、論理の進め方、分析の方法がとても上手いと思う。
似たようなことは広中平祐氏も述べており、彼の著書「学問の発見」の中で、過去500年、欧米で特に自然科学の発展が目覚ましかった理由の一つは、欧米人が東洋人と比べ物にならないぐらい、徹底的に分析する思索に優れていたからだ、と指摘している。
その一節では、欧米人は一つの問題があると、それをいろいろな要素に分けて、あらゆる角度から徹底的に調べあげるのに対し、東洋人は、大きな知恵袋の中に似たような問題をたくさん入れてしまい、その問題に関する議論は宇宙的な議論になってしまって最初の問題がどこにあるのか消え失せてしまう、と説明している。

一つの問題を複数の観点から徹底的に分析して、優れた独創的な理論や概念を導くことが論文の目的。

【3】論文ではアウトラインが命である

論文はその構成(アウトライン)を作る作業が一番重要。
論理的に説明するからには、構成がしっかりしていないと、問題から回答する流れに矛盾が出てくるからだ。

「論文は３段構成の三重構造である」と言われる。
例えば、演繹法、帰納法、弁証法、仮説検証、IMRADなどがある。

演繹法：論理1→具体例1→具体例2
帰納法：事実1→事実2→論理1
弁証法：A→非A→統一
仮説検証：現状→課題→解決策

人文科学や社会科学でよく使われるアウトラインは、弁証法。
ある人が自分の立てた問題に対して、ある回答をしているのだが、その回答が間違っているとする。
すると論文のアウトラインとしては、ある人の回答を提示し、その回答が何故間違っているかを説明し、最後に自分が正しい回答を提示する流れ。

つまり、弁証法はいわゆる「正(テーゼ)」「反(アンチテーゼ)」「合(ジンテーゼ)」という組立てになる。
社会問題や政治問題に関する議論を読むと、たいていはこの構成で、他人の意見に反対して、自分の意見の正当性を示そうとする時によく見られる。

「勝つための論文の書き方」では、弁証法はアリストテレス以来使われている議論の仕方で、フランスの大学入試資格(バカロレア)の論文(ディセルタシオン)試験の準備として、弁証法を徹底的に仕込まれるらしい。
その話では、フランスの高校生は論文の書き方を徹底的に習得させられているわけだ。

フランスの思考表現スタイルと大学入試 | 名古屋大学:フランス語科のHP

フランス語を学ぶ人のために: さらにー2011年度仏バカロレア、ディセルタシオンの問題が公表されました

自然科学や一部の社会科学で使われるアウトラインは、IMRAD形式。
Introduction, (Materials and) Methods, Results And Discussionの略。
つまり、問題提起→実験・調査などの方法→方法の結果→考察と結論という流れ。

IMRAD - Wikipedia

自然科学では、問題を提起し、その問題を解くための方法を選んで実験や調査を行い、実験結果や調査結果を表や図でまとめて、最後に物理法則や新しい概念を提示する流れが多い。
いわゆる実験などの実証的なやり方。
社会科学でも、統計技法を使ってその結果を用いて問題に回答する構成もある。
自然科学系の論文を書くなら、「これから論文を書く若者のために」の本がとても分かりやすくお勧め。

提案型のビジネス文書(提案書、企画書)でコンサルタントがよく使うアウトラインは、仮説検証。
まず、ユーザ企業の現状から、ユーザ企業が抱える課題を列挙し、課題に対して解決策を提示する流れ。
いわゆる、AsIsモデルに対し、ToBeモデルを提示して問題解決を図る方法。

例えば、SIのシステム提案ならば、ユーザ企業の現行システムを説明した後、現行システムが抱える課題を洗い出し、その課題に対して、次期システムではこのように解決されますよ、と提示するだろう。
経営企画部のように、ビジネス戦略を立てる部署にいるならば、このアウトラインで提案書や企画書を作り、RFIを提示する時が多いだろう。

仮説検証スタイルの別名はフェルミ推定。
フェルミ推定とは、「シカゴの(ピアノの)調律師は何人いるか？」という問題が有名だろう。
物理学者フェルミが本来、原子爆弾の威力を机上の仮説から計算した手法なのだが、その発想方法をコンサルタントの一技法にフレームワーク化されたもの。
「地頭力を鍛える 問題解決に活かす「フェルミ推定」」がおそらく最も有名な本だろう。

フェルミ推定 - Wikipedia

論文を書く時はこのようなパターンを知っておくと、その枠組に自分の考えを当てはめれば書けるようになるはず。

RedmineでSubversion リポジトリ表示を高速化する方法

RedmineでSubversion リポジトリ表示を高速化する方法について、丸山さんが回答されていたのでメモ。

【元ネタ】
Subversion リポジトリ表示に時間がかかる - Google グループ

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

バージョン管理システムとの連携 | Redmine.JP

メーリングリストで以下の問題を提起されている。

(引用開始)
実プロジェクトで問題が起きたので、相談させてください。

・環境
　Redmine 1.3.3 / Ruby 1.8.7

・設定
　管理→設定画面のリポジトリタグで「コミットを自動取得する」はOffになっています

・症状
　Subversionのリポジトリを表示させると、時間がかかる
　→270程度のリビジョンを含むリポジトリで、およそ6秒かかる(100 ms程度の誤差で再現性あり、何度開いても状況変わらない)
　→この6秒の間, topコマンドで監視するとsvnコマンドがCPU1コア分を持って行っている

　現在、SubversionのサーバとRedmineのサーバは物理的に別マシン

・なんとかしたい
　Subversionのリポジトリ表示に時間がかからないようにしたい

svnコマンドが動いていることから、「設定」にあるコミットの自動取得Offの設定がうまくいっていないのでは？と思います。
次に調査できそうな場所など、ご教示いただければ幸いです。
(引用終了)

この現象は、既存のSVNリポジトリが例えば1万リビジョン以上もあり新規プロジェクトに登録すると、タイムアウトエラーになってしまう場合でも現れる。
原因と対策は、丸山さんが説明してくれている。

(引用開始)
リポジトリツリーの表示に"svn ls"を、リビジョン一覧の表示に"svn log"を叩いています。
つまり、１つの画面の表示にsvnコマンドを２回叩いています。
おそらくSubversionのパスが"svn://"か"http://"に指定されていると思います。
"file://"に変えるとかなり早くなると思います。
(引用終了)

原因は、Web経由でSVNリビジョン情報をごっそり取得しようとするので、HTTPレスポンスが所定時間内にリターンせず、タイムアウトになるから。
対策としては、Redmineと同じサーバー上にSVNリポジトリを同期しておき、そこから接続するようにする。

SVNならsvnsyncで別サーバーにあるSVNリポジトリとリアルタイムで同期するようにすればいい。
GitやMercurialなら、別サーバーのmasterブランチをクローンした後に定期的にpullすればいい。

SVNの既存リポジトリが大きすぎて、新規プロジェクトへ既存SVNリポジトリに登録するとタイムアウトしてしまう場合は、fetch_changesetsスクリプトをバックグラウンドで実施する方法で解決できると@g_maedaさんから聞いた。

ruby script/runner "Repository.fetch_changesets" -e production

リポジトリ | Redmine.JP

この方法の仕組みは、既存のSVNリポジトリからRedmineのDBへバッチ処理で定期的に取り込む処理になる。
つまり、Jenkinsのような高機能化したビルド管理ツールを使って、定期的にSVNリポジトリと同期するバッチジョブを走らせればいい。

Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索

Redmineとバージョン管理リポジトリの連携機能は、チケット駆動開発の発端となった「No Ticket, No Commit」に由来する運用ルールと密接に関係するため、この機能が使えなくなるとチケット駆動の威力が半減する。
チケットで成果物の変更管理をするだけでなく、トレーサビリティという効果も現れる重要な機能だからだ。

先日のRxtStudyでも、@akahane92さんがRedmineの性能改善に関する発表でも、上記に関連する内容を説明されていた。
もう一度再認識してみる。

情報システム部門のタスク管理~ITS応答性能の調査結果と対策 編~ #RxTstudy #6 #Redmine from Kuniharu AKAHANE

分散バージョン管理ツールにおけるブランチ戦略

分散バージョン管理ツールにおけるブランチ戦略やマージ・リベースの使い方に関するリンクをメモ。

【元ネタ】
(分散)バージョン管理システムの組織化

[Git] 使い分けできていますか？マージ（merge）&リベース（rebase）再入門

SVNでは、プライベートなワークスペースにチェックアウトして、ソースを修正する。
その履歴は例えばEclipseの環境だけでしか保持できない。

GitやMercurialでは、プライベートブランチは全て、masterからクローンされたブランチになる。
作業履歴を残すのも簡単。

すると、それらブランチをmasterへどのタイミングで、どのようにマージしたら良いのか、という問題が出てくる。
上記2つの記事では、ブランチの考え方とマージ方法について、その考え方を書いていてとても参考になる。

以前は複数の製品ラインの開発、つまりソフトウェアプロダクトラインで現れており、ブランチの制御が難しいという問題がずっとあった。
また、運用保守と新規開発の2本のソースを同時並行で修正しなければならない問題もあった。

だが、複数ブランチによる並行開発は、今の時代はとても当たり前。
GitやMercurialでは、開発者の人数分だけブランチがあり、masterにコミットする時は、開発者のプライベートブランチ(もしくはトピックブランチ)から、完成版のパッチだけをマージすることが可能になった。
masterのソースの履歴を常に綺麗に保つために、ブランチの履歴を削除したり統合したりするなど、コミット履歴の改変も可能だからこそ、そのような芸当もできる。

第4回品川Redmine勉強会で丸山さんの発表を聞いていて一番嬉しかった事は、構成管理パターンの参考資料として「パターンによるソフトウェア構成管理」だけでなく「Redmineによるタスクマネジメント実践技法」もあげられていたこと。
チケット駆動開発の面白さは、構成管理パターンとチケット管理の密な連携にあるので、もっとまとめてみたいと思っている。

Redmineのブランチ戦略

アジャイル開発による品質改善の事例

ソフトウェアテストで著名な秋山さんがSQIP分科会で細谷さんの講演をTwitterでログ公開されていたのでリンクしておく。
内容がとても為になると思う。

【元ネタ】
日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」 - Togetter

【1】ここでのアジャイル開発は、Scrumをベースとした開発のようだ。
つまり、要求をプロダクトバックログに一覧化するプロダクトオーナー、プロダクトバックログを元にスプリント単位で開発していくチーム、プロダクトオーナーとチームを側面支援するスクラムマスターの3つの役割がある。

「品質の問題が発生する要因として、『階層構造＋オーバーコミット』がある。オーバーコミットはスコープとコストに矛盾がある状態です。上の階層から実行部隊に矛盾が落ちてくる。この矛盾を上に上げて解消するためのロスがある。」という細谷さんの指摘は鋭い。

プロダクトオーナーが要求をまとめても、納期や工数の観点から、決められた納期までにリリース可能な要求の数には限界がある。
実際の現場ならば、リリース可能な要求の数はとても少ないだろう。
なのに、特に日本人は責任感が強すぎるために、残業や休日出勤してまでも、自分たちが制御できる範囲を超えた要求をコミットしようとしてしまう。
そのしわ寄せが、製品の品質劣化という症状として現れる。

細谷さんの回答としては、「『階層構造＋オーバーコミット』の問題を解消する方法としてスプリントがあるのではないかと考えています。優先順位を立てて、現場が、工数的にできる分だけにスコープを絞り開発をしていく。『甘いんじゃないか』という見方もあるかもしれないが、トータルとして効率が良くなるという考え。」で進めているらしい。
その考え方はとても現実的。

Scrumを実践した場合、リスバーガーのたとえ話のように、本来は顧客が取るべきリスクを開発チームが引き取って、製品自身の品質を劣化させて納品してしまうことはしない。

細谷さんの過去の発表も参考になる。

アジャイル開発でソフトウェアの品質を高める方法 － Publickey

【2】また、「アジャイル開発ではプロセスと型を大事にしています。自分たちが狙った品質を作ることができるプロセスになっているかを常にケアすることが大切です」という細谷さんの指摘もうなずける。

Scrumにおけるチームの自己組織化は、チームのメンバー自身が日々の活動のフィードバックを受けて、自分たちで問題を解決していく。その活動をスクラムマスタが支援する。
プロセスとしては、ペアプロや小規模リリースなどのプラクティスがあるだろう。型としては、自動テストや継続的インテグレーションのような技術があるだろう。
それらを自分たちチームのコンテキストに合わせて、製品の品質を向上させるために使う。

CEGTestという原因結果グラフのツールを使って、デシジョンテーブルを作って、自動テストケースとしてプログラムに取り込む手法を使ったという話も興味深い。
製品の仕様を原因結果グラフで書き表せるだけの技術力があれば、仕様を細かなレベルまで理解できているはずだし、単体テストケースの作成にも役立つだろう。
結果として、プログラムの複雑度が20以下になったという点も興味深い。

ソフトウェアテスト技法ドリルの感想: プログラマの思索

複雑度と単体テストケース数の相関関係: プログラマの思索

【3】アジャイル開発のドキュメンテーションに関しては、「ドキュメントの話題に移ります。ドキュメントについて『いつ』『誰の』役に立つのだろう？ と考えることが重要です。開発のため、テストのため、保守のため？？」と問題提起している。

「実装のため・保守のため・合意形成（契約、投資価値判断）のため、、、そのドキュメントは何のための情報ですか。それをしないとどんな問題が起こりますか。短期的・長期的視点で考える必要があります。」と。

この考え方については以下の記事を読んだ方が早い。

アジャイル開発におけるドキュメンテーションの実際(1) ―― 本当に必要ですか？ そのドキュメント｜Tech Village （テックビレッジ）　／　CQ出版株式会社

【4】「（第三者品質保証組織がアジャイルにどう関与したらよいかという質問に対して）スクラムマスターの支援をするのが良いと思います。どういう計測（実感含む）をして品質の確認をするのかについて相談に乗ってあげてください。」という指摘は納得できる。
QA部隊は、リリース判定の権限も持つので、どうしても開発部隊と衝突しやすい。
むしろ、QA部隊は手を出さず、開発部隊を側面から支援する役割の方がうまくいくのでは、という指摘。

【5】細谷さんの講演では、事前に参加者を4人のグループに分けて質問内容をPostItに書き出してもらい、タスクボードにToDoで貼りつけた後、講演後にPostItの質問が解決されたかどうかをチェックする仕組みで話されたらしい。
「参加者が講義に主体的に取り組む効果と、付箋を元にプレゼンを動的に組み立てることによる満足度向上（後から質問をもらっても手遅れになる）を図る手法らしい。」が目的だそうだが、参加者のフィードバックを早めに受け取れるし、それゆえに参加者の満足度も高まる利点もあるだろう。
そう言えば、AgileTourOsaka2012でも、講演かんばんを使っていたのを思い出す。

アジャイル開発と品質改善は、古くて新しいテーマ。
品質をどうやって担保するか、という問題は、今後も探ってみる。

【告知】SEA関西プロセス分科会のチケット駆動開発の講演をします #kspin

12月1日 第50回 SEA関西プロセス分科会(大阪府)

【第50回　SEA関西プロセス分科会のご案内】

第1部 講演「チケット駆動開発」

講師

阪井誠（株式会社 SRA）（書籍「チケット駆動開発」著者）
あきぴー（XPJUG関西）（書籍「チケット駆動開発」著者）

第2部 年末放談会「ソフトウェアビジネスのパラダイムシフト」

主催　：ソフトウェア技術者協会 関西支部 プロセス分科会
日時　：2012年12月01日(土) 13:30～17:00 (13:00 開場)

会場　： 大阪市立大学文化交流センター
　　　　〒530-0001　大阪市北区梅田1-2-2-600
　　　　大阪駅前第２ビル６階　大セミナー室
　　　　Tel　06-6344-5425　/　Fax　06-6344-5524
　　　　アクセス
内容　：

早いもので、SEA関西プロセス分科会も今回で50回を数えます。
これまで様々なテーマを取り上げて来ましたが、今年はクラウドやソーシャルメディアの本格的な普及、スマートフォンへの主流プラットフォームの移行、アジャイル開発の（第２次？）ブーム、HTML5やNoSQLデータベースに代表される新たなプラットフォーム技術の浸透など、ソフトウェアのビジネス・開発環境の両面に渡る激変が本格的に始まった年ではないかと考えています。
そこで、今年の締めくくりと第50回の区切りの両方を兼ねる意味で、この激変の年を振り返り、来年以降に予想される更なる大波を乗り切っていくためのヒントを考えるためのプログラムを企画しました。
第１部の講演では、今年、2冊目の共著書「チケット駆動開発」を上梓された阪井誠さんとあきぴーさんのお二人に、それぞれの観点からチケット駆動開発を解説していただきます。現場からの改善を推進し、アジャイル開発のプラクティスを統合・推進するための基盤となる「チケット駆動開発」の本質を考えることで、変化に立ち向かう実践知を探ります。
第2部は、SEA関西久々の「放談会」形式で、特に特定の講師・パネラーを据えず、「ソフトウェアビジネスのパラダイムシフト」のテーマで、参加者の皆さんとの自由なディスカッションを行います。この議論を通して、我々ソフトウェア技術者が感じている変化の「大きな波」を乗り切る為の課題を認識し、今後の取り組みに関するアイデア・ヒントを出し合って行きたいと考えます。

プログラム：

13:00　開場

13:30 ～ 14:20　講演１
テーマ：チャレンジ基盤としてのチケット駆動開発
講師　：阪井誠
内容　：

ソフトウェア開発とは、これまでに無かった事を実現することで顧客に価値を提供する仕事です。そのため、プロジェクトによって差はあるものの、ソフトウェア開発には、ビジネス、実装、環境に関する多くのリスクが存在しています。また、技術の進歩によって実現する機能に比べると開発規模がどんどん縮小していることから、あらかじめ問題を明らかにする事は難しく、新しく得られたノウハウもすぐに陳腐化してしまいます。そのような中で常に新しいソフトウェアにチャレンジをするには、足場を固めながら前に進み続ける事ができる様に、英知を結集して経験やノウハウを蓄積する必要があります。
今回の発表では、チャレンジ基盤としてのチケット駆動開発の特徴を説明します。まずチャレンジ基盤の必要性を述べ、次にチケット駆動開発による開発中の新たな発見や作業の履歴を蓄積、遠隔地とのコミュニケーションといった特徴をのべます。そしてチケット駆動開発が経験を生かせる可能性について述べます。
チケット駆動開発は、新しい技術へのチャレンジを続けるための基盤なのです。

14:30 ～ 15:20　講演２
テーマ：チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ
講師　：あきぴー
内容　：

昨今、高機能化したプロジェクト管理ツールをソフトウェア開発のタスク管理に適用して、 チケットを中心に作業する「チケット駆動開発(TiDD)」が、日本の開発現場で静かに広まっています。
しかしながら、日々実践されているTiDDのノウハウは開発現場ごとにバラバラに散らばっていて、TiDD初心者が参考にしづらいように感じます。
本講演では、TiDDの経験知をパターン言語で体系化することで、TiDDを実践する時に頻出する典型的な問題や解決策を整理し、TiDDを開発プロセスとして再定義する試みについてお話します。

15:30 ～ 16:45　放談会（フリーディスカッション）
内容：
今年は本当にいろんなことがあったと思います。
クラウドサービス、ソーシャルメディア、スマートフォン、これらが技術者・開発者の世界だけでなく、一般の人々の生活に浸透し、ソフトウェアの開発の形やビジネスの形を根本から変えそうな（変えてしまった？）様相を呈しています。
いっぽう、ソフトウェア技術者・開発者の世界でも、この変化に伴って、開発プロセス、開発環境、基盤技術などが大きく変化しようとしています。（してしまった？）その中で、それぞれの人が期待・興奮・不安・焦りを感じながら模索しつつ走り続けている状況ではないでしょうか？
このディスカッションでは、参加者の皆さんそれぞれのこうした思いを率直に出し合って、来年以降の更なる変化に立ち向かうためのヒントと勇気を持ち帰ることができれば、と期待しています。

【追記】
「チケット駆動開発」本の出版記念講演としては、今回が最後になります。
第50回という節目のSEA関西プロセス分科会では、阪井さんと共に、日本の開発現場で生まれ、日本のアジャイルコミュニティで育まれた「チケット駆動開発」について、その本質と今後の可能性について語ります。

最後のフリーディスカッションでは、参加者の皆さん全員で、日本の今後の「ソフトウェア開発のあるべき姿」について語れればいいなと思います。

「貢献したい気持ち」を持つ人達をコミュニティに集めて成果を出す仕組み～モチベーション3.0、アート・オブ・コミュニティ

昨日の品川Redmine勉強会に出て、感じたことをラフなメモ書き。
とりとめもないメモ。

【1】品川Redmine勉強会の懇親会で、とある女性から、私はTracにとてもお世話になったので、その感謝の気持ちから、ある勉強会のスタッフとしてお手伝いした、という話を聞いた。
世の中の女性全てが同じタイプではないけど、僕が今まで会ってきた優れた女性は、周囲の皆にも幸せになってほしいという気持ちから行動を起こす人が多いと経験上知っているので、とても共感できた。
そういう気持ちを持つ人達がコミュニティという場に集まっているのかな、と思う。

【2】コミュニティの面白さは、初対面でも、似たような興味をもつ同志(文字通り「志」が同じ人達)としてすぐに仲間になれること。
インターネットが普及したおかげで同志を集めやすくなった、という話を聞いた時もあった。
今まで自分があったことがない人達と議論したり、共同でプログラミングするだけでも、すごく知的刺激になる。
僕もコミュニティを通じて、アジャイルやOOA、テスト技術などを教わった。

またコミュニティでは、社会的地位や年収は全く関係ない。
コミュニティでは、その人が持つ技術力やリーダーシップなど、その人が本来持っている能力や人格が尊重されるし、技術やリーダーシップが抜きん出る人達がコミュニティで影響力を持つ。
その意味では、コミュニティはとても純粋な人間関係を育みやすいように思う。

2004年頃から今まで、たくさんのコミュニティに顔を出してきて思うのは、コミュニティはまさに人中心に動いていること。
コミュニティの中核となるメンバーが一人ないし複数人いて、彼ら彼女らが活発に活動する時はコミュニティも盛んになるが、彼ら彼女らの活動が下火になると、コミュニティの活動頻度も衰えて、関係そのものも希薄になる。

また、コミュニティが安定して維持していくのに重要な要素の一つは、勉強会の場所というホームを確保できるかどうか、という点。
活発に活動しているコミュニティは、マイホーム、マイ球場を持っている。
50人規模の部屋は、日本の個人の家では難しいので、どうしても大学などの公共機関や企業など公的機関を借りる事になりやすい。
交通の便が良く、近くにすぐに懇親会に行ける居酒屋があるような場所は意外に少ないから。

【3】コミュニティを動かすモチベーションとしては、「モチベーション3.0」の本を連想させる。

(引用開始)
コンピューター同様、社会にも人を動かすための基本ソフト(OS)がある。
〈モチベーション1・0〉…生存(サバイバル)を目的としていた人類最初のOS 。
〈モチベーション2・0〉…アメとムチ=信賞必罰に基づく与えられた動機づけによるOS。ルーチンワーク中心の時代には有効だったが、21世紀を迎えて機能不全に陥る。
〈モチベーション3・0〉…自分の内面から湧き出る「やる気!=ドライブ!」に基づくOS。活気ある社会や組織をつくるための新しい「やる気!」の基本形。
(引用終了)

「モチベーション3.0」では、モチベーション2.0に基づいた管理手法がいかに人から創造性をなくしているか、報酬に基づいた行動や目標設定した行動が逆に推奨されない行動を生み出していること、芸術家のようなクリエイターはモチベーション3.0に基いて偉大な作品を生み出しきた、などの事例を沢山載せている。
コミュニティ活動もモチベーション3.0から生まれた行動なのだろうと思う。
社員が創造的な活動に費やすことができる環境を整えた例として、Googleの20％ルールだけでなく、Jiraを販売しているアトラシアンでもFedex dayと呼ばれる日を作っているらしい。

Twitter / akipii: 「モチベーション3.0 持続する「やる気!」をいかに引き出すか」の第4章「自律性」にJiraを販売しているアトラシアンの社風が記載されている。興味深い。 http://www.amazon.co.jp/dp/4062144492/

金銭ではなくクリエイティブな人を惹きつける仕組みの一つとして、自律性(オートノミー)があげられている。
何となくScrumの自己組織化を連想させる。

【4】IT勉強会カレンダーのように日本でも各地でコミュニティが活発に開催されるようになってきた。
すると、コミュニティの運営ノウハウが重要になってきている。

「ボイス　ソーシャルの力で会社を変える」では、「ソーシャル戦略の先にあるもの」として「競争戦略から協創戦略へ」というフレーズがあり、マイクロソフトがコミュニティを育てて、自社の製品販売のマーケティングにも使っている事例が載っている。
例えば、マイクロソフトMVPはマイクロソフトの製品や技術を広める活動をした個人に与える称号であり、コミュニティ活動が製品の普及に大きく影響している事例の一つだろう。

Microsoft Most Valuable Professional - Wikipedia

だから、コミュニティ運営が企業の販売戦略にも大きく影響してきているのがよく分かる。
でも、「ボイス　ソーシャルの力で会社を変える」にも書いているように、自社の製品の宣伝にコミュニティを使うとうまくいかない。
製品を愛する人達が自然に動くような環境を作るのが大事らしい。

【5】「アート・オブ・コミュニティ」は立ち読みでパラパラとしか読んでないけど、コミュニティという場を運営していくノウハウが書かれていた。
コミュニティが社会的な影響力を持つようになると、コミュニティの全般的な作業を管轄する役割を担うコミュニティマネージャが現れてくる。
幸いなことに、コミュニティマネージャの話は、11章: コミュニティマネージャを雇用する ? アート・オブ・コミュニティ v1.0jp documentationで無料で公開されている。

アート・オブ・コミュニティ ? アート・オブ・コミュニティ v1.0jp documentation

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには - Social Change!

yomoyomoの読書記録 - Jono Bacon『アート・オブ・コミュニティ――「貢献したい気持ち」を繋げて成果を導くには』（オライリー・ジャパン）

O'Reilly Japan - アート・オブ・コミュニティ

TwitterやFacebookのようなSNSが社会的影響力を増している現在では、多種多様な人達が集まり成果を生み出すコミュニティという場が重要になってきて、そのコミュニティを円滑に運営する責任や役割を担うコミュニティマネージャという役割が必要になってくるのだろうと思う。
欧米ではオープンソース活動が活発になるにつれて、コミュニティマネージャという役割が生み出されているらしい。

日本ではコミュニティマネージャという役職は見られないが、今後そういう役割を担える人が必要とされてくるかもしれない。

【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine

本日行われた第4回品川Redmine勉強会の発表資料をCCアトリビューションライセンスで公開します。
スタッフの皆さん、参加者の皆さん、お疲れ様でした。

第4回shinagawa.redmine勉強会 : ATND

第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 from akipii Oga

今僕が考えている「チケット駆動開発をパターン言語で表現できるか」という問題に対して、勉強会のお題「チケットの粒度」「チケットの完了条件」について当てはめると、どれだけ本質に迫れるか、考えた結果を話しました。
内容は完成版でないし、解法は一つではないです。
オープンディスカッションの前座として、どれだけ皆の議論を引き出せるか、という観点で話しました。

オープンディスカッションでは7チームで議論してもらった結果、白熱したチームもあれば、違う議題に行ってしまったチームもあったり、面白かったです。
この2つの質問は、チケット駆動開発を実践する時に必ず通過しなければならない問題なので、勉強会で議論できたことは有意義だったと思います。

また、丸山さんのMercurialのお話、岡本さんのGitとScrumのお話、小久保さんのBacklogsプラグインの運用例のお話もありました。
Redmine界隈では著名な人たちばかりなので、今日の講演は盛り沢山だったかな。

岡本さんと丸山さんの話では、MercurialとGitではブランチの概念が全く違うという意味が、今日の勉強会で一番大きな収穫だったと個人的に思います。
チケット駆動開発の面白さの一つは、単なるタスク管理の上手な使い方だけでなく、構成管理の上手な使い方にも言及している所なので、コミュニティでまだまだ議論できる余地があります。

小久保さんの話では、Backlogsプラグインのカスタマイズで、新規ステータスから作業中ステータスへ変更する時に実績工数を入力しなければエラーとか、別のステータスへ遷移する時にコメント入力を強制させたり、却下ステータスへ移動する時は理由なしならエラーとするなど、ワークフローに関する制御が多くありました。
従来型開発では、ワークフローの制御はリーダーの承認や判子を押すなどの作業を入れたり、Excelなどのドキュメントに書き残してメンバーに強制させる手法でしたが、このやり方では、ワークフローの制御ルールをツールの1機能へ吸収してしまうことによって、開発者が意識しなくてもいいという利点があります。

小久保さんが、ツールの機能に実装されていないルールはメンバーに強制しない、と話された内容は、ワークフローの制御という開発プロセスの業務ロジックはチケット管理ツールの1機能になっているので、メンバーは自然に厳格なルールに従って作業できる利点を意味しています。
ソフトウェア開発のベストプラクティスはツールの1機能で実装してしまえばいい、という見本のような例だと思います。

そして、岡本さんがRedmine Git Branch Hookを紹介して下さったように、チケット駆動開発の基本的なプラクティスである「No Ticket, No Commit」をトピックブランチやストーリーブランチへ適用して、チケット単位にブランチを分岐して修正する場合はチケットにリビジョンの履歴をフックスクリプトで自然に残すという「No Tikcket, No Fork」へ発展させる使い方もあります。
つまり、チケット駆動開発はその時代のツールの最新の使い方を取り入れることによって、更に進化できる余地が沢山あります。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索

今後も品川Redmine勉強会というコミュニティの場で、Redmineコミッタとユーザの間で有意義な議論を交換しながら、より良い実践技法を通じて、チケット駆動開発を日本発のソフトウェア開発技法として提唱できたらいいなと思います。

【追記】
丸山さん、岡本さんのスライドはコチラ。

Redmineのブランチ戦略

RedmineとGitとスクラム from Takashi Okamoto

TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine

「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。
チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか？

【参考】
第4回勉強会 - shinagawa.redmine

第4回shinagawa.redmine勉強会 : ATND

チケット駆動開発のアンチパターンの事例: プログラマの思索

チケット駆動開発を上手に運用するためのポイント: プログラマの思索

プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。

チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。
現場リーダーがWBSからチケットへ作業を登録する時、1～2週間のサイズのワークパッケージから、1～3人日程度のタスクまで分割しなければならないが、それができない時が多い。

例えば、タスクの分割が不十分なチケットが登録されて、実際に仕事してみると、当初の見積よりも大幅にオーバーしたりする。
あるいは、作業してみたら、仕様の不明点や設計の考慮漏れが判明したり、顧客へ確認すべき課題が出たりして、チケットを登録した時の状況から変わってしまう時もある。

でも、全ての作業があらかじめ見通せているわけではないから、あいまいなチケットを登録してしまうのは現実としてよくある。

かと言って、チケットが細かすぎると、チケットが乱発されてチームが混乱しやすい。
例えば、本番リリース直後に同一原因の障害を大量に登録してしまう。
あるいは、チケットが大量にあるために、優先度を付ける作業が雑になり、期日やリリースバージョンが未定の「今すぐ」チケットが溢れたりする。
すると、もはやチケットの重みで、開発チームの進捗が鈍くなる。
「チケットがゴミ箱」「チケットが不良在庫」になってしまうのはそんな状況。

【2】「チケットの完了条件」は、チケットの閉じ方に悩んでいる人に多い。

チケットを完了できたと思っても、マネージャがチェックしたり、設計者がレビューしてみたら、テストが不十分だったり、プログラムがコーディングルールに沿っていない、仕様書で説明不足な点がある、などの理由で差し戻しが多発する時がある。
まさに「モンスターチケット」。

また、タスクと課題、障害ではチケットの完了条件はそれぞれ異なる。
例えば、タスクの完了条件はプログラムの単体テストが終わることだが、課題は不明点が解決されるだけでなく課題をタスク化できて初めて完了になる。
つまり、ワークフローによって完了条件は大きく変わる。

かと言って、チケットの完了条件を厳しくすると、作業の途中で発覚した仕様の不明点や技術上の課題が原因で、進捗率が90％のまま停滞してしまう、とか。
「停滞したチケット」というアンチパターンがそんな状況に当てはまる。

【3】チケット駆動開発を推進すると、単なるタスクや障害だけでなく、課題やリスクも登録するようになる。
すると、どうしてもチケットが溢れて、チケットを更新して精査するだけで1日が終わってしまう。
チケット駆動でプロジェクト運営するならば、大量に湧いてくるチケットをいかに取捨選択して捌ききるか、が重要になってくる。

僕は、チケットが大量に登録されるのは良くない状況とは思わない。
むしろ、プロジェクトの現状をありのままに映し出す鏡だと思う。
例えば、デスマーチプロジェクトになれば、解決されるチケット数よりも登録されるチケット数の方が多すぎて、疲労感を感じる時が多いのではないか？
現場のプロジェクトでは、設計上の課題を解決したと思っても、技術上の課題が出たり、仕様の不明点が出たりして、次から次へと問題が出てくるものだ。

つまり、「チケットの粒度」と「チケットの完了条件」は、チケット駆動開発に由来する本質的な問題なのだと思う。

明日の第4回shinagawa.redmine勉強会 : ATNDでは、オープンディスカッションを設けて、参加者全員で「チケットの粒度」と「チケットの完了条件」について、参加者自らの経験と常識を元に、

どんな状況でどんな問題をどのように解決して「上手くいったか」
どんな状況でどんな問題を解決しようとして「失敗した」か

について議論します。
明日の勉強会をとても楽しみにしています。

「チケット駆動開発」の感想を集めてみたpart6

「チケット駆動開発」の感想を見つけたのでメモ。

【1】Twitter / akipii: なるほど RT @ramusara: チケット駆動開発の本、「Redmineによるタスクマネジメント実践技法」への参照が多すぎて読まないと省かれてる部分が分からない。まぁ読みたい本としてメモってるからいつか買うんだろうけど

Twitter / akipii: ありがとうございます RT @ramusara: これまでの開発との比較や、チケット駆動に至るまでの流れを書いてあるので、そういうの知った上でごにょごにょと考える自分にとっては良い本だと思います。「とにかくこういう開発手法取り入れれば良いんや！」っていうのはダメ

【2】チケット駆動開発は「ソフトウェア開発と真剣に向き合う本」 - 勘と経験と読経

(引用開始)
先日発売された書籍「チケット駆動開発」をやっとのことで読み終えた。大変興味深い本だったのだが、仕事の状況などにかまけて通読するのに妙に時間がかかってしまった。ソフトウェア開発のコミュニケーションに関するプラクティスに関する本と捉えていて、いろいろな問題提起が含まれているのがとても面白い本だと思った（逆に、実践的ハウツー本を求めている人には向かないかもしれない）。以下、感想をいくつか。

＜方法論ではなくて一つのプラクティス＞
「チケット駆動開発」はひとつのプラクティスであって方法論ではないと思っている。必要に応じてプロジェクトに取り込めば良い、プラガブルなテクニックのようなものだ。

ウォーターフォール型でもアジャイル型でもハイブリッド型でも良いが、まず前提として「きちんとソフトウェアを開発できる計画・作戦が立てられる」人でないと本書は面白くないと思う。
逆に本書はソフトウェア開発の現場を加速したり向上させたりするものという理解。
一種の「コミュニケーションパターン」×「リーダーシップパターン」なんだろうと思っている(詳細後述)。ただ面白いのはイシュー管理システムを活用して、これらのパターンを現場に半強制してしまうところ。
ただし、ツールの導入は現場を取り巻く環境などにも依存してしまうので普遍的ではない(ツールは時により進化してく)。本書がツール「ありき」で書かれている印象なのはちょっと残念なところもある。
本書を読んでRedmineやTracのようなITS・BTSを導入しちゃうのは多分乱暴だろう。すこし引いて手元の現場の状況をよく観察してみることから始めないとうまくないと思っている。

＜コミュニケーションパターンとしてのチケット駆動開発＞
もともとソフトウェア開発は大量のコミュニケーションで成り立っているようなものだけれども、チケット駆動開発ではこのコミュニケーションを汎用的な「チケット」でマーク付け（タグ付け？）して管理するというのが一つのキモだと思う。ソフトウェア開発以外の世界だと、基本的にコミュニケーションは「流れ去っていく」ものである。議事録であったりメールの履歴としての記録はされるが、これらはあくまで記録であって随時閲覧されるものではない。チケットになって初めて管理できるようになる、というのがポイントなのだと理解している。

元ネタを失念してしまったのだけれども、どこかの企業の社長は部下に指示をする際に二枚複写のメモ帳に書き込みをして、一枚を渡しているそうだ。これも一種のチケット管理のやり方で、局面がフィットしていればうまく回るような気がしている。

＜リーダーシップパターンとしてのチケット駆動開発＞
チケット駆動開発を実際にやると「計画」から距離を置けるようになるというのも良い点だ（別にアジャイルを擁護するつもりはないのだけれども）。チケット駆動を回すと「権威付けされたトップダウンのリーダーシップ」は自動的に抑止されるような気がする。

・指示出し・タスク出しの間にチケット管理システムが入るので、トップダウンの性格が緩和される
・作業完了報告もリーダー宛というよりは、チケット管理システムが相手先になる
・指示出し・タスク出しそのものがトップダウンからボトムアップに切り替わる
・リーダーシップは「皆に指示出しをする」というより「全体が回るように支援する」傾向が強くなる

うまく整理がついていないけれども、このあたりの変化がチケット駆動開発の面白みなのかもしれないと思っている。
(引用終了)

【3】チケット駆動開発の本を読み返した。

(引用開始)
2月くらいからredmineを使い始めて、中規模なサイトを2,3個作って、チケットの粒度とか運用サイクルとかリズム（トヨタ生産方式でいうタクトに近いかな）なんかについて色々とわかってきたので改めて読んでみた。

最初は複数人で使うつもりで啓蒙してみたりしたんだけど、予想通り難しかったので、他人にふった仕事もIssueとして全て自分で管理したら、うまくまわった。4.２節の権限ポリシーをワークフロー型に振って、他人に仕事をアサインするっていうタスクをチケットとして切ったことになるのかな。

他人への仕事のアサインを不確実性のあるタスクとして登録して、タイムアウトしたら自分に再アサインするというやり方にしたわけだけど、これで淡々とこなせるようになったし、さらにイライラしなくなって精神的にも都合が良かった。

ついでにチケットも会議と紐付けるようにしたので、会議を定期的にやれば、プロダクトの開発サイクルもそれにつられてタイミングが揃うようになったし、会議の議題とかチケットの粒度も次の会議までの期間でできそうな(3週間くらい)に揃えやすくなった。

変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅です
これはそうだよなとしみじみと思った。というわけで、これ(チケット駆動開発)も読む予定
(引用終了)

【4】「curiosity driven works」「好奇心駆動仕事」でいこう：坂本史郎の【朝メール】より：ITmedia オルタナティブ・ブログ

(引用開始)
技術者Ａ) 単体テストを作成してから本体の開発に取り掛かる、
テスト駆動開発は大変よいものだと思います。
継続して布教していこうと思います。

私) ⇒「テスト駆動開発」という言葉があるのですか。Wikiでみたら
『近年はビヘイビア駆動開発へと発展を遂げている。』だそうです。
なぜ「駆動」という言葉を使っているのだろうか。
drivenの直訳としてはちょっといただけない。

技術者Ａ) Hoge driven development はすべからくHoge駆動開発と訳されています。
何か違和感がありますか？

私) ⇒違和感ありますね。drivenというのは、「意識して」とか「中核の」
というような意味合いで使われていると思うのです。定着してしまって
いるのであれば、最初に訳したケースが残念だったということか。

技術者Ｂ） →ちょうどＴさんから貸して頂いた『チケット駆動開発』という本の中で、
　「なぜ「チケット駆動開発」と呼ぶか?」という節があります。
　そこで示された理由は
　　　「チケットがプロジェクトをテンポよく推進してくれる」
　ということでした。
　この話のスタートである「テスト駆動開発」も、
　　　「テストがプログラミングをテンポよく推進してくれる」
　ような仕掛けになっています。
　この「テンポよく推進」を言い表す日本語として「駆動」を充てるのは、
　あながち外れてはいないと私は思います。
(引用終了)

【6】ソフトウェア開発プロセスを環境にする - 勘と経験と読経

(引用開始)
＜ルールとしてのソフトウェア開発プロセスの必要性＞
ソフトウェア開発プロセスは皆が守るべきルールのようなもので、ルールである以上みんながそれに従わなければいけない。CMMIなどでは遵守状況のモニタリングと継続的な改善を行う必要がある。この考え方の前提は「ルールを守らなくてもソフトウェアを作ることができる」ということなのだと思う。

ソフトウェアには物理的制約がほとんど無いので、絶対に守らなければならないルールというものは無い。例えばビルなどの建築物であれば当然のことながら土台の基礎工事をした後に、下部構造から構築しなければいけない。しかし、ソフトウェアにはこのような制約は無い(どんな方法でも構築できる)。

しかし、自由なやり方では大失敗してしまうことがある。そして、成功した場合より失敗した場合のダメージが大きいのがソフトウェア開発である。ソフトウェアでは無制限に失敗することが出来るからである(その反面、一般的には成功は有限)。

だからベストプラクティスを探してルールを作るのだけれども、それを守るというのがまた難しい。

＜ルールを環境にする＞
いまチケット駆動開発を読んでいる(未了)。
(中略)
チケット駆動開発のルールはシンプルで、『チケット無しのコミットは禁止(No Ticket, No Commit!)』というものである。この手法が良いのは、これ以外のルールをRedmineなどのイシュー管理システム(ITS/BTS)とバージョン管理システム(VCS)にまかせて環境化し、隠してしまっていることだと思う。

実際には、No Ticket, No Commit!以外のルールも存在するのだけれども、そのコントロールはITS側にまかされている(記録やワークフローなど)。
実際に存在する多数のルールをメンバーが意識する必要は無い。一つのルールを守るためにITSを使っていれば自然に所定のプロセスで作業をするようになる。
もちろんツールに頼ってしまうことによって、「開発者が考えなくなる」という問題はある。
(中略)
もちろん技術者教育は重要なのだけれども、なんでも教育の問題にするのは違っているのではないだろうか。

別にチケット駆動開発だけを持ち上げるつもりはないけれども、「考えなくても自然とルールが守れる環境をつくる」ということもセットで考えるべきではないかと思う。
(引用終了)

皆さんの感想を読みながら、更に「チケット駆動開発」について色々考えている。

astahの品質スイートプラグインとSVNプラグインが凄い

astahの品質スイートプラグインとSVNプラグインを使ってみたのでメモ。
モデルの使い道がとても広がる素晴らしいプラグインだと思う。

【1】Subversionプラグイン

SVNの配下にあるastahで書かれたモデルの差分やマージを行なってくれる。
モデルをソース差分のように、違いがはっきり分かるので、試行錯誤しながらモデルを洗練させていくのに良い。
astahのようなツールを使っていると、プログラミングだけでなくモデリングもアジャイル開発のように、少しずつコミットしては、その更新履歴を育てながら、完成させていくものだということが実感できる。

【2】品質スイートプラグイン

astahで状態遷移図を書くと、状態遷移表や状態遷移パスを出力してくれる。
以下に説明がある。

状態遷移表プラグインを使って、電話のステートマシン図を作成・改善する ? astah-QualitySuite 1.2 documentation

ステートマシン図を元に状態遷移パスを表示し、テストケースを作成する ? astah-QualitySuite 1.2 documentation

品質スイートプラグインの使い道としては、状態遷移図を書いた後、状態遷移パスを出力して、テストケースの元ネタを出力できること。
例えば、遷移回数＝３を設定すれば、3回遷移する状態のパスを全て出力してくれるので、テストケースの網羅性を高めるのにも役立つだろう。

astahはUMLだけでなく、ER図も描くことができる。
更に、ER図を作れば、テーブル定義書をExcel出力する機能もある。
つまり、astahでER図を書いてSVNで履歴管理すれば、Excelのテーブル定義書の最新版ををいつでも取得できる。

他にも、OracleやMySQLなどのRDBのスキーマをリバースしてくれるDBリバースプラグインや、FreeMindで書いたマインドマップを取り込むFreeMind map インポートプラグインがある。
astahのプラグインは少ないけれども、モデルからRailsソースを生成するとか、モデルからテストケースの元ネタを出力するとか、モデルから要件とのトレーサビリティを確保したテストケースを出力するとか、いろんなアイデアがあるはず。

astahを色々使ってみる。

業務ロジックをデータモデリングはどこまで表現できるか？

「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。

業務システムでは、データが命。
データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。
すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。

顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。
でも、DOAの方が現代は重要性を増していると考えている。
例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。

日本におけるデータモデリングの歴史は意外に古い。
TH法、T字型ER、渡辺さんのXEAD Modelerのように、たくさんの流派がある。
にも関わらず、日本の現場ではデータモデリングの技術が蓄積されていない。

「業務ロジックの制約をデータモデリングはどこまで表現できるか？」の疑問について関西IT勉強会の人たちと議論してみて、この問題はきちんと整理すべきだと考えている。
日本に流布されているDOA本は正規化の説明しかない詰まらない本ばかりで、テーブルのリレーションシップや項目の関数従属性でどこまで業務ロジックを表現できるのか、その技術とそれを適用した結果についてきちんとまとめられていない。
渡辺さんの本が唯一「DOAのアナリシスパターン」に近いと思うけれど、業務システムに仕様変更が入ったらどのように変化して進化していくべきか、を具体例と理論の両方から体系化された説明が不足していると思う。

データモデリングの技術については以下の技法があると考えている。
内容を整理していきたいと思っている。

【1】自然キー、人工キー、代理キー、代替キー、候補キー、2次識別子

候補キーと2次識別子に関する概念: プログラマの思索

データモデル表記読み替えハンドブック: プログラマの思索

DOAはOOA以前に表記法の問題点がある: プログラマの思索

主キー以外にも、キーにはいろんな種類があり、それぞれの意味を持つ。

【2】正規化と情報無損失分解

モデリング再復習DOA編part1～情報無損失分解と結合の罠: プログラマの思索

正規化したテーブルを結合して復元する時、情報が損失されてはいけないという制約が情報無損失分解になる。
複数の候補キーがあるテーブルの場合、正規化する時に情報無損失分解になるように注意が必要。

【3】2次識別子とボイスコッド正規化

2次識別子を使ったデータモデリング: プログラマの思索

渡辺さんの本がとても詳しい。
候補キーが2個以上現れる場合、必ずボイスコッド正規化せざるを得ず、その場合、unique制約(一意制約)で実装するのが一つの解決法になる。

【4】外部キーと複合キー

2つのエンティティでビジネスルール(業務の制約条件)が発生する場合、外部キーによるリレーションシップが発生する。

実践的データモデリング入門の感想: プログラマの思索

連関エンティティと関連クラス: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

業務ルールをどのように外部キーとして張ればいいのか、という問題に対しては、T字形ERが鮮やかに解決している。

自分流モデリング探しの旅(2)～T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

(前略)
* resourceとresourceをつなぐ場合：対照表を生成する。対照表はeventである。
　（例）従業員と営業所
　　　　　従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合：event側に参照キーを持たせる。
　（例）顧客と注文
　　　　　注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「１：１」「１：ｍ」：時系列の遅い方に持たせる。
　（例）受注と請求（一つの受注に対し請求は一つ）
　　　　　請求に受注番号を持たせる。
** 「ｍ：１」「ｍ：ｍ」：対応表を生成する。
　（例）受注と請求（複数の受注に対し請求は一つ）
　　　　　受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

この方法が全ての場面で適用できるわけではないが、当てはまる場合が多いので参考にすべき。

【5】派生関係

データモデリングでもOOAと同様に継承関係つまり派生関係という概念はある。
例えば、製品の品目、仕入先と取引先、など。
但し、ER図で派生関係が出る場合、モデルの実装はとても難易度が高いので要注意。

データベース設計で派生関係は難しい: プログラマの思索

【6】暗黙的なリレーションシップ、又は、継承属性、又は、動的参照関係

正規化したテーブルに対して、外部キーとなる項目がないが、複数のテーブルを結合したビューでは参照制約が存在する時、普通は「暗黙的なリレーションシップ」があると呼ぶ。
渡辺さんの本では「継承属性」、渡辺さんのBlogでは「動的参照関係」と呼ばれている。

正規化されたER図を単純に見るだけでは「暗黙的なリレーションシップ」が存在することを見つけ出すのは難しいと思う。
「暗黙的なリレーションシップ」をRDBMSで実装することは現在はできず、アプリケーションのロジック層で実現するしか今の所はない。

Twitter / akipii: 「動的参照に伴う制約はビューに対する外部キー制約である」。いわゆる継承属性又は暗黙的なリレーションシップの明確な説明だと思う。ようやく分かった気がする。　Hot Heart, Cool Mind. 渡辺幸三氏の「動的参照関係」について http://blogs.dion.ne.jp/keis/archives/10547207.html …

Twitter / akipii: 動的参照関係のようなルールを実現するには、プログラムでアドホックに書くやり方は簡単だが検証が難しい。本来はDOAのモデル上で全ての制約を表現したい、という方向性はうなずけるものがある。

渡辺幸三氏の「動的参照関係」について: Hot Heart, Cool Mind.

「動的参照関係」を手なづける: 設計者の発言

【7】テーブルの再帰構造

アルゴリズムの再帰構造と同様に、テーブルでも再帰構造は出てくる。
例えば、生産管理の品目、組織構造、会計の科目など。
でも、無限ループにならないような制約をプログラムで実装する必要があったり、検索の性能が悪くなるので使い勝手が悪い。
結局、正規化を崩したテーブル設計になりやすい。

だが、階層構造は入れ子集合を使うと、ツリー構造をRDBに綺麗にマッピングできるらしい。
Redmineのチケットテーブルでは、issues.lft, rgtは入れ子集合でツリー構造を表現した時、2次元の円の両端の座標を表している。
すると、チケットBの親がチケットAである場合、チケットA.lft＜チケットB.lft＜チケットB.rgt＜チケットA.rgtという関係が成り立つので、このルールを使ってガントチャートを階層化して表示しているわけだ。

Redmineチケットの階層化の実装方法: プログラマの思索

このテクニックを解説している本は「達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ」だけに書かれている。

自分で理解した内容はBlogで今後まとめていく。

Gitの差分比較が重要な理由

Diffが重要な理由について良い記事が書かれていたのでメモ。

【元ネタ】
テキストでないファイルのdiff（差分）をとる方法 - ザリガニが見ていた...。

(引用開始)
一旦diffの恩恵を経験すると、差分をとれない環境というのがとても不安に思えてくる。あの、MacBook ProのRetinaモデルのデスクトップピクチャに採用された写真家のKent Shiraishi氏も、常時モニタを２台並べて写真の色合いのチェックをしているそうである。曰く、自分の感覚なんて当てにならない、正確な色を再現するためには完璧にデジタル調整されたモニタを並べて、その違いを感じて現像するそうである。つまり、色の差分を見ているのだ！差分を知ることはとても大切。写真でも、テキストでも。
(引用終了)

プログラム、テキスト、WordやExcelのドキュメント、そして写真すらも差分比較するのは重要という指摘。
テキストの差分比較は簡単だしプログラマならよく行なっている。
だが、バイナリファイルの比較も重要なのだ。

「入門Git」の14章ファイルアトリビュートの部分では、Gitによるバイナリファイル比較の方法が書かれている。
例えば、P.248「バイナリファイルの比較」では、JPG画像の比較方法で、拡張子がJPGならば、EXIF情報で差分比較する設定方法について書かれている。
つまり、バイナリファイルそのものを比較するのではなく、バイナリファイルのメタ情報を比較するという手法もあり、Gitならバイナリのメタ情報の比較も簡単に行える点を指摘している。

(引用開始)
そのような感動的に素晴らしい情報が書籍「入門Git」には さらり と書いてある。あまりにも さらり と書いてあるので、なかなか気付けなかった...。実は、何度も読み直している中でようやく気付いたのだ。この辺りの話題は14章ファイルアトリビュートの中で、数ある便利な一つの機能（P248バイナリファイルの比較）として紹介されている。その他にもファイルアトリビュート＋何らかの設定により、素晴らしく便利な機能を手に入れることができるのだ。*1
(引用終了)

「入門Git」のAmazon書評は意外に低いが、その理由は多分、読者が自分の目的に合致している部分だけを読んでいるに過ぎず、きちんと読んでいないだけだろうと思う。
上記のBlog作者も似たような事が書かれている。

(引用開始)
*1：入門Gitは、読み直す度に新たな発見がある。
たぶん、すべての機能の解説が平等に網羅されているのだと思う。
そのため、Gitをある程度知らないと読みにくいのだが、Gitをさらに便利に使いたいと思ったときには、そこには問題解決のヒントがたくさんあるのだ。
タイトルが入門となっているが、これはGitの原典なのである。
(引用終了)

AgileTourOsaka2012の感想 #agileto2012

箕面で開かれたAgileTourOsaka2012に行ってきた。
感想をラフなメモ書き。

Agile Tour Osaka (Japan) | agiletour.org

11月3日 AgileTourOsaka2012 in Minoh　箕面の滝からこんにちは(大阪府)

[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～: ソフトウェアさかば

アジャイルツアー大阪 from Tsuyoshi Ushio

会場の8階の廊下から、箕面温泉や箕面の滝へ向かう道路が見えるので、景色はとても良い。
そんな会場で、50人近くの人達が集まり、講演内容も素晴らしく、熱気があった。

【1】牛尾さんの講演では、プロダクトオーナーの仕事に関するお話。
要求の洗い出しやヒヤリングについて、課題→対策→評価といういわゆる仮説検証スタイルでやっていくのが良いというお話。
要求開発やアジャイルUXの概念も絡めながら、コンサルタントとして必要なテクニックの紹介があって面白かった。

Twitter / akipii: ステークホルダー表を作るか。プロジェクト計画書の客も含めた体制図に似てるかな #agileto2012

Twitter / akipii: ありふれた言葉の裏に牛尾さんの豊富なコンサルタント経験を感じる #agileto2012

【2】藤原さんの講演では、楽天でアジャイルコーチとしてチームの成長に関わったお話。
個人的には、AgileTourOsaka2012の講演中最も深い内容に感じた。
彼は楽天というWebサービスで開発する環境で、管理職の立場でアジャイルを推進する立場にいて、僕自身は受託SIで業務系Webシステムの開発をしており、現場リーダーの立場でチケット駆動開発をベースにアジャイル開発しようとしている。
だから、僕自身の環境や立場、考え方を比較してしまったからだろう。

Twitter / akipii: 藤原さんのサービス開発経験の深さを感じる話。今日の講演で一番深い内容ではないかな #agileto2012

講演メモから内容の一部を抜粋しておく。

「ソフトウェア開発とは、ユーザのニーズとマーケティングの目標をソフトウェアへ変換すること」

仕様は正しいのか？
仕様は仮説でしかない
リリースは出口ではなく、入り口に過ぎないだろ？

Twitter / irof: 「仕様がないと作れないから早く決めて欲しい」一方で「仕様通り作るだけだとつまらない」同じ人の台詞。ふむ。。 #agileto2012

何故全部計測しないのか？　(メアリー・ポッペンディックさんからの質問)
ソフトウェアは想定した使われ方なのか？

Twitter / irof: リリース後から勝負が始まる。全部計測する。単純なところでもいいから。それが想定と合っているかみる。 #agileto2012

計画は守るべきか？
(マネージャは)間に合うように頑張って欲しい
計画は変更する
ビジョン・マイルストーンは作る。

Twitter / irof: 「ちゃんと計画する、計画は変更する」 #agileto2012

Twitter / irof: 「コンパス見ながら進んだら（ちゃんとまっすぐは進まないけれど）大体、まっすぐすすむ」 #agileto2012

Doneの定義がふりかえりで頻繁に議題に上る
プログラムを作った
単体テストが終わった
受入テストが終わった
ビジネスオーナーが承認した
(注：マネージャや開発者、ビジネスオーナーのそれぞれの立場でDoneの定義が違う)
(注：Doneの定義は、プロジェクトの進行中にいくつかのタイミングで変わるらしい)

Twitter / irof: (Done率を)ベロシティというとあやしくなるw #agileto2012

Twitter / irof: Done率.410 イチローより高打率w #agileto2012

Done率は意外に少ないね、という皆の感想

成功とは何か？
「安定的」に「継続的」に繰り返すこと
倉貫さんも最近同じことを言っている
(注：リリースが安定する意味に近い)

Twitter / irof: 成功は、仕様通りでビジネスの価値が正しいものを安定して継続的に繰り返すこと #agileto2012

「作らない」へ
機能は技術的負債

Twitter / irof: 「安定すると作りすぎちゃう」 #agileto2012

Twitter / sakaba37: 「リプレイス」はお金を稼がない #agileto2012

Twitter / irof: たいていのものを作れるようになっちゃったからこそ、作らないこと が重要 #agileto2012

品質とは何か？
開発プロセスに品質保証のタイミングがない

Twitter / irof: "品質とは誰かにとっての価値である" #agileto2012

アジャイルテストの4象限
重要なテストは自動化できるテストではなく、ソフトウェアの「手触り」を確認できるユーザビリティのテスト
ソフトウェアの「手触り」が大切
自動化テストを当たり前にして、手作業のテストを重視したら、バグ率が減った

Twitter / irof: 選択と集中、価値のある手作業へ。 #agileto2012

Twitter / irof:QAが手作業でやってたテストを自動化してしまった。QAがやったのは第三者的な視点を入れたに過ぎない。住み分け、とかではなく…#agileto2012

捨てるタイミング
最短で1イテレーション
捨てられても何度も試す時がある
JiraやRedmineによるチケット駆動開発をチームに導入すると、最初の1、2回目は失敗したが、3回目の導入でようやく成功した
課題管理がJiraで回るようになった

Twitter / irof: 3回トライして出来るようになる場合もある。タイミングの問題であることも多い。今回早める、みたいな。 #agileto2012

Twitter / irof: やめる判断は？上手くやめる方法？やめ時の判断とか、やめ方とか。→最短イテレーションのサイズで決める。ふりかえりで取捨選択する。やめやすくする雰囲気をつくる。 #agileto2012

Twitter / irof: 絶対的に悪いものは無いだろうから、この状況ではだめっぽかった、に過ぎないんだろうね。またやることで、やめることに対するネガティブイメージを下げた結果、やめやすくする。必然的にトライしやすくなる。 #agileto2012

Twitter / irof: 一番重要だったのはふりかえり。 #agileto2012

Twitter / irof: 「何故をひたすら考える。考える機会も話す機会もあまりないだろうけど、一歩進むために、どんどん問いかけるべきだろう。」 #agileto2012

エンジニアリーダー撲滅運動もやっている

Twitter / irof: エンジニアリーダー撲滅運動。そこがボトルネックになる……そんなことしてる場合じゃない。プログラム書いてた方が良い。仕方なくリーダーとかしちゃだめ。 #agileto2012

Twitter / irof:誰か一人が意思決定するなら、その人が作るべき。判断を仰いでるようじゃ"遅い"。速度に価値を置いてる故ですね。 #agileto2012

Twitter / irof: ファシリテーターやスクラムマスターのロールはある方が早くなる。彼らはリーダーではない。意思決定はしない。 #agileto2012

標準化撲滅運動を推進している
標準化の目的は人の入れ替えか？

属人化をなくすのが目的なのか
ある現場の改善を他に持っていきやすくする
他チームへ自チームの成功事例を展開しやすくするために標準化する
標準化には賞味期限がある

Twitter / haradakiro: 標準には有効期限を入れておくのは必須です。更新されない標準は自動的に廃止。RT @sakaba37: 標準化にも賞味期限があるので、最近は邪魔になる事が多いと思います。 #agileto2012

【3】長瀬さんのお話は、中国・ベトナム・タイ・インドのアジャイル事情。
中国などどの国も、元々プロセスがなかったのでウォーターフォールという概念すらなかった。
だから、プロセスを作る時に、最新のプロセスとして自然にアジャイルが導入された、とのこと。

Twitter / irof: 中国は欧米国内向けのアジャイル開発、日本向けのウォーターフォール開発……なんとまぁ。

長瀬さんのお話では、中国のアジャイルセミナーは有料であっても、1000人集まる所があるらしい。

Twitter / momontyo:AgileChinaすげー。初任給４万円の世界で３万円の参加費で１０００人集まる #agileto2012

個人的には、中国のSEは急激に成長しているように思う。
日本の大手SIのオフショア開発の基地として中国沿海部が多いだろうが、下請けの立場ではなく、実力的にも日本より優れてきていると感じる。
「PMPパーフェクトマスター―PMBOK第4版対応」本では、2009年に中国人のPMP資格取得者数が日本のそれを上回ったらしい。
つまり、単なるプログラミングという下流工程だけでなく、プロジェクトマネジメントという上流工程でも中国人のスキルが日本人のそれを上回る状況も確実に増えてきているはず。

今後、日本とアジアでは、ソフトウェア開発の役割分担へ分化していくだろう、とのこと。
長瀬さんは、日本の大手SIへアジャイル教育やアジア各国へアジャイル普及のビジネスをされているとのこと。
その目線で聞くと、そういう考え方になるのかなと思う。

Twitter / akipii: 日本の受託SIならそんな階段になる @daipresents: ”今後の日本のソフトウェア業界は？” ”アジアに開発は広がるのでは？役割も変わっていくと思う。プログラム設計、プログラミングだけでは厳しいかもしれない” #agileto2012

そんな状況で、日本のアジャイル事情はどのように進化してきたのか？

Twitter / akipii: 実感としてある @daipresents: ”10年前のアジャイルと今のアジャイルの違いとは？” ”XPが新しかった 新しいことが好きな人達が集まってた。そしてWFに潰されていったかもしれない” #agileto2012

アジャイル先駆者達は従来型のウォーターフォール開発の現場に押しつぶされた後、昨年からScrumへの注目と共にアジャイル・ルネサンスが起きているように見えるみたい。

アジャイル開発のルネサンス: プログラマの思索

久しぶりに日本のアジャイル魂を感じたコミュニティイベントでした。

【追記】藤原さんの資料が公開されました。従来型開発からアジャイル開発へシフトしようとする開発者だけでなくマネージャ層は必須の資料でしょう。

解説！地図を捨ててコンパスを頼りに未来へ進め！ Agile Tour Osaka 2012資料公開 #agileto2012 | 世界 | daipresents.com

地図を捨ててコンパスを頼りに進め from Dai Fujihara

チケット駆動開発のアンチパターンの事例

チケット駆動開発のアンチパターンの事例のつぶやきを見つけたのでメモ。
とても面白い。

【元ネタ】
Twitter / kobachi_dearu: チケット駆動開発は好きである。だが、身の回りを見てみると、どうも使い方がこなれていないようである。アンチパターンのようなものを見つけたので記す。

Twitter / kobachi_dearu: 【期日・バージョンのない大量の『今すぐ』チケット】　リリース直後のバグ対策など今すぐやって欲しいのはわかるが、いつ本番反映するのかという計画がない。工数の見積もりもしていない。気分の問題でやっており、今やっている作業を止めてでもやるべきか、というマネジメントができていない。

Twitter / kobachi_dearu: 【モンスターチケット】　チケットが返ってきたかと思うと、違う作業が追記されている。バグチケットが復活して「バグなおってなかった！？」と焦っていると、仕様変更や文言修正が指示されている。もちろん期日はバグ修正の時のままである。

Twitter / kobachi_dearu: 【外部連携仕様確定前に実装チケット】　のちに大量のバグチケットを生むことが約束されている。タスク分割も十分でないのでプログラマーがタスク分割して「仕様」や「実装」チケットを割り振ることになる。プログラマーにもプロジェクトマネージャーの給料を払うべきである。

チケット駆動開発がうまく運用できていないチームを見ると、似たようなパターンが多い。
そんな失敗パターンをアンチパターンと呼ぶ。
アンチパターンを見かけると笑ってしまいがちだが、実際の自分たちのチームでも当てはまる時が多くないだろうか？

「期日・バージョンのない大量の『今すぐ』チケット」は、例えば、テスト工程で大量の障害が発生したために、チケットが乱発される時が多いだろう。
同一原因で発生した似たような障害(つまり同類バグ)がチケットに登録されたため、一つのチケットを直せば、ほとんどのチケットは解決できる時が多いはず。

「モンスターチケット」は、何度もよみがえる不死鳥のようなチケット。
つまり、フィードバック(差し戻し)が頻発するチケット。
「アート・オブ・プロジェクトマネジメント」では、ソフトウェアのバグ修正では10回のうち3回は別の障害を埋め込んでしまう、という話があった。
バグが直ったと思っても、デグレードしていない確認を取るコストは結構大きい。

「外部連携仕様確定前に実装チケット」は、チケットの粒度が大きすぎるアンチパターン。
つまり、肥満児のチケット。
PMBOKのようにWBSでタスク管理する場合、一つのワークパッケージ(WP)のサイズは２週間と言われる。
でも、実際の開発者の時間間隔では、１～３人日程度まで分割した方が作業しやすいし、現場リーダーも進捗管理を安心して行える。
肥満児のチケットになる原因は、作業を１人日程度まで分割できるほど、作業内容を見通せていない点にある。
つまり、この機能を実装するには、どのように実装すれば良いのか、というイメージが沸いていない。
結局は、マネージャに技術力がないから、開発者が作業できるレベルまでタスク分割できていないだけのことだ。

こういうアンチパターンにネーミングしておけば、TiDD初心者にもノウハウを共有できるし、重要な知見として役立つ。
11/10に開催される第４回品川Redmine勉強会では、参加者全員でTiDDのパターンやアンチパターンを議論したいと思っている。

第4回shinagawa.redmine勉強会 : ATND

自分が知らない現場でのチケット駆動開発の経験事例は、皆知りたがっているのではないだろうか？
是非お楽しみに！

Jenkinsをジョブ管理ツールとして使う事例part2

Jenkinsをジョブ管理ツールとして使う事例を見つけたのでメモ。

【元ネタ】
Jenkinsで定期実行するJobを管理したほうが良い３つの理由｜Pimp my Code. @wataru420

上記の記事では、Jenkinsを高機能なCronとして使うメリットが書かれていて、参考になる。

(引用開始)
定期実行って、Cronを使ってやるのが一般的ですよね。
エンタープライズシステムだとJP1とか使って管理したりしますが、
それJenkinsで良くない？

というわけで考えて見ました。
なんでJenkinsがいいのか。

メリット（cronとの比較）

① SVNなどのSCMとの連携が可能

② メール等のアラートが可能

③ 実行履歴の確認が容易
デメリット

① Jenkinsが落ちたら動かない

ただこれはJenkinsの監視やバックアップである程度回避できます。

またJP1 などは大変高価なので、無償で使えるのは嬉しいですね！
(引用終了)

記事の最後に書かれているJenkinsプラグインも興味深い。

Jenkinsを高機能なCronとして使う場合、Cron Column Plugin - Jenkins - Jenkins Wikiのプラグインは良さげだ。
ジョブ名の横に「10分おきに起動」「夜間1時に起動」が表示されるので、リアルタイムなバッチなのか、日次なのか、月次なのか、が一目で分かる。

Next Executions - Jenkins - Jenkins Wikiのプラグインでは、次に実行されるジョブをサイドバーに表形式で表示してくれる。
つまり、「今日の18時にジョブAが起動」「今夜22時にジョブBが実行」などが表示されるので、タイマーのように理解できる。

また、Email-ext plugin - Jenkins - Jenkins Wikiを使えば、メールの通知内容や宛先をカスタマイズできるし、メールの通知タイミングを制御できる。
以前、@haru_iidaさんは、このプラグインを使って、Hudsonがビルドエラーを検知したら、メールを発行して、Redmineへ送り、Redmineチケットに自動登録される運用事例を講演されていた。
つまり、ジョブが異常を検知したら、即座にメールを発行するように制御することもできる。

Jenkinsはアイデア次第で、開発の効率を更に向上させてくれる可能性を秘めている。