プログラマの思索

最近、アプリケーション・ライフサイクル・マネジメント(ALM)という言葉を聞くようになった。
僕の理解では、ALMはSW開発のERPと同義だ。
考えたことをメモ。

【元ネタ】
アプリケーション・ライフサイクル・マネジメント - Wikipedia

IT Pro のための ALM 入門 | Tech Fielders コラム

IBMが推進する“分散型開発でのALMソリューション” － TechTargetジャパン プロジェクト管理

MSのTestManagerはTestLinkと全く同じ！: プログラマの思索

アジャイル開発はツールに依存している～SW構成管理を再考しよう: プログラマの思索

Kent Beck VSTSのホワイトペーパーの日本語訳

【1】アプリケーション・ライフサイクル・マネジメント - Wikipediaによれば、ALMとは、システムをツールでで継続保守するための全体的な管理を指す。
そもそもソフトウェアには納品という概念はない。
何故なら、納品後はシステムは稼働中となり、ユーザが日々運用していく。
つまり、システム開発には、運用中か開発中、未着手という三つのステータスしか無い。

その話を考えると、@kuranukiさんが言われている「Point of Sales」から「Point of Use」へ」の話を連想させる。
ソフトウェアは製造業と違い、納品したら常時稼働し始めて、運用保守しながらバックエンドでは次の新機能開発に従事する並行開発が普通なのだ。
だから、製造業よりもはるかに難しい場面が多いのだろう。

ALMはそのような状況を背景として、ソフトウェアを継続的に開発していくための開発インフラを提供する。
IBMのRational製品、MSのTFSが具体的に実現された製品群になるだろうと思う。

【2】しかし、ALMの弱点はアプリケーション・ライフサイクル・マネジメント - Wikipediaに書かれている通り、製品を提供するベンダーにロックインされてしまうこと、ソフトウェアの保守コストが大きくなることがあるだろう。

多分、普通はバージョン管理を入れて、障害管理にBTSを導入して少しずつ開発インフラを整えていく。
だが、スケジュール管理やコスト管理、テスト管理などソフトウェア開発全般をツールでカバーしようとすると、MSやIBMのような製品を使わざるを得なくなる。
すると、開発ツールがベンダーにロックインされてしまい、その後の開発や運用保守にも影響を受ける。
ベンダー製品が技術進化に遅れる危険もあるし、製品のライセンス費用もバカにならない。

【3】そんなことを考えると、ALMという概念とセットに売り出された製品はソフトウェア開発のERPと同じように思える。
ソフトウェア開発に必要な開発インフラを提供するだけでなく、コスト管理や内部統制などの機能まで付けている。
盛りだくさんの機能があるほど、管理者も開発者もどこまで使いこなせばいいのか分からない。

開発ツールを導入すると、副作用がある。
丁度、顧客がERPパッケージを導入すると従来の業務フローが変わるだけでなく、組織体制も変わってしまうのに似ている。
それについては以前下記で書いた。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ALMを提唱する製品を開発チームが使う場合、まずFG分析で、自分たちのチームにどこまで製品(ツール)の機能を新しく取り入れて、従来の運用は崩さないようにするか、見極める必要があるだろう。
そうしなければ、ツールを使いこなすだけで精一杯で、肝心の開発に役立たない。
そして、実際にツールを使いこなしていきながら、測定して評価する改善プロセスを実施する必要がある。
そうしなければ、高いライセンス費用を払ってでもツールを買って使いこなせているか、評価できないからだ。

つまり、ALMを提唱する製品はプロセスを含んでいて、それは従来の開発スタイルを大きく変える副作用がある。
事前調査してから使いこなさなければ、本来の威力を発揮できない可能性の方が高い。

ERPの導入事例は90年代から歴史があり、成功事例よりも失敗事例の方がはるかに多いように思う。
だから、ソフトウェア開発にERPのような大げさなものを導入して、逆に生産性を落とす危険性があると考えている人は多いだろうと思う。

【4】チケット駆動開発は本来Tracのチケット管理をSW開発のタスク管理に適用する発想から生まれた。
開発現場で試行錯誤しながら生まれた開発スタイルであり、ALMのような高尚な概念までたどり着いていない。

しかし、チケット駆動開発を実現するRedmineやTrac、GitやMercurial、HudsonやJenkinsと言ったツールを組合せると、最終的にはソフトウェア開発のERPのような仕組みに似てくる。
ツールによって、作業を見える化するだけでなく、コミュニケーションを活発化させて、開発チームの透明性を上げていく方向へ進化している。
ケント・ベックは「Kent Beck VSTSのホワイトペーパーの日本語訳」において、アジャイル開発にはそのようなツールが必要と述べている。

だが、その危険性についてもたくさんの人が感じ始めている。
@yusuke_kokuboさんや@daipresentsさんの主張を読むと、一度ツールにのめり込んだ後、ツールから離れた開発スタイルを追いかけているように見える。

Twitter / @yusuke_kokubo: @yusukey 一応補足しておきますけど、Redmineを独自カスタマイズしてるのは業務にあわせてゴリゴリしてるだけで、決して使うこと自体を目的にしてるわけではないですよ。 最近ではRedmineをどれだけ使わないで開発を進められるかが個人的なテーマです。

Redmineが1000人のエンジニアに使われるまでのこと | 世界

ツールに依存しすぎて重たすぎるERPになってしまうと、本来のアジャイル開発とはかけ離れてしまう危険があるからだろう。
今後は、その危険を避けながら、チケット駆動開発がどこまで進化できるのか、という問題が大切になってくるだろう。

【5】これほどERPの失敗事例がありながらも、ERPを導入して成功した事例もある。
羽生さんの本「楽々ERDレッスン 」では、ERPはBPR実現のドライバとして有効であり、 BPRでは統合DBが重要と認識した企業がビジネスプロセスの再編に成功している、と書かれている。
つまり、ERPで成功するには、統合DBという考え方を具現化することでBPRが促進されることを理解するのが重要ということ。

これは、統合DBで情報が一元化されることによって、その情報を複数のビューで見たり、多種多様なレポートをいくらでも出力できるようになる恩恵があることを指していると思う。
統合DBという資産を作り、その資産からどのように価値を生み出すのか、という視点が必要なことを示唆しているのだ。

この考え方をALMやチケット駆動開発に当てはめてみると、ERPの統合DBに相当するものは何なのか？
それは、バージョン管理の配下にあるソースや設計書、ビルドスクリプト、DDLなどだ。
更に、ITSチケットやWikiなどの情報も含まれる。
つまり、SCMリポジトリやITSのDBが統合DBに相当するものになる。

チケット駆動開発の発端となった運用ルール「No Ticket, No Commit」はソースの修正理由を必ずチケットの履歴に残す。
成果物の変更履歴をITSチケットに必ず残すという運用のおかげで、変更管理の情報がITSへ集約される。

そして、チケットを作業指示書と見なして、プロジェクト内部の全ての作業履歴をチケットへ集約する。
すなわち、チケット駆動開発における統合DBはSCMリポジトリやITSのチケット・Wikiなどの蓄積された作業履歴や共有情報になる。

チケット駆動開発では、全ての情報がITSを通じて表示できる仕掛けがあるので、ITSのレポート機能を中心にもっと強化すればいろんな価値を生み出すことができる可能性を秘めている。
チケットの粒度と進捗ビューの関係: プログラマの思索にも書いたけれど、Redmineのレポート機能は正直貧弱であり、まだまだ改善できる余地がある。

Redmineに蓄積された情報をどのように保守しながら、価値ある情報を見せていくべきか、という観点でプラグイン開発していけば、もっと進化できる可能性はある。
色々考えてみる。