« 2013年1月 | トップページ | 2013年3月 »

2013年2月

2013/02/24

CentOSにRubyをインストールする

CentOSにRubyをインストールする方法はいくつかある。
rvmでインストールするのが一番簡単だったのでメモ。

【元ネタ】
さくらVPS/CentOS 6.3 Ruby 1.93/RVMのインストール手順[Railsサーバへの道] - 酒と泪とRubyとRailsと

RubyはRPMがなかなか見つからない。
できれば、1.9.xを入れたいがRPMをソースから作るか、ソースからmakeしてインストールするかのいずれかしかない。

上記の記事では、rvmをインストールして、rvmからRubyの複数バージョンをインストールする方法が書かれている。
この方法ならば、1.8と1.9の両方を使えるし、rvmをアンインストールすればいいだけ。

sudo yum -y install curl curl-devel gcc gcc-c++ git openssl-devel httpd-devel readline-devel tk-devel make zlib-devel libffi-devel

sudo yum --enablerepo=epel -y install libyaml-devel

sudo bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

sudo usermod -a -G rvm root
sudo gpasswd -a ateam rvm
sudo gpasswd -a apache rvm

source /etc/profile.d/rvm.sh
rvm get head

rvm install 1.8.7
rvm use 1.8.7
rvm install 1.9.3

rvm use 1.9.3 --default

rvm list
で確認

cp -ip /etc/rvmrc /etc/rvmrc.org
vim /etc/rvmrc

rvm_trust_rvmrcs_flag=1
を追加

gem install bundler --no-ri --no-rdoc
もOK

| | コメント (0)

「ソフトウェア・グラフィティ」の感想

ソフトウェア・グラフィティを読んだ。
エッセー風の語り口が読みやすかった。
感想をラフなメモ書き。

ソフトウェア・グラフィティは、SRAを創立した岸田さんの自叙伝みたいなもの。
本来は詩人・画家と書かれているように、ソフトウェアの本と言うよりも文系に近い本なので、難解な部分もある。
でも僕には、ああなるほどと思える部分が多々あった。
以下、心に響いた部分を抜粋し、()の部分は僕の感想。

【1】構造化設計は2種類ある。
ダイクストラはGOTO文を破棄する方向。
それは、読みやすいプログラムをコンピュータ上でそのまま実行できるように設計しようとする発想。
逐次実行、分岐、反復の命令型言語への流れ。
ジャクソンやワーニエは、データ構造を反映するようなプログラムへ設計仕様とする発想。
対象システムのモデル化の発想は、多分DOAへの流れ。
つまり、二人の構造化設計の発想は全く異なる。

【2】ソフトウェア開発は演劇。
プロマネは舞台の監督。
シナリオ(システムの仕様書)をベースに、役者(プログラマ)のキャスティングを決めて、それぞれの演技(開発活動)をうまく取りまとめて、顧客(ユーザ)の満足を勝ち取る。
だが、本来ユーザが考えるべきシステムの問題解決をプログラマへ要求するようになるため、プログラマから特定分野のコンサルタントに転進していく人が多い。

【3】リーマンのソフトウェア進化論。
IBMのOS360プロジェクトを元に見出した経験則。
3つの法則がある。
第1の法則は、ソフトウェアサイズは時間の経過と共に増加する。
第2の法則は、ソフトウェアの品質は時間と共に劣化していく。
つまり、ソフトウェアもエントロピー増大の法則に従う。

第3の法則は、保守工程におけるソフトウェアの追加・変更・削除のモジュール数の増加は時間の経過と共に比例している。
つまり、ソフトウェア保守の組織的作業効率は常に一定である。
人を増やしても作業効率は変わらない。
作業の難易度や保守担当チームの人数などの要因に無関係に一定である。

(アジャイル開発では、「時間が経過してもソフトウェアのサイズや複雑さ、保守コストは抑えることができる」という発想から成り立つ。
だから、リーマンの法則に逆らう事象は可能だという発想ゆえ、根本的に異なる。)

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【4】リーマンによる2種類のプログラムの分類。
Sタイプは、仕様が確定できる(Specificable)。
一度仕様が確定できれば、その解決法(アルゴリズム)を表現したプログラムは、時間が経過しても変わらない。

Eタイプは、組み込まれた(Embeded)プログラム。
現実世界における業務を支援するために開発され、アプリケーションに組み込まれる。
仕様は利害関係者の最大公約数で決まるものであり、要求そのものは矛盾があるのが普通。
その時点の暫定的な仕様であり、時間が経てば、環境が変わったり、要求そのものが変わったりして、仕様も変わる。
1回目は「開発」、2回目以降は「保守」という開発サイクルは間違っている。

【5】プロジェクトマネジメントの基礎として、ソフトウェアの価値はどのように定義すべきか?
普通は、開発工数(人月)を元に評価し、進捗に応じて生産高を確定するのが主流。
(EVMみたいだ)
しかし、ソフトウェア開発は本来無形労働(Immaterial Labor)であり、その成果を定量的に把握するのは難しい。
むしろ定性的な値で評価すべきだ。
(アジャイル開発なら、リリースされたソフトウェアと言う現物で価値を測定する。ソフトウェアのROIが価値を表す。)

【6】ソフトウェア開発環境を議論にする時、生産性向上や品質改善を第1目的にすると楽しくない。
ソフトウェアファクトリーは、駅弁をどうやって早く安く作るかを目指したものであり、料理人にとって楽しい仕掛けではない。
(ソフトウェアの工業化の方向性は、アジャイル開発とは全く違う。
アジャイル開発における開発環境の整備は、リリースするサイクルをいかに短くして価値あるソフトウェアを作っていくか、が根本的な発想。
チケット駆動開発もその流れの一つ。)

日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経

| | コメント (0)

3/23に「プロジェクトマネージャー・リーダー必見!成功するプロジェクトのための開発基盤と手法」セミナーで講演します

3/23に「プロジェクトマネージャー・リーダー必見!成功するプロジェクトのための開発基盤と手法」セミナーで講演します。

【参考】
プロジェクトマネージャー・リーダー必見!成功するプロジェクトのための開発基盤と手法|セミナー|Growth xPartners Corporate Site

基調講演「チケット駆動開発をパターン言語で読み解く」

昨今、JIRAやRedmineのようなプロジェクト管理ツールをソフトウェア開発のタスク管理に適用し、アジャイルに運用する「チケット駆動開発」が日本の開発現場で静かに広まっています。
本講演では、チケット駆動開発をパターン言語として再構成するアイデアを元に、チケット駆動開発が何故有効であるのか、そして今後どんな方向へ進化すべきなのか、についてお話します。

【概要】
デブサミ講演後のAsked The Speakerで4人の方から質問をいくつか受けました。
内容を聞きながら、チケット駆動開発を実践している人が多い事実に改めて驚きました。
質問を聞くと、現場のリーダーやマネージャクラスの人達がチケット駆動開発に興味を持って各種ツールを導入してみて、試しているようです。
でも、それなりに効果を挙げているが、実際の運用面ではまだまだ改善点が多いという印象を持ちました。

僕自身、自分の限られた現場でしか運用していませんし、チケット駆動開発がソフトウェア開発の全ての問題を解決できるとは思っていません。
ソフトウェア開発の宿命と言える「複雑さ」「初めての技術の使いこなし」については、その問題点を低減させることはできても、根本的になくすことはできない。
たぶん、チケット駆動開発はソフトウェア開発におけるコミュニケーションを活性化させることで開発チーム内部の力をより緊密化させていく利点はあるが、それだけでは問題解決できるわけではない。

どの問題に対して有効で、どの問題に対しては他の方法をとるべきなのか、パターン言語という考え方で整理してみたいと思います。

| | コメント (0)

2013/02/19

アジャイル DevOpsの記事

IBMのアジャイル DevOpsの記事があったのでリンクしておく。

アジャイル DevOps: ソフトウェア・リリース・プロセスのフラット化

アジャイル DevOps: あらゆるものをバージョン管理する

アジャイル DevOps: インフラストラクチャーの自動化

アジャイル DevOps: Chaos Monkey を使用する

アジャイル DevOps: 一時環境

クラウドは今はとても重要な技術の一つ。
その意味は、環境が単に仮想化できるという意味だけではない。
どんな環境も即座に作れるようになったことで、インフラ構築もアジャイルな設計・構築が可能になったことだ。

従来のインフラ構築では、リリース後に使われる性能要件をあらかじめ予想して、サーバー・メモリ・HDD・ネットワークなどのハードウェアを購入する必要があった。
何故なら、それらハードウェアはとても高価だったし、たとえ安くなったとは言え、リリース後に性能を増強するのは、稼働中のサーバーを止めることができない故に難しいからだ。
だから、インフラ構築は、設計・構築・テストというWF型のプロセスが今もなお主流。

でも、AWSのようなクラウドが普及していく中で、インフラ構築もアジャイルな構築が可能になってきている。
計各時の性能見積もりに厳密さを求めなくても、試行錯誤しながら、クラウド上のインスタンスをスケールアップすればいいだけだからだ。
その場合、インスタンスの設定やスケールアップの作業そのものも、プログラミングで自動化することができる。
ChefやPuppetはそういう類のツールだと思った方がいいだろう。

さようならPuppet、こんにちはChef - Masatomo Nakano Blog

サーバの構築作業やシステム管理を自動化する「Chef」|サイバーエージェント 公式エンジニアブログ

すると、環境構築の設定をプログラム化できると、それらのバージョン管理が必要になり、更には即座にデプロイするビルド管理ツールも必要になってくる。
デプロイメントの自動化としてCapistrano、ビルド自動化としてJenkinsなどが使われるわけだ。

今更聞けないCapistranoでリリースの自動化 - プログラマになりたい

また、DBスキーマの変更管理として、LiquibaseというOSSのドメイン特化言語(DSL)まであるらしい。
これはこれで面白そう。
「DBリファクタリング」をツールで実現しているみたいだ。

Liquibase | Database Refactoring | ja:home

簡単に環境を作れるとなると、性能テストだけでなく障害テストのような信頼性のテストも行うことができる。
性能負荷テストではJMeterが良く使われてきたけれども、障害テストならChaos Monkeyを使って、故意に障害を起こして耐障害性を高める修正を行うこともできるだろう。

サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 - Publickey

インフラ構築すらもプログラマブルにしてしまうというクラウドの発想は、今後も注目し続けていく。

| | コメント (0)

2013/02/17

トヨタのかんばん方式とバグ追跡システムの密接な関係

実践 反復型ソフトウェア開発」の6.10節「トヨタのかんばん方式とバグ追跡システム」がとても興味深かった。
チケット駆動開発との関係も含めて、ラフなメモ書き。

【1】BTS(バグ追跡システム)は、本来は障害管理から生まれた。
だが、BTSの開発フローがソフトウェア開発にとても有効であったために、タスク管理やユーザのサポート管理として扱うITSないしチケット駆動開発へ発展した。

BTSのチケットは、PCやサーバーなどの資産管理にも使える。
そのアイデアは下記に書いた。

情報システム部門がTiDDを運用する時の注意点: プログラマの思索

IT資産管理システムi-doIT: プログラマの思索

実践 反復型ソフトウェア開発」では、BTSチケットをPC資産のようなハードウェアと紐づけて管理するのはとても有効だろう、そこからトヨタのかんばん方式へ発展させるのは自然なアイデアだと書いている。
BTSのチケットに変更履歴が自然に残り、後から全文検索できるし、チケット集計機能によっていくらでも欲しい情報を出力できるからだ。
また、チケットのステータスで資産の状態をワークフローで管理することもできる。

【2】「実践 反復型ソフトウェア開発」にあるトヨタのかんばん方式との関係性の説明はとても面白い。
実践 反復型ソフトウェア開発」では、「仕掛けかんばん」とBTSチケットが密接に関係していると指摘している。

仕掛けかんばんは生産指示書だ。
つまり、後工程の部門が前工程の部門に対し、必要な部品とその生産内容を書く。
仕掛けかんばんは、Pull方式と密接に関係しており、在庫引き当てで重要な役割を果たす。

かんばんにはいくつか種類があり、ほかに有名なものは引き取りかんばんがあるが、これは納入指示書に相当する。

仕掛けかんばんには特徴がある。

かんばんは必ず現物が付いており、かんばんと在庫部品は1対1で対応付けられている。
これによって、在庫の部品を追跡できる仕組みになっている。

また、かんばんの運用では、枚数が肝心。
枚数が多ければ無駄な在庫が多いし、枚数が少なければ、欲しい時に部品を引き当てできないので、販売ロスにつながる。
だから、「かんばんがなければ部品の生産を開始しない」というルールを守ることが大切になる。

かんばんを紛失すると、本来引き当てるべき部品が分からなくなり、在庫数量を確定できなくなり、会計監査でNGを食らうだろう。
そして、かんばんは安易に枚数を増やしてもいけない。枚数を増やすと、無駄に多い部品が工場内に流通してしまうため、無駄が多くなるからだ。

また、かんばんに書かれた内容で作られた部品に品質不良があれば、後工程の部門の生産ラインを止めてしまう。
そのようなプレッシャーが部品の品質を高めることにもつながったと言われる。

【3】BTSチケットに当てはめてみると、BTSチケットは開発チーム内に流通して、人的リソースに引き当てられる。
つまり、チケットのステータスに応じて、テスター・開発者・ライブラリアンなどのような人的リソースがアサインされる。
そして、チケットに起票されれば、障害の発生から完了までチケット経由で追跡できる。
つまり、BTSでは、チケットの総数やステータスをきちんと管理できれば、かんばんのように物理的存在がないから、どれだけ複雑になろうとも追跡できる仕掛けがある。

すると、チケットを起点として作業を追跡するため、BTSの運用では「バグ報告票がなければ作業を開始しない」ルールを守ることが重要になる。
チケット駆動開発なら「チケットなしの作業不可」「No Ticket, No Work」というプラクティスにつながるだろう。

チケットはかんばんと違って紛失することはないが、放置されると紛失された事とほぼ同義になる。
解決すべきバグ、追跡すべきバグが放置されれば、チーム内に不良在庫がたまっているのと同じ。

完全に修正されていないバグを後工程(テストチーム)に回すと、顧客の信頼を失ったり、社会的信用を落としたりする。
特に、システムを文字通り止めてしまうようなブロッキングバグを放置したまま、テストチームへ回すと、プロジェクトで大きな混乱をもたらす。

TPSの仕掛けかんばんは、物理的存在であるがゆえに、工場内での流通量を直接制御できる利点があるが、BTSチケットはバグが増えれば、いくらでも増えてしまい、チームの開発能力を上回ってしまう時もあるだろう。
つまり、物理的な仕掛けかんばんのおかげで、工場の生産能力に見合った在庫量へ制約条件を故意に課す事ができるのに対し、BTSチケットは電子媒体であるがゆえに、その枚数に制約をかけることは原理的にはできない。

しかし、アジャイル開発におけるイテレーションの考え方を適用すれば、定期的にリリースできる期間内で対処できるようにチケットの枚数に上限を付けることができれば、開発チームは、自分たちの開発ペースで作業していけるだろう。
アジャイル開発で出てくるVelocityや小規模リリースという概念には、チケットの枚数に上限という枠をはめることで、開発チームに自分たちで状況をコントロールできる能力を付与するのだ。

※追記
「かんばんの上限値」という概念が、WIP(Work In Progress)という概念につながる。

【4】仕掛かりかんばんとBTSチケットには、多くの類似点があるが、大きな違いもある。

かんばん方式では、後工程引取り(消費部門が生産部門に必要な部品の生産を指示して引き取る(Pullする))であるのに対し、ソフトウェア開発では、欲しくもないバグは後からいくらでも沸いてくること。
また、かんばんでは解決方法(どの部品を生産していつどこの後工程の部門に送るのか)が明確に書かれているのに対し、BTSチケットが最初に起票された時はその解決方法すら書かれていない。

つまり、TPSのかんばん方式では、かんばんという指示書に作業内容や納期などが明確に書かれていて、その枚数を制限することが容易であるのに対し、BTSを基盤とするチケット駆動開発では、チケットがバグとして起票されたならばすぐに解決方法が分からないので、作業指示書にもなりえない。
バグや課題などのように、どんな作業をすればよいか、あいまいなチケットを起票せざるを得ない場合が結構多いのだ。

そして、システムが使われるほど障害や改善要望があがってくるので、チケットの枚数を制限する事は事実上不可能。
特に、初回の本番リリース後は改善要望という名の障害チケットであふれやすい。
だから、ソフトウェア開発は混乱しやすい状況を既に孕んでいる。

そんな比較内容を読んでみると、チケット駆動開発の肝はやはりチケット管理なのだと痛感する。
チームの開発ペースの上限を超えないように、やるべきチケットを明確にし、チケットに人的リソースを的確に割り当てていくという基本をどれだけ実行できるようにするのか。

TPSのかんばん方式とチケット駆動開発の比較についても調べてみる。

| | コメント (0)

「アジャイル開発とスクラム」の感想

平鍋さんの著作アジャイル開発とスクラムを読んだ。
なるほどと思った部分を中心に感想をラフなメモ書き。

【1】第1~3部に分かれていて、第1部はアジャイル開発とスクラムの解説。
第2部はアジャイル開発の日本における実践例。
第3部は、サザーランドさんと野中先生のインタビュー、野中先生の原論文との比較。

個人的には、第1部はアジャイル開発では既に知られている内容だったし、第2部の実践例も何となく聞いていたし、第3部が一番興味深かった。
やはり、サザーランドさん本人の考え方、野中先生の原論文に込められた内容が、アジャイル開発やスクラムにどれだけ影響を及ぼしていたのか、を考えるととても奥深い。

【2】サザーランドさんのインタビューで、マイクロファイナンスにソフトウェア開発の問題を解決するヒントを考えた後、どんなきっかけでソフトウェア開発を変えたいと思うようになったのか、と平鍋さんが聞いている箇所がある。
開発チームはオブジェクト指向なソフトウェアだったので、チーム自身もオブジェクト指向に似た組織構造だったが、ソフトウェア開発の組織全体では、コマンドコントロールが効いていて、マネジメントも階層的だったため、Conwayの法則によって、ミスマッチが生じていたのだ、と。
つまり、ソフトウェアの構造はソフトウェア開発組織の構造に従う、というConwayの法則に逆らうように開発チームが動いていたため、緊張関係があったのだ、と。

アジャイル開発の底辺には必ずオブジェクト指向プログラミングが関わってくるが、それは単なるプログラミングの一技法ではなく、自己組織化という観点も含んでいる。

そして、チームワークと生産性に関わる論文を探していた時に、野中・竹中の原論文「The New New Product Development Game」に出会い、チーム構成とマネジメントの考え方がここにあると気づいた、と。
つまり、チームは階層的な組織構造ではなく自己組織化されていていること、逐一指示されるマイクロマネジメントは開発の生産性を落とすため、スポーツのような自己組織化するチームをモデルとして採用した、と。

更に、Coplienの論文「組織プロセスパターン」を元に、デイリースクラム(朝会)を取り入れたらうまくいった、と。

組織パターン トップ10 - James Coplien - Digital Romanticism

サザーランドさんが、Scrumを生み出していく過程で、野中先生の論文やCoplienのパターン言語を参考にしつつ、アイデアを固めていった経緯がとても面白かった。
色んな人のアイデアを参考にしてScrumは作られているんだな、と。

【3】野中・竹中の原論文「The New New Product Development Game」とアジャイル開発の比較検証も書かれている。
一部の内容は平鍋さんのBlogに少しだけ書かれている。

スクラムの原典を読み解く(1):An Agile Way:ITmedia オルタナティブ・ブログ

スクラムの原典を読み解く(2):An Agile Way:ITmedia オルタナティブ・ブログ

原論文にあるTypeC(アジャイルな開発チームに近い)の特徴を下記6つとしている。

・不安定な状態を保つ
・プロジェクトチームは自ら組織化する
・開発フェーズを重複させる
・「マルチ学習」
・柔らかなマネジメント
・学びを組織で共有する

【4】最も興味を引くのは「不安定な状態を保つ」。
新製品開発では、開発チームが簡単にできそうもないチャレンジングな課題が与えられ、明確なコンセプトや計画書が与えられるわけではない。
計画通りの作業で進められるわけではないから、チームには自由裁量が与えられると同時に極端に困難なゴールがスタートになる。

故意に「不安定な状態を保つ」点が大切。
元々分かっているような開発ならば、計画をきちんと決めて指示に従って作ればいいが、そうではない。
逆に不安定な状態だからこそ、その変化を利用する。
アジャイルソフトウェア開発では、仕様も要件も変わるし、スコープを意図的に変える事でプロジェクトをコントロールしようとする。
XPが提唱した「4つの変数」「スコープという唯一制御可能な変数」を思い出させる。

また、「プロジェクトチームは自ら組織化する」では、不安定な状況が自己組織化を促すのだ、という逆説的な説明もある。
指示がなければ動けない人は、そんな不安定な状況では作業できないからだ。
「柔らかなマネジメント」では、コマンドコントロールのようなマネジメントではなく、メンバーが自発的に行動しながらも、課題にぶつかったら支援するスクラムマスターのようなサーバーントリーダーが要求される。

そこから「開発フェーズを重複させる」ように、開発と製造も一体化し、情報は文書ではなく人が運ぶ。

【5】スクラムには、チーム、スクラムマスター、プロダクトオーナーの3つの役割がある。
そして、スクラムでは、この3つの役割は厳密に定義されている。

スクラムマスターはサーバーントリーダーだ。
スクラムマスターは、スクラムチーム(プロダクトオーナー、チーム、スクラムマスターを含むチーム全体)を見渡すマネジメントの役割を持つが、管理する役割ではなく、相互の対話を引き出すようなファシリテーターのような役割を持つ。
進捗管理などのマイクロマネジメントにタッチするわけではなく、チームのメンバー自身が動き出せるようにフォローするようなサーバーントの役割。

そして、スクラムマスターはスクラムというプロセスの責任者でもある。
認定スクラムマスター研修では、スクラムマスター照合表というチェックリストをもらったが、そこでは、プロダクトオーナーやチーム、組織がスクラムのそれぞれの役割を果たしているか、チェックする役割をスクラムマスターが責任を負うようなことで書かれていた。
さらに、スクラムマスターは、スプリントないしプロジェクトの教訓をまとめ、組織に資産として残す仕事も含まれている。

【6】第2部の実践例では楽天の藤原さんの事例がとても興味深い。
CIツールから導入して、最終的にはスクラムの全社導入まで、彼がアジャイルに取り組んだ流れが鳥瞰して読める。
個人的には、一つの物語のように、挫折や葛藤なども踏まえたお話が別の本になると面白いかなと思ったりする。

最後の一節で藤原さんが、エンジニア上がりのリーダーがプログラミングが分からなくなったと言い出したら開発チームのボトルネックになってしまう。若い人達がどんどん新しいアイデアを持って来ているのに、それをマネージャーが止めてしまうような事があれば、スピード重視の会社では致命的な損失になるから、という話があった。

最近は、プロジェクトリーダーやプロマネがソフトウェア開発のボトルネックになりやすい気がしている。
今の時代は技術の流れが速い。
昔、Javaなどの業務系Webシステム開発で腕を鳴らしていたとしても、2010年代の現在はスマートフォンやタブレットのアプリ開発、そしてAWSを中心としたWebインフラのクラウド化などのように、IT技術はどんどんシフトしていて、今の技術は初心者だろう。
昔のオブジェクト指向の考え方は今も通用するだろうが、開発現場で使われる言語は変わってきているから、過去の経験知による判断が有効でない場面が多くなってきている。

新しいトレンドの技術を理解できる管理職層にならなければ、新しいアイデアを判断できないし、逆にストップをかけてしまう既得権益層になってしまうだろう。

【7】アジャイル開発とスクラムを一通り読んで、IT以外の業界の経営者向けにアジャイル開発を知ってもらうのにとても良い本と印象を持った。
にも関わらず、Scrumを生み出した野中・竹中の論文のようなアイデアを日本人は生かせなかったのか、何故アジャイル開発は日本で育たなかったのか、という疑問が残る。

野中先生の言うSECIモデルでは、最初のSである共同化をとても重視する。
暗黙知と形式知をやり取りするモデルとして、なるほどと思うけれど、古き良き時代の日本の考え方のような気もする。
今の日本は、昔の追いつき追い越せから成果主義が主流であり、集団で何かアウトプットを出そうとする時、成果主義が別の副作用を生み出している。
昔のように、皆で合宿してアウトプットを出すぞ、という集団志向のやり方が、コンプライアンスや成果主義や個人主義など色んな阻害要因でうまくいっていない気がする。
SECIモデルを今の日本企業に当てはめても、WF型開発を前提にする会社には有効に働かないような気がするのだ。

野中先生も、90年代の日本の製造業は、分析過多、計画過多・コンプライアンス過多で今まで強みとして持っていた実践知リーダーシップを忘れてしまったと嘆いている。
だが、それをソフトウェアという新たなものづくりで復活させようとする平鍋さんの取り組みに感動しているとも言っている。

アジャイル開発に惚れ込んで活動していた僕にとっては当たり前の事実は、IT以外の業界では、野中先生を初めとして全く知られていなかった事実の方が驚異だった。
下記の記事でも、似たようなことが書かれている。

日本のIT産業における「失われた20年」の実相|TransNetCreation

(引用開始)
製造業においては、「米国発の概念・手法を日本企業が発展させて躍進した」のに対して、 ソフトウエア産業においては、「日本発の概念・手法を米国企業が発展させて躍進した」 という歴史的対称性です。
(引用終了)

そんなことを思うと、日本はアジャイル開発のアイデアを持っていたにもかかわらず、ソフトウェア産業ではウォーターフォール型開発に囚われ過ぎて、アジャイル開発を発展させる可能性を見出せなかったのではないかと思ったりする。

今は、「モチベーション3.0」では、成果主義のモチベーション2.0から内発的動機のモチベーション3.0へ変わるべきだ、と書かれているが、その方向性に解決法があるように直感している。
モチベーション3.0の例として、オープンソース運動やクリエイティブコモンズなどがあげられる。
つまり、自己組織化を生み出すためには内発的動機を重視する雰囲気が開発チームにあり、だからこそ、アジャイル開発がスムーズに行われるのではないか、と。
先日デブサミが行われたけれど、そのようなオープンな場でつながったエネルギーが変革の鍵を握ると直感している。

| | コメント (0)

2013/02/16

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy

本日欠席した第7回RxtStudy勉強会の発表資料を公開しました。
発表を楽しみに待っていた人がいたら、ごめんなさいです。

EVM(Earned Value Management)に関する質問を何度か聞くことがあり、今までBlogに書きながら考えていたことをまとめてみました。
EVMをチケット駆動開発に当てはめた場合、どのように適用すれば運用できるか、という観点で書いています。
但し、EVMの実例やアジャイル開発におけるVelocityとの比較についても書きたかったのですが、そこまでは触れていません。

| | コメント (0)

2013/02/14

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

デブサミ2013のセッション14-B-5「チケット駆動開発の本質」で講演した資料をCCアトリビューションライセンスで公開します。

タイムテーブル:Developers Summit 2013

今年のデブサミは参加者がとても多かったです。
関係者の方に聞くと、今日だけで2500人もの開発者が訪れたらしい。
10時前の開演時には、300メートル近い長蛇の待ち行列が並びました。

今回の講演では@sakaba37さんと、4年以上に渡るチケット駆動開発の経験を元に、チケット駆動開発の本質と今後の方向性について語りました。
僕は、現場の経験知や暗黙知として流通しているノウハウをパターン言語という形式知にまとめて、再利用できるようにするだけでなく、チケット駆動開発の本質に迫りたいと考えています。
今回は、そのアイデアの一部を披露しました。

また、パターン言語以外にチケット駆動開発を使って考えていることは、GitやMercurialを使った構成管理との連携です。
今日の講演で興味深かったのは、【14-A-7】ソーシャルコーディング革命後の開発委託の世界~QA@ITの事例です。
キーワードはGitHubが生み出した「ソーシャルコーディング」。

Gitは分散バージョン管理ツールという側面だけでなく、pull requestというマージ手法によって、オープンソースで広く流通しているパッチの取り込みをメールベースではなくWeb上で行えるようにした点が大きいです。
その意味は、コミッタとユーザないしコントリビュータという一方的な権力関係ではなく、開発者はいつでもフォークしてパッチを好きなように作り、そのパッチをコミッタへマージしたいという意志をpull requestという手段を通じて表明する点にあります。
この手法によって、ソフトウェアを開発する関係者がコミッタだけでなく、ソフトウェアを利用するユーザも巻き込んで開発できるようになり、「顧客を巻き込んで開発する」アジャイル開発の流れにも沿っています。

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

Twitter / hamukazu: 数年ぶりにデブサミ出て1日目の感想。前回出席時にもましてエンタープライズ系とウェブ系の技術の差が激しくなってる印象。#devsumi - エンプラ系:頑張ってテストを自動化しました(ドヤッ - ウェブ系:JenkinsでCIとか、朝起きて歯を磨くみたいな話ですよね 大体こんな感じ

チケット駆動開発の文脈では、trunkからのフォークは、トピックブランチないしフィーチャブランチであり、それはチケット単位でもあります。
そしてpull requestされてトピックブランチが終了する時、チケットもCloseされるという運用になります。

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

この手法の利点は、チケットとブランチが密接に絡むことによって、チケット駆動開発の効果の一つであるトレーサビリティを強化できることもあげられます。
Jiraでは、フォークとマージの時点でチケットを自動的に登録したり、完了できるような仕組みがあるようで、興味深いです。

バージョン管理という枯れたツールが、ここ数年大きく開発現場を変化させている事実を痛烈に感じました。

| | コメント (0)

2013/02/11

アジャイル開発は常識だ

アジャイルサムライ著者のインタビューを読んで、心の琴線に触れるフレーズがいくつもあった。
感想をラフなメモ書き。

【元ネタ】
Jonathan Rasmusson さんインタビュー ( 前編 )

Jonathan Rasmusson さんインタビュー ( 後編 )

【1】Jonathan さんが「アジャイルサムライ」を執筆した動機の一つは、アジャイル開発をコーチングや導入する時に使いたいためだったらしい。
というのも、新たな会社にアジャイル開発を導入する時には、7冊のアジャイル本を読んでから説明しなくてはならなかった、と。
ユーザーストーリー、計画、見積りについても10ページの説明で十分だ、と。

アジャイルサムライ」の良い所は、アジャイル開発の概略を網羅的に知ることができる点にあると思う。
アジャイルサムライ」はXPやScrumにも触れているけれど、XPやScrumを全て説明しているというのではなく、現場で運用する時の方法やコツ、ノウハウを説明している。
絵もコミカルで読みやすい。

【2】欧米でアジャイル開発が流行しているのは何故?という質問に対し、Jonathan さんは「常識」だから、と言う。

ウォーターフォールやステージゲート型の開発プロセスが何故ソフトウェア開発で過去40年も使われてきたのか?
何故、フィードバックも変更も反復もないまま、ソフトウェア開発が続けられてきたのか?
むしろ、フィードバックを生かし、変更して、反復してより良い物を作る方が常識だろう、と。

「常識」と主張する彼の言葉にはとても意味深いものが含まれている。
我々の日常生活でも、営業でも、作業でも、最初は失敗したとしても、フィードバックを受けて修正して、方向を変えていく。
でも、何故か、ソフトウェア開発では、変更可能性をリスクと認識し、いかに変化させないように持っていくべきか、と言う方向で進んできた。

インタビューでは暗黙的な共有だけれども、過去のメインフレーム上の開発では、コンピュータリソースが貴重で、何度も実験して試行錯誤していく手法が許されなかったために、事前の計画を常識以上に重視する手法が主流になったのだろうと思う。

でも、今は時代が違う。
過去は年単位で要求を収集し、分析し開発していたけれど、今は月単位、日単位でリリースしなければビジネスのスピードに乗っていけない。

さらに Kent Beck がかつて XP で述べたような変更コストの曲線も触れている。
XPが生み出したTDD、CI、コードの共同所有、リファクタリングが当たり前となり、ソースの変更コストが減り、変更に合わせて開発することが可能になった。
そして、北米では、アジャイル開発を取り入れたいという企業が増えてきた。
1年がドッグイヤーと言われる時代では、特に、ネット企業はそうだろう。
6ヶ月もかけて要求を収集するよりも、6ヶ月以内にリリースする方がビジネス的に最重要になってきたのだ。

【3】日本と北米の違いは、受託開発における請負契約とユーザ企業中心のタイムアンドマテリアルな契約の違いでもある。
Jonathan さんは、IT業界は今まで、どのように期待を管理するかということだけに注力してきたのではないか、いかに素晴らしい製品を作るかということを忘れていたのではないか、と疑問を投げかける。
がんじがらめの契約を決めると、お互いが守備的になり保守的になり、責任のなすりつけ合いになる。

北米では、ユーザ企業が開発チームを持ち、内製化して開発していると聞く。
すると、1年間の予算はこれだけなので、その範囲内で開発して下さい、というスタイルになる。
逆に日本では、ユーザ企業はSIに丸投げし、受託開発における請負契約を結ぶのが普通だ。

この辺りは、アジャイル開発だけでなく、PMBOKでも同様に、日本と北米の違いが歴然とある。
PMBOKでは、発注者がプロジェクトマネージャも兼ねるのが前提なのに、日本ではプロジェクトマネージャが受託側にいるため、PMBOKをカスタマイズしないと日本の開発現場で矛盾が生じる、と。

日本の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 …

つまり、北米では、プロダクトオーナーがユーザ企業にいて、ユーザ企業の内部にいる開発チームと距離感がないのに対し、日本では、プロダクトオーナーがユーザ企業の一人の権限に集中せず、ナントカ委員会のような合議制のために不在で、かつ、開発チームも受託側にいるために、ソフトウェア開発がビジネスと遠く距離が離れているのだ。
そのために、変更に合わせて開発することが難しく、機敏に修正することが難しい。

【4】要求収集から分析、設計までのプロセスで厳格なレビューを多く行うことで高い品質が達成できる手法についても、Jonathan さんは疑問を投げかけている。
「適切なものを作っているということはどうやって分かるのでしょうか。 バグフリーだけど誰も使いたがらないシステムができるかもしれません。」の言葉は辛辣だ。

エンタープライズアーキテクチャ(EA)やSOXについても厳しい意見を述べている。
EAでは、企業としてのITの方針をトップダウンで決めるが、 時代の流れはとても速く、技術もどんどん陳腐化していく。
ビジネスゴールや戦略が目指す方向とEAの方向が同じでない場合、対立が起き、不毛な議論が続く。
そこで必要なのは、プロジェクトの最初で絶対に行うべきことの一つであるアジャイルサムライのインセプションデッキを使うべきだ、と。
プロジェクトの最初に、関係者を部屋に集めて議論を行い、全員のゴールを合わせるべきだ、と。

また「SOX は、時間のムダ、ひどいものだ。 ひどい。」という意見も辛辣だ。
SOXは、ソフトウェア開発を促進するために使われるのではなく、無駄な管理作業が増えて、開発スピードやビジネスのスピードを落とすことに注力されるために使われているからだろう。
(もちろん、SOXやコンプライアンスの重要性は分かっているし、Jonathan さんも文章を読めば理解されている)

【5】12年前に生まれたアジャイル開発は熱狂を失ったのか、と言う質問に対し、Jonathan さんは、常識になったから戦うものがなくなった、と言う。
Jonathan さんはアジャイル宣言について教えることはないと言う。
今の若い世代にとって、プロセスよりも人々、ドキュメントよりも動くソフトウェアは常識だから、自然な開発スタイルだから、と。
新世代は贅沢なことにWFを知らない。だから、戦うものはないし、チームで反復型開発するのが自然だから、と。

【6】「アジャイルサムライ」では、Scrumのようなプロダクトオーナーやスクラムマスターという役割は中心的ではなく、プロジェクト管理者、顧客、アジャイルコーチなどのように、従来の役割でアジャイル開発を回すための工夫が説明されている。
Jonathan さんによれば、その理由は、彼がXPからアジャイル開発を知ったので、XPが提唱した技術的側面を重視したかったことと、スクラムの導入の難しさとしてスクラムの役割をいきなり導入できない現場もあるから、従来の開発コミュニティの人達でも安心してアジャイル開発ができるように役割を提示したかったから、と。
その意味では、「アジャイルサムライ」はとても実践的な本だと思う。

【7】Jonathanさんのモットーである「共有し(Share)、学び(Learn)、成長する(Grow)」はとても意味深い。
「自分が学んだことを他の人たちに教え、共有する」ために、BlogにiPhoneアプリ開発をたくさん書いたりする。

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

この内容は、馬場史郎さんの本「SEを極める50の鉄則」を思い出す。
SEは常に、新しいプログラミング技術、アーキテクチャ設計、プロジェクト管理や顧客との交渉のようなビジネスマンとして鍛えられた経験が必要になるのに、そういう経験がなかったために、5年おきに落第する人が多い、と。
常に新しい技術、マネジメント、設計などのトレンドを取り入れて、ゼロベースで勉強しなくてはならない。

【8】「アジャイルサムライ」の執筆では、最初の原稿は捨てて、2年かけて最初から書いたらしい。
インセプションデッキの部分が100ページもあったけれど、40ページに削り、それが成功した、と。
「短いものを書くのに多くの時間を要します」という言葉は、僕も実感する。
最初に言いたいことをたくさん書き、そこから削って、端的な文章になって初めて完結する。
本を書くのは創造的な仕事なのだ、という言葉は僕も賛成する。

このインタビューは「アジャイルサムライ」の背景だけでなく、Jonathan さんの考え方も書かれていてとても参考になった。

| | コメント (0)

2013/02/09

「反復型ソフトウェア開発」はソフトウェア工学の良書

実践反復型ソフトウェア開発」を読んでみたら、構成管理・ビルド管理・障害管理の方法や概念、用語がうまく整理されて説明されていて、とても分かりやすかった。
僕もこんな本を書きたかった。
ラフなメモ書き。

僕がRedmineによるチケット駆動開発を見つけて、ハマった理由の一つは、ソフトウェア開発特有の技術や概念がここにある、と直感したから。
バージョン管理やビルド管理、障害管理は、ソフトウェアに関わる仕事をしている人ならば、必ずかじっている。
でも、実は、バージョン管理やビルド管理、障害管理について、正式な説明も勉強も受けたことがなく、現場で失敗を繰り返してようやく身に付けた技術が多いのではないだろうか?

ソフトウェア開発は、プログラムを書けばそれで終わりではない。
チームでソフトウェアを開発する場合、複数人の作業が衝突しないようにバージョン管理が必要だ。
クライアントアプリを配布したり、Webサーバーへモジュールをりりーするには、ソースからビルドしてデプロイないしインストーラーを作成するビルド手順を自動化ないし定形作業化した方がいい。
テスト中やリリース後に発生した障害は、BTSやITSで管理して、ソフトウェアの品質向上に役立てるようにする。

それらの作業はとても地味だけれども、プロジェクトの成功のための基盤となるものだ。
技術者で生きていく限り、ソフトウェア開発の基盤となる構成管理、ビルド管理、障害管理は常に最新の情報を追いかけるべきだ。
何故なら、それらの技術は時代とともにどんどんパワフルになっているから。
そして、それらの開発基盤は最終的には開発プロセスへ取り込まれる。
開発プロセスの品質を向上させるには、開発基盤の効率化も欠かせない。

ソースをバージョン管理するのは当たり前だが、ブランチをそれぞれの目的に応じて作って、管理しているか?
マージ作業を手作業でやって失敗していないか?
GitやMercurialのような最新のSCMを使って、メインラインとトピックブランチを使い分けているか?

複数チームで開発している場合、いきなりメインラインにコミットやマージするのではなく、段階的統合ブランチを使って、品質が安定したと分かってからメインラインに入れるようにしているか?

保守ブランチとして、リリースブランチ、リリース準備ブランチ、ユーザブランチをそれぞれの用途に応じて使い分けているか?
作業ブランチとして、フィーチャブランチ、トピックブランチ、バグフィックスブランチ、リファクタブランチなどを使い分けているか?

最新版でセキュリティパッチを当てた時、既にリリース済みの古いバージョンへパッチを当てるバックポートを意識して使っているか?

ブランチにおける指定された範囲内のリビジョンをまとめてメインラインへポートするバルクポートと、必要なリビジョンだけを選んでポートするチェリーピックポートを使い分けているか?
(これは、Gitのcherry-pickコマンドと同じ)

ベースとなるソースを更新するリベースを使っているか?

2個のブランチ間でポートを繰り返す双方向マージを行う場合、マージトラッキング機能が強力なSCMを使ってマージ機能を自動化できるようにしているか?

実践反復型ソフトウェア開発」で興味深い箇所は、構成管理や障害管理の章で、「チケット駆動開発」という単語は出ていないけれども、チケット駆動開発に関わる概念が出ていること。
コミットフック、障害管理票とソースのリビジョンの紐づけは、No Ticket, No Commitにつながる。
BTSを障害だけでなくToDoリストへ拡張することは、Ticket Firstにつながる。
障害管理票がなければ作業を開始しないことは、No Ticket, No Workにつながる。
BTSチケットがソフトウェアかんばん、そして工場内で使われる仕掛けかんばんに似ていることは、リーンソフトウェア開発につながる。

この辺りはもっと整理してみたいと思う。

| | コメント (0)

Redmineチケットのステータスのネーミング方法

チケットのステータスのネーミングは結構悩みがち。
ラフなメモ書き。

【元ネタ】
Redmineのチケットのステータスは「~待ち」にすべき - nazonoDiary

Redmineのチケットステータス - gdgdでも生きてる

Redmineチケットのステータスをデフォルトで運用すると、うまく回らない時がある。
その理由は、今誰がチケットを担当すべきか、認識が一致しないから。

以前の僕も「検証中」「検証完了」「リリース完了」というステータスを作っていた。
だが、複数のチームで運用した所、特にリーダー層から不満が出てきた。
彼らとしては、「~前」というステータス名が欲しいらしい。

例えば、「検証前」なら、開発者が修正完了したがリーダーのレビューが終わっていない状態。
「リリース前」なら、リーダーの検証が終わったので、ライブラリアンが受入環境へリリースするのを待っている状態。

似たようなステータス名のルールとして「~待ち」がある。

そのような意見が出た理由は、「~完了」「~中」だと、誰がそのチケットを持つのか、分かりにくいから。
普通は、ステータスが変わったタイミングで、チケットの担当者が変わる。
開発者からリーダー、開発者からライブラリアンへ、など。

「検証前」「リリース待ち」のステータスならば、誰がそのチケットを担当すべきかすぐに分かる。
でも「検証完了」「リリース完了」のステータスならば、そのチケットにおける自分の作業は完了しているから、と放置してしまいがち。

チケットが更新されるタイミングはチケットのステータスが変わるタイミングが多く、ステータスが変われば、担当者も変わる。
僕は、XPのペアプロみたいに、チケットもペアで作業するものと考えているので、チケットのステータスが変わるタイミングが重要と思っている。

チケットはどんどん更新されるほど、開発は回る。
一つのソース、一つのドキュメントを複数人が作ってはレビューしたり、チェックすることで品質が上がっていく。
放置されるチケットは、ゴミ箱と同じ。
チケットをワインや日本酒のように寝かせても、品質は良くなるどころか、問題がどんどんやばくなって行く。
チケットが常に最新化されて、Closeに向けて進むように、ステータス名には細心の注意を払った方がいい。

【追記】
下記の意見を見つけた。

Twitter / kawanishi_ameya: Redmineのステータスは、「ステータス」欄を使うんじゃなくて、子チケットを切ってチェックリスト代わりにするか、チェックリスト的なプラグインを入れて使うのがいい気がする。

一つのチケットの作業量が多い場合や、一つのバグ修正を本番リリースするまでに検証手順やプロジェクトのルールが複雑な場合、子チケットでステータスごとのタスクを管理する方法もある。

例えば、仕様変更の要望を開発する時、親チケットにタスクの概要を書いておき、子チケットに「設計」「開発」「テスト」「本番リリース」「稼働後検証」などの子チケットをぶらさげて、子チケットにそれぞれの開発者をアサインする。
子チケットは「新規→担当→完了」の状態遷移のみで、開発者のToDoリストに近い。
親チケットでは、完了された子チケットの工程単位に、親チケットのカテゴリで「設計」「開発」「テスト」「受入検証」「本番リリース」「稼働後検証」などの工程ないしステータスをセットする運用がある。

この運用の利点は、ステータスの追加や変更がRedmineの全プロジェクトに影響をおよぼすため、そう簡単にカスタマイズできないのに対し、カテゴリは一つのプロジェクト内部で制御できるので、各プロジェクト単位で独自のステータスを設定する運用が可能なこと。
色んな運用方法があるだろうと思う。

| | コメント (0)

2013/02/08

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart17

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。
ありがとうございます。

【元ネタ】
小川明彦 阪井誠 『Redmineによるタスクマネジメント実践技法: チケット駆動開発+テスト工程管理のA to Z』

(引用開始)
Redmineはオープンソースで開発されているBTS(Bug Tracking System)で、もともとはバグが発生したらそれを修正してリリースするまでにどれぐらいかかるか、とか、修正はだれが担当してるか、とか、それと一緒にプログラム・ソースのヴァージョン管理システムとも連携させましょうか、ついでにガント・チャートも出力しちゃったり……! とかいうクッソ意識高い系のシステムであり、本書はそれを応用して、システム開発全般のマネジメントにも使っちゃいましょうよ! というモノ。

この手の技術書ってツールのインストール方法とかヴァージョンが変わると陳腐化されやすい知識から解説がはじまったりするんだけれど、この本にはそういうのがあんまりない。日夜プロセスやメソッドは改善されていくし、ツールは変化していくけれど「こういう事象にはこういう風に使うとイイっすよ!」というアイデア集として使える。「ウチじゃまだExcelを使って進捗表を作ってるんですよ……」という残念な職場にいらっしゃるIT関係者各位は、これを読んだらまるでRedmineが7つ目のドラゴンボールに思えてくるのではないか。

かく言う私の職場も、こうした便利なタスク管理ツールがなく、大部分の人がExcelで進捗更新して(Notes上に貼られた……)、もちろんそんなの更新がめんどうくさいから、リアルタイムな更新なんかみんなしないわけで、一週間に一度ぐらいしかプロジェクト進捗表が更新されない、なんてザラな環境にあったりするのだった。で、それはあまりに邪悪だ……と思って、せめて自分のチームで使う用にだけでもExcelじゃない進捗ツールがあれば……、と思って、ちょっと前にNotesで作り込んじゃったのね。ホントはRedmineとか導入したかったんだけども、自由な職場ではないので「なんか、こんなRedmineってこんな感じだろう(使ったことないけど……)」と想像しながら。

それは新たな邪悪さの温床では……という感じではあるのだが、これが大活躍で。Excelだとみんな更新してくれないけど、Notesでフォーム作って、ボタンを押せばフィールドに日付が入って、自動で作業状況の集計をしてくれる、ってだけで、めちゃくちゃにリアルタイムに情報が集まり、かつ、たまたま業務でイレギュラーなタスクの割り込みがあったときも「だれがいま一番余裕か!?」っていうのもすぐに把握できるようになったんだよ!!! わざわざ、もう「すみません、いま余裕ありますか……」と雰囲気で恐る恐る作業依頼をしにいかなくても良いんだ!!!!!!

本書を手に取ったのは、Excelじゃないとこんなにありがたい感じになるんだ……じゃあ、ホンモノをRedmineを利用したら、どういうことになってしまうんだろう……と思ったから。読んでみたら「俺の考えたRedmineっぽいモノ」とは、結構違ってて「ウワッ、こういう感じで設計すれば、もっと使い勝手良かったじゃん!(次は絶対パクろう)」とか良いネタ本にもなってくれたし、何より、本書の執筆者たちも「作業の進捗がツールで見えるだけで、こんなに楽になることがあるんだ!」という自分と同じユリイカ感を書いてたのも「そうだよね!」と全力で同意したくなった。

人の管理とかをやりはじめたばかりのIT関係者の方々は、これを読むといろんな発見があると思います。Redmineを導入できなくても、ウォーターフォールでも、職場の状況が見えないことで発生ストレスを、どう解決するかのヒントがたくさん含まれているなかなか射程範囲が広い本だと思います。これキッカケにPMBOKとか、ホントにマネジメントっぽい知識体系にもちょっと興味が広がったりもしたよ。

(なお、現在はHerokuでRedmine動かして、個人的にゴニョゴニョとなにかを試しているところです)
(引用終了)

ここ2,3年は、開発環境周辺の技術がクラウドも含めて、従来よりも急激に進化しています。
ExcelやMS Projectによる進捗管理は、それなりのノウハウを試すこともできますが、スケールアップしにくく、メンバー自身が自発的に行動するように促すことも出来ません。
Scrumの自己組織化、アジャイル開発におけるタイムボックス開発、PMBOKによるEVM、ITILを使った運用保守のタスク管理という概念も、僕はRedmineを通じて体験したし、その利点も、そして導入上の落とし穴も体験できました。

所詮ツールに過ぎないかもしれないけれど、現代はソフトウェアが業務の効率化や情報の整理だけでなく、ツールを使った運用によって新人がスキルを身に付けたり、Wikiなどを通じてノウハウを共有したり、課題が会社全体に公開されることで皆が突っ込み合えるような仕組みを作れたりします。

問題にぶつかった
→解決できなくて、無視したり、隠そうとする
→どんどん傷口が広がる
→最後は火を噴いて、誰も止められなくなる

というパターンが従来は多かったと思いますが、Redmineのようなツールによって、課題や進捗が見える化されることで、Scrumのいう「透明化」が促進されます。
すると、

問題にぶつかった
→解決できなくて、転げるが、全ての作業履歴が公開されている
→気づいた人が、アドバイスしたり、ツッコミを入れたり、手伝ったりする
→転げた人も、周囲の支援を受けて、何とかやり遂げる

のようなパターンへ変化するでしょう。
つまり、強制的に改善せざるを得ない環境を作り出すことによって、問題が解決されるだけでなく、解決できなかった人も経験を通じて成長できるチャンスを得られるでしょう。

Redmineの背後にあるチケット駆動開発は、たくさんの可能性を秘めていると思います。

【追記】
他の人の感想も追記しておく。

Twitter / naitoh: 「Redmineによるタスクマネジメント実践技法」読了。チケット駆動開発が網羅的に説明されてる。8章のEVMは予定工数と工数実績入力しろって事ですよね、ハードル高し。メトリクス測定が課題〜fluentd使って「入力する手間」減らせんかな? http://www.amazon.jp/dp/4798121622

Twitter / namihira_k: 【Redmineによるタスクマネジメント実践技法】読み終わった-\(^o^)/Redmine(プロジェクト管理ツール)の運用ノウハウが書かれています。Redmineでは日々作業をチケットとして管理していきます。#namihirayonda http://www.amazon.co.jp/Redmine%E3%81%AB%E3%82%88%E3%82%8B%E3%82%BF%E3%82%B9%E3%82%AF%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E5%AE%9F%E8%B7%B5%E6%8A%80%E6%B3%95-%E5%B0%8F%E5%B7%9D-%E6%98%8E%E5%BD%A6/dp/4798121622/ref=sr_1_fkmr1_1?ie=UTF8&qid=1328278551&sr=8-1-fkmr1 …

Twitter / islandcoral:これマジ良い本だなあって読んでて思った。Redmine使ってなくても参考になる内容だと思う。 Redmineによるタスクマネジメント実践技法 小川 明彦 http://www.amazon.co.jp/dp/4798121622/ref=cm_sw_r_tw_dp_-gvipb0XRCFSN …

Twitter / process_ok: Redmineの使い方ももちろんですが、ありがちな失敗パターンをたくさん乗せているところが価値があるなあと思いました。何でもチケットやメトリクスに頼ればいいというものではないと。『Redmineによるタスクマネジメント実践技法』http://j.mp/M9KgFm

Twitter / jiskanulo: Redmineの設定方法や使い方よりもRedmineを用いてのアジャイル開発手法に重きを置いて解説してた チームメンバーに是が非でも共有したい する / Amazon.co.jp: Redmineによるタスクマネジメント実践技法: 小川….

Redmineによるタスクマネジメント実践技法 mkisonoさんの感想 - 読書メーター

(引用開始)
「プログラマの思索」ブログをたまに読んでいたので、内容的に新しいところはあまり無かったが、本でまとめて読むと効率がいいように感じた。興味があるところまででひとまず終わりにして、Testlinkとの連携については読んでいない。
(引用終了)

Twitter / takeboruta: ブログ更新しました。できるだけ漏れがなく、管理を効率的にしてくれる方法は模索する意味でも、本書を参考にしてより効率的な開発を行いたいところです。>Redmineによるタスクマネジメント実践技法 http://bit.ly/ij8ODt

| | コメント (0)

2013/02/03

【告知】第7回RxTstudyで「チケット駆動開発におけるEVMの考え方」を講演します #redmine

2013/2/16の第7回RxTstudyで「チケット駆動開発におけるEVMの考え方」を講演します。

【元ネタ】
第7回RxTstudy : ATND

RxTstudy

【タイトル】チケット駆動開発におけるEVMの考え方

【概要】
昨今、ITプロジェクトの売上計上が、以前の検収時の丼勘定から工事進行基準に変わったため、EVM(Earned Value Management)というPMBOK発のコスト管理が注目されています。
しかしながら、ITプロジェクトにおける工数管理はマネージャだけでなく開発者にとっても大変面倒であり、EVMの現場への適用も混乱している所が多いように思えます。
本講演では、Redmineによるチケット駆動開発を実践している場合、EVMをチケット駆動開発へどのように適用すればよいか、EVMの効果的な運用方法は何か、についてのアイデアをお話します。

| | コメント (0)

【告知】デブサミ2013でチケット駆動開発の講演をやります #devsumi

デブサミ2013でチケット駆動開発の講演をやります。

【参考】
「Enterprise」「Social Game」「startup」3つの世界のAction!:Developers Summit 2013

【14-B-5】チケット駆動開発の本質:Developers Summit 2013

【公開】デブサミ2011でチケット駆動開発とチケット管理システム大決戦セッションで話します #tidd: プログラマの思索

【14-B-5】チケット駆動開発の本質
Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の著者らが語る実践を踏まえたチケット駆動開発の本質。著作に書ききれなかった思いを語らせていただきます。 まず、阪井がチケット駆動開発のバリエーションの一つである「挑戦の道具としてのチケット駆動開発」について語り、あきぴーが「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」と題して語り、チケット駆動開発の本質に迫ります。

【メモ】
2年ぶりにデブサミでチケット駆動開発を講演することになりました。
2010年に処女作「Redmineによるタスクマネジメント実践技法」、2012年に「チケット駆動開発」を出版してみて、「チケット駆動開発」というアイデアが著者の想像以上に日本の開発現場に普及しているのを実感しています。
この度の講演では、チケット駆動開発の現状を踏まえた上で、今後どのように発展していくべきなのか、について語りたいと思います。

【メモ2】
デブサミ2013のセッションで僕が注目する講演をあげてみます。

【14-B-1】3つの世界:エンタープライズ、ソーシャル/ゲーム、スタートアップ:Developers Summit 2013
玉川憲(司会)/三谷慶一郎/伊藤直也/孫泰蔵

玉川さんと言えば、「クラウドデザインパターン」でも有名。

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

DevOpsアンチパターン: プログラマの思索

【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ~10の40乗のパターンをいかにテストするか~:Developers Summit 2013

形式手法も混ぜたテスト技法のお話。
Publickeyの記事でも有名だった。

自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) - Publickey

自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(中編) - Publickey

【14-B-6】サステイナブルなSIを実現する開発基盤のあり方:Developers Summit 2013
鈴木雄介

鈴木雄介さんは、アーキテクチャ設計とプロジェクトマネジメントの関する話題でとても興味が惹かれる。

【14-A-7】ソーシャルコーディング革命後の開発委託の世界?QA@ITの事例(仮):Developers Summit 2013
和田卓人(司会)/西村賢/ソーシャルコーディングクラスタ

今回のデブサミで最も興味を引く講演の一つ。
ソーシャルコーディングが受託開発という閉ざされた環境の開発スタイルをぶち壊す破壊的イノベーションをもたらすのではないか、という指摘。

Twitter / akipii: GitHubがもたらしたソーシャルコーディングの破壊的イノベーションの記事。分散バージョン管理は権力の一極集中から民主政への変化みたいらしい。 GitHub時代の開発委託とは? デブサミでQA@ITの事例の話をします http://bit.ly/11oAl6w

GitHub時代の開発委託とは? デブサミでQA@ITの事例の話をします - QA@IT公式ブログ

【15-A-5】人が作るソフトウェア ~今『組織パターン』を読む意味~:Developers Summit 2013
和智右桂

Coplien著の『Organizational Patterns of Agile Software Development』に関する講演で、僕が最も興味を持っている講演の一つ。
僕の問題意識として、パターンが現場の経験知を形式知にする点で有効だとしても、作られたパターンカタログが網羅的で矛盾なく整合性が取れているのはどう保証されるのか、と和智さんに聞いた時がある。
和智さんは、Copienが収集したパターンカタログでは、網羅性や整合性の観点よりも、優れた複数のソフトウェア開発組織から共通のプラクティスを抽出して、WF型開発からアジャイル開発へ段階的に変化していくのに役立つような観点で書かれている、と回答された時があり、なるほどと思った時がある。

和智さんは、「エリック・エヴァンスのドメイン駆動設計」「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」「実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる」など、最近とても優れた翻訳本を出版されています。

Coplienの開発工程の生成的パターン言語を読むpart1: プログラマの思索

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

【15-B-5】SQLアンチパターン - 開発者を待ち受ける25の落とし穴:Developers Summit 2013
和田卓人

RDBに関するアンチパターンのお話。
アーキテクチャ設計のアンチパターン集~44のアンチパターンに学ぶDBシステム: プログラマの思索のお話とも関連するのかな、とか思ったりしている。

こう見ると、やはり僕はパターン言語周辺に興味がありますね(笑)
逆に言えば、日本でアジャイル開発を実践されている人達も、皆違う動機から行動しているのかもしれないが、パターン言語と言うアジャイルの原点に立ち戻っているのかもしれません。

今年のデブサミは、従来よりももっとコミュニティや開発者との交流に力を入れているようです。
例年以上に盛り上がるのではないか、と思っています。

| | コメント (0)

パターン言語のアイデア

懸田さん(@kkd)さんがパターン言語のアイデアをSlideshareで公開されていたのでメモ。

Twitter / kkd: @akipii @akipii これあまり内容がなくてすみません。とりあえず一昨年copeに見てもらおうと思って書いて、それっきり放置していたのを思い出してとりあえず上げておきましたw そのうちパタン関係はちゃんと書きます。

Twitter / akipii: @kkd Facebookで見かけた角さんの言葉「パターンではForceが大切」が何故か気になっています。@kkdさんの資料では、パターンのContext、Problem、Solution、Forceの整合性をチェックするのにとても役立ちそうな気がします。参考にします。

Twitter / kkd: @akipii @akipii ForceはProblemとSolutionを繋ぐ鍵であり、現場で問題解決する時には、気づきにくい部分と思います。(当たり前すぎる、言語化されていない、身体感覚)。

Twitter / kkd: @akipii そういって頂けると、途中版でも公開しておいてよかったです。ありがとうございます!

僕がパターンに注目している意図は、現場で暗黙知として認識されているプロジェクト管理やソフトウェア開発ノウハウを最良できる形式としてパターンが有効であると考えているから。
日本のソフトウェア開発は実はそれなりに歴史があり、特にWF型開発のプロジェクト管理や品質管理に関しては独特のノウハウを持っているし、そのノウハウはアジャイル開発にも生かせると思っている。

でも、それらのノウハウは断片的知識で散文的に散らばっていたり、知的財産やセキュリティの理由から各企業が保持しているノウハウが公開されていないために、日本のソフトウェア開発の現場はいつまで経っても同じような失敗を繰り返している時が多いと思う。

忘れ去られた日本のIT技術~プロジェクト管理: プログラマの思索

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

そのような状況に比べて、欧米では、また、PMBOKやBABOK、CMMI、ソフトウェアプロダクトラインのように、それまで各社で持っていたベストプラクティスを抽象的な体系として再利用できる形式知としてまとめてきている。
また、オープンソースという形で開発者が作ったプログラムが公開されることで数多くの人達の間でノウハウが共有されているし、アジャイル開発という変化にとても強い開発スタイルが生み出されている。

GitHubが生み出すソーシャルコーディングがOSSの世界を急速に進化させている - しふーのブログ

懸田さんの上記の資料はとてもシンプルであるが、パターンの概念を使って、現場のノウハウをどのように抽出するか、という観点でとても役立ちそうな気がしている。
他にも川口さんがパターンに関する資料も公開されている。

最近のアジャイル界隈はパターンに関する話題が増えているのだろうか?

アジャイルはパターンムーブメントに戻るのか: プログラマの思索

| | コメント (0)

小学生からプログラミング教育を始めるエストニア

小学生からプログラミング教育を始める国の記事があったのでメモ。

Fumi's Travelblog: 読み書き算盤プログラミング

(引用開始)
「作家にはならないから読み書きを学ばないなんて人はいないですよね。エンジニアにはならないからプログラミングを学ばないというのもそれにちょっと似ています。クリエイティブに物を考えること。論理的・システマチックに物を考えること。他の人とコラボレーションをすること。こうしたことは、誰にとっても役に立つ。」
エストニアでは、小学校一年生からプログラミングの勉強をすることになったそうです。まずは 20 校で始めるパイロットプログラムですが、全国 550 校に広げていく予定。7 歳から 19 歳のエストニアの子ども達が、プログラミングの勉強をしていくことになります。
そしてその理由については、「アプリ開発者を生み出そうとしているわけではなく、テクノロジー、コンピューターやウェブとの関わり方がスマートにできる国民を生み出したい」から。(The idea isn’t to start churning out app developers of the future, but people who have smarter relationships with technology, computers and the Web.)そういう国民を生み出すには、中学校からでは遅い。小学1年生の頭が柔らかいうちから始めなければ、と。エストニアの学校は全てインターネットに接続されており、4年以内に全て DSL の常時接続インターネットに切り替える予定とのこと。また、エストニアは e-government が進んでいる国としても有名です。
(引用終了)

プログラミング技術もITリテラシーの一つという理念。
エストニアの事例がどこまで効果を上げるのか分からないが、昔からの読み書きそろばんだけでなく、ITリテラシーも今後生きていくために必要な技術になってきている背景から生まれている。

丁度、大前研一氏や勝間和代氏が、今後のビジネスマンに必須のスキルは、英語・会計・ITと言っていたことを思い出せる。
今の日本、そして世界がグローバル化して英語というコミュニケーション技術を必要としており、資本主義社会という枠組みの国家が多い限り、簿記やファイナンスという知識は必須になってきているし、スマートフォンから人工衛星までITが張り巡らされているのを見ると、プログラミングも必要になってきている。

日本でも小学校から英語が必須になった。おそらく近い将来、プログラミングや簿記も義務教育に組み込まれるかもしれない。

| | コメント (0)

2013/02/02

Excelの内容をredmineのwikiへ変換するアドオン

Excelで作った表をredmineのwikiへ変換するアドオンが公開されていたのでメモ。

【元ネタ】
Twitter / tellus1019: Excelで作った表をredmineのwikiへ簡単にコピーするためのアドインを作成しました。 選択したセルデータをTextile形式に変換してクリップボードにコピーします。 使用・再配布については添付したReadMeを参照して下さい。 http://www15.atpages.jp/tellus1019/Textile.zip …

Textile.zip

Twitter / tellus1019: 社内でredmineの運用テストを開始。 久しぶりのwiki編集。 やはり仕様管理はwikiが一番利便性が高い。 wikiで仕様書を揃えていくのは一苦労だが、その分プロジェクト全体の精度が上がる。 ここをサボって方眼紙エクセルをアップとかすると連動性がなくなり意味が無くなります。

【追記】
Hayashi, KojiさんはTwitterを使っています: "Excelで作った表をredmineのwikiへ簡単にコピーするためのアドインを更新しました。 Office2013などの64bitに対応したWindows版でも動作すると思います。 基本的な機能に変更はありません。 https://t.co/65AGC2bBF2"

akipiiさんはTwitterを使っています: "このアドオンは重宝してる。RT @tellus1019: Excelで作った表をredmineのwikiへ簡単にコピーするためのアドインを更新しました。 Office2013などのWindows版でも動作すると思います。 https://t.co/W3g6TqC3Mp"

Excelで書かれたドキュメントはとても多い。
だが、Excelで書いてしまうと、すぐに肥大化するし、履歴管理も肥大化するほど難しくなるし、Excelで開かなければ誰も見なくなる。

むしろ、開発環境のセットアップ方法や仕様、コーディング基準、定形作業の手順など、チーム全員に共有したほうが良い情報はWikiで社内に公開した方がいい。
Wikiの良さは、箇条書きや表や色付けなどが簡単に書けること、全文検索機能があるので必要な時にすぐにノウハウを探せることなどがある。

Wikiに貯められた情報は、チームの財産だ。
財産であるからこそ、いつでも探し出すことができることがとても重要になってくる。

上記のツールはExcelのアドオンとして提供されており、Excel上でコピーしたらTextile形式に変換してクリップボードにコピーしてくれるらしい。
Excelの内容をコンバートする時に役立つだろう。

Wikiでは、パンくずという階層構造を作ると記事が目次化されて読みやすくなる。
Wikiに書きたいノウハウは、階層ないしカテゴリで分類した方が一目で探しやすくなる。

RedmineのWikiにはパンくずの一覧を表示させることもできるので、目次のように見ることもできる。

Redmine ユーザガイド 日本語訳

また、RedmineのWikiは即座にPDF化できるので、紙媒体で納品したい時に役立つだろう。
PDFのしおり機能も含んで出力できるから、仕様書は全てWikiに書いた方がPDF化もやりやすくなる。

Redmine 1.4新機能紹介: Wikiの全ページを一括してPDFに出力 | Redmine.JP Blog

| | コメント (0)

« 2013年1月 | トップページ | 2013年3月 »