« 2013年9月 | トップページ | 2013年11月 »

2013年10月

2013/10/31

「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム

ヘンリック著「リーン開発の現場」の感想をラフなメモ書き。

【1】「リーン開発の現場」で最重要の概念は「仕掛り(WIP:Work In Progress)」である。
僕もレビューに加わったのだが、WIPをどう訳すか、という問題を翻訳者の藤原さんや市谷さんだけでなく、レビューアも巻き込んで議論となった。
リーン開発の現場」の翻訳書では、WIPという単語をそのまま表現し、脚注で「仕掛かり」と記載されているが、僕は、WIPのような英単語ではなく、仕掛かりという日本語で表現すべきだったと考えている。
その理由を、以下、色々書いてみる。

【2】理由の一つ目は、会計簿記の観点だ。

工業簿記(簿記2級)の観点では、工場では原材料→仕掛品→製品の流れでモノが作られる。
原材料を仕入れて、仕掛品という未完成の中間物を経て、製品という完成品へモノが価値あるもの(実際は売上計上されるもの)へ変わる。

仕掛品という言葉には、工場ないし倉庫で、まだ完成途中のモノで、100%の価値があるわけではないが、少なくとも資産価値はあるものとして捉えられる。
実際、工業簿記では、仕掛品という科目は資産科目になっている。

リーン開発の現場」本を読むと、ユーザから収集したフィーチャ(機能)から仕掛中のタスクやシステムテストを経て、ソフトウェアが作られる流れだ。
その場合、仕掛品に相当するものが「かんばん」で表現されているストーリーやタスクなどに相当する。
アジャイル開発の観点では、それら仕掛品はソフトウェア開発においては価値がない(未完成のソフトウェアはユーザの要望を満たすものではなく、全く価値がない)という主張が、ソフトウェア特有の観点であり、従来の製造業と違う点だと思う。

餃子の王将を例にすれば、玉ねぎや小麦粉が原材料で、生の餃子や餃子の皮が仕掛品、焼き餃子や水餃子が製品に相当するだろう。
但し、餃子の仕掛品は単品でも売れる(つまり価値がある)所にソフトウェア開発とは違う特徴がある。
でも、生の餃子(仕掛品)は焼き餃子や水餃子(製品)よりも安いので価値は低い。

会計知識のある方が「WIPとは仕掛中のモノ(仕掛品)の状態だよ」と聞けば、似たような概念として認識しやすくなり、かつ、ソフトウェア特有の考え方にもなるほどと思ってもらえるのではないか、と考えている。

ここで、製造業の場合は、餃子の王将の例のように、仕掛品である生餃子や玉ねぎや肉などの原材料は、価値は低いけれども資産価値があるという点に注意しよう。
製造業などのビジネスでは、製造工程で作られる仕掛品や廃棄物などの副産物を、他の業者に転売できたり、他の工程に再利用できれば、多少なりとも売上を上げることができる。
実際、工場では、廃棄物を燃やして廃熱を発電に使ったり、廃棄物を牛などの飼料にするなど、副産物を再利用する方法がある。

副産物を再利用することができれば、無駄な在庫が発生したとしても、転売できる手段があれば、在庫の価値は少なくともゼロではない。

しかし、製造業では製造工程で作られる仕掛品などの副産物を有効活用できる場面があるのに対し、ソフトウェア開発では、開発工程で作られる作業中の設計書やプログラムの断片、テストスクリプトは正直余り価値がない。

例えば、リリースされておらず、総合テスト中のモジュールやライブラリは、まだ障害が残っている可能性もあり、そのままでは使えない。
むしろ、どこまでテストすればリリースできる品質になるのか、という調査工数もいるし、回帰テストや障害修正の工数も余分にかかる。
テスト工程で作られたテストスクリプトやビルドスクリプトも、参考にはなるけれど、そのスクリプトが別のシステムでそのまま使えるわけではなく、中身を調査して、流用できる部分とカスタマイズする部分を区別して開発し直す必要がある。

つまり、ソフトウェア開発では、仕掛かり中の機能、それに派生する設計書やモジュール、ライブラリ、スクリプトなどの副産物は、そのままでは再利用しづらい。
ソフトウェアを再利用するには、工数がかかりすぎるのだ。
それだけの工数を投入するのが難しい場合、再利用できないために、最初からスクラッチで開発した方がマシという決断もありえる。

だから、ソフトウェア開発では、仕掛かり中の機能やそれに派生する成果物は、価値がゼロと見なした方が、無駄な作業が発生しづらいという場面があるのだろう。

【2】もう一つの理由は、製造業のかんばんの観点だ。
製造業におけるかんばんの観点では、ソフトウェアかんばんに出てくるタスクカード(又は障害管理票)は仕掛かんばんに相当するという話がある。
例えば、「実践 反復型ソフトウェア開発」のP.207「トヨタかんばん方式とバグ追跡方式」を参考にしてください。

本来の製造業のかんばんでは、仕掛かんばんが工場内部の製造指示書に相当し、工場の各工程で加工される仕掛品という現物とセットで仕掛かんばんが渡される。

仕掛かんばんが仕掛品という未完成の現物と必ずセットで動くことから、例えば、
「かんばんなしでは部品の生産は開始しない」
「かんばんに書かれた製造方法と品質を満たさなければ後工程に回さない」
「工場内に流通するかんばんの量を制限することで在庫を減らし、作業負荷を下げる」
などの幾つかの特徴が出てくる。

この特徴は、今回の本に書かれているソフトウェア開発の「かんばん」の考え方に同一だ。
むしろ、トヨタを代表とする製造業のかんばんが発生源で、そのアイデアをソフトウェア開発に適用して派生した特徴でもある。

つまり、製造業のかんばんの考え方に慣れている人にとっては、「仕掛り」という言葉からWIPが意味することを理解できるだろうし、ソフトウェア開発にも同様に適用できることを理解してもらえると僕は考えている。

【3】製造業におけるかんばんをカイゼンの道具として扱う場合、故意に仕掛かんばんの枚数を減らすことで、仕掛かんばんとセットになっている仕掛品を減らす方法がある。
この手法の意図は、在庫を意図的に減らすことで、ボトルネックを故意に出現させて、課題を明確にすることだ。

TOCが教える所では、ボトルネックの生産能力が全体プロセスのスループットを決めるので、ボトルネックの工程が中断しないように稼働率を維持するようにすれば、他のプロセスは特に気にしなくてよい。
逆に言えば、在庫を減らしてもボトルネックも課題も出なければ、無駄な在庫が多すぎたという話になる。
「工場内に流通するかんばんの量を制限することで在庫を減らし、作業負荷を下げる」と書いた話はその意味になる。

今回の本では、WIPが仕掛り作業(仕掛品)を意味していて、11.1節「WIPの制限を活用する」という所で同様の手法が書かれている。
ヘンリックも、WIPの数をコントロールすることで、機能をたくさん開発し過ぎてテストに作業負荷がかかり過ぎないようにしたり、チームの稼働率を100%にし過ぎないようにすることに注力しているように思える。

実際、機能をたくさん開発しても、テストチームがテストできる機能の量よりも多ければ、テスト待ちの機能が発生し、そこでテスト待ち時間が発生する。
開発できてテスト待ちと言う仕掛かり中の機能をたくさん作ることは、無駄な在庫をたくさん作っているのと同義なのだ。

ヘンリックの意見が興味深い点は、機能(フィーチャ)はWIPで制限するが、バグや技術課題はWIPの制限対象でないことだ。
11.2節「なぜ機能開発だけWIP制限するのか」に記載のように、バグは緊急かつ重大な場合があるのでやむを得ずに優先する場合がある。
技術課題は、それを解決すると、後続のプロセスのボトルネックが解消するために、技術課題のWIPは制限しない。
解決によって別のプロセスへボトルネックが移動するからだ。

実際、UIの障害を一通り解消した後、性能要件の障害がクローズアップされてくるなどの場合もあるだろう。
つまり、障害や作業の優先度によって、プロジェクトのボトルネックはどんどん変わる。

では、機能のWIPが満杯の時、暇になった開発者は、どうすべきか?
ヘンリックが言うように、TOCが教える内容と同様に、ボトルネックになったプロセスの作業を手伝ったり、技術課題の解決に従事したりして、チーム全体でボトルネックの作業に注力するのだ。
この場面で、アジャイル開発の信念である「人重視」「チーム重視」が有効に活きるのだろう。

【4】在庫管理の業務では、倉庫に残った製品や仕掛品の数量だけでなく、リードタイムの計算がとても重要だ。
ある工程の生産性がいくら高くても、必要な部品や機材が揃っていなければ、後工程に必要な部品を納期までに揃えることができない。
作業前に、必要な部品や機材を発注して納品してもらうことも必要だからだ。
リードタイムは普通、作業時間だけでなく、発注や納品にかかる期間(リードタイム)や検査・運搬そして作業待ちの時間も含まれる。
リードタイムを計算することで、スケジュール管理がやりやすくなるだけでなく、顧客に的確に納期回答できる利点がある。

小売業や生産管理の業務システム開発に携わった経験がある人なら知っていると思うが、リードタイムの計算ロジックはとても難しいし、業務の中で最も重要な機能の一つだ。

例えば、餃子の王将のように、原材料が食材で発注する場合、食材は倉庫で保持できる期間がとても短いため、納品したらすぐに餃子を作って全て売り払わないと、せっかく仕入れた食材が腐ってしまって無駄になる。
シャンプーやペンのような商品とは違って、普通の生鮮食料品は1週間も持たないからだ。

だから、販売日にこれだけ売れると見込み生産の計画を立てて、食材の発注リードタイムや作業時間、検査時間などを計算することで、玉ねぎや肉などの食材がいつどれだけ必要かを予測する。
王将の店の休業日に食材が納品されても困るし、調理場に溢れんばかりの食材が届いても困るので、食材の発注リードタイム計算は結構シビアだ。

12.3節「サイクルタイム(1機能にかかった開発時間)」に出てくるサイクルタイムは、1機能にかかった作業時間のことだが、リードタイムと同義だと思う。
例えば、ある機能を開発するには、別チームが作ったライブラリが必要だったり、特殊なテスト環境が必要だったりする理由で準備時間がサイクルタイム(リードタイム)に含まれるだろう。
あるいは、テストデータのパターンが多いために、回帰テストの時間を別途増やすなど、検査の時間もサイクルタイムに含まれる場合があるだろう。
サイクルタイムには純粋な作業時間だけではない場合もあると思う。

ヘンリックの意見で興味深いのは、サイクルタイムを減らすには、WIPを制限することだ。
機能のWIPが大きいほど、サイクルタイムに準備時間や作業待ちの時間が多く含まれて、実際の作業時間は少ない場合があるからだ。
だから、一つの機能の開発に集中できるように、WIPを制限してマルチタスクを避けて、他チームが作るライブラリの完成までの待ち時間を避けるように運用するのだと思う。
つまり、全てのリソースを一つの機能の開発またはボトルネックの作業に注力できる環境をWIP制限で実現しているのだ。

サイクルタイムの計測に意味がある理由は、おそらくソフトウェア開発の現場は製造業とは違って、開発環境の準備やライブラリの準備などの作業待ちが多く、仕様漏れによる手戻り修正などが多発しているために、価値あるソフトウェアを作っている作業時間が極端に短い事実を示しているのだろう。

だから、「リーン開発の本質」でメアリーが提唱するバリューストリームマップは、サイクルタイムが何故長いのか、を分析する道具の一つとして使われているのだろうと推測する。
バリューストリームマップは、ある作業の処理時間が作業中の時間か作業待ちの時間かを判別するマップだ。
バリューストリームマップを使うと、作業中は価値を作成している時間帯として意味があるが、作業待ちの時間は何も価値を作り出していないので無駄であり、排除すべきだと言うことが分かる。

そして、ソフトウェア開発では特に、作業待ちの時間が多すぎるというのが最大の特徴だろう。
実際、たくさん機能を作ったのにテストチームの作業が手一杯でテスト待ちの機能が大量に発生したり、せっかく設計書を作ったのにレビューアが手一杯でレビュー待ちの設計書が大量に発生して手戻りが後で大量に発生する場面などがあげられるだろう。
いかにテスト待ち、レビュー待ち、開発待ちなどのような、無駄な作業待ち時間を減らすか、がソフトウェア開発では特に重要になってくる。

サイクルタイムの概念が重要なのは、作業待ち時間を減らすことで、サイクルタイム(リードタイム)が短くなり、頻繁にリリースできる仕組みがそろうからだ。
サイクルタイムは、リリース頻度と大きく直結する。
頻繁にリリースできる開発プロセスになれば、安定してアジャイルに開発できるようになる。

次回は、サイクルタイムの計算方法と待ち行列理論の関係について考えてみたい。

| | コメント (0)

2013/10/26

「リーン開発の現場」はアジャイルサムライの再来となるか

ヘンリック著「リーン開発の現場 カンバンによる大規模プロジェクトの運営」の翻訳がついに出版されました。
藤原さん、市谷さん、お疲れ様でした。

ざっくり読み直した感想をラフなメモ書き。
ネタバレを含んでいるので、読んでない人は注意。

【1】内容はとても読みやすいです。
スウェーデンの公共システムという大規模プロジェクトに対し、アジャイル開発を適用した事例のお話。
カンバンを使って、アジャイル開発を補強している。
内容がとても実践的なので、何となくアジャイルサムライの本を予感させる。

リーン開発の現場」のカンバンは、XPやスクラムで出てくるタスクボードとは違う。
リーン開発の現場」のカンバンは、機能ボード、フィーチャかんばんだ。
(但し、タスクボードに相当するタスクかんばんも出てくる)

つまり、開発者の作業(タスクカード)を管理するタスクボードではなく、ユーザ観点で機能(ストーリーカード)を進捗管理するカンバンがこの本の主役であり、カンバンをいかに効果的に使うべきか、カンバンを使うと以前とはどのように違う効果が出てくるのか、が主題テーマだ。
だから、プログラマの観点よりも、発注者のユーザやプロジェクトリーダーの立場で見た方が分かりやすいと思う。

Twitter / akipii: 「リーン開発の現場 カンバンによる大規模プロジェクトの運営」の日本語版解説(@hiranabeさん)がとても分かりやすい。どの本でも平鍋さんの解説を読むと本の内容を読まなくてもエッセンスがすぐにつかめるのがすごい。 http://www.amazon.co.jp/dp/427406932X

【2】ヘンリックが運用しているカンバンは、XPやスクラムが定義するタスクボードよりも複雑だ。
タスクボードは、ToDo→Doing→Doneの3つしかステータスがない。
ヘンリックが運用しているカンバンでは、少なくとも下記のフェーズ(ステータス)がある。

・アイデア
・機能
・開発準備OK
・次の10機能
・開発中
・システムテスト準備OK
・システムテスト中
・受入テスト準備OK
・受入テスト中
・本番リリース前
・本番リリース完了

見ての通り、フェーズが多く、その仕組みがウォーターフォールプロセスのように見えてしまうかもしれない。
しかし、ウォーターフォールプロセスとは大きく違う。

WF型プロセスでは、前工程の作業が全て完了して初めて後工程の作業が始まる。
しかし、カンバンシステムでは、各フェーズは並行して動く。
実現したい機能はアイデアとして生まれ、開発できる単位まで分割されて詳細化されると、機能単位で開発されていく。
開発着手の前に、すべての機能が出そろう必要はない。
機能(フィーチャ)単位に、カンバン上をフローとして流れていく。

ヘンリックが運用しているカンバンは、アイデアで生まれた機能が仕様化され開発され、システムテストや受入テストを経て、リリースされて実現されるので、Push型だ。
本来のかんばんは、マーケットが必要とされる製品に必要な部品が前工程にPullされることで各工程に波及していくので、その違いはある。

第4章プロジェクトボードにその理由が詳しく書かれている。
更に、ヘンリックが運用しているカンバンは、下記のような彼独自の特徴がある。
この辺りも「リーン開発の現場」に詳しく書かれている。

・アナリスト、テスターを機能開発チームに所属するものの、彼らだけの仮想的なチームをなしていること。
・デイリースタンドアップミーティングを3階層で分けて、プロジェクト内の風通しを良くすること
・プロジェクト全体とチームのタスク管理の観点を、プロジェクトかんばんとチームかんばんで使い分けること
・WIPをうまく使うことで、タスクが溢れることがないように調整していること
・技術課題やバグは別のかんばんで試すこともできる(カンバンのスケールアップにもつながる)

【3】カンバンで最も重要な概念がある。
それはWIP(Work In Progress)、つまり、仕掛り中の作業、仕掛中の機能だ。

「第11章 WIPをマネジメントする」「第12章 プロセスメトリクスを計測し活用せよ」は内容が濃くて面白い。
生産管理では、かんばんの枚数を減らして在庫を減らすことで問題を具現化させて、改善していく手法を取ると聞くが、WIPも似たような考え方があると思える。
リトルの法則や「最も小さくて小さ過ぎない」ようにWIPを設定するの説明は、この本で最も興味深い内容の一つだ。

WIPが重要な理由は、稼働率が高すぎても低すぎても生産性が上がるどころか、むしろ下がってしまうため、生産性が最も高くなる時点の稼働率にするのにWIPの概念が使われるからだと思う。
実際、稼働率100%のプロジェクトは、チーム全員が毎日残業して休日出勤も強いられているために、たくさんの障害が頻発し、レビューもテストもろくに行われておらず、品質がボロボロだろう。
逆に、稼働率が低すぎるプロジェクトは、暇な開発者が多すぎて、肝心の成果物が全く作られておらず、進捗が遅延しているだろう。

つまり、「最も小さくて小さ過ぎない」ようにWIPを設定する。
第12章プロセスメトリクスでは、「WIP制限を必要最低限に保つ」という文章で記載されている。
(個人的には、「必要最低限」という言葉よりも「最も小さくて小さ過ぎない」の方が好きだ。)

ヘンリックは、カンバン上のフローをスムーズに流すために、WIPを制限することで、サイクルタイム(リードタイム)を短くすることで、機能をリリースする期間を短くしている。
つまり、頻繁にリリースできるような仕組みを作るために、WIP制限を有効に使っているのだ。

Twitter / akipii: 「リーン開発の現場」の最重要キーワードはWIP。WIPは着手中の未完成の機能や作業。WIPは稼働率を意味すると思う。待ち行列理論から類推するとWIPは大きすぎると皆忙しすぎて作業待ち時間が増えて生産性が減る。逆にWIPが低すぎると皆暇すぎて生産性が減る。ほどほどのWIPが重要。

ヘンリックは、カンバンを高速道路の交通量に例えている。
車の流れをスムーズにしたいと思うならば、高速道路に車をぎっしり詰めるべきではない。
高速道路で渋滞が発生するのは、本来の交通量を超えた車が道路に溢れているから。
だから、交通量の変化を吸収して、流れを速くするには、スペースやゆとり(Slack)が必要。

Twitter / akipii: 「リーン開発の現場」を読むとカンバン中心のプロジェクト管理の本質には、リトルの法則または待ち行列理論が背後にあるのが分かる。カンバンを高速道路の交通量にたとえて、タスクの消化を早めるには、交通量(WIP)を制限してスペースを作ることと同じと言っている。この比喩は本質的だと思う

また、WIP制限(仕掛中の機能・作業の上限値)が必要な理由をプリンタにも例えている。
プリンタは一度に1枚しか印刷できないので、WIP制限は1になる。
もし紙が詰まれば、警告を出して、速く修理すべきだ。
逆に、より多くのページを印刷しようとプリンタのキューに貯めこむのは、プリンタ故障の問題をより大きくさせるだけ。
WIP制限によって、プリンタが処理できる本来の能力を実現しているわけだ。

Twitter / akipii: リーンの言葉で言えば、XPやスクラムはタイムボックスという期間で在庫を制御する。カンバンは仕掛り作業(WIP)を直接制限することで在庫を制御する。「リーン開発の現場」の@hiranabeさんの解説より http://www.amazon.co.jp/dp/427406932X

【4】レビューにも参加させて頂いて、今読み直してみて、まだまだ奥が深いと感じる。
そして、まだ僕がカンバンを経験していないために理解できていない問題は2つある。

一つは、ヘンリックが運用しているカンバンは、日本のトヨタが生み出したかんばんとどの部分が似ていて、どの部分が異なっているのか?
いわゆるソフトウェアかんばんが、製造業のかんばんとは異なる本質的な特徴や性質は何か?
欧米人が「かんばん」を彼らなりにどのように理解してソフトウェア開発へ適用したのか、を明確にしたい。

もう一つは、生産性や稼働率が待ち行列理論からどのように分析されて説明できるか?
カンバンがソフトウェア開発の進捗管理でとても有効な理由は、生産性や稼働率の見える化が強力であるからだと思う。
カンバンを使うと、WIP制限によって、稼働率を調整することでリリースサイクル(サイクルタイム、リードタイム)を短くでき、それによって、頻繁なリリースを安定して実現できる。
その仕組みの背後には、待ち行列理論が関係していると直感しているので、その構造を明らかにしたい。

上記の問題意識で、更に読んでみたいと思う。

| | コメント (0)

2013/10/12

ソフトウェアは資産なのか負債なのか

ソフトウェアは資産なのか負債なのか、についてラフなメモ書き。

【元ネタ】
Life is beautiful: ソフトウェアの資産計上に関する素朴な疑問

ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!

ワンポイント経理実務情報

No.5461 ソフトウエアの取得価額と耐用年数|法人税|国税庁

ソフトウェアの減価償却-ソフトウェアに関する会計と税務について

ソフトウェアは会計上は無形資産として計上される場合が多い。
でも、現実の感覚は、ソフトウェアは負債だと思う。
特に、業務システムは、導入当初は負債であり、運用していきながら、その価値を回収していると考えた方がいいと思う。

ユーザ企業が業務システムを新規開発しようと思い立った時、普通は、投資対効果(ROI)の計算から始める。
現状は手作業でやっている業務が、どれだけの人件費や消耗品費などでどれだけ費用がかかっているか?
その業務をシステム化した場合、業務にかかる時間や人件費がどれだけ削減されて、どれだけ価値が出るのか?
すると、システムを導入すると、何年使えば元が取れるようになるのか?

例えば、業務系Webシステムの機能改善の場合、現在は一つの仕入伝票を入力するのに5分かかっていたとしよう。
ユーザインターフェイスや機能改善で、入力時間が2分に短縮できるとしよう。
すると、一人1枚の仕入れ伝票の入力に3分が短縮される。
その3分を時給計算して、1日または1ヶ月の仕入れ伝票の平均枚数やオペレータの人数を計算し、時間短縮による費用を算出すれば、その金額だけコスト削減になる。
そして、機能改善の投資額と時間短縮の費用を比較し、どれだけの期間で元が取れるようになるのかを計算すれば、投資対効果が計算できる。

ユーザ企業のいわゆる情報システム部門や経営企画部門は、システム開発案件を発注する場合、このような投資対効果を計算して、経営者へ説明する時が多いようだ。
つまり、発注したシステムがどれだけ価値があるのか、を経営者に説明しているのだ。

すると、開発の期間が1年以上のように長くなるほど、投資対効果が薄いことになる。
これだけ技術革新の期間が短くなっているのに、元が取れるのに数年単位という時間はあまりにも長すぎる、と最近の経営者は思っているのではないだろうか?

業務システムを導入するのには、数百万~数億円の投資額が少なくともかかる。
せっかく作り上げたとしても、本番リリース直後は、実際に運用してみて、障害や改善要望が色々判明し、それらを反映してやっと使い物になる。
つまり、システム開発案件を発注し、数ヶ月~1年かかって作ってもらい、更に数ヶ月かけて導入して、初めて使い物になる。
すなわち、最初に支払った投資額を回収するには、かなりの時間がかかる。

しかも、システムの寿命よりもハードウェアの寿命が最近はすごく短くなっているので、3年経つとすぐにサーバーリプレース案件を実施しなければならない。
システムがやっと運用にのってきたのに、安定しているシステムに手を加えないといけない場合が非常に多い。
システムは使用期間がながくなるほど、保守費用もリプレース費用もかかってくるのだ。

そんなことを考えると、ソフトウェア、特に業務システムは、資産と言うよりも負債と捉えた方が現実に合っているような気がする。
それは、個人が購入した住宅や車に似ている。
住宅や車は資産かもしれないが、その実態は借金(負債)で購入したものだ。
個人の年収(売上)の身の丈に合わないモノを買ったならば、じきに負債の利息の支払いで破産してしまう。

ソフトウェアも同様に、資産と思って買い物をしたはずなのに、実際は多額の借金をかけて作ったものであり、実際に使って元を取らなければ、単なるガラクタだ。
しかも、ソフトウェアの保守費用も毎年かかるわけだから、使われていないソフトウェアは費用を垂れ流していることになる。

そんな現実が明確になってきたからこそ、アジャイル開発のように、ソフトウェアを定期的に価値あるものとして証明できる開発スタイルが必要になってきたのだろうと思う。

| | コメント (2)

2013/10/06

業務システム開発の難しさ

業務システム開発の難しさについて考えたことをメモ書き。

【1】システム開発の対象は、業務システム以外にも、Webもあれば、最近ならスマフォやタブレットなどもある。
Webやスマフォ、タブレットは、リリースやデプロイ作業が自動化できるれべるになっていれば、アジャイルに開発しやすい。
リリースサイクルを短くできるならば、顧客を要件定義に深く巻き込むことで、オンサイト顧客に近い立場で開発しやすい。

しかし、業務システム開発は、機能が膨大なシステムになりやすく、全体像を見えるようにするのが難しい。
でも、それ以外にも、アーキテクチャの観点と体制の観点で、Webやスマートフォンの開発よりも難しい点が多いと思う。

【2】業務システムのアーキテクチャの観点では、いつも下記の4つにいつも苦しんでいる。

(2-1)ERPの導入方法(一括移行、段階移行、パイロット導入)
(2-2)ERPのリプレース(リライト、ラッピング、リホスト、リエンジニアリング)
(2-3)システム間連携 or 外部接続(リアル連携、メッセージキューイング、バッチ処理、EAIなど)
(2-4)データ移行(マスタ、トランザクションのデータ変換)

一つのシステムを作りこむだけでも大変なのに、複数の部門へシステムを導入して運用に載せたり、複数のシステムとデータ連携したりする作業がどうしても発生する。

外部接続やデータ移行は、その技術レベルはさほど難しくないし、事例も数十年以上前からあるのに、いつもトラブルが発生する。
設計の詰めが甘かったり、性能要件の考慮が漏れていたりしたために、動かしてみて初めて障害に気づく時が多い。
リプレース作業も、ハードウェアを交換するだけで、プログラムはそのままでいいはずなのに、ApacheやDBなどのミドルウェアのVerUpによって、プログラムのリコンパイルが発生したり、リライトが発生したりする。
更には、回帰テストしてみると、バグがどんどん出てくる時もある。

複数の部門に導入する場合、現場の責任者や担当者に説明会を開き、納得させて、実際に運用してもらわないといけない。
すると、彼らから信頼を得るために、色々と交渉したり折衝する必要が出てくる。
しかし、ベンダーとユーザ企業の間で役割が曖昧な場合、この辺りのやり取りがうまくいかない時がある。

多分、体制が不十分なために、ベンダー担当者も現場担当者も当事者意識が薄くなり、本気で業務システムを運用しようという雰囲気にならないのだろう。

【3】業務システムの上記4つの問題点に対する解決方法は、僕はまだ知らない。
古くから知られている技術であるにも関わらず、今もなお、問題解決はコンテキスト依存が多すぎて、この手法が良いというレベルまで落としきれていない。
でも、それぞれの技術の詳細をリストアップしてみると、利点と弱点は明確になっているので、1つずつ潰していくしかないのだろうと思っている。

また、体制面の問題は、ベンダーの上司(プロジェクトオーナー)やユーザ企業のオーナー(プロダクトオーナー)を巻き込んで、いかに彼らに動いてもらうようにするかが大切なのだろうと直感している。
現場リーダーがいくら頑張っても、ユーザ企業の担当者がこちらが準備したシナリオに納得して動いてくれないと、ゴールに導けない。

そのためには、現場リーダーには、プロジェクトオーナーやプロダクトオーナーというパトロンが必要なのだと思う。
彼らがバックにいて、現場リーダーを支援してくれるからこそ、プロジェクトは前進するし、現場担当者も当事者意識を持って本気を出して当たってくれる。

そんな事を考えると、スクラムというフレームワークはうまくできていると思う。
プロジェクトの体制を一から作らずとも、スクラムのフレームワークを適用すれば、ベンダーやユーザ企業の担当者に役割がアサインされ、有機的に動く仕組みが整う。
そんなフレームワークが適用されていなければ、現場リーダーが自ら体制を作り、提案して、根回ししないといけない。

【4】システム開発は技術だけでは解決できない部分が多い。
その部分はアーキテクチャだったり、体制だったり、開発プロセスだったり、色々ある。
その部分をもっと明確にまとめてみたい。

| | コメント (0)

2013/10/05

Redmineの外部接続、データ移行の機能

Redmineは調べるほど、とても奥深く面白い。
Redmineを一つの業務システムと見なした時、特にRedmineの外部接続、データ移行の機能について考えたことをメモ書き。

【元ネタ】
Redmine: 期限が間近のチケットをメールで通知する機能 (Windows環境): Computer Practice

【1】業務システムには、普通のフロントエンドのWebシステムとは違った特徴がある。
特に、外部接続とデータ移行に特徴があると思う。

外部接続とは、外部のシステムと自システムを連携する仕組み。
よくある例は、夜間バッチとか、SOAPやRESTなどのリアル連携。

データ移行とは、業務システムに他システムのマスタデータやトランザクションデータを加工して移行する方法。
よくある例は、システムのリプレース時に、旧システムから新システムへデータ移行する時がある。

いずれも、業務システムとして機能させるには、外部からデータを取得して入れることが大切。
しかし、外部接続にせよ、データ移行にせよ、システムアーキテクチャとしてはかなり枯れた技術なのに、テストが大変なのでいつもトラブルが起きやすい。
外部接続やデータ移行の仕組みが揃っている業務システムは、数多くのデータを取り込んで一元管理できるので、色んな使い道を探ることができる。

技術的には、外部接続やデータ移行の問題点や解決方法は古くから知られている。
これらの観点でRedmineを分析してみよう。

【2】Redmineを外部接続やデータ移行の観点から分析すると、どんなインターフェイスを持っているのか?
Redmineには、rakeコマンドでバッチ処理のように一括処理する仕組みが下記のようにある。
ここから色々分析してみる。

rake -T | find "redmine"

rake redmine:attachments:prune # Removes uploaded files left unattached after one day.
rake redmine:email:read # Read an email from standard input.
rake redmine:email:receive_imap # Read emails from an IMAP server.
rake redmine:email:receive_pop3 # Read emails from an POP3 server.
rake redmine:email:test[login] # Send a test email to the user with the provided login name
rake redmine:fetch_changesets # Fetch changesets from the repositories
rake redmine:load_default_data # Load Redmine default configuration data.
rake redmine:migrate_from_mantis # Mantis migration script
rake redmine:migrate_from_trac # Trac migration script
rake redmine:permissions # List all permissions and the actions registered with them
rake redmine:plugins # Migrates and copies plugins assets.
rake redmine:plugins:assets # Copies plugins assets into the public directory.
rake redmine:plugins:migrate # Migrates installed plugins.
rake redmine:plugins:test # Runs the plugins tests.
rake redmine:plugins:test:functionals # Run tests for functionalsdb:test:prepare
rake redmine:plugins:test:integration # Run tests for integrationdb:test:prepare
rake redmine:plugins:test:units # Run tests for unitsdb:test:prepare
rake redmine:send_reminders # Send reminders about issues due in the next days.
rake redmine:tokens:prune # Removes expired tokens.
rake redmine:watchers:prune # Removes watchers from what they can no longer view.

【3】外部接続の観点

【3-1】他のWebシステムからRedmineのチケット情報を取得したい場合、REST APIで取得するのが一番簡単だ。
つまり、HTTPで接続するだけでXMLやJSONのデータを取得することができる。
あるいは、データをPOSTするだけでチケットを更新したり登録することができる。

リアル連携の良い点は、マッシュアップのように、データを簡単に取得して色んなWebサービスをカスタマイズしやすいこと。
リアル連携の弱点は、リアルタイムにデータ連携する前提のシステムでは、障害の影響が大きいこと。

この辺りは以前たくさん書いた。

Rest api - Redmine

RedmineのREST APIは素晴らしい~ビッグデータの手法をRedmineにも活用する: プログラマの思索

【3-2】Redmineの外部接続機能で面白いのは、メールの送受信によるインターフェイスを持っている点だ。
具体的には、メール送信によるチケット自動更新や期日が間近のチケットを通知する機能を持つ。
Redmineには、メールによるチケット登録インターフェイスには、下記のrakeコマンドが用意されている。

rake redmine:email:read # Read an email from standard input.
rake redmine:email:receive_imap # Read emails from an IMAP server.
rake redmine:email:receive_pop3 # Read emails from an POP3 server.

Redmineにおけるメールによるチケット登録機能は、調べてみるととてもよくできている。
管理画面上のユーザ権限とは別に、メールによるチケット登録インターフェイスでも、チケットの属性を指定できたり、チケット更新の権限を制御できる機能を持っている点がすごい。

メールを通知する機能は普通の業務システムでは普通に付属している。
例えば、サーバー監視ツールやログ監視ツールから障害検知メールを流したり、CRMからイベントやキャンペーンを一括メール送信したりする。
だから、これらの機能と連携すれば、例えば、Jenkinsのビルドエラー通知メールから障害チケットを起票したり、顧客からの問合せメールを起点にチケット登録することもできる。

この辺りは以前たくさん書いた。

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

期日が間近のチケット通知インターフェイスは下記になる。

rake redmine:send_reminders # Send reminders about issues due in the next days.

期日が間近のRedmineチケットをメールで通知する: プログラマの思索

期日が間近のチケット通知インターフェイスは、個人的にはもう少し機能改善して欲しい。
現場リーダーの観点では、各プロジェクト独自の観点でチケットをフィルタリングして、メンバーに毎朝自動通知するようにしたいものだ。
機能改善の方法としては、例えば、RedmineのクエリIDを指定して、そのチケット集計結果をメールのBody部へ記載して通知することも考えられる。
RESTを使えば、Redmineの特定のクエリの結果は取得できるので、シェルスクリプトを自作してCronで通知する実装でもいい。

【4】データ移行の観点

【4-1】Redmineの機能の中で、SCMリポジトリと連携する機能は核となる機能だ。
従来から、Redmineでは、「リポジトリ」画面を開くまではリポジトリへの最新のコミット情報が取り込まれまない問題があった。
最もお手軽な解決手法は、SVNなどのSCMツールのpost-commit-hook時に、HTTP接続でリポジトリ情報取得へアクセスして更新する手法だろう。
実際は、Redmine管理画面からAPIキーを取得し、post-commit-hookスクリプトに、APIをパラメータで渡すURIを実行する手法になる。

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

しかし、Subversionのリポジトリ画面の表示がとても遅くなる別の問題もあったりする。
その原因は、SVNリポジトリが大きすぎたり、更新頻度が多いために、RedmineがHTTP接続でSVN表示する処理に負荷がかかりすぎる点にある。
解決方法としては、リポジトリ情報をRedmineへ更新するrakeコマンドをCronないし移行作業で実施する手法がある。

「リポジトリ」を開くまでSubversion等のリポジトリへのコミットが「活動」に表示されません ? Redmine.JP

rakeコマンドは下記になる。

rake redmine:fetch_changesets # Fetch changesets from the repositories

@daipresentsさんの資料にも、RedmineとSVNの接続処理の問題に対しては、SVNの参照リポジトリと更新リポジトリを分けて、Redmineからは参照用SVNリポジトリにアクセスするようにし、更新用SVNリポジトリへ開発者がコミットし、参照用SVNリポジトリと更新用SVNリポジトリはsvnsyncなどで同期する方法が書かれている。

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine: プログラマの思索

【4-2】Redmineで興味深い点は、TracやMantisからRedmineへ移行するデータ移行ツールが付属している点だ。
データ移行ツールが必要な背景としては、他ツールで使っていたマスタやチケットデータを捨てずに移行して使いたい場合があるだろう。

下記のrakeコマンドが用意されている。

rake redmine:migrate_from_mantis # Mantis migration script
rake redmine:migrate_from_trac # Trac migration script

他システムからの移行 ? Redmine Guide 日本語訳

他にもbugzillaからも移行が可能なようだ。

ralli/migrate_from_bugzilla

データ移行ツールはMantisやTracのバージョンに依存するだろうから、そのまま使えるかどうか、事前検証が必要だろうが、上記のインターフェイスを利用すれば、移行コストを下げられるだろう。
あるいは、データ移行ツールとして、上記のrakeコマンドではなく、importerプラグインを使う手法を取ることもできるだろう。

【5】このように、Redmineを業務システムとして分析した場合、オープンソースであるにも関わらず、外部接続やデータ移行のインターフェイスを持っている点は、とても素晴らしい。
外部接続、データ移行のインターフェイスがあれば、外部システムとデータ連携しやすくなるので、既存のRedmineを価値あるシステムとして長持ちさせることができる。

例えば、Redmineをフロント側のWebシステムとして、開発者やプロジェクトの情報を日々蓄積する目的で使っておき、バックエンドの業務システムへRedmineのトランザクションデータを流し込む運用も考えられるだろう。
あるいは、MantisやTracからRedmineでデータ移行することでプロジェクト管理ツールを一元化したり、SCMリポジトリの情報を日々連携することで、Redmineの価値を更に高めることもできるだろう。

今後もRedmineの機能を追いかけていく。

| | コメント (0)

« 2013年9月 | トップページ | 2013年11月 »