ALMとDevOpsについて学んだこと

社内勉強会で講師を招いた話なので、具体的な部分はぼかします。

内容は、ALMはツール依りの話だし、DevOpsはクラウドやソーシャル依りのAgilerの話だけど、エンタープライズ系でうまくまわすためにはどうすればいいか、現状を改善するために何を考えるべきか、というもの。
私の立ち位置は、一般企業の情報システム部が自分たちで自社システムの開発ができるよう、環境を整えたり、やり方を議論したりするものです（開発もしてます）。

ALMについて
SDLCが開発のライフサイクルに焦点を当てているなら、ALMはアプリケーションのライフサイクルに焦点を当てています。アプリケーションのライフサイクルは、企画から開発、利用をして、利用されなくなるまでです。利用されなくなるまで、開発は継続的に行われます。

DevOpsについて
ALMと似ているけど異なる視点で、運用と開発は表裏一体であり、運用からのフィードバックも受けて開発は行われ続けるのだから、それを意識したものになっていくというものでした。その目指す先は、Programableな運用作業はすべて開発者が自働化(※)して、人の手でしかできないところにだけを運用担当がする、ということでした。Jenkinsの川口さんの発言に似てますね。
※誤字ではありません

Agile ALMについて
ALMはツールをもとに展開された話ですが、アプリケーションのライフサイクルに当てた考え方は、アジャイルの考え方に近いものがあります。XPで思考の転換や矯正をして、Scrumなどでプロジェクトを運営していきますが、プログラマを含めたステークホルダーがそれらをうまくまわしていくための環境づくりは非常に大きな役割になります。その環境を構成する要素（ツール）には何が必要でどうまわしていくか、という話がAgile ALMです。

これについての最低限の構成は次の図となります。

迷ったら、 ALMinium と Jenkins を用意すれば良いでしょう。ALMiniumはITS/BTSとVCS, JenkinsはBuild Machineに当てはまります。

以下、考察
とりあえずこの構成は最初から作っておくと良いでしょう（ステージング環境と本番環境はあとでも良いですが）。その理由は2つあります。

ひとつは、最初から用意するのと比べ、途中で別のものを導入したりツールを変更することの方が負担が大きいからです。
現在の私の状況では、各要素は用意していたけれど、VCSに集中型を利用したため、Build Machineからのバグ報告やdeliveryがうまく回らない（手動作業が多い）ようになっています。分散型を入れれば即解決するわけではありませんが、最初から入れておけば「こういうものだ」と言えたのに、「どうして変えるべきか」を理解してもらわなければなりません(※)。
※この「うまく回らない」は関与しない人にも説明が必要なのですが、関与しないから「うまく回っている」ように見えてしまうのです。

もうひとつは、いじれる環境があることの利点です。
アジャイルで製品を顧客に早く提供することは、早い段階で問題や要望を挙げやすくする状況をつくることができます。これは、ツールとプロジェクトメンバの関係にも当てはまります。
たとえば、プロジェクトメンバが上長に作業を報告するのに「こんなふうな情報を管理(※)したい」と思ったときに、今までは何か大変な作業をやっていたのが、打ち合わせ時に画面をみながらやっていると、「こういうことはできないか」と事前に言ってくれるようになりました。ITSにRedmineやTracを使ってる場合、設定やプラグインの利用で解決できることが分かったので、不便だと思ったことは言ってもよいということを教えてくれます。
また、Build MachineにJenkinsを使っていれば、製品の品質が悪いなと思ったときにプラグインを入れれば、なんらかの事実がすぐに明らかなになります。原因究明に時間をかけたり、保留、なんて事態に陥ることはありません。
プロジェクトチームがプロジェクトとともに成長して「こういうことができたらもっとうまくまわせるのに」と思ったことを補助するために、思ったときにすぐ試せる環境（ツール）があらかじめ揃えられているのは、思考停止を回避する策になります(☆)。
※他に良い言葉が思いつかなかったので、この言葉を使います
☆プログラマはわりと、揃っていようがいまいが、自分で環境作って検証して提案してきますが、プロジェクトメンバはプログラマだけではないのです

まとめ
自分で「こういうサイクルができると良いよね」って図を書いて、ここはどうしよう、ああしようって考えるといいと思います（まとまってない）。