業務プロセスにおけるラストワンマイルを最適化するとは

こんにちは、大手町くずろうです。

本日は、「業務プロセスにおけるラストワンマイルを最適化するとは？」について考えてみたい。

一般的に業務というものは、複数のベンダーから提供されるサービスを利用して運営されていることが多い。各サービスは、複数ユーザーへの展開を前提としているため汎用性は高いが、柔軟性は低い。更に、その汎用性故に各社の業務を完全にはカバーできないため、隙間領域（その大きさは各社によって異なる）が生じる。ここがITとして検討すべき業務プロセスにおけるラストワンマイル（SIerにとってのビジネス領域）となる。
　ここで立場が異なる２つの視点から、ラストワンマイルを最適化する際の課題を挙げてみる。

業務担当者の視点

業務要件の変化に応じて、期限までに正確に業務ツール等のシステム化対応や自動化対応をして欲しいと感じている。しかし、期限の短さや業務内容の複雑さから、社内IT部門より完全なものが提供されることは難しいことも理解しており、まずは業務遂行可能なものであればよいと妥協している。コストの妥当性は判断できないため、IT部門の判断に依存している。また、システム化や自動化の要望を挙げても、すぐには対応されないケースも多い。その場合には、手軽にプログラミングできるMs-ExcelやMs-Access、あるいは最近ではUiPath等のRPAプロダクトなどを利用してツールを作成することがある。ツールの品質は作成者のスキルに依存するが、現状の業務を第一に考えると、やむを得ないという結論になる。これらツールは、しばしば当初の想定に反して長期にわたり運用されるが、担当者の異動等に伴い、仕様が不明なものとしてIT部門に報告される。

IT担当者の視点

　複数のベンダーから提供されるサービスやそれを取り巻く周辺の業務ツール等の社内システムは、その運用の中で追加・改善要望が蓄積されていくが、これらの要望に効率よく対応するため、出来るだけまとめて対応したい（即応しない）。現状業務への影響は絶対に回避する必要があるため、コストよりも品質を重視するケースが多い。また、業務ツール等のシステム対応や自動化の要件については、業務部門より提示してもらうか、業務部門の協力を得て把握する。しかし、実際に業務を対応していないIT担当者が業務全体を俯瞰して体系的に要件を把握し、イレギュラーケースをも想定することは困難である。そのため、開発を行う際には前提となる制約を設け、さらに想定外対応のためのリスクバッファを積むという方法を取らざるを得ない。
　業務部門が突貫工事的に作成した業務ツール等のシステムに対しては、IT部門として責任が持てないため、ユーザー責任ということを明確にする。何らかの理由によりIT部門で業務ツール等のシステムを引き取って管理する場合、仕様の文書化などで対応するが、言語や方式の統一性が無いため、その後のメンテナンス性は低下する。

業務ツール等のシステム化対応や自動化対応フローを見直す

上記は、複数のベンダーから提供されるサービスやそれを取り巻く周辺の業務ツール等の社内システムの利用部門と提供部門、それぞれの視点の一例であるが、これだけでも様々な課題が存在することが分かる。今回は、これらの課題のうち、業務要件を把握することが難しいという点に着目し、解消するための対応について一つの考え方を示す。
　システム開発では以前から、ウォーターフォール開発といって、業務要件・システム要件を設計した後、前工程に戻ることなく順次機能を開発・テストするという方式が存在する。これらは、システム構築者が明確に要件を決定できるようなシステムには適するが、業務プロセス全体の内容理解が必要で複雑かつ変化が多いラストワンマイルのシステムには不向きである。
そのような場合にはどのような方法が効果的か、続いてその方法論について延べる。

試作開発と正式開発

　業務部門のシステム利用者すら、実際に使ってみないと要件を明確に出来ないようなシステム化や自動化には、業務担当者が中心となってIT担当者とペアを組み試行錯誤のアジャイルな開発を繰り返すことが効果的である。この試作開発では、機能要件の洗いだしを行いながら、短期間で実装を行う。あわせて、正式開発を行うかどうかの判断の機会を当初から設けておき、必要に応じて品質目標・機能範囲・汎用性などを考慮して正式開発を行う。なお、正式開発に向けての判断としては次のようなパターンがある。
1）正式開発は行わない　デメリット（そのシステムやツールが利用できなくなった場合の業務リスク）を理解しての判断とし、次回の判断ポイントのみ決めておく。
2）正式開発を行う　正式開発のコストが発生するが、メリット（IT部門によるメンテナンスを可能にすることで持続的な業務ツールとする）との比較をした上で、正式開発に移行する。
　このような、正式開発の前に試行開発の工程を置く方式は、一見遠回りをしているようでいて、結果的にはロスなく最短で目的を実現できる一つの解決策となる。とはいえ、なにひとつ目新しい内容はないし、極めてあたりまえの話であり、とてもお恥ずかしい、笑。