ALM(アプリケーション・ライフサイクル・マネジメント)勉強会

先月になりますが、2/4(金)開催の名古屋アジャイル勉強会のテーマが「ALM(アプリケーション・ライフサイクル・マネジメント)」ということで、ムリヤリ仕事を定時で終わらせて参加しました(;^ω^)(それでも15分ほど遅刻しましたが・・・)
サブタイトルは「ALMとは?開発完了で終わりじゃない、アプリケーションの一生を追え!」
ITシステム開発に携わる人間としては、非常に魅力のあるテーマです。(´∀`*)

DSC_0544.JPG

まず、「ALMとは何か?」ということですが、自分もそういう単語があるのは知っていましたが、内容はほとんど分かっていない状態でした。
ちなみに、Wikipediaでは次のように紹介されています。

**ALM(アプリケーション・ライフサイクル・マネジメント)とは?**
アプリケーション・ライフサイクル・マネジメント(ALM)とは、ソフトウェア開発・保守を各アプリケーションのライフサイクルにわたって継続的にプロセス管理をする考え方である。ALMは、業務管理とソフトウェア開発の融合により、要件管理、設計、実装、検証、バグトラッキング、リリース管理を、ツールを使用してそれらの促進と統一化を実現することである。 -Wikipediaより-

つまり、ソフトウェアを開発してそれで終わりではなく、それを業務で運用することによって得られるフィードバックを受けつつ、継続的に開発・保守のプロセスを管理する考え方を指すようです。
今回の講師は、マイクロソフトのエバンジェリストである長沢さん@tomohnです。
15分遅れて会場入りしたため、最初の部分は聴けませんでしたが、いくつか印象的なお話が拝聴できましたので、簡単に紹介したいと思います。
●ALMにまつわるお話
プロジェクトから得たナレッジを蓄積して最適化・横展開!
成功/失敗に関わらず、プロジェクトが終わると様々な「教訓」が得られます。プロジェクトが終わってヤレヤレ┐(´∀`)┌ ではなく、それを最適化した上で次のプロジェクトに横展開することが重要です。
個人的には、この「最適化」というのが結構重要ではないかと思っています。
というのは、あるプロジェクトで成功したやり方を、背景や前提・制約条件等が異なる別のプロジェクトでそのまま適用しようとすると上手くいかないことが多いからです。
プロジェクトごとにアレンジしやすいようにある程度「最適化」を行うプロセスを経る必要がある、という意味だと私は受け取りました。
また長沢さんもおっしゃっていましたが、「プロジェクトから得たナレッジ」を次に活かせるようにするには、プロジェクトの活動に「透明性」を持たせる必要があります。
人-プロセス-テクノロジーのバランス
ソフトウェア開発とは、顧客企業や市場などからのビジネス・ニーズを、様々なアイデアの詰まったソフトウェアという知的財産として実現することで、ビジネス価値を生み出す活動です。
そこでは、開発に携わる「人」、開発の「プロセス」、そして「テクノロジー」という3要素のバランスが大切だそうです。
3つの要素のうちどれか1つでも足りないソフトウェア開発プロジェクトは上手くいかない、ということですね。
変化に対応
ALMは開発プロセスに依存するものではありませんが、どちらかというと、ウォーターフォール型の開発プロセスよりは、スクラムなどのアジャイル型の方が相性が良いようです。
ウォーターフォールだと、開発の初期段階で仕様を確定してしまうため、時間とともにビジネス・ニーズが変化した場合に対応しきれないという問題があります。ALMの観点で観れば、「時間とともにアプリケーションの価値の増加が鈍る」ということが言えます。
一方、アジャイル型開発(例えばスクラム)は、イテレーションごとに運用面のフィードバックを受けられる「改善のフレームワーク」でもあるため変化に対応しやすく、結果、イテレーションが終わるごとにアプリケーションの価値が上昇することになります。
いずれにしても、「アプリケーションを作って終わり」ではなく、「その価値を継続的に高めていく」ことが、ALMの本質であり目的なのではないかと感じました。
テクノロジーのサポート
「人-プロセス-テクノロジーのバランス」のところでも述べた3要素のうちの「テクノロジー」のお話です。
従来は、例えば「要求分析」「モデリング」「構成管理」「ビルド管理」など、各フェーズで使うツールがバラバラでした。それで何が問題になるかというと、例えば要求とソースコードのトレースが難しくなり、情報を探すのに時間を取られて本来の価値を生み出すための時間が削がれるという弊害が生まれます。
ALMをサポートするツールは、これらの情報を1つの情報HUBで一元管理することができるため、例えばバグ情報とソースコードの修正の関連性が明確になるという大きなメリットを得ることができます。
参考までに、ALMツールが提供している機能を書き出しておきます。(Wikipediaより引用)

  • 要件分析
  • 要件管理
  • 機能管理
  • モデリング
  • 設計
  • プロジェクト管理
  • 変更管理
  • 構成管理
  • ソフトウェア情報管理
  • ビルド管理
  • ソフトウェアテスト
  • リリース管理
  • ソフトウェア開発
  • 課題管理
  • モニタリングとレポーティング
  • ワークフロー

ALMへの移行
長沢さんの講演がひと通り終わった後、ワークショップとして各グループ内でデスカッションを行いました。
ここで、あるグループから「ALMの経験が無い組織において、どうやってALMに移行するのか?」という興味深い問題提起がなされました。
長沢さんによると、「まず現状を把握する。そして設定したゴールとのギャップを認識する」ところからスタートすべきということでした。ここでも「透明性」がキーワードとなります。
「汚いものを隠さずに露わにする」こととで、それを「みんなで綺麗するしようとする」作用が働きます。こうした取り組みは、組織的な文化をも変えると言っても過言ではありません。それを継続するには、背中をプッシュしてくれる何らかの力が必要で、これもその一例と言えるでしょう。
また、今までのやり方に満足するのではなく、常に「もっと良い方法があるんじゃないか?」と考えることが重要だというお話もいただきました。
●最後に
ALMを自組織に導入することを考えると非常にハードルが高いのが現実ですが、長沢さんのお話にあったように、まずは「現状を把握してあるべき姿とのギャップを洗い出す」ことで改善への第一歩を踏み出したいと思います!( ´∀`)b
(終)