情報システム部の仕事 の中で、社内システムの開発、運用、保守がその一部としてありますが、この3つの業務領域は、単純にその言葉で片付くほど単純なものではありませんし、それぞれにおいて求められるスキルも異なってきます。
しかし、部や課、チームなどを運営するに当たってはそれらの業務領域と言うものは、どの人が担当するものか明確にしておく必要性があったりします。
※ べき論で言えばそれは人に依存する形ではなく、チームであったり課であったり部であったりと何からかのユニット
によって決められているべきでしょう。
何でも出来ることに越した事はありませんが、それを全ての人に求める事も難しいでしょうし、万一そのなんでもできる人が担当業務を抜けるという事になると、その穴は大きく他の人で埋め合わせる事が出来ない可能性も出てきます。
健全に部や課を運営する為にはあるユニットごとに業務を明確にしておき、そこに必要なスキルをそこに所属する人に対し均等に教育しておけば、万一にも対応がしやすくなります。
こうする事で、そのユニットの存在意義、そこに所属する人のスキルセットが明確になる点などメリットがある一方でそこに所属する人はそれら求められるスキルセット以外を磨く術が無くなる、単純な業務の繰り返しによるモチベーションの低下などというデメリットもあります。
そういった対応の為に配置の転換を行ったりと、その人の思い描くキャリアパスに従って新たなスキルを身に付けさせる為の方法を用意しておく事も必要です。
では、このような業務領域の整理をどのようにやっていけばよいのでしょうか。
一つには、システムの領域と業務の領域のマトリックスを作り、そこに担当するユニットを一つずつ当てはめて行くという手段があります。
例えば、システム的な領域の分類としては「プログラム」や「コンテンツ」、「ソフトウェア（ミドルウェア）」、「サーバー」、「ネットワーク」などにわけ、一方で業務的な分類としては、「構築」、「ヘルプデスク」、「監視」や「障害対応」などに分類します。
※ 業務領域については、「運用」「保守」などの大きなカテゴリわけをすると、具体的に運用ってどこからどこまで？
というグレーゾーンが残るので、実際の運用業務を洗い出した上で、それらの業務領域を定義するなどした方が
まとまりやすいと思います。
プログラムの変更対応などが多くある場合に、「構築」とは分けて「改修」というようなカテゴリを用意しておいたり
コンテンツ内の文言を変更対応業務などに対応させるため「修正」というようなカテゴリを用意したり。
それら定義したカテゴリは、実際にどのような業務を行うのかを明記しておく事です。
これら、2つの領域に対してマトリックス図を作ります。
| 構築 | 改修 | 監視 | 障害 | |
|---|---|---|---|---|
| プログラム | ||||
| コンテンツ | ||||
| ソフトウェア | ||||
| サーバー | ||||
| ネットワーク |
この図のクロスする部分をどのユニットが担当するのかを明確にしておくわけです。
「構築」の「プログラム」はAユニットが、「サーバー」の「監視」はBユニットがと言う具合にです。
これらを定義した上で、次にその領域の細かな業務を一つずつ見ていった場合にその業務がどの領域に該当するのか照らし合わせ、そしてそれを担当するユニット（人）を明確にしていくわけです。
例えば、「コンテンツのバックアップ業務」がある場合に、バックアップ業務は「障害」の領域に当たるから、じゃあ「コンテンツ」の「障害」の担当領域であるBユニットが業務するんだよねと言う具合にです。
これらに関しては、ある程度そのユニットにおける責任者を交え合意をとっておくことが重要になります。
細かな業務の割り振りなどは、担当者レベルで同にでもなることなので、まずはその割り振りをするに当たっての前提となる領域をきちんと決めておく事が重要です。
