« 2013年10月 | トップページ | 2013年12月 »

2013年11月

2013/11/29

リーンとカンバンの本質と現場改善~平鍋さんと現場課題を考えるの感想 #リーン開発の現場

本日開催された「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜 - リーン開発の現場 塹壕コミュニティ | Doorkeeper」に参加してきた。

リーン開発の現場」の裏話が聞けるかなと期待していた。
平鍋さんの話がとても面白かったので、メモした内容をそのままアップしておく。
感想をラフなメモ書き。

【参考】
リーンとカンバンの本質と現場改善 ?平鍋さんと現場課題を考える? - リーン開発の現場 塹壕コミュニティ | Doorkeeper

【1】現場は現れる

ヘンリックがかんばんを試しているうちに、アジャイルが現れた。
計画して出てきたわけではない。
経験して適応して、プロセスは出現する。

【2】リーンは分かりにくい

何故リーンは分かりにくいのか?
XPやScrumのようなプラクティスがないから、と。

XPなら、テストファースト、継続的インテグレーション、ペアプログラミング、ソースの共同所有などの具体的なプラクティスがある。
Scrumなら、プロダクトバックログ、デイリースクラム、スプリントレビュー、スプリントデモなどのプラクティスないし規律がある。
だから、そのプラクティスを使っていれば、自然にそれらの概念の本質を体で経験することができる。

でも、リーンにはそのような実践的なプラクティスがない。
6つの無駄、サイクルタイムの短縮など、抽象的な概念ばかり。
だから、分かりにくい、と。

この話を聞いて、リーンが分かりにくい理由がようやく分かった。

【3】スターバックスにおけるリーンサービスの例

TPS→リーン生産→リーンシンキング の流れで抽象化されて、
リーンサービス、リーン製品開発、リーンソフトウェア開発へ発展した。

スターバックスではリーンを取り入れたリーンサービスを実践しているらしい。
例えば、オペレーションの効率化。
顧客の待ち時間を減らすために、リーンサービスを導入した。

でも、それだけが本質ではない。
オペレーションを効率化して、顧客と話しサービスする時間を増やしたのだ、と。

【4】製造業ではムダを指さすことができるのに、ソフトウェア開発ではムダが見えないので指差しできない

トヨタのコンサルタントは、工場の現場で、止まっている物を指差す。
これはムダでしょ、と。
ソフトウェア開発では、ムダが見えない。
だから、ムダな物を指差すことができない。

いかにムダを見えるようにするか。
その手法の一つがかんばんだ、と。

【5】リトルの法則

WIP=LeadTime * Throughput

WIP:中間在庫
LeadTime:待ち時間
Throughput:生産性

⇔LeadTime=WIP/Throughput

同じThroughputならば、WIPを減らせば、LeadTimeが短くなる。

【6】WF・Scrum・Leanに対し、リトルの法則による比較

WF型開発では、1年かけて作って、最後に1回だけのリリース。
Scrumは、1スプリント1ヶ月の単位に、順次リリース。
リーン開発では、1個ずつ1日毎にリリース。

リトルの法則の変数は、下記の比較になる。

変数 WF Scrum Lean
WIP 365個/年 30個/月 1個/日
LeadTime 1年 1ヶ月(1スプリント) 1日

注意する点は、WF・Scrum・Leanのいずれもスループットは同じであること。
365個/年=30個/月=1個/日だから。
つまり、同じスループットならば、WIPの量を減らすほど、1年>1ヶ月>1日のようにリードタイム(サイクルタイム)は短くなる。

平鍋さんは、WF・Scrum・Leanのリードタイムを爆弾処理に例えていた。
WF型開発は、大きな爆弾を分析→設計→実装→テストの工程ごとに、ドカンと渡す。
後工程に行くごとに爆弾が破裂するリスクが高くなり、最後のテスト工程で、ビッグバンテストで爆発して死人も出る。

Scrumでは、中くらいの爆弾をスプリントごとに渡す。
最初は慣れていないので、爆弾が破裂して、死人は出ないが、けが人は出る。
でも、スプリントを経るごとに、爆弾を渡す時は相手の目を見て渡す、とか、爆弾が破裂しないようなノウハウを経験して、爆弾の扱いがうまくなっていく。
Scrumで言われる適応と検査に相当する。

Leanでは、セル生産のように、スモールバッチで小さな爆弾で渡す。
けが人も出ないし、小さいからスムーズに渡せる。

【7】リトルの法則の応用例

平鍋さんから質問。
大野市は4万人いるが、1日何人亡くなるでしょうか?
あるいは、1日何人の赤ん坊が生まれるでしょうか?

回答は、1人の人間の平均寿命が80年とすれば、リトルの法則を使うと、
4万人/80歳=500人/年=1~2人/日。

この数値は、生まれる赤ん坊と死ぬ人がほぼ同率であるという前提だが、ほぼ当たっているらしい。
リトルの法則は色々使えるよ、という例。

【8】Scrum・Kanban・セル生産の共通点はWIP

アマゾン川を例に出す。
アマゾン川の河口が最終製品だとすれば、支流は前工程。
それだけたくさんの支流にある部品が必要。

Scrumでは、スプリント単位にWIPを制限する。
Kanbanでは、流量(フロー、物の流れ)でWIPを制限する。

つまり、河口から支流へ、製品が売れるたびにマーケット情報を送って、部品を河口側が引き取る。
すなわち、プル生産。
後工程の信号が来るまで、前工程ではムダな在庫を作らない。

プル生産の標語は、Stop Starting, Start Finishing。

セル生産では、1個作りで後工程に流す。
例えば、屋台。
屋台では、一人がソーセージを焼き、マスタードやケチャップを塗り、販売する。
一人でいろんな作業を触れて、顧客の好みに気付く。
今日はマスタードを塗ったほうが売れる、とか。

【9】方法論の終焉(End of Methodology) by Alistair Cockburn

End of Methodology (日本語訳):An Agile Way:ITmedia オルタナティブ・ブログ

かんばんを使った現場は、どこも違う。
一つの方法論がすべての現場で使えるわけではない。

標準プロセスはいらない。
ふりかえり改善フレームワークで、経験的プロセスをそれぞれの現場で作っていく。

【10】ブラジルの受託アジャイルの事例

ブラジルでは、アメリカと時差が同じなので、アメリカからのソフト開発の受託案件が多い。
でも、100%アジャイル。

顧客のロゴを各チームに旗として飾る。
チケット管理システムからチケットを印刷して、かんばんに貼り付けて、かんばんでタスク管理する。
リリースしたら、シャンパンで乾杯する。
その後のふたを貯めている。

【11】Kanbanの良い所

かんばんを見れば、タスクは「ここ」にあります。
あと2週間でリリースできます。
と言える。
「ここ」「あそこ」と指差すことができる。

平鍋さんの現場で使うかんばんでは、ToDo→Doing→Doneではなく、ToDo→Doing→「Accept」にしたらしい。
Doneにしても、手戻りが発生する場合があり、Doneとは言いがたい。
最後のアクセプタ(Doneを判定する人)が受け取った状態を「Accept」としたらしい。

これは面白い。
Doneの定義は、Scrumでも言われるように、チームごとに違う。
しかも、チームが成長するたびに、Doneが定義する範囲は広がる。
定期的なふりかえりで、Doneの定義をいつもチェックすると良いのだろう。

【12】平鍋さんへの質問「SIでは、リーンの考え方は人減らしに使われてしまい、チームを生き生きさせる方向に向かないのではないか」に対する回答

僕は、ソフトウェア開発におけるリトルの法則については、以前色々考えた。

チケット駆動開発におけるサイクルタイムの計測方法~リーン開発で最も重要なメトリクス: プログラマの思索

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

ソフトウェア開発におけるリトルの法則は、下記になる。

CycleTime=WIP/Velocity

・CycleTime:1タスクの平均完了日数。
 →チケット駆動なら、1チケットの平均完了日数。バグチケットなら平均障害修復時間(MTTR)を指す。
・WIP:開発チームの仕掛中のタスクの最大個数。
 →チケット駆動なら、開発チームが手をつけている着手済みチケットの最大枚数。
・Velocity:開発チームのタスク消化能力。
 →チケット駆動なら、1スプリントにおける完了チケットの平均枚数。開発チームが1スプリントで消化できるチケットの枚数を指す。

この公式から分かることは何か?
開発チームが作業に着手できるチケットの枚数には限界(つまり、WIP)があり、リトルの法則から論理的に計算できる。
チケット駆動開発ならば、サイクルタイムやベロシティというメトリクスは簡単に計測することができる。
実際、サイクルタイムは、チケットの開始日から終了日までの期間の平均値。
ベロシティは、1スプリントという一定期間における完了チケットの平均枚数。

すると、WIPはサイクルタイムやベロシティから計算できるので、開発チームが手を付けることができるチケットの最大枚数が導出される。
その意味は、開発チームはWIPという数値以上のチケットを抱えられないと言う事実であり、WIPを超えるほどのチケットがあっても、開発チームは消化できないのだ。

チケット駆動開発を実践すると、普通は、チケットがどんどん溢れる。
100枚、500枚の未完了チケットがバックログとして積まれている状態は普通だ。
しかし、リトルの法則が教える所では、開発チームがリリース可能なバックログとして選択できるチケットの枚数は、WIPというメトリクスによって、限界がある。

例えば、サイクルタイムが5日/枚、ベロシティが5枚/週の開発チームが、100枚の未完了チケットを抱えていたら、約1~2年分のチケットを抱えていることになる。
開発チームのWIPとしては、25枚/週程度になる。
それ以上のチケットがあったとしても、着手できずにキュー(待ち行列)として無限に溜まっていくだけだ。
つまり、開発チームの能力に応じて、WIPを減らす必要があり、チケットを捨てるか選択する必要がある。

サイクルタイムを短くすることは、アジャイル開発にとって重要な意味を持つ。
その理由は、サイクルタイムは文字通り1チケットのリリース間隔であり、サイクルタイムが短ければ、1機能1チケットをより早くリリースできる。
リリース間隔が短いほど、頻繁にリリースできるから、市場の状況や経営判断に応じて、柔軟にリリースする機能を取捨選択する余裕も生まれる。
この考えは、「リーン開発の本質」で言われる「オプション」「最終責任時点」の話につながる。
つまり、即座にリリースできる能力があるからこそ、選択肢を数多く持つことができるから、リスクを減らすことができる。

リトルの法則に従うと、サイクルタイム(リードタイム)を短くするには、WIPを減らせば良い。
すると、WIPを減らしすぎると、作業量が減るので、暇な人が生まれる。
つまり、ソフトウェア開発者の稼働率は落ちる。

平鍋さんの話では、リーンを実践すると、無駄な作業をする人が減る。
この現象を省人化と言うらしい。
つまり、ある製品の工程で人が余れば、ボトルネックとなる別の工程へ人を配置して、柔軟に変えていく。
すなわち、人は多能工になる。

しかし、SIにとって、SEやPGの稼働率は人月商売の要だ。
普通は、チームの生産性が上がり、人が余るようになると、火が噴いている別プロジェクトの応援に駆り出される場合が多い。
すると、せっかくチームとして上手く回っていたのに、抜けた人の役割を別の人がカバーせざるを得なくなるので、チームのバランスが崩れてしまう。
何よりも、チームの精神的雰囲気も悪くなる。

SIでリーンの考え方を導入すると、確かにソフトウェア開発のリードタイムは短くなり、無駄な作業をする人も減るだろう。
でも、リーンがSIでは人減らしに使われる危険は無いのか?

そんな質問を平鍋さんにしたら、こんな回答があった。

リーン製品開発やリーンソフトウェア開発の考え方としては、垂直方向(バーティカルライン)に人が動く。
例えば、開発工程で人が余り、テスト工程で人不足でボトルネックになっていたら、ボトルネック解消のために人がテスト工程に移って、支援する。
この現象を応受援という。
つまり、暇な人の労力を振り分けて応急の手助けをしていることになる。
製品単位、顧客単位に人が上下の工程に動く。

でも、SI業界では、水平方向(ホリゾンタルライン)に人が動く。
例えば、暇な人ができると、火が噴いている別プロジェクトにアサインされてしまう。
人はプロジェクトを転々と渡り歩く。
でも、リーンの本来の考え方は、顧客単位に人が動く。

SIの請負契約のせいですかね~と言われていた。

【13】「リーンはプラクティスがないから分かりにくい」「同じThroughputならWIPを減らせばLeadTimeは短くなる」という話は分かりやすかった。
リーンの考え方は6つのムダのような話もあるが、僕としては、リードタイム(サイクルタイム)というメトリクスを中心として、リーンの構造を探ってみたいと考えている。

| | コメント (0)

2013/11/25

仮説から理論を構築する過程で大切なこと

最近、地球の歴史や恐竜に興味を持っているのだが、『決着! 恐竜絶滅論争』を読んで、自然科学における仮説から理論を構築する手法について、気づいた点があったのでメモ。

【参考】
【読了本】『決着! 恐竜絶滅論争>』 定説はなぜ「定説」たり得たのか - 読んで、観て、呑む。 ~押川閑古堂日乗~

書評 「決着! 恐竜絶滅論争」 - shorebird 進化心理学中心の書評など

後藤和久『決着! 恐竜絶滅論争』 - logical cypher scape

【1】恐竜の絶滅の原因は、隕石による衝突だ、という仮説が1980年代に提唱された。
その仮説の斬新さに異論反論も多かったが、隕石特有の物質であるイリジウムが恐竜絶滅のタイミングに大量に発生している地質的証拠が大きな証拠としてあがった。
さらに、1991年に、メキシコのユカタン半島でチチュルブ・クレーターが見つかったことで、隕石衝突説が決定的となった。

しかし、その後、デカントラップと呼ばれる火山噴火説が恐竜絶滅の原因として根強く世間に流布されており、隕石衝突説ではない、という反論があたかも広がっているように思われた。

そこで、『決着! 恐竜絶滅論争』の著者は、改めて、恐竜絶滅の原因は隕石衝突説であると主張するために、定量的な証拠を元に論理的に説明する試みをおこなった。
下記が、2010年にサイエンスに掲載されたその旨の総説論文であり、『決着! 恐竜絶滅論争』はその論文の解説である。

The Chicxulub Asteroid Impact and Mass Extinction at the Cretaceous-Paleogene Boundary

【2】『決着! 恐竜絶滅論争』を呼んで面白かった点は、科学者の間で、火山噴火説と隕石衝突説を討論している過程で、仮説がどのように理論として構築され、決定されていくのかが分かりやすかったことだ。

火山噴火説を唱える科学者は、隕石衝突説に反論するだけで、次から次へと判明してくる地質学的証拠に対し、年代推定があいまいだ、とか、別の解釈もできる、などと反論していた。
しかし、火山噴火説では、イリジウムの異常濃集がどうしても説明できず、チチュルブ・クレーターが恐竜絶滅のタイミングで作られて、その衝突の余波による大津波や大地震や大火事の証拠に対して、自説を補強できるだけの説明ができなかった。
単純に反論するだけでは、自説の正当性にはつながらないのだ。

ある仮説が提唱され、それに反論するグループが出ることで、最初に仮説を提示したグループはもっと多くの証拠や定量データを示さなくてはならない。
もしそれができなければ、その仮説は正当性がなく、支持を失う。
多くの証拠や定量データを背景に、論理的に説明できる仮説だけが、その後の歴史に残る。

自然科学の理論を読んだり勉強する時に面白いのが、仮説をめぐる奥深い議論だ。
数多くの証拠や定量データをどのように解釈し、どのように仮説を補強するのか。
そして、自説に対する反論に対し、証拠や定量データを使って、どのように反撃するのか。

仮説が理論へ変化する過程は、そのようなたくさんの反論で鍛えられて、歴史に残るようになる。
反論に言い返せないような仮説は、理論にはならない。
だから、仮説を理論へ格上げするために、補強するための資料をもっと集めるために、証拠を探しに出かけたり、定量データを集めようとする。
そのために、たくさんの論文を書く必要があるわけだ。

【3】そのやり方は、ソフトウェア工学でも同じ。
ある時代のあるチームのあるプロジェクトでの経験則が、他の場所でも通用するように、再現可能になるようにするには、経験則を補強するような定量データを集めて、論理的に説明できるようにすることだ。

ソフトウェア工学は、自然科学というよりも社会科学の一部として捉えた方が良いと思えるフシがある。
だから、ソフトウェア工学はとてもあいまいな基盤の上の理論にすぎないように思える。
でも、経験則を一つの実践知として、形式知として、まとめ上げるのは有意義な活動であると思う。

チケット駆動開発も、当初は現場から生まれた経験則に過ぎなかったけれども、実践知として再現可能な理論体系へまとめ上げることは可能だと思っている。
今はまだあいまいな知識や経験談で散在しているけれど、それらを体系的にまとめることは可能だろうと思っている。

【追記】
最近の地球科学の本は、高校時代に習った内容と比べると、最近10年間で内容が大きく変わっている。
新しい証拠や斬新な仮説がどんどん出て、従来の静的な地球ではなく、スノーボールアース仮説のように地球が完全に凍結してしまったとか、スーパープルームで火山の大噴火が古生代末期に起きて地球上の生物の95%以上が死滅してしまったとか、色んな仮説が出てきている。
読んでいて、ハラハラドキドキするくらい面白い。

個人的には「凍った地球―スノーボールアースと生命進化の物語 (新潮選書)」や「地球環境46億年の大変動史(DOJIN選書 24)」が、初心者にも読みやすくてお勧めだと思う。


| | コメント (0)

2013/11/23

統計学ブーム

日経情報ストラテジー2013年12月号に「統計学が最強の学問である」著者特別インタビューがあったのでメモ。

統計学が最強の学問である」の本は立ち読み程度しか読んでいないけれど、記事は面白かった。
最近のバズワード「ビッグデータ」「データサイエンティスト」が気になっていたから。

記事で気になった点は2つ。
一つは、最近のコンピュータ能力の向上のおかげで、プログラマのレベルの人でも統計学という理論を背景に、手持ちの大量データを解析する環境が揃ってきたこと。

10年以上前まで、Excelでグラフ化したり、Excelで財務分析したりするぐらいだった。
でも、今は、業務システムで貯められた大量のトランザクションデータを元に、回帰分析など統計学の手法を使って色んな観点で分析できる。
その時、ビジネス系のエンジニアならば、RDBに関するSQLは必須。
さらに、最近のビッグデータというバズワードを背景としたデータマイニングでは、R言語という統計学用のプログラミング言語が注目されているようだ。

R言語 - Wikipedia

今まで統計学ソフトと言えば、高価なツールしかなく、個人が購入できる代物ではなかった。
また、パソコンが登場するまでは、統計学は机上の空論に近い学問だった。
計算量が多すぎて、紙と手計算では、少しでも複雑になれば不可能に近かったからだ。
統計学は理論として確立されていても、実際の現場では使えず、頭の中でしか理解するしなかった。

しかし、プログラミングというスキルがコモディティ化したことと、最近のコンピュータ能力の向上のおかげで、能力とやる気さえあれば、データマイニングできる環境が揃いつつある。
R言語というオープンソースの言語とツールを導入すれば、世界中の人達が作ったライブラリを利用して、自分が分析したいことを実現できる。

そんな話を聞くと、RDBがコッドの集合論という数学的な理論を元に作られた後、RDBMSが普及することで業務システム開発で一般的な環境になった状況を追いかけている気がする。
統計学という古い学問や理論は既にあるのに、今まではCSVの大量データから傾向分析するための作業が手作業だったので、なかなか現場では使えなかったという背景があったわけだ。

チケット駆動開発がBTSという古いツールを元にタスク管理やソフトウェア開発のプロジェクト管理へ適用できた背景も、統計学とデータ分析の話と同様に、ソフトウェア開発をサポートするツールや環境がようやく最近になって揃ってきたのと同じ。

もう一つは、データ分析という手法が課題解決の手法と密接に絡んでいる点。
記事では例として、医学研究においてがん罹患率や生存率を探求したいが、そのままでは範囲が広く、元データも10年以上蓄積する必要があって現実的でない。
そこで、がん罹患率に直接影響しやすい別の指標、例えば喫煙率で代用して、その傾向を探る方向で分析する。

つまり、解決したい課題に対して、その前提条件に最も関係する変数や指標に着目して、最も効果的な解決方法を見出す手法を取る。
全ての範囲で大量のデータを収集して整理しても、真の解決にはならない。
最も有用であるとおもわれる仮説を立てて、その仮説をデータ分析で実際に検証し、そのフィードバックを受けて仮説を修正し、仮説の正しさを高めていく。

この手法はまさに、フェルミ推定のような問題解決手法や仮説検証スタイルと密接に絡んでいる気がする。

そんな話を聞くと、「創造的論文の書き方」に書かれていた話として、データ分析というデータの精度が高いツールを用いた時に、他の条件の精度を無視して強引な結論を出してしまう危険性を思い出す。
つまり、統計学とデータ分析の手法が強力な道具であったとしても、たった一つの観点におけるデータ分析の結果から、一般にはこういう傾向があるはずだ、とオーバージェネラリゼーション(過大一般化)してしまう罠のことだ。
この話は、ソフトウェア工学における「メトリクスの罠」も連想させる。

だから、いくら統計学やデータ分析が強力な道具であったとしても、論理の飛躍や強引な結論に陥らないように、上手く使いこなすことが大切なのだろう。

僕の考えとしては、Redmineをメトリクス収集ツールとみなした場合、チケットとして蓄積されたデータに対し、統計学の手法を使って分析することで、どのような経験則が得られるのか、を探ってみたいと考えている。
統計学とデータ分析、特にR言語については、今後も調べてみる。


| | コメント (0)

チケット駆動開発におけるサイクルタイムの計測方法~リーン開発で最も重要なメトリクス

リーン開発の現場」「リーン開発の本質」「リーンソフトウエア開発」を読み直すと、リーン開発で最も重要なメトリクスはWIP(仕掛り制限)ではなく、サイクルタイムであるような気がした。
ラフなメモ書き。

【1】「リーン開発の現場」を読み直すと、XPやScrumには出てこなかったメトリクスとして、サイクルタイムが出てくる。

リーン開発の現場」では、サイクルタイムとは、1機能の開発にかかった日数(週数)。
かんばん上の計測方法としては、「次の10機能」ステージから「受入テスト準備OK」ステージへ到着するまでの時間である。

サイクルタイムは何故重要なのか?
サイクルタイムは、顧客の要求が受付された後、本番リリースまでにどれくらいの時間がかかるか、を意味する。
サイクルタイムが短いほど、顧客の要求が製品に反映されるリードタイムが短くなるから、よりスピーディに注文を受け付けることが可能になる。
一時期のDellのPC組立事業と同じだ。

しかし、サイクルタイムを短くするのは現実的にはかなり難しい。
実際にサイクルタイムを計測してみると、その内訳の殆どは作業待ち時間で消費されている。
つまり、「ムダ」がたくさん含まれている場合が多い。

リーン開発の現場」では、プロセスサイクル効率でムダがどれくらい存在するのかをメトリクスで示している。

プロセスサイクル効率=作業日数/経過日数

リーン開発の現場」によると、たいていの企業ではプロセスサイクル効率は10~20%くらいだという。
つまり、サイクルタイムが20日(1ヶ月)だとしたら、実作業時間はわずか2~4日であり、残りの16~18日は作業待ち時間として在庫として積まれている事実を意味している。
作業待ちが16日以上もあるのならば、何故すぐにリリースしないのか、という指摘をしているわけだ。

製品が作業待ちとして80~90%も倉庫で眠っているとしたら、倉庫に保管している間、電気水道代もかかるし、その期間に市場が値崩れしてしまう危険もあるからだ。

【2】「リーンソフトウエア開発」P.33において、バリューストリームマップで分析したサイクルタイムの例が載っている。

(1)伝統的なウォーターフォール型開発の場合、
要求抽出→プロジェクト承認→要求収集→顧客の承認→分析→設計→設計レビュー→コーディング→テスト→導入
の作業が発生し、下記の内訳となる。

作業時間(実績工数)=21.6週
作業待ち時間=35週

サイクルタイム=作業時間+作業待ち時間=56.6週

プロセスサイクル効率=21.6/56.6=38.2%

(2)アジャイル開発の場合は、
要求抽出→プロジェクト承認→仮設→1イテレーション→2イテレーション→3イテレーション
の作業が発生し、下記の内訳となる。

作業時間(実績工数)=14.1週
作業待ち時間=2.8週

サイクルタイム=作業時間+作業待ち時間=16.9週

プロセスサイクル効率=14.1/16.9=83.4%

上記のサイクルプロセス効率を比較すると、WF型開発では、サイクルタイムのうち実作業して顧客に価値を提供している割合はわずか38%しかないのに対し、アジャイル開発では、サイクルタイムの実に80%以上を顧客に実際に価値を提供している作業に費やしている。
つまり、アジャイル開発の方が作業にムダが少ないことを指摘しているわけだ。

但し、「リーン開発の現場」では普通の企業のプロセスサイクル効率は10~20%しかないと書かれているから、もしそれが本当だとしたら、上記のWF型開発のメトリクスよりも更に悪いために、本当に意味ある作業に殆ど費やしていないことを示しているのだろう。

【3】チケット駆動開発で、サイクルタイム、プロセスサイクル効率はどのように実装されるか?
回答は下記だ。

チケットの属性には、開始日、終了日、実績工数が必ず入力されているとする。

(1)サイクルタイム=チケットの平均完了日数(チケットの開始日から終了日までの経過日数)

(2)プロセスサイクル効率=チケットの実績工数の合計/チケットの完了日数

各チケットでサイクルタイムは上記で計算できるので、アジャイル開発では、各イテレーションの全てのチケットのサイクルタイムを計算できるから、1イテレーションの平均サイクルタイムを出力できる。
そこから、イテレーション単位にプロセスサイクル効率を計算できる。

【4】上記の定義を見ると、チケットのサイクルタイムはMantisの平均完了日数とまさに同一だ。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

つまり、チケットが起票されてCloseされるまでの経過日数が平均完了日数であり、サイクルタイムとなる。
更に、障害チケットのサイクルタイムは平均修復時間(MTTR)そのものになる。

アジャイル開発では、サイクルタイムを短くすることに注力する。
その意味は下記にも書いたけれども、MTTRを極力短くすることによって、信頼度を高く保つことにある。
そのやり方は、WF型開発が極力故障を起こさないような方針に対し、アジャイル開発はたとえ障害がたくさん発生してもMTTR(サイクルタイム)を短くすることで、信頼度を同じ程度に保てるはずだ、という主張になっている。

アジャイル開発と品質管理の関係: プログラマの思索

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

【5】上記の定義を見ると、チケットのプロセスサイクル効率は、簡単に出力できる。

チケットが完了したタイミングで、実績工数と完了日数は確定される。
つまり、チケットを完了ステータスへ更新するタイミングで、リアルタイムにチケットのプロセスサイクル効率を計算すれば良い。

【6】チケット駆動開発において、サイクルタイムやプロセスサイクル効率というメトリクスは、どんな分析結果を提供し、どんな課題が発生するのか?

リーン開発の本質」P.129にタスクリストの話が載っている。
あるマネージャは、プロジェクトのタスクリストに750個のタスクがあり、それらに優先順位を定期的につけているという。
メアリーは、その要求を1ヶ月に平均していくつ完成できるか、聞いた。
マネージャは、平均して、毎月9つは完了すると答えた。(つまり、Velocityは9個/月)
すると、750個/9(個/月)=約7年分の作業がタスクリストに積まれていることになる。

その意味は、新しい顧客の要求がたった今到着したとしたら、タスクリストという作業待ち行列(キュー)の順序を変更できない場合、7年後にならなければリリースされないことを意味している。
メアリーは、絶対に終われないなら、そんなに大量のタスクリストに意味があるのか、と問うている。

この寓話は非常に重要な指摘事項だ。
チケット駆動開発を運用すると、チケットはどんどん溜まっていく。
チケット駆動開発では、忘れたくない作業や顧客の要望で重要度は高くない要望もチケット化する時が多いからだ。

だから、100枚や300枚のチケットが残として残るのは普通だ。
すると、残チケットの重みでタスクの進捗は落ちていきやすい。

例えば、300枚の残チケットがあるならば、Velocityが5枚/週としても、60週=約1.1年分のタスクが積まれていることになる。

以前Mantisを運用していた時、Mantinsのメトリクス画面において、チケットの平均完了日数は100~300日という値はザラに表示されていた。
その場合ならば、もっとひどくなるだろう。

それゆえ、チケット駆動開発では、棚卸しという場で、全チケットを精査し、イテレーション(リリースバージョン)単位にチケットを振り分けして、制御可能な作業量へ調整する。
棚卸しはできれば毎日、少なくとも週1回は行わなければ、チケットの精度が落ちてしまう。

また、Pivotal Trackerのように、Iceboxという要望の貯蔵庫を別途作る運用もある。

Pivotal Trackerとredmineの違い: プログラマの思索

例えば、忘れたくない作業や顧客の要望で重要度は高くない要望のように、今すぐ着手する必要はないチケットは、Iceboxに一旦保管しておき、棚卸しのタイミングで必要なチケットをBacklogに引っ張り出し、イテレーションに割り当てる。
Iceboxという特別なイテレーション(Redmineの対象バージョン)に保管しておけば、サイクルタイムの計算外として運用することも可能になる。

その意味では、チケットの棚卸しというプラクティスで、サイクルタイムが長くなりやすい罠を防ごうとしている。
だが、棚卸しだけでは対策は不十分だ。

リーン開発の現場」に出てくる因果関係図、「リーン開発の本質」に出てくるバリューストリームマップ、TPSのなぜなぜ分析のようなツールを使って、サイクルタイムにムダな作業がないか、なぜ作業待ちというムダが発生するのか、を徹底的に原因追求する必要があるだろうと思う。

【7】XP→Scrum→リーンというアジャイル開発の進化の歴史を辿ると、XPが見出した暗黙的なメトリクスが具現化された過程のように思える。

XPが提唱した週40時間労働、持続可能な開発ペースという概念は、ScrumがVelocity(スプリント単位の平均開発速度)で具現化された。

XPが提唱した小規模リリース、イテレーション単位の頻繁なリリースの背後には、サイクルタイム(要望受付からリリースまでのリードタイム)を短くするという手法が隠されている。
そのメトリクスはリーン開発では、サイクルタイム、プロセスサイクル効率で具現化された。

チケット駆動開発上でサイクルタイムやプロセスサイクル効率を実装した場合、どんな効果が生まれるのかをさらに考えてみたい。

| | コメント (0)

2013/11/18

データベース技術の今後の動向

本屋で偶然見かけた「7つのデータベース 7つの世界」を立ち読みしたら、とても面白かった。
また、Twitterで見つけた「データベース技術の羅針盤」というスライド資料がとても素晴らしかった。
リンクをメモしておく。

Twitter / matsunobu: 昨日のDB Tech Showcaseで話した「データベース技術の羅針盤」の資料を公開しました #dbts2013 http://www.slideshare.net/matsunobu/ss-28303485 …

Twitter / g3akk: 現在Facebookで活躍されているMySQLスペシャリストの松信さん @matsunobu によるすばらしい資料→http://slidesha.re/1bEqr4u 衰退する技術にdedicateすることがいかに無駄か、これはデータベース技術者に限ったことではないとおもう。公開に感謝

Twitter / zyunnosuke:Facebookで働かれているMySQLエンジニアの松信さんが日本で11/15に発表されたスライド。俯瞰的な資料がまた素晴らしい!
データベース技術の羅針盤 http://ow.ly/qSJaR

Twitter / ezmscrap: DBの話だけでなく、エンジニアのキャリアの話が面白い。面白いが、先を見るのは難しい。例えば、私はXMLDB技術に詳しいという黒歴史がある。やってる時は役に立つ、広まると思ったんだけどねーw 「データベース技術の羅針盤 http://htn.to/4cYddK


7つのデータベース 7つの世界|Ohmsha

DBと言えば、RDBを思い出すのが普通だが、最近はNoSQLのように、リレーショナルでないデータベースが雨後の筍のように出ている。
NoSQLについて僕は全く理解していないけれど、「7つのデータベース 7つの世界」では、次の7つのデータベースについて解説してくれているので、初心者には分かりやすい。

PostgreSQL : リレーショナルデータベース
Riak : キーバリューデータベース
HBase : カラム指向データベース
MongoDB : ドキュメント指向データベース
CouchDB : ドキュメント指向データベース
Neo4J : グラフ指向データベース
Redis : キーバリューデータベース

書籍「7つのデータベース 7つの世界」のご紹介 (コーソル DatabaseエンジニアのBlog)

何故、NoSQLが注目されるのか?
RDBだけでは解決できない問題領域において、NoSQLが役立つという状況があるからだろう。
そして、最近、「ビッグデータ」「データサイエンティスト」のようなバズワードが巷に出てきて、世の中の大量データからいかに意味あるデータを抽出すべきか、という問題が注目されているからだろう。

最近なら例えば、JR東日本がSuica利用データを、顧客の同意なしにビッグデータとして加工して販売して新聞に載った。
どの駅にどの時間帯にどんな傾向の人が乗降するのか、というデータは、住宅販売や小売業などのユーザに販売すれば非常に役立つだろう。

NoSQLの全貌は理解できていないけれど、個人的な興味を惹く内容は、MapReduceとの相性と、クラウドとの相性だ。

前者については、RiakやHBaseでは、MapReduceを使って、大量データを処理することができる。
特に、HBaseはHadoopでも使われている。
個人的には、HadoopがCobolのような古いバッチ処理の代替技術になりつつあるように思える。

基幹系バッチ処理をHadoopで高速化: プログラマの思索

歴史を振り返れば、RDBよりも以前は、固定長のテキストファイルをこねくり回すCobolのバッチ処理がエンタープライズ系では主流だった。
そして、今もなおCobolは生き残り続けている。
NoSQLはCobolの代わりに、固定長のテキストファイルの代わりに独自のデータ形式で情報を保持し、高速または大量に処理できるような仕組みとも言える。
つまり、NoSQLは、RDBがCobolを乗り越えようとした歴史の先祖返りと見なしてもいいかもしれない。

後者については、NoSQLはクラウドとも相性が良い。
7つのデータベース 7つの世界」では、HBaseをクラウドに持っていく方法についても解説している。

最近では、業務系基幹システムのバッチ処理をHadoopでリプレースし、さらにクラウド上で動かす記事があった。

「オンプレミス・システムの終わり」の始まり~AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道

NoSQLやHadoopの事例はWebシステムの大量データの処理しか今までなかったけれども、業務系基幹システムのバッチ処理にも同様に適用できる。
今まで、月次や年次の会計処理や、製造業における部品の所要量計算はバッチ処理で翌朝にならなければ出力されなかったが、Hadoopを使えば、1日数回実施できるので、あたかもリアルタイム処理のように扱える。
1日1回の結果が1日数回出力できるならば、在庫を減らしたり、会計報告書を見るサイクルを早めることで、経営判断を強力に支援することができる。

さらに、クラウドに業務系のバッチ処理が乗れば、サーバーのリプレースも関係なくなる利点もある。
オンプレミスではハードウェア障害として、HDD障害が非常に多いけれど、そんな障害対応からもインフラエンジニアは開放される。
何よりも、データ量の増加速度に応じて、スケールアップしやすい点もクラウドの良い点だ。

データベース技術の羅針盤の資料を読むと、そのようなデータベース技術の進化によって、DA(データ管理者)やDBA(データベース管理者)、インフラエンジニアが不要になり、コストを削減できる点も指摘している。
特に、クラウド上にバッチ処理もフロント側Webシステムも乗ってしまうと、従来必要であったDBAやインフラエンジニアの重要性は低くなる。

そんな歴史の進化を見ると、ソフトウェア技術の進化とは、ソフトウェア開発チームにおける数多くの役割を収斂させることだと言えるのではないだろうか。

組織パターン」や「XPエクストリーム・プログラミング入門」を読み直すと、ソフトウェア開発チームにたくさんの役割が必要だった。
例えば、プロジェクトマネージャ、テスター、品質管理者(QA)、ドキュメントライター、トラッカ(XP)、など数多くの役割が出てくる。
もちろん、DA(データの論理構造を決める管理者)、DBA(DBの物理構造を保守する管理者)、インフラエンジニア(基盤技術者)も開発チームには必要だ。

しかし、すべての技術がクラウドに乗って、その保守コストを劇的に下げることが出来れば、今まで必要だった役割がなくなり、開発チームに必要とされる役割はもっとシンプルになっていく。
むしろ、開発者に要求される技術が非常に広く深くなってくるとも言えるだろう。
ソフトウェア開発に必要な役割の数が減ったように見えるのは、あくまでも、重要度が低くなった役割の作業が減っただけなので、一人の開発者が複数の役割を担当できるようにならなくてはならないのだろう。

アジャイル開発では、単能工よりも多能工を重視するけれども、上記の技術の流れによる役割の変化も、その流れに同一視できるかもしれない。

| | コメント (0)

2013/11/17

JMeterの使い道

JMeterを別の観点で使った事例があったのでメモ。

【元ネタ】
【JMeter】毎月のクレジットカードの明細ダウンロードを自動化|ミセログ

Apache JMeter - Apache JMeter?

JMeterと言えば、Webシステムの負荷テストで使うツール。
例えば、リクエストを意図的に増やして、Web上の画面遷移の応答時間を計測した結果、どれだけの負荷がかかるとレスポンスが悪くなるかを調査したりする。

JMeterの画面上で、URLとリクエストパラメータをセットすればいいだけなので、操作性はとても良い。
普通は、負荷テスト用のテストシナリオを画面遷移としてケース作成し、そこからJMeterへ設定するやり方が多いだろう。

上記の記事では、クレジットカードの毎月の請求明細をダウンロードするために、JMeterを使って、画面遷移をあらかじめ設定しておき、WindowsのタスクスケジューラでCron代わりに定期的にダウンロードしている。

このやり方は面白い。
JMeterという負荷テストツールを本来の使い方ではなく、Web画面を操作する一連のバッチ処理として運用している。
他のやり方としては、例えば、Webシステムの受入テストの自動化にも適用できるだろう。
あるいは、RESTのようなWebの外部接続テストの自動化にも使えるだろう。

つまり、複数のWeb画面遷移に関わる処理が必要な場合、JMeterでその作業を自動化できるので、他にも色んな場合を想定できる。
色々考えてみる。

| | コメント (0)

チケット駆動開発が進むべき道part6~ウォーターフォール型開発への適用の方向性

最近、Redmineの話を聞いてみると、チケット駆動開発を、アジャイル開発を導入する手段として使うのではなく、むしろ、従来のウォーターフォール型開発を補完するような形でチケット駆動開発を取り入れて機能強化しているように思える。
考えたことをラフなメモ書き。

【参考】
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOL

[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば

なぜ日本ではチケット駆動開発が注目されるのか?(ゲストブログ) | Atlassian Japan

チケット駆動開発を上手に運用するためのプラクティス(ゲストブログ) | Atlassian Japan

【1】日経SystemsではRedmineの記事が1年に1回は掲載されているが、その理由を聞くと、読者アンケートを取った結果では、Redmineの読者評価が高いらしい。
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索に書いたけれども、SIerのマネージャ層がRedmineを導入して、プロジェクト管理を補完しようとしていると思われる。
もちろん、開発者が現場で使いやすいから、という理由もあるだろうが、上司の理解がなければ、そこまで興味を持たれて、実際に導入することもないだろう。

その方向性を考えると、日本のSIが従来から続けているウォーターフォール型開発に、チケット駆動開発を流用して、不足している部分を補完する動きのように思える。
つまり、チケット駆動開発をアジャイル開発の実装例として導入するのではなく、従来型のウォーターフォール型開発を機能強化する流れと言える。

【2】開発者の観点で見た場合、チケット駆動開発は、チケットとソースの相互リンクという機能が最も最優先だろう。
実際、ソースをコミットしながら、チケットを更新してCloseしていく時に、「No Ticket, No Commit」を運用して、チケットとソースをリンクさせる。
この運用ルールはトレーサビリティの強化につながるので、リリース後の保守で、リバースエンジニアリングしたり、仕様を理解するのに役立つ。

git-flowモデルと組み合わせて運用すれば、多数のブランチ管理もチケット管理と連動でき、ソースの変更理由を追跡しやすくなる。

TiDDとgit-flowを合わせた開発手法について | Technology-Gym

ゆえに、開発者としては、ソース管理が最初にありきで、チケット管理と連携させることで、タスク管理をより強化する方向にいく。
「ソース管理が最初にありき」という考え方は、出荷可能な製品を頻繁にリリースしながらアジャイルに開発していくスタイルと相性が良い。

【3】しかし、マネージャの観点の場合は、チケット駆動開発をメトリクス収集ツールとして扱い、進捗報告や品質管理、課題管理といった管理作業を楽にする機能を最優先するだろう。

彼らとしては、プロジェクトの進捗状況や品質をリアルタイムに見たい。
だから、チケット集計機能が最も重要になる。
タスクチケットをガントチャートで進捗管理したり、障害チケットからバグ収束曲線を出力してテストの終了条件を判定したりする。
また、チケットの予定工数と実績工数をwork_timeプラグインで入力してもらって、コスト管理に役立てることもできる。

チケットの集計条件を色々変えれば、いくらでも欲しいビューを出力することができる。
しかし、Redmineのチケット集計機能は、ロードマップ、ガントチャート、クエリぐらいしかなく、正直貧弱だ。
実際は、クエリでチケットをCSVで抽出し、Excelで整形するやり方が多いだろうと推測する。

【4】Redmineをベースにアジャイル開発として運用する場合と、ウォーターフォール型開発として運用する場合では、頻繁に見るビューが決定的に異なる。

アジャイル開発のように運用する場合は、Redmineのロードマップを基本にして、どのバージョンをいつリリースするのか、に力点をおいて進捗管理していく。
ロードマップ画面はリリース計画そのものであり、RedmineのバージョンはXPのイテレーション、Scrumのスプリントに相当する。
だから、ロードマップ画面による進捗管理を実践すると、自然にタイムボックス単位に開発する運用になる。

この運用の利点は、ロードマップを見れば、過去のリリース履歴から修正されたソースや仕様変更の経緯が書かれたチケットへ辿ることができる。
また、将来、どんな機能を優先してリリースするのか、も一目で分かる。

一方、ウォーターフォール型開発で運用する場合、Redmineのガントチャートを基本にして、当初の予定と実績にどれだけの差異が発生しているか、を中心に管理していく。
Redmineのチケットは、先行・後行関係を付けることもできるので、FS関係を実現できるから、ガントチャート上でクリティカルパスを見つけ出すことは実現可能だ。
ウォーターフォール型開発の進捗管理では、クリティカルパスを守るために有限な資源をリソースしていくやり方が多くなる。

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

また、Redmineの最新版では、ガントチャート画面でイナズマ線が表示できるようになったので、どのタスクが遅れているのかが一目で分かるようになった。

Redmine 2.3の新機能: プログラマの思索

Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog

【5】以上のように、Redmineの機能強化の方向性を追いかけてみると、ガントチャート画面を強化するなど、エンタープライズ向けを意識した観点が多く見られる。

実際、イナズマ線を実装したチケットのコメントを見ると、

Gantt progress line needs in Japanese enterprise.
Customer always requires it to developer.

と書かれている。

Feature #12122: Gantt progress lines (html only) - Redmine

Feature #3436: Show relations in Gantt diagram - Redmine

また、最近感じるのは、「Redmineによるタスクマネジメント実践技法」の第8章「チケット駆動開発を発展させるアイデア」の内容を実装した事例をちらほら見かけることだ。

例えば、EVMの実装の一部は、下記のEVMプラグインで既に実現されている。
EVMをRedmine上で実現できれば、コスト管理を予測しやすくなるだろう。

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

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

さらに、ITILの実装例としては、holonという会社が「Redmine for ITIL」というサービスで既に売り出している。
hinemosとも連携しているので、Redmine以外にも付加価値を高めている良い例だ。

Redmine for ITILが解決するもの: プログラマの思索

そんなことを考えると、EVMやITILのように既に理論はあるものの、従来のウォーターフォール型開発では運用しにくかった手法や実現しづらかった手法が、チケット駆動開発では簡単に実現できるため、その手法をRedmineの一機能として実現して適用しようとする方向性のように思える。

但し、その方向性は、アジャイル開発の利点を生かす流れではない。
あくまでも、従来のウォーターフォール型開発を変えることはなく、弱点を補完する機能だ。

この点は僕はあまり意識していなかったけれど、「アダプタブルウォーターフォール」とは違っており、ウォーターフォール型開発を改良する別の手法であるように思えるので、その根本原因や今後の動向を色々考えてみたい。


| | コメント (0)

2013/11/06

「リーン開発の現場」の感想part5~かんばんと因果関係図がセットで運用されるのは何故か

リーン開発の現場」で読みながら気づいた点をメモ。
ラフなメモ書き。
間違っていたら後で直す。

【1】WIP制限(仕掛り作業の上限値)を下げるのがいつも有効とは限らない

デスマーチプロジェクトでは、メンバー全員の稼働率は100%を超えて働きすぎている状況だ。
だから、プロジェクトの作業負荷が高すぎる場合、WIP制限の値を下げて、メンバーから方の重荷を減らし、本来の力を発揮できるようにする。
WIP制限を下げるのが有効な状況は、過剰なマルチタスクが多く、後続プロセスに負荷をかけすぎる場合だ。
在庫をたくさん作っても、後続のプロセスが処理できなければ、効率が悪い。

例えば、テスト環境が1個しか無いのにたくさんの障害修正を送りこもうとするケース、レビューアが1人しかいないのにたくさんの設計書レビューを詰め込むケース、継続的デプロイの環境がないのに頻繁にリリースしようとするケースがあげられるだろう。
そんな場合は、ボトルネックとなる前工程の仕掛り作業の上限値を下げて、後続プロセスの作業負荷をかけすぎないようにする。

しかし、WIP制限を下げるのが本来の根本的解決ではない場合がある。

例えば、テスト環境が1個しか無いのにたくさんの障害修正を送りこもうとするケースでは、そもそもテスト環境が1個しか無いのがボトルネックなのだ。
テスト環境を仮想化して開発者1人に1個、あるいは、システムテストブランチごとに1個用意できれば、スムーズに作業が流れるだろう。

同様に、レビューアを複数人配置できれば、設計書レビューをもっとはかどらせることも出来るだろう。
継続的デプロイできるように、リリース作業を自動化すれば、頻繁にリリースできるようになるだろう。

つまり、目の前の問題の根本原因は別のところにある。
WIP制限を下げる方法は実は対症療法でしかない場合もありうるし、おそらくWIP制限を下げることが根本原因ではない場合が多いのでないだろうか。

【2】ヘンリックが編み出した因果関係図とは

リーン開発の現場」第20章には、因果関係図の説明がある。
因果関係図は「リーン開発の現場」独自の根本原因を突き止める手法だ。
内容を読むと、QC7つ道具の特性要因図やシステム思考の因果ループ図をミックスしたような頭を使って、目の前の問題から悪循環となっていく症状や原因を洗い出し、根本原因を突き詰めていく手法みたいだ。

実際に「リリースサイクルが遅い」「バグが多い」「ペアプロできない」問題を因果関係図で深掘りしていく内容はとても面白い。

この因果関係図を読んで疑問に思ったことは、何故、ヘンリックは、かんばんとは直接関係のない「因果関係図」の手法を説明しているのか?

その疑問を考えていると、トヨタがかんばんやなぜなぜ分析を生み出した事実を何となく連想させる。

【3】かんばんと因果関係図は何故セットで運用されるのか?

以下はあくまでも僕の推測だ。

かんばんの最大の特徴は、強力な「見える化ツール」である点だと思う。
かんばんで進捗管理を始めると、従来のガントチャートとは違って、作業の流れが見えるようになる。

普通は、プロジェクト内部で発生するすべての作業をコントロールしているのは、プロマネの頭の中だけだ。
開発者は、自分のタスクをこなすだけで精一杯で、自分のタスクがプロジェクトのどの部分を占めているのか、理解しづらい。
そんな状況では、チームは一体感を持ちにくい。

ところが、ヘンリックの運用事例のように、かんばんで進捗管理を見える化すると、ユーザ観点の機能カードの流れが一目で分かるし、機能カードをさらに各チームがタスクカードに分割して作業するから、自分のタスクカードがどの機能カードに直結しているか、開発者にも分かる。

かんばんで良い点は、作業待ちが発生するカードやフェーズが目につきやすいことだ。
特定のカードが特定の場所で滞留していたら、そこがボトルネックになっていて、後続のプロセスに作業が流れていない。
ちょうど、糞詰まりみたいなものだ。
特定のフェーズで流量が狭くなっているので、後続のプロセスに作業が流れていないのだ。

そんな状況を解決するには、一つは、ボトルネック工程の前工程の仕掛り作業の量を減らして、ボトルネックの処理量に合わせるように調整する方法がある。
これがWIP制限を下げる手法に相当する。
でもこの方法は対症療法でしかなく、問題を悪化させる場合もありうる。

もう一つは、ボトルネックとなる工程は何故スループットが少なすぎるのか、その原因を徹底的に深掘りして、根本的な解決を試みる手法がある。
おそらく、この状況で、なぜなぜ分析が使われて、根本原因を突き止めて、解決方法を見出すのだろうと思う。

すなわち、かんばんとなぜなぜ分析は、セットで運用されるべき手法なのだと思う。

なぜなぜ分析の経験は僕はないけれども、経験者から聞いた話では、根本原因は最終的には心理的要因に落ち着くらしい。
例えば、油断、思い込み、先入観など。
だから、なぜなぜ分析をやるのは、精神的に追い詰められる時が多く、やるのは結構しんどい、と聞いた時がある。
おそらくそこまで突き止めないと、根本的解決にならないのかもしれない。

そんな事を考えると、ヘンリックがかんばんを使った運用事例をかなり詳しく説明した最後に、因果関係図で根本原因を追跡する手法を説明している理由は、かんばんと因果関係図が密接に相互に関係しあっているからだと思う。
かんばんでボトルネックが見える化されるからこそ、因果関係図でボトルネックとなる原因を徹底的に究明する必要があるわけだ。

以上のようなことを考えると、欧米人はトヨタが生み出したかんばんやなぜなぜ分析をソフトウェア開発に上手く適用して、効果が出るようにうまく実現したように思える。
その考えが正しいか、調べてみる。

| | コメント (0)

2013/11/04

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理

リーン開発の現場」で読みながら気づいた点をメモ。
ラフなメモ書き。

【1】トレーサビリティ

チケット駆動開発の大きな利点の一つは、トレーサビリティだろう。
ソースから本来の仕様や障害などの変更理由をいつでも辿ることができる。
No Ticket, No Commitによって、ソースからチケットへのトレーサビリティを実現する。

リーン開発の現場」を読むと、ヘンリックはかんばん上でトレーサビリティを実現させるための工夫を凝らしている。
第7章「準備OKを定義する」で詳しく書かれている。

機能カードが開発準備OKとなる条件として、まずID(識別子)が振られる。
そのIDは一意なキーであり、要求仕様や設計書などはWikiに記載されており、Wikiに書かれたIDと紐づくように運用されている。
この運用によって、機能カードのIDから本来の要求や詳細な設計内容を辿ることができる。
要求品質の観点では、先方追跡性が実現されている。

機能カードがシステムテスト準備OKとなる条件として、デモが完了しているなどの条件だけでなく、コミットコメントに修正理由と機能IDが残されている条件もある。
「リポジトリにコミットする時に、機能IDでタグ付されるべき」という運用は、まさに「No Ticket, No Commit」と同一だ。
この運用によって、機能カードから実装されたソースへ辿ることができる。
要求品質の観点では、後方追跡性が実現されている。

トレーサビリティは、大規模プロジェクトやオフショア開発など、コミュニケーションがどうしても不足しがちな状況では威力を発揮する。
ヘンリックは「大きなプロジェクトでは、いつもトレーサビリティについて大騒ぎするね」と書いているように、彼も同じような経験をしているのだろうと推測する。

【2】プロセスサイクル効率

12.5節「プロセスサイクル効率」で紹介されている。

プロセスサイクル効率=作業日数/経過日数

・作業日数=実際に開発(作業)していた日数。
 ⇒WIPステージ(開発中→システムテスト準備OK→システムテスト中)で貼られていた期間。
・経過日数=サイクルタイム。
 ⇒開始日(次の10機能→開発中)から終了日(システムテスト中→受入テスト準備OK)までの期間。

プロセスサイクル効率の意味は、機能カードに携わっている期間のうち、作業待ち時間がどれくらいあったのか、を計測するメトリクスであること。
つまり、プロセスサイクル効率が低いほど、作業待ち時間が多く、無駄が多いことになる。
プロセスサイクル効率が低い機能カードは、かんばんのWIPステージに長期間貼られているものの、実際はほとんど手付かずになっている状況を意味している。

ヘンリックは、プロセスサイクル効率を効率化する意識がない限り、普通の企業では10~15%程度だろうと言っている。
この事実が正しいならば、経過日数10日の機能カードは、実は実績工数が1~1.5人日しかないことを意味する。
この状況では、実績工数1人日のチケットをリリースするには、7~10倍の期間がかかることになる。
つまり、頻繁にリリースするのはとても難しい。

こんな状況に陥りがちな理由は、ソフトウェア開発では、作業待ちになりやすい状況が多いからだろう。
例えば、要件定義後にたくさん設計書を書いたけれども、レビューアが忙しすぎて、レビュー待ちで放置され、ようやくレビューしたら、たくさんの指摘を受けて再修正が発生した。
テスト環境やテストデータが準備されていないために、せっかく開発した機能がテスト待ちで放置されて、ようやくテストしたら、予期しない障害が多発して、手戻りが大きく発生した、などの事例が思い浮かぶ。

作業待ちの時間が減らせるならば、機能カードはかんばん上をスムーズに流れ、サイクルタイムが短くなるからプロセスサイクル効率は高くなるはず。
作業待ちが多い機能カードには、必ずボトルネックが存在するので、ボトルネックを解決すれば、作業待ち時間は減るはず。
プロセスサイクル効率は改善の道具として使えるわけだ。

ソフトウェア開発で作業待ちが発生しないようにするには、特に、機能の実現可能性を調査したりテストするためのテスト環境構築、ビルドの自動化が重要であると個人的には思っている。(当たり前だけれど)

【3】構成管理

第14章「バージョン管理の方法」では、大規模プロジェクトにおける構成管理の手法が書かれている。

trunkはメインブランチであり、最新の安定したブランチ。
「安定している」とは、システムテストの準備ができていること、とヘンリックは定義している。
trunkには、機能テストが通過して、システムテスト準備OKになった機能カードが組み込まれる。

チームブランチは、各チームが開発しているブランチであり、すべてのユニットテストが通過している。
開発中のソースもコミットOKらしい。
チームブランチは、trunkと同期しているが、制限がある。
チームブランチ→trunkは、システムテスト準備OKにならなければコミットできない。
trunk→チームブランチは、毎日同期される。
もちろんコンフリクトは発生するだろうが、頻繁にマージ作業を行なっているらしい。
この運用によって、チームブランチには、開発中だが最新の状態になる。

システムテストブランチは、安定したシステムのバージョンから派生して、システムテストを行うためのブランチ。
最新の機能カードが組み込まれてシステム準備OKになったら、システムテスト中フェーズへ移して、システムブランチ上でテストする運用らしい。
この運用では、システムテストブランチでは、新しい機能カードが組み込まれないため、テストと障害修正だけに専念できる利点がある。
障害修正はシステムテストブランチ上で直接行われ、テストが終われば、trunkにマージされる。

ヘンリックの運用では、システムテストを継続的に実施するが、毎回全てのシステムテストを実施しているわけではない。
回帰テストが自動化されている保証があるし、修正された範囲が限定されているので一部のテストケースを実施すればよいという判断もある。

個人的には、大規模プロジェクトになるほど、わずか1行のソース変更でもサイクルタイムが長くなる傾向にある。
特に、設計者、開発者、テスト担当者のように複数人が役割分担する場合、そのワークフローを通過するだけでも時間がかかってしまう。
ヘンリックが言うように、ソース1行を変更して本番リリースされるまでの時間を計測しておくことは、そのプロジェクトのアジャイル度合いを直接表現するメトリクスになっているだろう。

| | コメント (0)

2013/11/03

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係

ヘンリック著「リーン開発の現場」において、サイクルタイムという重要なメトリクスが出てくる。
理解できていることをラフなメモ書き。
間違っていたら後で直す。

【参考】
数学トレーニング講座

待ち行列(1)

- サルでもわかる待ち行列

リトルの法則 - Wikipedia

リトルの法則 - Elegant Cat Wiki

待ち行列の計算

【1】待ち行列理論は情報処理技術者試験でも良く出てくる。

その中でリトルの法則は、リトルの法則 - Wikipediaの通り。

【リトルの法則】L_q=λW_q

L_q:待ち行列内に滞在している平均客数
λ:平均到着率
W_q:待ち行列内の平均待ち時間(つまり、客が待ち行列に到着して最後尾に並びはじめてから、サービスを受け始めるまでの時間)

リトルの法則の使い道は、リトルの法則 - Elegant Cat Wikiに書かれている。

「1時間に20人のお客さんが来て,平均30分間滞在していたら,店の中には1時間あたり平均10人のお客さんがいる」

「例えば,日本の人口流動では、日本人の平均寿命はだいたい80年、日本の総人口は1億2千万人くらいとすれば、年間あたり150万人が出入り(出生・死亡)している」

「例えば,大学への入学者数では、学生数1万人,平均4年滞在だと,年間2,500人ほど入ってくる計算になる」

リトルの法則を使えば、病院や人気のレストランや遊園地のアトラクション、ATMの待ち時間を簡単に計算できる。

リトルの法則の注意点としては、以下の通り。

・系が安定していて割り込みがないのが前提
・対象がどのような確率分布であってもこの振る舞いをする
 (つまり、M/M/1モデルだけでなく、サービス窓口が2個以上でも同じ)
・客が待ち行列に到着する割合(平均到着率:λ)は待ち行列を出る割合、サービスが完了する割合(サービス利用率:μ)が同じと想定する

【2】サイクルタイム、Velocity

リーン開発の現場」によれば、かんばん上で採取するメトリクスとして、Velocityとサイクルタイムを計測している。
Velocityは、1週間に開発した機能の数。
具体的には、1週間で受入テスト準備OKフェーズに移動された機能カードの数。
Scrumでも出てくるおなじみのメトリクス。

サイクルタイムは、1機能の開発にかかった時間。
具体的には、開始日(次の10機能フェーズから開発中フェーズに移動された日)から終了日(システムテスト中フェーズから受入テスト準備OKフェーズへ移動された日)までの時間。

Velocityもサイクルタイムも、かんばん上では計算しやすい。
Veclocityは1週間後に、受入テスト準備OKに入ったカードを数えればよい。
サイクルタイムは、カードごとに、開始日と終了日の差を計算すればよい。

では、なぜ、Veclocityとサイクルタイムが重要なのか?
Veclocityは開発チームの生産能力そのものに相当する。
値が大きいほど、開発チームは数多くの機能を開発完了できることを意味している。
実際は、プロジェクトが安定すると、Velocityの値も増えていくが緩やかに一定の値で安定するときが多い。

リーン開発の現場」では、Velocityの計算ではストーリーポイントを使わない。
その理由が12.2節「ストーリーポイントを使わない理由」に書かれている。
僕の理解では、機能カードの粒度が一定ならば、機能カードをポイント付けする必要がない、とヘンリックは決めているようだ。

サイクルタイムは、機能が開発完了するまでの開発時間を意味している。
値が小さいほど、開発時間が短いので、頻繁にリリースできることを意味している。
リーン開発の現場」では、サイクルタイムは、実際の作業日数よりも5~10倍に長くなるらしい。
つまり、サイクルタイムには、作業待ち時間がかなりの割合を占めていて、リリースできるまでに相当な時間と労力を費やしているわけだ。

リーン開発の現場」では、サイクルタイムを機能ごとの管理図でグラフ化し、ある機能が開発完了するまでの時間を予測するのに使っているようだ。

また、「リーン開発の現場」によれば、機能の開発規模とサイクルタイムに相関関係はないらしい。
つまり、機能の大きさがサイクルタイムに影響を及ぼしていないとヘンリックは結論付けている。

【3】サイクルタイムの計算方法

リーン開発の現場」の12章プロセスメトリクスP.88-89で、サイクルタイムの計算を以下で計算している。

・開発中の機能(仕掛り中(WIP)の機能)
 =L_q(待ち行列内の平均カード数)
 =30機能

・1週間で開発できる機能(Velocity)
 =λ(平均到着率)
 =5機能/週

⇒サイクルタイム(1機能あたりの平均待ち時間)
 =W_q(待ち行列内の平均待ち時間)
 =30/5=6週間

※注意:
リーン開発の現場」P.88を読むと、下記の仮定があるように思える。
・Vecocityは5機能/週で安定していた。
・WIP制限(仕掛かり制限)は、30機能で上限値を決めていた。
 かんばんの写真を見ると、開発チームは3チームあり、チームごとのWIP制限は10機能で決めていた。
 ⇒3チーム全体のWIP制限は、3 * 10=30機能になる。

かんばんのメトリクスで面白いのは、仕掛かり中の機能カード数とVelocityを計測できれば、リトルの法則によってサイクルタイムの理論値を計算できることだ。

ヘンリックは、サイクルタイムを平均6週間から2週間に改善したいと考えていた。
すると、選択肢としては、二つある。

一つは、Velocityを増やすこと。
もう一つは、WIP制限を減らすこと。

Velocityを5⇒10機能/週へいきなり増やすのは、現実的に無理。
むしろ、WIP制限を減らす方が即効性がある。
作業中の機能カードの数を減らすだけだから、簡単だ。

WIP制限を30⇒15機能へ減らすと、サイクルタイムは下記で計算できる。

・開発中の機能(仕掛り中(WIP)の機能)
 =L_q(待ち行列内の平均カード数)
 =15機能

・1週間で開発できる機能(Velocity)
 =λ(平均到着率)
 =5機能/週

⇒サイクルタイム(1機能あたりの平均待ち時間)
 =W_q(待ち行列内の平均待ち時間)
 =15/5=3週間

※注意:
リーン開発の現場」P.89を読むと、下記の仮定があるように思える。
・1チームごとのWIP制限(仕掛かり制限)は、10⇒5機能で上限値を決めた。
 ⇒3チーム全体のWIP制限は、3 * 5=15機能になる。

よって、サイクルタイムが6⇒3週間に半分減らせたので、当初の目標の1/3へ減らすのは無理だったが、十分な削減だったとヘンリックは結論付けている。

【4】サイクルタイムにリトルの法則を適用する意味

サイクルタイムの計算方法で面白いのは、かんばん上で流れる仕掛中のカード枚数の上限値(WIP制限)が待ち行列内の客数(L_q)に相当することと、Veclocityが待ち行列システムの平均到着率に相当することだ。

前者は、何を意味しているのか?
どの開発チームもメンバーが手持ち無沙汰にならないように、メンバーにタスクを1個以上アサインするが、かんばん上で作業できる機能カードは、WIP制限という上限値があるので、その上限値いっぱいまで作業するのが前提になっているように思える。
つまり、かんばん上の機能カードは常時、WIP制限という上限値までいっぱいに貼られている場合が多い。

すると、かんばん上で開発中~システムテスト中の機能カードは、あたかも待ち行列と見なすことができる。
待ち行列にたまっている客数、つまり、機能カード数はWIP制限という上限値になっているわけだ。

後者は何を意味しているのか?
リトルの法則の前提条件としては、待ち行列への平均到着率(λ)やサービス利用率(μ)が同じと想定している。

かんばん上の仕掛中の機能カードがWIP制限という上限値いっぱいまで貼られていたとすれば、かんばんは機能カードで満杯状態だ。
すると、この前提条件を満たす状況では、開発中フェーズに機能カードに入れるタイミングは、システムテスト中フェーズから受入テスト準備OKフェーズへ機能カードを出すタイミングと同じになる。

普通は、サービス利用率(サービス処理率)がVelocityに相当するように思えるけれども、上記の前提条件があるから、平均到着率と見なせるのだろう。

つまり、機能カードが開発完了しなければ、次の新しい機能カードが開発中フェーズのかんばんに入れることはできないから、Pullシステムに似ているように思える。
かんばんでは、後工程の作業が終わらなければ、前工程でいくら作業して成果物を後工程へ送り続けても、WIP制限によって、前工程で成果物を作れない仕組みになっているわけだ。

【5】WIP制限(仕掛り制限)を制御する理由

【5-1】WIP制限が重要な理由は、「リーン開発の現場」ではいくつか書かれている。

一つは、過剰なマルチタスクを避けるために、後続プロセスに負荷をかけすぎないようにするため。(P.75)
WIP(仕掛中)とは、開発中・システムテスト準備OK・システムテスト中の3つのフェーズに貼られているカードを指す。
開発中のカードは開発チーム、システムテスト中のカードはテストチームの役割分担になっている。

開発チームは開発中のカードだけに専念してどんどん機能を実装すればいいが、じきにシステムテスト準備OKにカードがたくさん溜まってくる。
テストチームは頑張って、システムテスト中へ機能カードを移してテストするだろうが、普通はテストの方が時間がかかるから、システムテスト中がボトルネックになってくる。

でも、1チームのWIP制限が10枚と決まっていれば、システムテスト準備OK・システムテスト中のカードが10枚あって、開発中のカードが0枚であったとしても、開発チームは次の新しい機能カードに着手することはできない。
機能カードをどんどん開発して、システムテスト準備OKへ移しても、テストがボトルネックなので、無駄な在庫をどんどん増やしていることになるからだ。

つまり、開発チームは手持ち無沙汰だが、テストチームは忙しすぎて次の作業に手が回らないことを意味している。
だから、この状況では、開発チームはテストチームの支援に集中すべきだ、とヘンリックは言っている。

もう一つは、メトリクスの一貫性を保つため。(P.78)
ヘンリックは故意に、機能カードのみWIP制限という上限値を付けており、技術課題やバグ修正にはWIP制限はつけていない。
WIP制限があるからこそ、待ち行列の客数(L_q)がほぼ一定になるし、平均到着率(λ)も平均化しやすい。
リトルの法則が使えることを意味しているのだろう。

【5-2】「リーン開発の現場」では、WIP制限を減らす手法に力点を置いているが、その手法がいつも有効とは限らない。
WIPを減らしすぎると、メンバーが手持ち無沙汰となり、暇になって遊んでしまう。(P.89)
更に、遊んでしまう人が増えて一部の人だけが忙しい状態になれば、Velocityが小さくなってしまい、悪影響を及ぼす副作用もありうる。

だから、「リーン開発の現場」では、WIP制限がいっぱいの理由で手持ち無沙汰となったメンバーには、技術課題に取り組んでもらうことを「奨励している」らしい。(P.78)
技術課題を解決すると、後続プロセスの中にあるボトルネックが解消する場合があるからだ。(P.76)
実際、テスト自動化、ビルド自動化、テストデータの作成、テスト環境の構築などに取り組めば、テスト作業のボトルネックが解決されるだろう。

そのために、「今週の質問」というカードを貼り付けておき、やることのないメンバーには、「今週の質問」にある「今日すべきことは何か?」に従って優先順位の高い作業に取り掛かるように仕向ける。
つまり、WIP制限によって、メンバーは、いつもと違う作業を時々やってもらうようになる。(P.79)

「WIP制限の本質は、何かを始めるよりも、今の作業に集中して終わらせることだ!」(P.79)とヘンリックが主張しているのは、上記のような理由があるのだろう。

【5-3】ここで、WIP制限のように、機能カードの上限値を設定する箇所は、仕掛中(WIP)の機能カード以外にもあるのに注意したい。
「次の10機能」フェーズは、開発チームが取り掛かるプロダクトバックログに相当するが、カード枚数は10枚に制限されている。
そのおかげで、開発チームはどれに取り掛かればよいか、すぐに判断できる。

また、バグの登録枚数を30枚に制限している。(P.54)
ヘンリックによれば、バグがトップ30に入るかどうかの議論が必要なバグだけに集中したいから。
バグ一覧が無制限に満杯の場合、長時間の退屈な変更管理ミーティングが必要になり、時間の無駄だから、と彼は言っている。
バグがブロッカーならば、すぐに修正すれば言いし、トップ30に入らないバグに対処するよりも、機能カードに着手する方が優先度が高いから。

この箇所は、チケット駆動開発の弱点を補っている部分のように思える。
チケット駆動開発では、どうしてもチケットは乱発されやすい。
すると、チケット一覧からチケットを棚卸ししたくても、変更管理ミーティング内で精査できない時が多くなる。
バグのトップ30のように既に上限値があれば、チケットを捨てても構わない。
バグの一覧はいつも最新化されているならば、棚卸しのコストはかなり減る利点がある。

【5-4】WIP制限をうまく使うテクニックは、TOCの話を連想させる。
TOCでは、ボトルネックとなる工程がシステム全体のスループットを決定づけるから、ボトルネックの生産能力を上げるべきだと言っている。
これは、テスト工程がボトルネックだからこそ、前工程である開発中フェーズの機能カードを頑張っても在庫を無駄に増やすだけで、テスト工程に注力すべきという話につながるだろう。

また、TOCでは、生産の揺らぎ(変動)を安定させることにも言及している。
これは、Velocityが平均到着率とみなせた場合、Velocityを安定化することで、スループットを安定化できることを意味していると思う。

また、メンバーが技術課題を解決するとボトルネックが解消される話は、TOCにおけるボトルネック改善プロセスに似ているように思える。
ボトルネックを探して解決して、惰性にならないように、別のボトルネックを探して注力していくプロセスと同じだから。

【6】「リーン開発の現場」を読むと、単にかんばん上で機能カードを作業しているだけではなく、とても細やかなノウハウが詰め込まれているのが分かる。

Redmineによるチケット駆動開発を経験していれば、チケット一覧をかんばん、チケットを機能カードに対応付けて、作業するだけに思えるかもしれない。
でも、「リーン開発の現場」では、かんばんを単なる作業用のタスクボードではなく、WIP制限という仕掛中のカード数に上限値を設けて、テストチームの作業負荷が高くならないようにして、メンバーがプロジェクト内で自発的に動くような仕組みが織り込まれている。

リーン開発の現場」の写真にあるかんばんを見ると、フェーズがたくさんあるだけでなく、かんばんの枠外にあるメモがたくさん貼り付けられている。
そのメモは「今日の質問」「次の5つの技術課題」など、WIP制限によって暇なメンバーが手持ち無沙汰にならないように、普段とは違った作業をしてもらうような雰囲気が仕組まれている。

そんな部分を読み取ると、「リーン開発の現場」のかんばんによるプロジェクト管理は、ヘンリック独自のノウハウがたくさん詰め込まれているのが良く分かる。

但し、「リーン開発の現場」を読んで、新たに以下の疑問も持っている。
色々考えてみたいと思う。

(1)サイクルタイムを最小値とするには、WIP制限(仕掛制限)をどれくらい減らせばいいのか、という手法はあるか?
 WIP制限を小さくしすぎると、逆にサイクルタイムは長くなるのではないか?

(2)メンバーの稼働率と、サイクルタイムに関係性はあるか?
 直感的には、稼働率が低すぎるとメンバーは暇すぎるのでVelocityが落ち、サイクルタイムもさほど短くならない。
 稼働率が高すぎると、メンバーの作業負荷が高いため、Velocityは低くなり、サイクルタイムは急激に長くなると思われる。
 最も頃合の良い稼働率を計算するための手法はあるか?

| | コメント (0)

« 2013年10月 | トップページ | 2013年12月 »