« 2013年2月 | トップページ | 2013年4月 »

2013年3月

2013/03/31

A successful git branching model とgithub flowの比較

A successful git branching model とgithub flowについて、その考え方を比較するスライドを作ってみた。

【元ネタ】
GitHub Flow (Japanese translation)

git-flow によるブランチの管理 - O'Reilly Japan Community Blog

A successful Git branching model: プログラマの思索

git-flow による構成管理とRedmineの関係: プログラマの思索

GitHub Flowは、GitHub上でのブランチ管理戦略だ。
GitHub Flowの本質は、PullRequest主導のチケット駆動開発とも言える。

GitHub Flowが使いやすい理由は、GitHubと言うWebUI上で、masterから派生されたブランチ一覧を見れるので、ブランチに相当する開発中の機能の現状が分かりやすいことと、GitHub上でPullRequestを送ることでコミッタがパッチをWeb上でコードレビューでき、即座にマージできることにあるだろう。
もしそのパッチが気に入らないならば、却下して、マージしなければいいだけのことだ。

開発者がコミッタへパッチを送る作業と、コミッタのコードレビュー、コミッタのマージ作業をGitのPullコマンドで実現した点が凄い所だと思う。

また、A successful git branching model のように、たくさんのブランチを意図的に作り、マージやリリースを複雑にするワークフローでもない。
Gitコマンドを手作業で実行しなくても、GitHubという優れたWebUIがその操作を代替してくれる。

歴史を振り返ると、2000年頃に出現したXPのプラクティス「ソースの共同所有」が叫ばれた時代は、CVSがまだ一般的に普及しているとは言えない頃だった。
そして今、GitHub FlowというPullRequest主導のチケット駆動開発によって、よりアジャイルに開発してリリースできるようになった。

技術やツールがプロセスや文化を変えていく。
その観点で今後も追いかけてみる。

| | コメント (0)

2013/03/30

サーバー構築を構成管理とTDDで作業する時代になってきた

ChefやPuppetなど、サーバー構築をプログラムで作成する時代になってきた。
しかも、サーバー構築を構成管理とTDDで作業するのが最近の流れのようだ。
クラウドが当たり前の時代になった今、もう一つの技術革新が生まれているように思う。
クラウドについてはまだ理解不十分だけれども、気になる記事をメモ。

【元ネタ】
Chefのテストスイーツを色々試してみた (1) - カイワレの大冒険

Chefのテストスイーツを色々試してみた (2) - カイワレの大冒険

Chefサーバを動かすまでの方法をまとめてみた(自動化のススメ) - カイワレの大冒険

2008年出版された「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」では、ラストマイル問題が提示されていた。
ラストマイル問題とは、いくらソフトウェアを作っても、本番環境へリリース&稼働確認するのにかなりの時間がかかってしまうという内容。
開発環境で正常動作しても、本番環境へのデプロイや本番環境相当の開発環境の構築に手間がかかる所に大きな問題点がある。
開発がTDDやCIでも、肝心の本番環境で動作しなければ意味が無い。

ラストマイル問題には3つのボトルネックがある。
一つ目は、本番環境は大規模で複雑で高価であること。
以前は、サーバーやネットワーク機器のインフラを揃えるのも高価だし、特にDB周りのミドルウェアは商用製品ならどうしてもお金はかかる。

2つ目は、本番環境というインフラを設計し、構築し、検証するコストが大きいこと。
インフラ構築はどうしてもWF型開発のように、設計重視にならざるをえない。
インフラというハードウェアの購入時からOSのインストール、DBやWebサーバーのインストールに至るまで、手順を間違えると後戻りできないからだ。

3つ目は、たとえ本番環境を用意し、テストも用意できたとしても、全てのテストを実行するには時間がかかりすぎること。
インフラ担当者ならば、サーバー間の接続テストや負荷テストを色々考えないといけない。
アプリ担当者ならば、アプリケーションのシステムテストや受入テストのテストケースも重要だが、業務系システムならば、膨大なテストデータを予め投入しておく必要もある。
そして、テストデータが多いほど、回帰テストも時間が長くなる。

しかし、ラストマイル問題のようなインフラ周りの長年の問題も、クラウドと言う新しい技術が大きく変えているようだ。
本番環境を仮想化するというだけでなく、ライブラリやミドルウェアのバージョンを構成管理して、インフラの稼働確認をテスト駆動していく発想で推し進める。
インフラというハードウェアをソフトウェアへ変換することで大きく変わる点は、何度もやり直しが効くため、アジャイルにインフラ構築しやすくなることだ。

アジャイルにインフラ構築できることによって、最初は小さく作っておき、ユーザからのアクセス数が増えてきたら動的にリソースを増やすというシステム設計が可能になる。
その分、インフラ構築の初期投資も浮くし、最初からサーバーの負荷を想定した完璧な設計も必要なくなる利点がある。

上記の記事では、Chefを使って環境構築を自動化するだけでなく、RSpecやCucumberで受入テストも行い、最後はRakeでまとめてテストできるようにして、継続的インテグレーション化していく方向のようだ。
従来のインフラ構築とは全く違うすごいやり方だなと思う。

後もう一つ注意すべき点は、ChefやRSpecやCucumberなど、Rubyで全てがまかなえること。
クラウド時代のサーバー構築では、Rubyという技術が必須になってきているように思える。

最近の技術のトレンドは、GitとGitHubにおけるPullRequest主導のチケット駆動開発、そしてRubyライブラリを中心としたクラウド技術にあると思う。
この流れを今後も追いかけていく。

| | コメント (0)

Gitによるチケット駆動開発の事例

Gitによるチケット駆動開発の事例をSlideshareで見つけたのでリンクしておく。

【元ネタ】
第5回テックヒルズ『Go to Git !』~さらばSVN~ に行ってきました | shinodogg.com

資料を要約しながら、自分の感想も入れてみる。

SVN主導の開発で抱えていた問題。
「pull request主導のチケット駆動開発したい。svnには障壁が多い。」

trunk, staging, releaseの3つのメインブランチ戦略。
(僕もSVNでこのブランチ管理の経験はある。
きちんとソース管理はされているが、マージが手作業な場合、ライブラリアンの負荷が途方もなく大きい。
どのリビジョンをリリースするのかというExcel申請書が大量に届いて、それを見ながら手作業でマージしてビルドする。)

SVNはマージやブランチを切るコストが大きすぎる。
(trunkから派生したブランチとtrunkの間のマージはまだ楽だが、ブランチ間同士のマージはまだまだ厳しい。)

理想は、GitによるPullRequest主導のチケット駆動開発。
(チケットにソースの修正理由や発端、経緯が記載されている、ないし、リンク箇所があるので、コードレビューしやすいし、担当を引き継ぎしやすい。)

Gitには、TiDDを実行する環境が揃っている。
GitHubにはチケットもWikiもあるし、PullRequest機能によってコミッタがそのパッチをレビューしてマージできる作業が埋め込まれている。
Trvis-CIと連携すれば、GitHubリポジトリのソースをWeb経由でワンクリックでビルド&リリースできる。

「ツールが文化を規定する」。
「知の高速道路、巨人の肩」。
速くなる、楽になるだけで世界が大きく変わる。
SVNでは到達しづらい目標にすぐに辿りつけて、追い越せる。

Gitによるチケット駆動開発のメリット。
リポジトリブラウザが速い。
Redmine+SVNとは全く違う。

TiDDをやりやすい。
diffを見ながら会話して、ワンクリックでPullReqestしてマージできる。

メンバーの意識も変わる。
コードを見てもらえる安心感。
ちょっとした思いつきをコミットできる気楽さ。
ペアプロやコードレビューを育む環境。
PullRequestのおかげでOSSの敷居も低くなった。

移行期間中は、SVNがメインライン、Gitが開発用のブランチ。
gitに慣れてもらい、cherry-pickで指定リビジョンをつまみ食いしてマージ。
その間にワークフローを直す。

(マージには幾つかの種類がある。「実践 反復型ソフトウェア開発」で詳細に書いてくれているので後でまとめたい)

git-flowやgithub-flowは夢。
git-flowよりシンプルなgithub-flowが理想。
リリースできないものをmasterに入れない。

GitHub Flow (Japanese translation)

(この部分は、比較検証して後で考察したい。)

移行時のチェックリスト。
上を倒す。
GitHubを使えば、コードレビューで改善できる点は理解してもらいやすい。
レビュー文化は正しい文化なので取り入れましょう。
でもGHEまでは受け入れられなかった。
数百万の初期導入費用は即OKではない。
なので、gitlab化。

横を倒す。
SVNすら使っていないエンジニアには、バージョン管理のメリットを説明。
共有サーバの短所、画像の履歴管理や差分表示。

元気なプロジェクトで便利そうで楽しそうな雰囲気作り。
PullRequestでワイワイ。
(ブランチ作成→コミット→PullRequestを公開)

移行しない理由を潰す。
環境、ツール、ドキュメントを整備。
前プロジェクトのリポジトリを勝手に同期しておき、いつでも移行できるようにする。
ドメインを全社に公開して、全社的に移行する雰囲気を作る。
不満を言われた瞬間に直す。
詰まった時にすぐに聞ける環境づくり。
(Gitを理解したエンジニアを増やす)

コンフリクトが起きたら、コミットツリーを書いて、原因を説明する。
Gitの手順に慣れてもらう。

移行していないプロジェクトは仲間はずれ、カッコ悪いね、という雰囲気作り。
「開発者はうまく怒らせるとすごい生産性を発揮する」。

リポジトリをGitにするだけでは駄目なのか?

WebUIからGitでバージョン管理できるのが大事。
ワークフローはツールが規定する。
UIが使われ方を規定する。
(まさにその通り)

WebUIが無かったら、SVNとほぼ同じ使い方をされてしまう。
ゴールはPullRequest文化の輸入。
個人で幸せになってもいいのは小学生まで。
チームの生産性最大化を目指そう。

| | コメント (0)

2013/03/24

構成管理パターンの記事「Streamed Lines: Branching Patterns for Parallel Software Development」

実践 反復型ソフトウェア開発」に構成管理のパターンやアンチパターンに関する記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
Streamed Lines: Branching Patterns for Parallel Software Development

1999年に書かれたという上記の記事は、構成管理に関する基本的な考え方が体系立てて書かれている。
内容は、ブランチ管理やマージの考え方、手法が整理されたもの。

1999年といえば、CVSが普及する前後であり、SubversionもGitも出現していなかった時代ゆえに、先を見通した良い記事かなと思う。
パターンによるソフトウェア構成管理」よりも内容が詳しい。

内容は後で整理してみる。

Appendix A - Streamed Lines: The Patterns

Basic Branch/Line Elements
E1. Activity Branch
E2. Functional Branch
E3. Component Branch
E4. Project Branch
E5. Development Line
E6. Maintenance Line
E7. Integration Line
E8. Release Line

Branching Policy Patterns
P1. Codeline Policy
P2. Codeline Ownership
P3. Relaxed-Access Line
P4. Restricted-Access Line
P5. Merge Early and Often
P6. MYOC (Merge Your Own Code)
P7. Early Branching
P8. Deferred Branching

Branch Creation Patterns
C1. Policy Branch
C2. Branch per Task
C3. Codeline per Release
C4. Subproject Line
C5. Virtual Codeline
C6. Remote Line
C7. Component Line
C8. Platform Line

Branch Structuring Patterns
S1. Mainline
S2. Parallel Maintenance/Development
S3. Overlapping Releases
S4. Docking Line
S5. Staged Integration Lines
S6. Change Propagation Queues
S7. Third Party Codeline
S8. Inside/Outside Lines

Branching Traps and Pitfalls

T1. Merge-a-phobia
T2. Branch-a-holic
T3. Merge-mania
T4. Continual Cascading
T5. Spaghetti Branching
T6. The Unknown Branch
T7. The Never-ending Branch
T8. "Big Bang" Integration
T9. The Wrong-Way Merge
T10. Run-away Merge
T11. Development Freeze
T12. Codeline Pudding
T13.Integration Wall

| | コメント (0)

2013/03/20

Springフレームワークをバッチ処理やHadoopにも適用する

最近、JavaのSpringフレームワークが熱いと思っている。
ラフなメモ書き。

【元ネタ】
Spring Framework | TECHSCORE(テックスコア)

Eclipseを使ったJava開発入門/フレームワーク/ライブラリ/Spring/DIでHelloWorld | DI wdsdx.com

今必要な人のための速習 Spring Framework - 今必要な人のための速習Spring Framework---目次:ITpro

Spring3入門―Javaフレームワーク・より良い設計とアーキテクチャ:書籍案内|技術評論社

VMware が Spring Hadoop を発表

Hadoop開発を容易にする「Spring for Hadoop 1.0」が登場 - SourceForge.JP Magazine : オープンソースの話題満載

【ハウツー】概説 Springプロダクト(12) - Spring Batchで簡単にバッチを作る (1) Spring Batchとは | 開発・SE | マイナビニュース

SpringBatchとは - omotenashi-mind

01.Spring Batchの基本概念(ステップ) - soracane

Springは、2000年代前半、理論先行で使いづらいEJBよりもDI(依存性注入)で実現したPOJOを使ったフレームワークとして注目されていた。
JavaでWebシステムを使う場合、StrutsベースのSAStrutsかSpringのどちらかのフレームワークを採用する場合が多いだろうと思う。
海外ではSpringが多いのかな。
ドメイン駆動設計」の著者の方も、DDDで設計後、Springフレームワークで実装する方法で説明されていた。

ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

業務システムを設計するアーキテクトの観点では、Springが他のJavaフレームワークよりも勝る利点は、バッチ処理でも同様のフレームワークを流用できる点があると思う。
つまり、Webシステムと言うフロント側だけでなく、集計処理や帳票作成などで使うバッチ処理でもSpringフレームワークを元に実装可能なことだ。

すると、Java開発者は、Springという一つのフレームワークに慣れれば、Web画面もバッチ処理も実装できることになる。
従来の業務システムでは、Web画面はJava、バッチ処理は従来通りCobolというように言語が異なるため、Java開発者とCobol開発者を両方揃える必要があり、開発チームもWebとバッチのようにアーキテクチャの観点で分かれてしまってコミュニケーションが悪くなる弱点があった。
でも、Springを使うならば、数少ない人的リソースをWeb画面もバッチ処理にも一人のJava開発者で対応できることになり、開発人員を減らせるだけでなく、開発者が画面からバッチ処理まで全てのロジックに触れることになり、より理解も深まるだろう。
Conwayの法則「組織はアーキテクチャに従う」に従えば、より一体化したチームになれる可能性がある。

更に、上記の記事では、SpringがHadoopにも対応したらしいので、アクセスログのような膨大なデータから顧客の利用データを経営分析することに使うという発想にも役立てることができるだろう。

色々調べてみる。

| | コメント (0)

本作りもチケット駆動開発で

もうすぐ出版される『わかりやすいアジャイル開発の教科書』の出版の経緯を編集者が公開されていたのでメモ。
本作りもチケット駆動開発だったらしい。

【元ネタ】
『アジャイル開発の教科書』物語(その4) - 心との対話、技術との対話

『アジャイル開発の教科書』物語(その3) - 心との対話、技術との対話

『アジャイル開発の教科書』物語(その2) - 心との対話、技術との対話

『アジャイル開発の教科書』物語(その1) - 心との対話、技術との対話

『わかりやすいアジャイル開発の教科書』の予約が始まりました。 - mnishikawaの日記

アジャイル開発の資料作りで役立つイラスト集を公開! - mnishikawaの日記

「わかりやすいアジャイル開発の教科書」 - Yasuo's Notebook

Sphinx+GitHub+BuildHiveで作る手軽なソーシャルドキュメンテーション環境 - Yasuo's Notebook

本作りでは、Backlogでタスク管理されていたらしい。

(引用開始)
正月が明け、ふとした疑問「「担当:三津田」と書かれたメール」について皆さんに聞いてみた。すると、私が知らないうちに、この本作りがチケット駆動開発になっていた(!)。
 打ち合わせで、「Backlog」や「チケット」という単語がよく飛び交うなぁと思いながら聞き流し、本のコンテンツや進行のことばかりに気を取られていた結果が、これであった。
 チケット管理システムのBacklogには編集が対応すべき文字・図版の直しや要望(つまり校正の指定=チケット)が山積みになっていた(最終的にはチケット数1000件オーバー)。
 これを見て一瞬青くなったが、西河さんが冷静に一言。

「チケットこなしているとタスクがどんどん減っていきますから、おもしろいですよ」

 この一言を聞き、私も知らずのうちにアジャイルなものづくりに巻き込まれてしまっていたことに、いまごろようやく気づいた。

 本来、本作りは、

①「原稿書き上げ」

②「初稿ゲラ(本のイメージに組み上がった原稿)校正」

③「再校ゲラ(初校の直しが反映したゲラ)校正」

④「確認校(印刷所に納めるもの。ほぼ「版」である)校正」

⑤「出版」

 という5つのステップで作られる。
 著者さんの執筆作業は「①「原稿書き上げ」」でほぼ終わりになる。②以降の作業はあくまでも「確認」であり、⑤に向けてひたすら確認と直し、追加を行っていくというのが、いわゆる本作りである。
 細かな直しや追加修正は①で終わっているというのが大前提で本は作られる。
 雑誌と違って書籍は、企画書をベースにした1冊としての「総体的な整合性」が求められる。
 それゆえに本は、このような半ウォーターフォール型の制作工程で作られている。
 ところがどうだろう。
 『アジャイル開発の教科書』の本作りにおいては、②、③、④がタイムボックスになり、イテレーション(繰り返し)されまくっていた。
 制作当初、私は編集者として、いままでのやり方では本ができそうにないという直感があったが、それにしても、こんなにまでアジャイルな本作りになるとは思ってもいなかった。
 一般的に、本としての整合性・一貫性を保つために、②、③、④の工程で大きな追加・修正・変更を入れるということはあまりない。それは言い換えれば、本作りにおける追加・修正・変更は「手戻り」と認識されていたからだ。
 しかしアジャイルなものづくりの考えに立脚し、追加・修正・変更を「価値を高める作業」と、発想を切り替えたらどうだろうか。
(引用終了)

神は細部に宿る。
良い本づくりは、誤字脱字の修正だけでなく、目次やレイアウト、内容の構成も重要だし、レビューアの指摘事項を逐一反映することも大事。
とにかく細かい作業が多い。
それらを1つずつ反映していくことで、良い作品に仕上がっていく。

そのためには、チケット管理のツールが必須だろう。
とにかくタスクを上げて、1つずつこなしていく。
たくさんのチケットがあがっても、それら全てを解決するのがゴールと分かる。
ゴールが分かれば、担当を変えるなり、チケットを精査するなり、優先順位をつけるなり、色々やり方はある。

全てのタスク管理はチケット駆動開発から始めてみよう。

| | コメント (0)

IPA版アジャイルプラクティスのパターン言語集

IPAがアジャイルプラクティスのパターン言語を公開していたのでメモ。
これは凄い。
パターン言語というアイデアは、かなりマニアックな考え方と思っていたのに、世間に認知されてきたのかな?

調査報告書や「アジャイル型開発におけるプラクティス活用リファレンスガイド」を読んでみて、気づいた点を抜粋して書き出してみる。

【元ネタ】
情報処理推進機構:「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドを公開

情報処理推進機構:「アジャイル型開発プラクティス・リファレンスガイド」を公開~アジャイル型開発の初心者向けに実践ノウハウを事例から分類・整理~

Twitter / IPA_SEC:SECでは、アジャイル型開発で用いられる組織、プロセス、技術等の実践のための指針である「プラクティス」について、先駆的企業を対象に事例調査を行い、リファレンスガイドとしてまとめ、本日3月19日公開しました。ぜひ、ご利用ください。http://sec.ipa.go.jp/reports/20130319.html …

Twitter / hiranabe: "IPA 「アジャイル型開発プラクティス・リファレンスガイド」を公開" なんと、パターン言語記述で力が入っています! http://bit.ly/ZaDct6 "

Twitter / takepu: 【IPA】「アジャイル型開発におけるプラクティス活用 リファレンスガイド」読んだ。「アジャイル成分300%」の濃厚仕立て。中身の是非は兎も角、IPAがこの資料を公開できる状況になったのだな、と、あらためて実感した。日本、始まった。 http://goo.gl/Rnuo2

Twitter / takepu: 【IPA】「アジャイル型開発におけるプラクティス活用 リファレンスガイド」P.51 とか、「ペアプロ」を写真付きで紹介するなんて、昔は本当、考えられなかった!! http://goo.gl/Rnuo2

Twitter / takepu: これから、日本のソフトハウスは激変するのではないか。だってIPAさんが「アジャイルプラクティス」を公開しているのだから、「IPAが言ってるんだから、やりましょう、いまでしょ?」ってなる気がする...。でも、何も考えずに導入して失敗するパターンががが... orz

【1】2009年度の調査では、約35%の開発プロジェクトでアジャイル型開発手法を実施している。
アジャイルと非アジャイルの技術とプラクティスを組み合わせてより大きな組織に合うようにハイブリッドにすることに苦闘している。
(中略)
国際競争力の強化のため、世界的に主流となっているソフトウェア開発手法であるアジャイル型開発に日本も取り組み必要がある。
しかし、現状、日本では「普及が遅れており、ようやく認知され始めた」段階であるとされる。

まさにその通り。
但し、2012年後半から、日本人発のアジャイル開発の書籍が急激に増え始めた点は注目すべき流れ。
日本のアジャイルコミュニティの影響力が強くなり始めた事実があると思う。

日本人が書いたアジャイル開発本が増えてきた: プログラマの思索

チケット駆動開発の英訳記事が公開されました: プログラマの思索

【2】日本でアジャイル型開発が阻害されている要因。
海外では、同一組織内でソフトウェア開発が行われている。
オフショアでも顧客と開発チームがいつでもコミュニケーションが取れる環境を作っている。
ユーザ企業にIT技術者が多い。

これもよく言われていること。
そのような制約でアジャイル開発をどのように適用していくか。
あるいは制約条件を壊す動きを始めるか。

【3】アジャイル(Scrum、XP、WFとの折衷型など)を適用した調査結果では、「成功した」が50%を超えているが、「うまくいったがうまくいかなかった面もある」が23%あるのが興味深い。

日本の現場に合ったノウハウがもっと必要なことを示唆している。

【4】適用プラクティスでは、日次ミーティング・ふりかえり・イテレーション計画ミーティング・イテレーションをほとんど採用されているのに対し、ニコニコカレンダー・かんばん・システムメタファはほとんど採用されていない。システムメタファはゼロ。

アジャイル開発の基本であるタイムボックス開発、コミュニケーション重視は押さえられている。
かんばんはまだこれから。
システムメタファは、業務用語集の代わりとして使われていくためにもっとノウハウが必要だろう。

【5】2009年度と今回の調査では、スプリントバックログのようなScrumのプラクティスの適用率が高くなった。
これは、認定スクラムマスター研修が国内で開催されるようになってきたことにより、Scrumが普及したためであると思われる。
また、紙・手書きツール、タスクボードの適用率も高くなっている。
これは、コミュニケーションを重視するために、事業者と開発者が同一拠点で一体化して開発する事例が多くなってきた事によると思われる。
また、ユニットテストの自動化も適用率が高くなっている。
これは、アジャイル開発がプロセスの側面だけでなく、技術・ツールのカテゴリのプラクティスを実践することの重要性が認識され始めたためと思われる。

アジャイル開発のエンジニアリング側面とプロセスの側面の両方が重視されて実践されていることを示唆している。

【6】B2Cサービスでは、インテグレーション専用マシンや継続的インテグレーションの適用率が高い。
これは、社内システムよりもリリース後に変更が入る率が高く、迅速なフィードバックが求められるためである。

【7】小規模ではイテレーション計画ミーティング、中大規模ではリリース計画ミーティング、人材のローテーションの適用率が高い。
これは、中大規模では、人材を流動化させて、ナレッジやノウハウをいかに流通させるかが課題であると思われる。

【8】プラクティスのパター言語テンプレートは下記の通り。
状況・・・解決すべき問題が発生する状況
問題・・・特定の状況で発生する問題
フォース・・・解決策を選択する上で鍵となる考慮点や制約事項
解決策・・・プラクティスそのもの
利用例・・・プラクティスの利用例
留意点・・・プラクティスを適用する上でコンテキストに応じた留意点やプラクティスをそのまま適用できない時の代替策

これを読むと、IPAはパターン言語をきちんと理解して、アジャイルプラクティスを抽出しようと試みているのが分かる。

【9】日次ミーティングの留意点には「必ずしも朝の時間帯にこだわらず、関係者が集まりやす時間帯に開催する(例えば終業時間帯に開催する夕会)」と書かれている。
これを読むと、たくさんの事例を元に、状況に応じて、問題解決する手法を提案しようとする試みが感じ取れる。
何も朝会が絶対の解決法ではなく、それぞれのプロジェクトに応じて柔軟に対応すべき。

【10】ふりかえりの利用例では、「当初はKPTを使っていたが、ファシリテータの技量にふりかえりの質が依存してしまう、声の大きいメンバーに影響を受けてしまうことに気づいた。そこで意見を集めるやり方として、555(Triple Nickels)を用いることにした」と書かれている。
この内容もよく分かる。
KPTはとても良い手法なのだが、ホワイトボードを使ってメンバーから意見を吸い上げたい時、ファシリテータの能力が高くないと、あまり意見が出ず、肩透かしになる。
日本人は人前で発言することに慣れていないから。

僕もPostItで各人にKPTの観点で書いてもらい、一人ずつ話してもらうようにしていた。
すると、若手や女性の意見が意外性があり、結構貴重な意見になる時が多かった。
そんな観点があるのか、とか、そんな考えを持っていたのね、とか。

【11】「まとめ」ではこんなことが書かれている。

現状、日本では「普及が遅れておりようやく認知され始めた」段階とされるが、アジャイルプラクティスの適用率は高まっている。
一方でアジャイル型開発を導入しさえすれば、生産性・品質・コストに関する問題が解決するという誤った認識も生まれ始めていることから、プラクティスへの正しい理解を広めると共に、「アジャイルコーチ」(外部からの変化)と「組織に合わせたアジャイルスタイル」(内部からの変化)をバランスよく取り入れながら正しい普及活動を進めていくことが今後の課題になるだろう。

僕が暗黙的に感じていたこと、直感的に思っていたことがズバリ書かれているなあと思った。
また、「アジャイル」がビジネスとして成り立ち始めていること(例えばアジャイルコーチとしてコンサルタントになる)、Scrumが言う組織的阻害要因(organization impediment)にも触れて、それを継続的に解決しなくてはならないことを示唆している。

【12】また、「まとめ」ではこんなことが書かれている。

契約の違いはプラクティスにあまり影響を与えていないが、海外と国内の環境の違いを踏まえると、日本の環境では特に以下のプラクティスを活用する必要がある。

・ファシリテータ(スクラムマスター)
・顧客プロキシ
・共通の部屋

【12-1】スクラムマスターの必要性は、スクラムの新しさ: プログラマの思索にも書いたように、発注者(プロダクトオーナー)と開発チームのバランスを取るためだ。
顧客や開発者とは別の独立した役割であるスクラムマスターが必要で、スクラムマスターがいることでそれぞれの役割が一方的に強くなることを防ぐだけでなく、本来のゴールを認識させたり、スクラムチーム内部で発生した課題を解決するために組織的阻害要因を取り除くことに注力する。
従来のプロジェクトマネージャの役割は、プロダクトオーナーとスクラムマスターに分割されるべきなのだろう。

【12-2】顧客プロキシは、受託開発の場合、SI側に顧客の代理人としてプロダクトオーナーを配置することに相当するだろう。
但し、僕の経験では、顧客プロキシのハードルは高い。
SIではいわゆる業務SEが顧客から要件を引き出してまとめるために、しょっちゅう出張で出かけたり、開発チームへフィードバックしたり、要件定義書を作るためにかなり時間がかかったりして、彼がボトルネックになる時が多い。
牛尾さんや倉貫さんも既にそのような事例と注意点を指摘されている。

アジャイルはなぜ失敗するのか?~教科書には載っていない反復型開発の3つの掟(4/4):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

アジャイルはなぜ失敗するのか?~教科書には載っていない反復型開発の3つの掟: プログラマの思索

ITエンジニアのスキル向上ゼミナール - 【中級】反復開発 現場のノウハウ 第2回:ITpro

図4●顧客の“代理”を立て,プロジェクトに常駐
TISの倉貫氏はXP開発を進めるに当たり,常時プロジェクトに参加してもらえない顧客に代理人(ユーザーのシステムを長年開発している開発者)を立て,プロジェクトに常駐してもらった。同氏はこのプラクティスを「顧客プロキシ」と名づけた

【12-3】共通の部屋は、XPのオンサイト顧客と同じ。
プロダクトオーナーと開発チームが同じ場所で仕事することで、いつでも仕様確認や本来の優先順位を議論できる場を作り出すこと。

最近注目すべき流れとしては、トヨタ生産方式やリーンの考え方を元に、かんばんを使った手法がある。
部屋の壁やホワイトボードにかんばんを作り、機能(フィーチャー・ストーリーカード)やタスクカードを載せてプロジェクトの進捗や課題を見える化する手法だ。

かんばんとスクラム 両者のよさを最大限ひきだす

「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ

チケット駆動開発の目的も最終的には、かんばんが目指している「プロジェクトの見える化」「透明化」をサポートすることにあると思っている。

【13】「プラクティス(パターン)を現場から発信できる場作り」では、「もっと日常的に現場の開発者が自分たちの工夫を言葉にして、それを社内や社外にかかわらず共有しながら、現場の知を交流させて新しい知を生成していく必要がある」と書かれていて、全く同感。
日本人技術者のスキルは、海外と比べてさほど劣っているとは思わないし、DOAや品質管理などでは日本独自の技術を持っている。
にもかかわらず、そのような技法が共有されておらず、現場の経験知がバラバラに散在していて、参考にしづらい。
ノウハウをパターン言語として再発明して、新しい言葉による価値の創造に向かえば面白いだろうと思っている。

| | コメント (0)

2013/03/17

スクラムの新しさ

スクラムが従来のアジャイル開発に比べて優れている点は、役割のバランスが絶妙なことにあると思う。
また、日本の受託ソフトウェア開発の最大の弱点は、プロダクトオーナー不在が常駐化している事だと思う。
色々考えたことをラフなメモ書き。

【参考】
日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記

ソフトを他人に作らせる日本、自分で作る米国:日経ビジネスオンライン

Twitter / akipii: PMBOKではプロジェクトマネジャが発注者にいることが前提になっている。日本ではIT企業すなわち受注者にPMがいることがほとんどだから、米国の手法を修整して取り入れないとうまくいかない。ソフトを他人に作らせる日本、自分で作る米国 http://business.nikkeibp.co.jp/article/tech/20121010/237890/?P=3&rt=nocnt …

Twitter / akipii: 日本は一括請負契約、欧米はTime&Material契約、つまり時間単価契約。日本の方が赤字プロジェクトになりやすい指摘が面白い。 日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記 http://yoshinorinie.hatenablog.com/entry/2012/11/26/095526 …

【1】Scrumが従来のアジャイル開発に比べて優れている点の一つは、Scrumが定義するソフトウェア開発プロセスでは、プロダクトオーナー(PO)・スクラムマスター(SM)・チームの3つの役割だけで十分である、と明確に定義したことだと思う。
この3つの役割が、Scrumでは絶妙なバランスで成り立っているのだと思う。

プロダクトオーナーは、プロダクトのバックログを決定し、プロダクトのROIに最終責任を持つ人。
彼が、リリースする仕様を決定し、プロダクトの予算や原価管理の責任も持つ。
そして最も重要な特徴の一つは、複数のスクラムチームから成る大規模プロジェクトであっても、プロダクトオーナーは唯一人の人物に限ることだ。
つまり、プロダクトのバックログを決定する責任と権限は唯一人の人物で明確化されている点が画期的。
この点は、認定スクラムマスター研修で衝撃を受けた内容の一つだった。

唯一人のプロダクトオーナーがバックログを決めるので、小規模や大規模なシステムにかかわらず、システムの統一方針はプロダクトオーナーの中では一つにまとまる。
もちろん、大規模システムではプロダクトオーナー一人では忙しすぎるから、機能エリアごとにプロダクトオーナーを補佐するサブPOのような人がいて、それぞれでバックログを管理するが、プロダクトオーナーが各エリアのバックログを集めて最終的に決めるようにすればいいらしい。
POを補佐するプロダクトオーナーのチームが大規模プロジェクトでは必要になることを示唆している。

フィーチャーチーム

Scaling Lean & Agile Development: Feature Teams | Introduction to Feature Teams | InformIT

Coplienの生成的パターン言語では、Patron(パトロン)に当たる人になるだろう。

pattern12 - パトロン

【2】スクラムマスターは、プロダクトオーナー・スクラムマスター・チームの3つから成るスクラムチーム内のコミュニケーションを円滑化させ、課題解決を図る権限を持つ人。
スクラムマスターは、スクラムのプロセスの守護者でもある。
僕のイメージではファシリテーターのような役割を持つ人であり、サーバント・リーダーシップを持つ人とも言える。
Coplienの生成的パターン言語では、FireWall(防火壁)やGateKepper(門番)に当たる人になるだろう。

pattern25 - ゲートキーパー

pattern24 - ファイアーウオール

【3】スクラムがアジャイルな開発チームに必要な役割を3つに明確化したことは画期的だと思う。
PO・SM・チームに期待されている役割が明確なのだ。

逆に、XPで定義されている役割は、XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法(第1版)によれば、プログラマ・ユーザ・テスター・トラッカー・コーチ・コンサルタント・上司の7つがある。
XPエクストリーム・プログラミング入門―変化を受け入れる(第2版)では更に10個以上に増えている。
だから、役割が多すぎるために、組織運営で注意すべき点が多く、それぞれの役割で期待されていることが分かりづらい弱点があると思う。
(個人的には、XPエクストリーム・プログラミング入門は第2版よりも第1版の方が好きだ)

XPではオンサイト顧客のように、ユーザが果たすべき責務がプラクティスの一つとして既にある。
だが、プロダクトオーナーはオンサイト顧客であるだけでなく、予算や原価管理の権限も持ち、システムのROIまで責任を持つから、更に権限が強力だ。
だから、プロダクトオーナーと開発者の関係は、プロダクトオーナーの方が強すぎてそのままではバランスが悪くなってしまいがちになると思う。
でも、そこにスクラムマスターと言うプロダクトオーナーと開発者とは違う第三者的な立場の人がいて、スクラムチーム全体で課題解決していき、スクラムのプロセスを守るような役割が設定されている。

【4】@hatahataさんから、プロジェクトマネージャがシステム提案やシステム要件定義で最初にやることは、MANを持つ人を探すことだ、と聞いて納得した。
MANとは、Money(システムの予算)、Authority(システムの要件や仕様)、N(ニーズ。システムを実際に使う為に欲しい機能が分かること)の3つの権限を持つキーマンを指す。

日本の受託開発では、MANという3つの権限を持つ人がそれぞれに分かれていたりする。
例えば、予算を持つのは経営戦略室のように社長に近い部門で、情報システム部門がユーザ企業の各部門のニーズを集めて集約する役割を持つ場合が多いだろう。
だから、ユーザ企業の情報システム部門は単なる窓口に過ぎず、決定する権限が圧倒的に弱い。

更にマズイことには、ナントカ委員会のような合議体が予算・要件を決定するために、予算・要件・ニーズの各要素が更に複数人に分かれてしまっている場合があることだ。
例えば、1ヶ月に1回開催されるナントカ委員会で、すべての委員が予算や要件を承認しないと、先に進められない状況が出てくる。
日本の組織では、こういうトロい意思決定が意外に多い。
特に公的機関はそのような場合が多いのではないだろうか?

つまり、日本の会社や公的機関の組織構造上、プロダクトオーナーのような強い権限を持つ人物が唯一人ではなく、複数人に分かれてしまっていて、誰が最終的な権限を持つのか不明なのだ。

こうなってしまった理由の一つは、ユーザ企業がSIベンダーにシステムの開発を請負契約で全て丸投げしていることもあるだろう。
あるいは、ユーザ企業の情報システム部門がコストセンターのために権限が弱く、SIベンダーがユーザ企業の情報システム部門と化してしまっていて、ユーザ企業がSIベンダーにシステムの保守だけでなく、システムの提案を通じたビジネスや業務の改善まで期待していることもあるだろう。

すると、ユーザ企業にプロダクトオーナーがいないので、SIでは、プロジェクトマネージャが限定された権限のプロダクトオーナーとスクラムマスターの2つの役割を担うことになる。
プロジェクトマネージャは、開発チームに作業指示を的確に出すこと、ユーザの要件の取りまとめとバックログの決定、開発上出てきた課題解決に至るまで、権限の範囲がとても広い。

つまり、プロジェクトマネージャの権限は開発チームよりもはるかに強力過ぎる。
開発チームとのバランスが取れておらず、一方的になっているのだ。
プロジェクトマネージャは作業量が多すぎて忙しすぎるし、開発チームは受け身になりがちで、なかなか解決されない課題のために、開発が遅延しがち。
そのために、開発チームもプロジェクトマネージャも四苦八苦する時が多いと思う。

【5】スクラムでは、上記のような問題点に対し、ソフトウェア開発には3つの役割だけで十分であり、三者が自分の役割を明確に意識して行動することで、より良いソフトウェアがアジャイルに作れると明確に指摘した。

XPはオンサイト顧客やコミュニケーションという概念を通じて、ソフトウェア開発に必要な諸要素を暗黙的に示唆した。
スクラムはそれをプロダクトオーナーや透明化という概念で明確に定義し、プロセスとして提示したことに意義があると思う。

| | コメント (0)

2013/03/11

GitHubによるソーシャルコーディングが法律や出版物を変革させる可能性

デブサミ2013で最も感銘をうけたのは、GitHubによるソーシャルコーディングがとてつもなく大きな可能性を秘めていることに気づいたこと。
考えたことをラフなメモ書き。

【参考】
Twitter / iR3:ほ? アイスランドでは皆で憲法を書こうという取り組みがあるのか。大規模で、民主的な取り組み。オープンソースのしくみが政治を変えるというのは現実の流れとして動いているのね。

Twitter / tiny_mina: 昨日撮ったNHKのTED番組「スーパープレゼンテーション」を見た。Githubを使った立法ができれば、日本は官僚政治から脱却できるんだな。でもいったい何百年後だろう。アイスランドはすでに議員がこんな動きを始めてるらしい。

Twitter / iR3: しかしソフト開発には今ふたつの踏み絵があるな。ひとつはGit ふたつめはGithub まだまだGit以前のところが沢山存在する。周回遅れの自覚はあるのかな? #devsumi #devsumiB

"翻訳" ドイツ連邦の法律がGitHubで管理される | ntcncp.net

法律はソースコードに似ている - モジログ

開発者からの強い支持、5年弱で300万ユーザーを突破:共同創業者に聞いた、GitHubは何が違ったのか? - @IT

【公開】チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ #devsumi #devsumiB: プログラマの思索

【1】GitHubがない時代、オープンソースのソースコードを修正するには、ソースコードの保持者であるコミッタへユーザが自分のパッチをメールで送って、承認してもらう必要があった。
コミッタがそのパッチを気に入らなければ、取り入れてもらえない。

また、パッチはメールで送られ、パッチの正当性を説明したり、更にパッチを修正するなどのやり取りは、メールの履歴で残していく。
延々とメールのやり取りが続き、後からログで探すのが面倒。

そもそも、オープンソースである限り、ユーザはコミッタに関係なく、自分でそのソースをフォークして改造してもいいはずなのに、そのようなやり方を採用するコストが高かった。

また、パッチを取り込むのは従来は手作業が多かったと思う。
つまり手作業でマージする場合が多かったのだ。

diffコマンドでパッチを作れば、patchコマンドで自動で取り込むことは出来る。
また、Subversionならば、trunk(メインライン)から派生したブランチ上で修正したパッチは、svn mergeで取り込むことはできる。
でも、Subversionの場合、trunkから派生したブランチ間でのマージは、merge trackingの機能が弱いためにあまり実用的でないから、手作業でマージするしかない場合が多い。
手作業のマージほど、危険で難しい作業はない。

でも、GitとGitHubが出現して大きく変わった。

コミッタが公開したソースコードは、ユーザが自由にCloneないしフォークして、自分のブランチ上で好きなように改造できる。
もしバグを見つけたら、バグ修正したリビジョンをコミッタに送って、Pullしてもらえばいい。
更に良いアイデアを機能として追加したならば、機能追加のリビジョンをコミッタに送ってPullしてもらえばいい。
これがPullRequestの発想であり、ややこしい手作業のマージ作業から開放される利点がある。

コミッタとユーザがフォークとPullRequestを通じて、ソーシャルな関係を通じて、コーディングしていくというソーシャルコーディングの流れ。
でも、PullRequestという自動マージは、単なるバージョン管理ツールの一機能という位置づけではない。
もっと大きな可能性を秘めている。

【2】Gitで管理できる対象はソースコードだけではない。
テキスト媒体なら何でも可能だ。

例えば、本のような出版物をレビューするフローを考えてみよう。

従来は、著者がWordなどの原稿に書き、バージョン管理もせず、PDF化してレビューアに配布していた。
そして、レビューアはメーリングリスト上で、誤字脱字の指摘を何ページの何行目、などのようにメールで書いて送りつけていた。

このやり方の欠点は、いくつかある。
一つは、原稿がバージョン管理されていないため推敲しにくいことや、PDFやepubのような他の形式へ変換するのが面倒なこと。
バージョン管理されていなければ、「第1章_20130311_new.doc」のようなファイル名でどんどん残してしまうため、どれが最新か分からなくなるし、修正履歴がないので後で参照する手段がない。
また、紙媒体にする時はPDFが都合がいいし、epubで出力できれば、iPhoneのようなスマートフォン上で簡単に読めるから、通勤電車や待ち時間のようなすきま時間でいくらでも原稿を読み直すことができる。
一つのテキスト媒体を複数の形式の媒体へ変換できれば、生のテキストファイルだけバージョン管理すればいい。

つまり、著者が自分の考えをテキストで書き、ツール(Sphinx、Pandoc、ReVIEWなど)で出版物(HTML, pdf, epub, docなど)へ変換すればいい。
最近は、ドキュメントを作るオープンソースのツールが揃ってきており、Kindleの自費出版のようなマーケットを考えると、重要なマーケットになってきていると思う。

Sphinx-Users.jp :: ドキュメンテーションツール スフィンクス Sphinx-users.jp

Pandoc - About pandoc

ReVIEW + Jenkinsでドキュメントを常時ビルドする | Ryuzee.com

もう一つは、レビューアから指摘された事項を逐一反映するのが面倒なこと。
もし、原稿をGitHubでバージョン管理しているならば、レビューアがその原稿をフォークして、誤字脱字の箇所はパッチとして著者に送りつけて、PullRequestしてもらえばいいのだ。
その方が手っ取り早いし、指摘箇所の反映漏れもなくなる。
しかも、PullRequestの修正履歴がmaster上に残るので、修正履歴も確実に残せる。

この手法は、著者だけでなくレビューアも含めた仲間全員でより良い出版物を作ろうとする活動になる。
つまり、より良い創作物を作るには、外部のフィードバックだけでなく、外部の力を利用して修復してもらう手法も取り入れると良いことを暗示している。

【3】GitHubに関連する記事で最も興味深いのは、ドイツやアイスランドでは、自国の憲法や法律の条文をGitHub上で自由に修正してフォークしたりPullRequestすることで、実験しながらより良いものを作っていこうという動きがあることだ。

そもそも、憲法のような条文はテキスト媒体なので、Gitのようなバージョン管理と相性が良い。
しかも、YY年にXと言う理由で法律を改正した、という内容は、バージョン管理のリビジョンのコミットログに位置づけられる。
つまり、法律というmasterのコードライン上で、条文の修正がコミット履歴として残ることに対応する。

憲法のように、その国の基本的な条文は国民自らが理解するだけでなく、現状に合うように修正したり、逆に悪い現状を正すために別の法律を修正することが大切になってくる。
その時、GitHub上で憲法や法律をフォークしておき、現状に応じて色んな状況に対応できるように、条文を変えた場合、整合性が取れるか、実現可能であるか、試せばいい。
つまり、各ブランチ上でいろんな法律の解釈を試せばいい。
そして、法律の解釈に相当する各ブランチで、これはいいと思う修正内容は、パッチをPullRequestで送りつければいいのだ。

GitHub上で法律の解釈を各ブランチ上でフォークして修正して実験する手法は、その法律の妥当性を考えさせる訓練になるだけでなく、法律が人を縛る道具ではなく、逆に人を守る道具になるように変えてくれる可能性があると思う。
特に最近は、勝間和代さんが情報主義と呼ぶように、情報を知らない人、知識に無知な人は専門的知識のある人の餌食になりやすい。
特に法律はその傾向があると思う。
だからこそ、法律のような硬いものはGitHub上のソーシャルコーディングによって、更に民主化できる余地があるように思う。

もちろん、GitHubで管理されている法律の条文はテキスト媒体だろうから、SphinxやPandocのようなツールでPDFやepubなど各種媒体で簡単に配布できる。
沢山の人に触れられるようになれば、より真剣に考える機会も増えるだろう。

GitHubによるソーシャルコーディングは、単なるツール上の一手法だけでなく、政治的影響力も秘められていると思う。

| | コメント (0)

2013/03/09

37シグナルズ「小さなチーム、大きな仕事」の感想

37シグナルズのDHHが書いた「小さなチーム、大きな仕事」について感想をメモ書き。

書評:小さなチーム、大きな仕事ー37シグナルズ成功の法則 - Social Change!

Bugle Diary: [本]小さなチーム、大きな仕事

小さなチーム、大きな仕事―37シグナルズ成功の法則 - 基本読書

【起業&仕事術】「小さなチーム、大きな仕事―37シグナルズ成功の法則」:マインドマップ的読書感想文

「小さなチーム、大きな仕事―37シグナルズ成功の法則」を読み終えて - アインシュタインの電話番号?

World Cafe: 『小さなチーム、大きな仕事』を読む

小さなチーム、大きな仕事―37シグナルズ成功の法則 | bmblog

Ruby on Railsの創始者で一躍有名になったDHHが書いた本の日本語訳。
小さなソフトウェア会社が活躍するための経験知が書かれている。

気に入ったフレーズを書き残す。
()は僕の感想。

・現実の世界なんて無視しよう
 →現実の世界は場所ではなく、言い訳だ。何も試さないことの正当化だ。あなたには関係ない。

・「失敗から学ぶこと」は過大評価されている
 →他人の失敗はしょせん他人の失敗だ。一度成功した起業家は次もうんと成功しやすい。進化は常に上手くいったものの上に築かれ、過去の失敗は引きずらないものだ。
  (成功体験が人を基本的には成長させる)

・あなたに必要な物を作る
 →すごい製品やサービスを生み出す最も単純な方法は、あなたが使いたいものを作ることだ。自分で欲しい物を作れば、直接すばやく、代理を通さずに品質を評価できる。
  何と言っても、「自分自身の問題を解決する」アプローチは、作り手は作る物と恋に落ちる。問題をよく知っているだけでなく、解決の価値も知っている。
  (好きなモノこそ上手になれ)

・必要な物は思ったよりも少ない
 →本当に10人必要か?
  本当に50万ドル必要か?
  本当に6ヶ月必要か?
  本当に、オフィス、倉庫、広告、会計士、工場、店舗、IT部門が必要か?
  いずれ実際に大金のかかる道に行ったとしても、今ではない。
  偉大な企業(例えばアップル)はガレージでさえスタートするものだ。

・新興企業(スタートアップ)ではなく、企業を始めよう
 →スタートアップ企業は、自分で稼ぐ方法を見つけるまで他人のお金を使わせてもらえる不思議な場所。そこにはビジネスの論理が関係ない。でもこの不思議な場所の問題は、それがお伽話であることだ。全てのビジネスはマーケットの力と経済のルールに支配されていて、収入があり、支出があり、利益が出せなければ去るだけだ。
  スタートアップは現実を無視し、避けられないこと(利益を上げて持続可能な本物のビジネスにならなければならないこと)をできるだけ後回しにしようとする人々によって経営されている。
  利益に至る方針のないものはビジネスとは言わない。それは趣味だ。
  スタートアップというアイデアに頼ってはいけない。本物のビジネスを最初から目指そう。

・制約を受け入れる
 →制約は武器だ。資源が制限されると、それで何とかしようと、創造性が求められる。

・中途半端な製品ではなく、半分の製品
 →素晴らしいアイデアも一度に実現しようとすると一気にくだらない製品になってしまう。
  より良いものを作るには、やりたいことを半分にするのだ。
  中途半端な一つよりも、とてもよくできた半分の大きさのものを作る方が良い。
  もし素晴らしいアイデアが本当に魅力的なものならば、後からでもやることができる。
  多くのものは小さくすればするほど良くなる。
  (アジャイルの小規模リリースにもつながる)

・決断することで前に進む
 →はっきり決断しないと、仕事は山積みになり、結局、そうした山のそれぞれの問題は放置されたり、急いで処理されたり、放り出されて解決されないままになる。
  完璧な解決を待たず、決断して前進するのだ。
  決断に決断を重ねる流れに入ると、勢いが生まれ、モチベーションも高まり、あなたが決めた一つ一つがあなたの土台になっていく。
  どれほど計画しても間違ってしまうものもある。あまりにも分析しすぎて、先送りしてしまい自体を悪化させるようなことをしてはならない。

・副産物を売る
 →何かを作る時、実は何か別のもの(副産物)を生まれている。副産物に注目し、チャンスを見出すのだ。
  例えば、材木業界は、かつて捨てるだけだったおがくずやチップを売り、収益を上げている。
  37signalsも、ソフトウェアを作る会社だが、その知識をブログで公開し、ワークショップや雑誌の記事になり、最終的に今の本となって出版された。その副産物として、100万ドル以上の利益が37signalsに入ってきた。
  ソフトウェア会社は普段、本を書くことを考えてない。バンドは普通、収録の過程を映像で撮って売ろうと考えていない。自動車会社は普通、製造工程で出てきた木の切れ端を豆炭にして売ろうと考えていない。
  でもそれら副産物で収益を上げることができる。おそらく、あなたも売れるかもしれない何かを作っているだろう。
  (出版した人ならこの感覚はわかるはず)

・柔道のような解決策を見つけるのだ
 →柔道のように、最低限の力で最大の効果を発揮するそこそこの解決策を見つけるのだ。それに後からでも、そこそこなものはとても良いものに変えることができるから。

・小さな勝利を手に入れる
 →仕事のはずみはモチベーションの燃料だ。
  あることを成し遂げ、次のことに進むことによって仕事のはずみが生まれる。

・ヒーローにはなるな
 →やめることが最善の方法になりうる時もある。
 既に一つのことにそれだけの価値がないほど多すぎる時間を費やしたのであれば、そこから手を引くこと。

・長すぎるToDoリストは終わることがない
 →長いリストにはゴミが集まる。長いリストには罪悪感を抱かせる。
  長いリストはいくつもの小さいリストに分解しよう。
  問題を素早く扱うことができるように、可能な限り小さな要素へ分解するのだ。

・小さな決断をする
 →大きな決断は変えるのも難しいし、たとえそうでなかったとしても自分は正しい決断をしたと信じ続ける傾向がある。客観的でなくなってしまう。
  そのかわり、効率良く一時的な小さな選択をしよう。
  小さな決断は大きな間違いをすることもない。変更の余地がある。失敗しても大きなペナルティはなく、修正するだけだ。

・けんかを売る
 →競合相手が最低だと思ったらそう言おう。アンチでいることは、あなた自身を差別化し、人を惹きつけるのに非常に良い方法だ。
  例えば、アウディ、アップル。
  敵を持つことは顧客に伝えるための素晴らしいストーリーをもたらしてくれる。人々は対立によってかき立てられ、情熱に火がつく。
  (良いコンフリクトは場を活性化させる)

・基本的に「ノー」と言おう
 ”顧客の言うことを聞いていたら、もっと速く走る馬を彼らに与えていただろう。(自動車王:ヘンリー・フォード)”
 →「ノー」と言っても後悔することはめったにないが、「イエス」と言って後悔することはよくある。

・顧客をあなたよりも成長させよう
 →既存の顧客にこだわり続けていると、新たな顧客から自社を切り離してしまう。
  あなたの製品やサービスは既存顧客にあまりにも最適化されすぎており、新たな顧客に魅力がないものに写ってしまう。
  顧客が成長すると、アプリケーションが彼らのビジネスに合わなくなってくる。
  でも僕らはノーと答えた。その理由は、顧客が僕らの製品をモノにできないよりも、顧客には僕らの製品を追い抜いて欲しいと考えていたから。
  あなたの製品を使っている人よりも使っていない人の方が多く存在する。そうした人達が使い始めることができるように、製品が小さくてシンプルになっているようにしよう。
  あなたの会社、ニーズがコロコロ変わる特定の個人よりもあるタイプの顧客に忠実であるべき。
  (顧客が重要なのか、マーケットが重要なのか)

・無名であることを受け入れる
 →無名であるときこそ、思い立ったアイデアを試してみよう。
  例えば、ブロードウェイも大きな公演の前に小さな町でテスト公演することで、俳優は専門家の厳しい評価を受ける前に観客から生の評価を受けることができる。
  (デブサミのような大きな講演の前に、小さなコミュニティで講演する体験をしておくことが大事)

・観客を作る
 →どんな会社にも顧客はいるが、一番幸運な会社は観客がいる。
  今の時代の最先端を走る会社は、莫大なお金を広告にかけるよりも、人々に来てもらうようにする。観客は時々あなたの所に舞い戻ってきてくれる。観客は一番理解なる顧客であり、一番の見込み客だ。
  37signalsはブログに毎日10万人以上の読者、つまり観客を築いてきた。彼らはブログの内容に興味を持ってくるわけだから、僕らの製品、僕らが売る物にも共感を示してくれるはずだ。
  昔ながらの方法では、毎日10万人の人に連絡するにはいくらのお金があっても足りない。
  話す、書く、ブログを書く、ツイッターでつぶやく、映像を作る、などで観客を作る。
  価値ある情報を共有し、ゆっくりと確実んい忠実な観客を獲得すれば、何か言いたい時にも、然るべき人達が既に聞いてくれている。
  (ソーシャルビジネスの基本的な考え方につながる。TwitterやFacebook、Blogは、TVの広告よりもはるかに影響力がある)

・料理人を見習う
 →優れた料理人は、自身が知っていることを公開し、皆と共有することで有名になる。
  彼らは自身のレシピを料理本に記載し、自身の技術を料理番組で披露している。
  彼らは、そうしたレシピやテクニックだけでは彼を凌駕するのに十分でないと知っている。
  経営者も彼らを見習うべきだ。
  あなたも著名は料理人を見習おう。
  彼らは料理し、料理本を書く。
  あなたはのレシピ、料理本は何か?
  (ノウハウをオープンにした方が実は儲かる。ソーシャルな時代の流れ)

・人を雇うにはまず自分自身から
 →まず自分自身でやってみるまで誰かを雇ってはいけない。
  自分で仕事の本質を理解すれば、新しい人達のマネジメントもうまくできる。いつ厳しく接し、いつ励ませば良いのか分かる。

・会社を知人のいないパーティにしない
 →短期間に人をたくさん雇うと、知人のいないパーティになってしまいがちだ。
  いつも新しい顔があるのでよそよそしくなり、対立や劇的な反応を避ける。
  物事が厳しくなった時にも皆が率直に自分の意見を言えるような環境が必要だ。
  それがないと、人の感情を傷つけないが誰も愛さない商品を作ることになる。
  (急成長の会社でありがちな罠)

・文句は放っておく
 →議論の的になったからと言って、バカみたいに後退しないことだ。
  たいていの場合、人はいずれ自分たちで変化に適応する。
  一回新しい方針に慣れればその方が前より良いと思うものだ。
  人が文句をいう時は、しばらく様子を見たいとはっきり言ってしまうことだ。
  (他人を気にするな、自分の内なる声を大切に)

・ロックスターは環境が作る
 →人は駄目な仕事、普通の仕事、素晴らしい仕事をする。
  それは我々の想像以上に環境による所が大きい。
  ロックスター環境は信頼と自律と責任から生じるものだ。
  良い環境は働いている人を尊重している証拠だ。

・ひらめきには賞味期限がある
 →皆がアイデアを持っている。
  ひらめきには果物や牛乳のように賞味期限がある。
  何かしたいことがあれば、今しなければならない。
  ひらめきは不思議なものだ。生産性を高め、ヤル気をあおる。でも、待ってはくれない。

| | コメント (0)

チケット駆動開発の英訳記事が公開されました

Atlassian Blogsにチケット駆動開発の英語記事が公開されたのでリンクしておく。

【元ネタ】
What is Ticket Driven Development, and why is it attracting attention in Japan? | Atlassian Blogs

[#TiDD] 世界に飛び出したチケット駆動開発: ソフトウェアさかば

アトラシアンブログに「チケット駆動開発を上手に運用するためのプラクティス」の記事を書きました: プログラマの思索

なぜ日本ではチケット駆動開発が注目されるのか?: プログラマの思索

ticket-driven development; TiDDの意味 - 英和辞典 Weblio辞書

@sakaba37さんと僕が書いたAtlasianの記事を大澤さんが英訳してくれました。
(僕の顔写真がないのが寂しいですが笑)

3人の方が以下のコメントを付けてくれています。
海外でもチケット駆動開発に興味を持っている人は多いようです。
おそらく、「チケット駆動開発」という言葉を使わなくても、似たような開発スタイルは日本だけでなく海外でも普通に行われているのでしょう。
コメントの中で、アジアではまさにホットなテーマだという言葉が気になります。

(1)Nice Post Ticket Driven Development is very new for us and it is very useful. Thanks for sharing.

(2)Ticket Driven Development is a hot subject in Asia right now, and due to its reputation we co-authored a guide about it. Initially we considered Ticket Driven Development was getting lots of attention due to exclusive aspects in Asia.

(3)Is the the book available in English?

(4)We are also using the same pattern.We have sprints divided in tickets and tickets have complete life cycle.Tickets are further bifurcated in technical tasks,story etc.and tickets are linked to code commits.

二番目のコメントの方は、Ticket Driven Developmentのガイドを共同執筆したというコメントがあり、どんな内容なのか気になる所です。
(リンク先はインドの人らしい)

| | コメント (0)

2013/03/03

日本人が書いたアジャイル開発本が増えてきた

2013年になってから、日本人自身がアジャイル開発の経験知を書籍にまとめて、形式知として普及させようとする流れが起きている。
とても注目に値する動きだと思うので、リンクしておく。

【参考】
アジャイルBooks - Developer's Factory

Twitter / akipii: いいね 翔泳社編集部のサイト「SEeditors」にて、2月のPC書売れ筋ランキングを紹介しています。http://bit.ly/WqCNZk スクラム本2冊『SCRUM BOOT CAMP THE BOOK 』『アジャイル開発とスクラム』がランキング上位入り!

Twitter / akipii: まさしく同感 RT @legoboku: 日本人による本が続々と。 / “http://Amazon.co.jp : わかりやすいアジャイル開発の教科書: 西河 誠, 前川 直也, 細谷 泰夫: 本” http://htn.to/34QqJC

Twitter / akipii: 「私たちの中に確かに存在するが簡単に説明できないアジャイル」という言葉はとても実感する。コンテキストを共有できるのに他人にアジャイルを説明するのは難しい。「わかりやすいアジャイル開発の教科書」 - Yasuo's Notebook http://yasuo.hatenablog.com/entry/2013/03/02/230650 …

「わかりやすいアジャイル開発の教科書」 - Yasuo's Notebook

Scrumの公開資料: プログラマの思索

Scrum本が最近続々出てきた: プログラマの思索

【1】一番重要な本は、平鍋さんが書かれた「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」。
平鍋さんに書籍の特徴について伺った時、経営層や管理職層に呼んでもらうために、文章を縦書きにして、極力ソフトウェア開発の内容を省いて、アジャイルの思想やエッセンスを書くようにした、と聞いた。

日本人自身がアジャイルの概念を生み出した後、アメリカでソフトウェア開発へ適用して育てられ、日本に逆輸入された経緯がとても分かりやすく書かれている。

「アジャイル開発とスクラム」の感想: プログラマの思索

野中郁次郎先生の講演資料の解説記事: プログラマの思索

【2】前川さん、西河さん、細谷さん共著の本「わかりやすいアジャイル開発の教科書」ももうすぐ出版される。

「わかりやすいアジャイル開発の教科書」 - Yasuo's Notebookに本の裏話が書かれていて、その一節にこんな文章が書かれていてとても共感した。

(引用開始)
アジャイル開発には、アジャイルソフトウェア開発宣言に賛同しているという以外に明確な定義はありません。SCRUMやXPはフレームワークやプラクティスを紹介することができますが、「アジャイルとはこういうことだ」と説明するのは難しく、あたかもアジャイルは実体が存在しないような印象もあります。それが最初に私が「チャレンジャーだなぁ」と思った理由です。
でも、同時に私がずっと感じてきたことがあります。「アジャイルには、はっきりとした実体がないように思えるのに、アジャイルコミュニティーの仲間と、アジャイルについての確かな共感が存在する」ということです。10年余りのアジャイルコミュニティーの活動をふりかえると、いろいろな仲間と出会ってきました。
古くから一緒にXPJUG関西や東京のXPJUGで出会った皆さん、ここ数年で知り合ったSCRUM実践者の皆さんなど多くの方々と出会って一緒に活動してきましたが、いつも感じることは、会って少し話するだけでお互いのコンテキストを共有して、共感することができることです。まるで長い間知り合いだったような錯覚を覚えることもあります。
その理由は、私たちの中に、アジャイルが確かに存在して、それをバックグランドとして共有しているからではないかと考えています。今回の書籍は「私たちの中に確かに存在するが簡単に説明できないアジャイル」をできる限り表現しようと努めました。
(引用終了)

アジャイルという言葉を定義して説明するのは難しいのに、コミュニティでは以前から友人だったかのように、初対面のアジャイラーともすぐに仲良くなれるという矛盾。

【3】日本のScrum本は、@ryuzeeさんたちが共著で書かれた本「SCRUM BOOT CAMP THE BOOK」で決まりかな?

【4】日本人が書いたアジャイル開発本が増えることが重要な理由は、10年前にXPを中心としたアジャイル開発が日本ではあまり普及せず、潰された苦い経験があるから。
Scrumを主流としたアジャイル開発の手法も、アメリカで上手くいっているかもしれないが、日本の開発現場にそのまま適用できるとは思っていない。
だから、誤った理解で失敗した経験で、アジャイル開発はうまくいかないという固定観念が生まれる危険性があるからだ。

Twitter / ryuzee: 待っててください! RT @akipii: 日本人が書いたScrumの辞書みたいな本が早く出版されて欲しい。Scrumの概念を引用する時はこの本を参考にして、みたいにしたい。間違った理解でScrumの概念を説明されるとコミュニティの人も困るだろう。

Twitter / akipii: XPやリーンソフトウェア開発は@hiranabeさんや長瀬さん達が数多くの翻訳本を出版してくれているので、文献を参考にすれば用語を理解しやすい。Scrumも同様に日本人が翻訳するなり著作するなりして、アジャイル開発の普及の弾みにして欲しい。やっぱり書籍は重要!

Twitter / hiranabe: @akipii スクラムの日本語書き下ろしの本が、来年ぞくぞくと出るらしいよ!

Twitter / akipii:@ryuzee @hiranabe Scrumに出てくる独特な用語、(プロダクト)バックログ、スプリント、スクラムオブスクラム、チームリード、Velocityなどを1冊の本で解説して欲しいのです。日本の大手SIがアジャイルに注目した今、Scrum解説本は重要度を増してます。

Twitter / akipii:@ryuzee @hiranabe 日本の大手SIがアジャイル開発を導入しようとする今、日本のアジャイルコミュニティからScrum解説本やアジャイルの実践ノウハウ本をもっと多く出すべきと思います。間違った理解によるアジャイル開発の失敗例がCMMIのようにたくさん出てきそう

2013年になって日本人がアジャイル開発の書籍を次々に出版していく背景には、過去10年間、コミュニティを中心にアジャイル開発を実践してきた経験知がようやくまとまってきて、世間に説明できるほどの質と量が集まってきたのも理由の一つかもしれない。
今後出版される日本人のアジャイル書籍には注目していく。

| | コメント (0)

改訂Trac入門

〔改訂〕Trac入門が5年ぶりに出版されるらしいのでリンクしておく。

【元ネタ】
2013-03-01 Trac 入門 <改訂版> 出来!- kondoumhの日記

僕と@sakaba37さんが「Redmineによるタスクマネジメント実践技法」を出版した頃、ITSを使ったチケット駆動開発に関する書籍は「Trac入門」ぐらいしかなかった。

第1版の「Trac入門」では、Tracのインストールや設定方法だけでなく、PMBOKの各プロセス領域にITSがどこまでカバーできるか、という観点の記述もあり、プロジェクトマネージャを読者層に入れることも意識して書かれていたように思う。

あれから5年以上経つけれど、ソフトウェア開発で何らかのツールも無しで開発を進めるチームはありえないだろう。
最近、チケット駆動開発に限らず、日本人自身が自らの開発現場におけるアジャイル開発の経験知を書籍にまとめて出版する事例が多くなってきた。
そういう背景を考えると、日本でアジャイルはキャズムを超えたというだけでなく、日本のソフトウェア開発も新しい段階に上がってきたのではないかと思う。

| | コメント (0)

チケット駆動開発の課題~ITILやDevOpsの適用方法

Redmineなどのチケット管理ツールをタスク管理ではなくインシデント管理で運用する場合、従来の手法ではうまくいかない場合が多いし、そのような経験をたくさんしてきた。
思ったことをラフなメモ書き。

【1】例えば、自社でAmazonや楽天のようなショッピングカートのWebシステムを持っているとしよう。
すると、新しい機能を追加していく開発チームと、Webシステムのインフラ構築やインフラ周りの監視に関わる保守チームの2つのチームが自然に体制として現れる。

システムは自動車などの製品とは違って、リリースした後、ユーザに使われてからが本当の本番だ。
何故なら、システムが稼働して初めて、ショッピングカートにクレジット決済などで現金が入り、売上が上がっていくからだ。

システムが使われていくと、ショッピングカートの動きがおかしい、ここのユーザインターフェイスが使いづらい、404エラーが出た、突然画面に接続できなくなった、などたくさんの障害やら、単なる問合せと思っていたのに重要な障害だったと判明するような問合せが毎日届く。
保守チームはこのような問い合わせに対し、1つずつ調査してはユーザに回答したり、障害と判明すれば開発チームに修正依頼を出して緊急リリースしたりする。
特に、Exceptionが出たとか、画面に表示される利用金額が狂ったとか、個人情報が漏れたとか、システムや会社の信用に関わる障害が発生したら、即座に対応しなければならない。

だから、保守チームはコールセンターのように電話受付やメール当番もしながら、サーバーの保守や監視、開発作業をするのだから、とても忙しい。

プログラミングの開発とサーバーインフラの構築はそもそも技術が全く違う。
SSL、セキュリティ周り、Zabbixなどの監視ツール、FireWallやBigIPなどの切り分け、Apacheの負荷分散、RAID5によるHDD分散によるバックアップなど、単なる開発とは違う技術が必要とされる。

また、開発チームへの連携も意外とうまくいかない時が多い。
2つのチームメンバーに要求される役割も違うのでお互いを理解し難いし、一つのインシデントに関わる人が多いほど、伝言ゲームになりがちで無駄が発生しがち。

つまり、開発チームと保守チームは、元々風通しが悪く、そのためにリリース間隔が長くなりがちな状況がとても多い。
それが原因でシステムが大規模化し複雑化するほど、リリースサイクルが長くなり、障害も多発しやすい。

そのような状況を解決するために、ITILのような運用保守フレームワークや、開発チームと保守チームは一体化すべきだというDevOpsのような考え方が出てきたのだと思う。
だが、そのような考え方を実際の現場に適用する場合、そう簡単に当てはまるとは限らない。

【2】ITILのようなIT運用保守フレームワークでは、インシデント管理→問題管理→変更管理→リリース管理でプロセスが流れていく。
普通の現場でITILを適用する場合、インシデント管理は保守チームが担当し、問題管理以降は開発チームが担当する時が多い。
何故なら、実際のシステムの機能を修正するなら開発チームが担当するからだ。
但し、HDD故障が障害の原因ならば、問題管理以降は保守チームが引き続き担当するし、OracleやWebSphereなどのようなミドルウェアに障害があるならば、ベンダーに作業を依頼し、保守チームが変更管理プロセスでリリース計画を立てるなどの作業をするだろう。

つまり、問合せの内容によっては、プロセスを担当するチームや関係者が変わってくる。
また、一つの問合せは、状況に応じてステータスが頻繁に変わる。
今は誰がボールを持って担当しているのか、今何が課題なのか、をリアルタイムに追跡できる仕組みがなければ、ITILは絵に描いた餅だ。
普通はExcelのインシデント管理表から、ステータスが変わるたびに別のExcelの問題管理表、変更管理表へ転記されて、どんどん複雑化していく。
この問合せは結局、何が原因で、どのように解決したのか、という結論を知りたいだけなのに、延々と経過報告ばかり読まされたりする。
せっかく蓄積されたインシデントや障害管理票のデータを生かしきれていないチームはとても多い。

【3】実際の運用保守プロセスは3層構造が多いと思う。
まず、問合せを一次受付するインシデント管理。
その問合せをまず事前調査して、FAQやWikiを参照すればすぐに回答できる問題なのか、あるいは、再現性がなく時間が掛かる根深い問題なのか、あるいは、ハードウェア故障やネットワーク回線の問題ゆえにベンダーに更に調査依頼すべきなのか、を判断する問題管理。
そして、障害修正や問題解決の方法が確定している前提で、リリース計画を立てて修正とテストを実施し、デプロイ&リリースしていく変更管理とリリース管理。

ここで一番重要なプロセスは、問題管理プロセス。
何故なら、問合せに対して、できるだけ早く問題解決の方針を立てたり、優先度を付けるプロセスだから。
この問題管理プロセスで時間がかかると、大したことがない問合せが実は個人情報漏れやシステムの故障につながり、会社の信用に関わる重大な障害を引き起こしたりする場合がある。
だから、問題の原因と解決方法を早く的確に示すことが重要。

だが、日々の問合せは結構多いために、一つの問合せに対する解決方針を立てる作業は時間が掛かりがち。
保守チームはそもそもコストセンターなので、さほど優秀な人員が多いとは限らないし、人数も少ない。
リリース直後は問い合わせが多いだろうが、システムが安定稼働していれば暇なので、人が多く張り付くと赤字になるから。
この問題管理で判断を間違ったり、問い合わせ対応の優先度を間違えると、保守チームだけでなく開発チームの作業負荷が多くなり、最終的にはシステムの機能改善や障害対応に支障をもたらす。

【4】Redmineのようなチケット管理ツールでITILを運用する時、タスク管理や課題管理とは異なるノウハウが必要だと思う。
インシデント管理からリリース管理までのそれぞれのプロセスはワークフローが全く違う。
変更管理以降のプロセスは普通のタスク管理に近いが、インシデント管理や問題管理は、JiraやTracで使われる課題管理に近い。
だから、一つのワークフローで全てのプロセスをカバーしようとすると、現場でうまく作業が流れない。

また、ITILのような運用保守では、チケット集計機能がとても重要だ。
今日までインシデントは何件発生して、どれだけ未対応なのか。
このインシデントは誰が担当していて、今どんな課題を抱えているのか?
直近1ヶ月のインシデントを集計すると、どのような傾向が見られるのか?
それらの集計結果や過去の対応ノウハウを蓄積したら、特定の日に発生する障害を事前に見つけることができたり、定期的に対応した方が良い運用作業へ落としこむのができるのではないか?

個人的には、Redmineはチケット集計機能が弱い。
むしろ、JiraやTracの方がチケット集計機能が強い。

また、チケットをインシデントや変更管理のタスクにどのようにマッピングすればいいのか、という問題もある。
インシデント管理・問題管理・変更管理(+リリース管理)の3層構造のプロセスをどのようにチケット管理へ適用すると良いのか?

一つのチケットで3層構造のプロセスを当てはめるのは多分うまくいかない。
ステータスが増えすぎて分かりにくいし、作業者が混乱しやすい。
また、チケットがなかなか完了しないので、チケットがどんどん増えていき、チケットの重みで破綻する。

インシデントを親チケット、問題管理以降のタスクを子チケットで管理する方法もあるが、運用が複雑になりがち。
子チケットはどんどん増えるし、全ての子チケットが完了しなければ、親チケットのインシデントは完了できない。
例えば、問い合わせに対し暫定対応したものの、本格対応は更に調査が必要だったり、多くの工数がかかるため延期する場合、インシデントのチケットは残ったままになる。
すると、完了できないチケットはどんどん増えていき、優先度を付けることすら難しいぐらいチケットが氾濫してしまいがちになる。

また、実際の運用では、インシデントだけを集計して、問合せの発生源や原因、種類などを傾向分析したいものだ。
なのに、一つのチケットで複数のプロセスを表していると、集計しづらいし分かりにくい。

僕が今ベターと思える運用方法は、インシデント管理・問題管理・変更管理(+リリース管理)のそれぞれのプロジェクトをRedmineの親子プロジェクトにマッピングし、それぞれのプロセスを独立したチケットで管理し、細かな作業タスクはそれぞれのプロセスのチケットの子チケットで管理するやり方。
それぞれのプロセスは、担当するチームや関係者が異なる時が多いし、それぞれのプロジェクトでチケット集計すれば、ステータスや工数、傾向分析の集計がやりやすいからだ。
但し、チケットがその分細分化されるため、煩雑になるトレードオフはある。

【5】DevOpsという概念はとても過激な概念だと思う。
リリースサイクルを3ヶ月に1回から1ヶ月に1回、1週間に1回、1日に数回などのようにどんどん短くするには、一人ないし少人数で、開発からデプロイ・リリースまでの全てのプロセスを担当できるようにならなければ、絵に描いた餅だ。

開発と運用の新しい関係、「DevOps」とは何か? - Publickey

「開発と運用の一体化」という言葉はとても美しいが、それを本当に実現するならば、開発メンバーはインフラチームの仕事もできるし、保守メンバーは開発チームの仕事もできるような文化にしなければならない。
例えば、プログラミングもできるし、自分一人でサーバー構築できるし、HDD交換やネットワークの配線設置作業もできるマルチな能力をメンバー全員が持つような状況を指す。

DevOpsを実現するには、ツールと文化が必要と言われるが、その理由は、ツールによってインフラ周りをできるだけ自動化して誰もが簡単にリリースできるようにすること、そして、開発メンバーとインフラメンバーが協力して作業できるような環境が必要であることを示唆しているからと思う。

最近のDevOpsの記事などを読むと、AWSなどのクラウド、Chefなどの環境構築ツール、Jenkinsなど万能のジョブ管理ツールを駆使して、プログラムを書いたら即座にリリースできるような仕組みがあって初めて実現できるように思える。
つまり、HDD故障やネットワーク回線の混雑などの意識しないようなインフラを構築できれば、開発チームがインフラチームを兼ねるDevOpsないし、そもそもインフラ運用など不要というNoOpsが実現できるわけだ。

Scrumではフィーチャーチームと呼ばれる概念があり、大規模プロジェクトで複数チームがScrumを運用する時、作業単位や工程単位ではなく、機能単位のチームを作り、一つのチームがなんでもできるような体制を作る。
DevOpsの概念は、Scrumのフィーチャーチームを実現ないし補強する概念だと思う。

フィーチャーチーム: プログラマの思索

つまり、開発者がインフラ構築ないしリリース作業もできるような多能工になることで、Scrumのフィーチャーチームという体制を組むことができる。
でも、僕はそのような経験がないので、Scrumのフィーチャーチームで回すために必要な制約条件が何か、はまだ分からない。
おそらく、そう簡単な適用方法ではないだろうと思っている。

| | コメント (0)

« 2013年2月 | トップページ | 2013年4月 »