ヘルプデスクとは？ ヘルプデスクを効率的に行うツールをご紹介
近年、アジャイル開発の採用率が増加傾向にあります。
ガートナージャパンが2014年に実施した調査によると、ウォーターフォールモデルを採用している日本企業は6割である一方、アジャイルモデルを採用している日本企業は3割に達しています。
1年を超える大規模プロジェクトを実施している企業は依然として多く存在しますが、グローバル競争が激化している昨今、競合他社よりもいち早く新機能をリリースするために開発期間の短縮に注力している企業も少なくありません。
ウォーターフォールモデルでも短期開発は可能ですが、求められている機能をより短期間でデモを実施できる状態まで作りこみ、ユーザのフィードバックを得ながら開発ができるという意味では、短期開発の効率の良さにおいてはアジャイルモデルに軍配が上がると思います。
さて、開発期間の短縮を目指す上で避けられない課題の一つとして、変更･リリース作業の効率化が挙げられます。
アジャイルモデル開発を行うためには、テスト自動化や継続的デプロイなどを通じて製品の品質を担保しながら、いつでもリリースできるような体制を整える必要があります。
しかし、ここで問題が発生します・・・
アジャイルモデルはウォーターフォールモデルと比べて変更･リリースの頻度が非常に高く、その度に必要となる作業が煩雑なものでは、あっという間に工数が膨れ上がってしまいます。
例えば、変更･リリースの際に文書作成やレビューなどがプロセスとして組み込まれている企業では、開発期間の短縮を実現できるのでしょうか？
私は実現できると思います。
ITILでは、変更管理について以下のように定義されています。
標準的な変更･･･手順が事前に承認されている、影響範囲やリスクの軽微な変更。
通常の変更 ･･･RFC(変更要求)が必要な、一般的な変更。
緊急の変更 ･･･バグ対応のためのパッチリリースなど、迅速に対応しなければならない変更。
そもそも、ITIL（アイティル）って何？ということを詳しく知りたい方は、以下の記事でITILの概要やメリット、資格体系などを詳しく解説していますので、ぜひご参照ください。
>> ITIL®とは ～ITサービスマネジメントのフレームワーク～
｢緊急の変更｣はイレギュラー対応などにあたるため、本稿では説明を割愛します。
｢標準的な変更｣と｢通常の変更｣は一見似たような意味の用語に思えますが、｢変更に至るまでの手順が承認されているかどうか｣がポイントとなります。
｢通常の変更｣の場合、変更のたびにRFCを提出するため、変更の承認を受けるための文書作成やレビューなどが必要となります。
RFCには、変更におけるビジネス上の影響や妥当性の評価などが明らかになるというメリットがある反面、工数がかかるというデメリットがあります。
対して、｢標準的な変更｣では、変更にいたるまでの手順について事前に承認を受け、変更時にはその手順を実施していれば手続きを簡略化することができます。
修正箇所や影響範囲の大きい変更には適用できませんが、それらの小さい変更であれば｢標準的な変更｣を実施し、一定以上の品質を保証しながら変更の工数削減を実現できます。
アジャイル開発であっても｢通常の変更｣を実施するケースはもちろんありますが、小規模･低リスクな変更については｢標準的な変更｣を実施して、スピーディーな機能の提供を実現してはいかがでしょうか。
Rankingランキング
New arrival新着
Keywordキーワード
