コラム
業務のIT化を考えるコラム「はじめに」
2016.02.24
ジャパンシステム株式会社 コンサルティングアドバイザー
株式会社アトリス アーキテクチャー開発執行役員 長嶺 亮
組織の業務を、ＩＴ技術を用いてシステム化（以下、単にシステム化とする）する際、多くの場合、その組織で日々遂行している業務を可視化するため、業務フローに整理し、この情報を元に要件定義や仕様書にまとめ、その上でシステム化を進める事が多いのではないでしょうか？
業務の「見える化」を図った上で、何をしたいかを整理する形で仕様にまとめるということで、一見上手くいきそうな感じがします。
ところが、実際にプロジェクトを始めてみると、なかなか思い通りに進みません。現実の業務では滞り無く流れているはずの業務を可視化しようと、業務フローの作成に着手してはみたものの、議論が収束せず、仕様としてまとめることができなかったり、業務フローはできて、そこから業務機能としての仕様は確定した（と思った）ものの、システム設計に上手く繋げられなかったり、あるいは、システム実装まで完了したものの、いざ稼働してみると、想定していた業務が出来なかったりと、なかなか簡単には進まないことを目の当たりにします。
何故このような事が起こるのでしょうか？
実務担当メンバーから集まる情報が不完全からなのでしょうか？業務を可視化する際の業務フローの表記法が誤っているからなのでしょうか？あるいは、システム実装担当の技術レベルの問題なのでしょうか？
本コラムではこれらの根本的な原因は、上記のいずれでもなく、業務フローを起点とした業務の捉え方に問題の本質があるのではないかと考えています。
筆者自身、過去のプロジェクトで幾度となく、このような問題に直面しておりその経験を踏まえて、業務の見える化は業務フローを抑えれば良いというのではなく、（もちろん、業務フローも重要ですが）業務フローを抑える前にも可視化すべき対象があるのではないかという考え方を持つにいたりました。
この機会に、この考え方について整理して、業務の捉え方についての議論のきっかけにしていければと思います。この連載コラムは次のような流れで進めて行きます。
第１回（今回）は導入編として、業務をシステム化する際の業務分析で、最初に取り組むべき可視化対象が「業務フロー」（流れ）ではなく、その根底に存在すると考えられる「業務の仕掛け」なのではないかという考え方を提示してみます。
第２回では、業務の話から一旦離れて、「流れ」と「仕掛け」の位置づけを考えながら、「流れ」の分析の延長上に「仕掛け」は現れないし、逆に、「仕掛け」の延長上に「流れ」が現れるものでもなく、「仕掛け」は「仕掛け」として可視化する必要性について述べようと思います。
第３回では、「流れ」とは別に可視化対象として最初に整理すべき「仕掛け」がいかなるものか、組織の業務とは何かについて掘り下げながら、組織の「業務の定義」を試み、その定義に基づいて、業務の「仕掛け」として表現する対象を明確にします。
第４回では、業務の「仕掛け」を可視化した「業務俯瞰図」の概要について自治体の業務の一部を取り上げ、具体例を交えながらイメージを持てるように解説を試み、第５回と６回で業務俯瞰図上に登場する各要素の説明を行います。
そして、最終回では業務俯瞰図の読み解き方および、その活用方法について説明を行い、組織の業務の捉え方として、業務俯瞰図にまとめる方法が業種業態を問わず、汎用的に表現可能であることを示し、この方法論の有効性について述べようと思います。