ビジネス課題への解決策(アイディア)と、新たな発想(+α)が見つかるIT情報メディア

Menu
  1. TOP
  2. システム運用
  3. アジャイルから学ぶITサービスマネジメント

アジャイルから学ぶITサービスマネジメント

  • LINEで送る
  • このエントリーをはてなブックマークに追加

さて、さっそくですが私のプロジェクトでは只今UIを重視したシステムの開発を考えています。
UIを重視しているのでプロジェクトの人だけの主観で実装を進めてしまうとトンデモないシステムが出来あがってしまうと思います(笑)世にお披露目出来ない事になってしまうので、第三者の人の主観でフィードバックを適度に取り入れたいと考えまして、アジャイル開発で進めております。

アジャイル開発とは聞きますが、実際にはウォータフォールモデルでプロジェクトを進めている方が多いとは思います。実際は何をしているかという人の為に簡単に説明致します。

ざっくり言いますと、「小さいウォータフォールモデルを水車の如く何回も回しまくる手法」です。
...ちょっとざっくりし過ぎてしまいましたので、もう少し詳しく説明致します。

0.メンバーでプロジェクトの認識を合わせる
1.要件を洗い出す
2.要件の中で今回何を作るかを決める
3.設計・実装・テスト
4.デモ(リリース)
5.振り返り
6.2に戻る

2から5までの流れをスプリントと呼んでいます。0はプロジェクトを始める前段階の話です。4でデモを行ってフィードバックをもらい、
振り返りで次にどうするべきかを考えるのがアジャイルの特徴です。常にフィードバックをもらいながら開発ができるので出来あがった時に第三者から見て、トンデモなシステムができる事が少ないです。

と、ここまで簡単なアジャイルの説明をさせて頂きましたが、アジャイル開発をしていたら、ITサービスマネジメントと似ているなと気付きました。


実は話はここからが本題です。

今回はアジャイルから学べるITサービスマネジメントを話していきたいと思います。
ITサービスマネジメントは、ITサービスを円滑に回すために常にお客様の要望を取り入れ改善していくという事は重要な課題です。

ITILのサービスオペレーションで言いますと インシデント、FAQと言ったものはお客様から得られるフィードバックですね。

インシデントから根本的原因になっているものを抜き出して問題管理に上げ、変更、リリースと進んでいきます。
ITILV3では最後に継続的なサービス改善をしていきます。
ここまで書いたとおりの事をアジャイルで当てはめると

1.要件(インシデント)を洗い出す
2.要件(インシデント)の中から作る(問題管理へ上げる)ものを決める
3.設計・実装・テスト(変更)
4.デモ(リリース)
5.振り返り(継続的サービス改善)
6.2に戻る

と言った感じです。
はい、似ていますね。
と言う事で、アジャイルで学べたことはITILにも活かせるのでは・・・と今回考えまして、
私がアジャイルで大切だと思った事を挙げまして、皆さんにITサービスマネジメントに活かして頂けるのではないかと思いました。
今回はアジャイル開発で大切だと思った3つの事を挙げて終わりたいと思います。

1.意外にお互い認識がすれ違っている事

アジャイルではプロジェクトの方向合わせをするのにインセプションデッキというものを作ります。
プロジェクトを様々な観点から見てそれについて話し合ったもの一つ一つがインセプションデッキになります。
詳しい説明はここでは省きますが、興味がありましたら以下のサイトで説明がありますので参考にしてください。
http://www.slideshare.net/TakaoOyobe/5-45195080

話し合いをしてみるとプロジェクトの一人だけ認識がかけ離れていたり、以外に一部の認識が合っていた等ありました。

認識があっていないと最悪アンジャッシュの如くすれ違いが起きて、取り返しのつかない事が起きます。
障害の問い合わせが来たらどう対処するか、イレギュラーな事が起きたら何を最優先にするか
等認識を合わせておくと迷いがなく対処ができると思います
認識を合わせる場を設けるという事自体がとても重要で一回は話合っておいた方がいいと、思ったのが一つです。

2.振り返りの重要性

アジャイル手法では一番の肝が振り返りです。
フィードバックをもらったのに振り返りをしないなんてありえないですよね?振り返りの場ではフィードバックを元に開発物を改善していくのももちろんですが、
同時に今まで行ったプロセスも見直し、次のスプリントでは全く違うプロセスで進むこともあります。
(時にはプロジェクトを止めるという判断も)
ここが肝なのでアジャイルでは時間をかけて振り返りを行います。通常の業務で振り返りはしているが、時間をかけていない所もあるのではないでしょうか。

たまには時間をかけてやってみるのもいいかもしれません。

3.その場であった最適なものを採用する

 

ITILでもアジャイルの本でも最後の一言に「これが最善ではない」と書いてあります。
ある枠にはめようと考えるのではなくて、ある枠の良いものを手元に寄せてくるというのが良いと思います。
ですが、最善じゃないと直ぐに思って止めるのは悪いと思います。
話は少し違いますが、リーンスタートアップ的にも方向転換するかしないかの判断は相当難しいと言っています。
ここでの判断は命取りになりかねないと頭には置いて最適なものを選ぶといいと私は思います。

以上となります。

まだ、アジャイル開発を始めたばかりなので、「そんな事分かってるよ」、と思った事もあったかもしれませんが、参考になりましたら幸いです。それでは今回はこれで失礼させていただきます。

メールマガジンの登録はこちらから
メルマガ登録 お問い合わせ