なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

チケットに何を埋め込むか+管理者目線のチケット制御のテクニック

今週は、ITSMにおける悩みというか管理の実務を担う方向けの一つの考え方として整理できればいいなと思い、今回のテーマを選びました。

ズバリ、ITSMツールのチケットには「何を埋め込めばいいのだろう」という問題。そして、それをどう展開していったらいいのかのテクニック。

 

これを進めるにあたって、そもそも「チケット」とは何か?をテーマに語りましょう。

チケットとは、おおよそIT運用やIT開発をしていく上で生じる作業を関係者で眺められるようにしたものです。想像してください。ホワイトボードにペタペタ貼られた付箋。その付箋一つ一つがIT運用や開発で今起こっている、そしてこれから起こる、そしてすでに終わった作業の一覧です。そうなのです。そもそも、チケットとは「付箋」です。

ですから、全員が一堂に会しているのなら、大きいホワイトボードに作業を付箋にして貼り付ければITSMツールは完成なんです。

小難しく考える必要はありません。チケットは付箋。そして時間がかかり重い作業であればあるほどチケット(付箋)に書かれる文字は多くなり、チケット(付箋)は大きいものにせざるをえなくなる。

じゃあ、そんなことが今のこのご時世できるか?

……できませんよね。いえ、正確に言えばできないことはないのですが、日本や世界中に散らばった同僚やパートナー企業の人と同じ場所で同じ時間に働くなんてことは一朝一夕にはできません。それに、付箋ばっかになっていたら集計に時間がかかりますし、集計するだけで一苦労です。

それに対応するために、スモールスタート、かつ俊敏に動くAgileがあったりするわけですが。

ITSMは、管理者向けのナレッジであり、管理と人間の営みとして起こる運用を両立させるためのツールでもあるのです。リモートや時差のある人たちとも一緒に働けるようにする。その点では、働く上でのバリアを取り除くことができるナレッジとも言えます。

では、何の情報を付加することで、上記のようなアナログな一目見てわかる状況可視化をITSMツールで実装するか。

それには、そもそもチケットに何の情報を入れるべきなのかを整理しておく必要があります。

今回はテクニックの話もあるので、先に整理したものをご覧下さい。文字文字しており申し訳ありません、、、あ、それはいつもの通りか。。(図1:チケットに付加する情報整理)

図1:チケットに付加する情報整理

左を見ていただければわかりますが、チケットに入れる情報は大きくは2つにしか過ぎません。

先ほどのホワイトボード上の付箋の例えをそのまま使うと、付箋そのものの存在を示す「定義」と、その付箋の大きさ、色、形を示す「周辺情報」です。チケットを実際に取って作業をする運用者目線だと、チケットの大きさ、色、形も「定義」に含まれると考えると思います。しかし、今回は、ITSMの実務者目線から見ると、そのチケット(付箋)の大きさ、色、形は、KPI /SLA /SLOとそのサービス提供組織(自組織)がどのようにサービス運用を改善したいのかの分析目線で入手できる情報のことをさします。

そして、管理者目線でこれらを見ていてもダメです。なぜならこのチケットを実際に手に取り作業を実施してくれるのは運用者。したがって、彼らのためになる、または彼らからすると意味がない情報は見えなくしてあげないといけません。ここのミソは、「見えなくしてあげる」ということです。無くしてはいけないのです。つまり、論理的に削除することは良くても物理的に削除してはいけません。特に分析情報。そして、分析情報は、結局運用者目線で大切なことであったり解決したい課題に直結するため、可能であれば一定のルールを決めて、セルフ追加、セルフ削除であることが望ましいです。

言うなれば、サービス管理ツールは生物です。運用や開発が刻一刻と状況を変えています。したがって、一定期間後、取得していたタグ情報は陳腐化し意味がなくなることもあります。それを速やかにキャッチアップできるのは管理者ではなく現場です。現場を最大限尊重し信頼し、一定の範囲内で持って彼らを支援する。その感覚でツールの要件を決めていきましょう。

 

ここから先は、私の感覚と実際の設計に基づく感想になりますが、、、、

WF(ウォーターフォール)的なガッチリしたレポートToが決まっているものは、マネジメント(管理)の与える影響が強いため、その点はService NOWが良いかなと。

Agile的な、フラットな階層構造で進めているプロジェクトは、その目的で分けるのが良いと思います。

例えば、チケット(作業)管理側面が強いものはRedmineとかJiraとか。ただしどんな時でも、工数、人月を管理するのであれば、それは別で管理しましょう。というのも、そもそも工数管理そのものがマネジメント(管理)の側面が強い印象があります。これは、日本における労働三法の影響だろうなと考えています。そもそも二次産業隆盛期に作られた均一化された労働力管理を行うための法律なので。。

では、Agileな仕事の進め方ではどのように工数管理を行うべきかというと、1チケットあたりにかかる時間を均一にする。つまり、仕事にチケットを振るのではなく、時間にチケットを振るのです。可能であれば、1仕事=1チケット=1単位時間となることが望ましいです。

さて、いつも以上にサラッと書いてしまいましたが、このアーティクルは答えではなく、答えに繋がる何かにご活用いただければ幸いです。