Compartilhar via

コラム: ライフサイクル管理

  • Artigo

日本でもここ数年特にソフトウェア開発ライフサイクル（SDLC: Software Development Lifecycle）が注目されています。ALM（Application Lifecycle Management）という表現をしたりもしていますが、ソフトウェアエンジニアリングを人材・プロセス・テクノロジーでカバーし、役割を超えチームとしての活動を行っていくための下地・・・という基本に変わりはありません。

日本では特にこれをツールで実現するといったところにフォーカスしがちですが、ツールはあくまで文字通り 『道具』 でしかありません。どんなによい道具であっても使い方を誤れば効果を発揮しませんし、逆によい道具を選ばないと本当に実現したいこと（解決したい悩み）を達成できないかもしれません。

重要なのは、ツールではなく、「何を改善/解決したいのか」、「それがライフサイクル管理で改善/解決できるまたは、そうなるための下地となりえるのか」、「そのために最適なツールややり方はなにか」を組織/プロジェクトで真剣に考えることです。

過去、数十のプロジェクトの提案、コンサルティングをさせていただき、またそれ以上に多くのプロジェクトや組織の方々とディスカッションをさせていただいた私の経験からも、上記は強く訴えたいポイントです。

とはいえ、ツールから学べることも多くあります。ツールでは多くの方々の悩みを解決すべき最大公約数的な機能が実現されています。それらの機能がなぜ実装されたのかを知ることで、自分たちの悩みを解決するためにその機能が意味をなすのかを知ることができます。それにより改善すべきポイントの根っこを抑えることができます。それがその機能で完全にカバーできていることもあるかもしれませんが、おおむね、機能だけではカバーできず、ルールやプロセス、教育といったものが伴います。

ツール選定のポイントですが、まずそのツールのコンセプトを理解するといいでしょう。何をするため、何を解決するためにそのツールがあるのか、そのツールがある存在理由であったり、開発理由といったものを知ることでツールの機能を越えたツールの価値を見出すきっかけにすることができます。
# 残念ながらコンセプトを機能で完全にカバーしているツールばかりではありません。上述のようにツールの機能だけでは補いきれないのも現実（だからこそ、人材とプロセスがより重要といえます）ですし、コンセプトを完全にカバーするための機能がまだそろっていないツールもあります。ただし、あるコンセプトを実現するためのツールであることが明確だとそのツールの将来像も含めて選定の検討を行うことができるようになりますね。

これからは、実験も兼ねて、こういった話題も『コラム』として書いていきたいと思います。すべての投稿に共通ではありますが、当然このコラムも私の投稿時の意見/見解であり、マイクロソフトの正式な意見/見解ではありません。詳しくは こちら を。

ながさわ

Comments