業務メンバーがシステム構築を丸投げできない理由を一生懸命説明してみる。あるいはシステム目線での業務整理について

前回書いた「社員ファースト経営」は少し毛色が違ったのだが、今はまた「変革プロジェクトを成功させるために」という、自分にとってホームグラウンド的なテーマの本を書いている。無事に出版されたら7冊目の本になる。

書いている途中に、

なぜ業務担当者がシステム構築プロジェクトにずっと関与する必要があるのか？
⇒最初に要件を言っておしまいではなく、システムが稼働するまで、ずっと業務メンバーとシステムメンバーは議論し続けた方がいいよ

という命題に対して自分なりの整理ができたので、ブログに吐き出しておこう。
本が出版されるのは1年以上先だし、そもそも本にこの話をうまく組み込めるのかは、現時点で見えていないので。


★なぜ業務担当者がシステム構築プロジェクトにずっと関与する必要があるのか？

システム目線がなくても制度やプロセスを整理できるなら、それでもいいけど、大抵はできないから、システム構築プロジェクトをやりながら（できればやる直前に）業務ルールや業務プロセスをシステム目線も入れて、整理をするのが最適。
というのが僕の回答だ。
まあ、これを読んだだけだと全然分からないだろうから、少し丁寧に説明する。


★システム目線がない場合の、業務設計
システム部門の発言力が弱く、業務担当者が新しい制度を立案する際、システムへの実装をほとんど考慮しない会社は多い。

国の制度になぞらえると、「食料品の消費税率は低くする。でも店内での飲食は贅沢だから、消費税率は高いままで良い」みたいな制度設計は、お店で実際にやる業務について、あまり考慮せずに決めた感じしますよね。
コンビニで買ったものを家で食べた時と、イートインで食べた時と、コンビニ前の駐車場で食べた時とで、消費税率が変わる？それをどうやって判定し、ごまかしをどうやって防ぐのか？みたいな話が煩雑すぎて。おにぎりを2つイートインで食べ、1つ持ち帰ったら税率変わるの？とかね。幸いなことに？日本の小売/飲食の従業員はレベル高いからもう慣れちゃってますけど。
それと同様に企業内の制度でも、「これ、システムで自動で判定するの絶対ムリなやつじゃん」「今のシステムでやろうとすると、3年間、別途EXCELでデータ管理が必要になる」みたいになっていることが多いんですよね。

もし業務の詳細やシステムロジックに精通しているスーパーマンだけが制度設計をするならば、こういった問題は起きないのかもしれない。でもそんなスーパーマンはおらず、後追いで「なんとか業務がやれるようなシステム改修」が行われるのが実態だ。


★理想的なシステム構築プロジェクトでは

理想的なプロジェクトでは、業務担当者とシステム担当者が次のようなステップで検討を進める。
1)現状業務（長年の蓄積でカオスになりつつある）を把握する
2)業務をこう変更できないか？（業務目線での要求）
3)業務をこう整理すると実装しやすい（システム目線での提案）
4)上記2と3を持ち寄り、すり合わせの議論をする
5)では落とし所はここで

2)は業務上本当にやりたいビジョンのようなもの。さきの消費税率で言えば「生活必需品である食品の消費税率は低くしたい」にあたる。
3)は実務に落とし込んだときに、非効率になりすぎないような詳細の制度設計。
時には、2)から4)までを行ったり来たりして、ようやく5)にたどり着くことも多い。


システムの改修や再構築が必要なプロジェクトでは、業務メンバーがガッチリ参加しないと良いプロジェクトにならないよ、というのは僕の持論だ。「システムを作らせる技術」などで、しつこいくらい繰り返し強調してきた。
それは、この2),3),4)の議論こそが、理想と実務とシステム構築費用のバランスがとれた、理想の将来像に近づく、唯一の道だと思っているからだ。


★ダメなシステム構築プロジェクトで起きていること
上記の理想とは異なり、業務メンバーがシステム構築プロジェクトにガッチリ参加しないと何が起こるのか。
（例えば、要件定義で作ってほしいシステムについて語ったら、あとは情報システム部にお任せできると信じている業務メンバーは多い）

まず、システム要望書を渡したまま、業務メンバーが全く時間を割いてくれない場合は、細かいところをどう作ればよいのか判断がつかない。その場合は「きっとこうかな？」という感じでシステムを作ることになる。
そして稼働後に「変なんですけど。困るんですけど」と苦情が寄せられる。
これで苦情を言われるシステムメンバーは気の毒だし、業務メンバーは自業自得だと思う。

ここまで悲惨なシナリオにならなくても、下記のようなプロジェクトはかなり多い。

1)未整理の現状を把握する
2)業務をこう変更してくれ（業務目線の要望書）
3)本当はこう整理した方が実装しやすいのだが、言う相手がいない（システム目線）
4)仕方なく、2)を愚直に実装
5)複雑なシステムになる（構築費用の増加）
6)複雑なので、メンテナンスしにくくなる（改修に時間がかかり、費用も増加）

要は、エンジニアが無理やり実装するので、一応動くけれども、良くないシステムになってしまう、ということです。

★なぜシステム目線があった方が良い業務設計ができるのか？
これはエンジニアの経験がない人には説明が難しいのだが、簡単に説明を試みよう。

・システムを作る際、業務や業務で使うデータの整理を行う（モデリングと呼ばれる）。
・優れたエンジニアは、モデリングの訓練を積んでいる。
・エンジニアは自然言語で書かれた業務目線の要望書を、モデリングしてからシステム仕様に落とし込もうとする。
・その際、曖昧なこと（要望書に書いてないが、システム構築上必要な詳細要件）が洗い出される
・またモデリングの過程で、要望を少し変えればずっとシンプルになりそう、といったことも見えてくる
・なので、エンジニアからの提案に聞く耳を持ったほうが、良いシステムができる
・それだけでなく、良い業務設計にもつながる

という感じだ。伝わっただろうか。
もちろん世の中にはこれができず、業務メンバーに建設的な提案ができないエンジニアもたくさんいる。だからここに書いたことは「優れたエンジニアがプロジェクトに参加している場合は」という感じなんですけどね。

ということで、今日言いたいことをまとめて終わりにする。
・システム構築プロジェクトで、業務メンバーはエンジニアに仕事を丸投げするな
・具体的には、要件定義が終わったあとも時間を割いて欲しい
・エンジニア（システムをつくる人）からの良い提案を引き出せるかで、業務とシステムの品質は変わってくる
・それは「システムを作らせる技術」の一部
・システム投資の額も左右するし、システムの長期的な寿命にも大きく関わる


書いてみて、本に書くには、ちょっとややこしい話すぎる気がしてきた（こうやってブログに書きっぱなしのテーマはよくある）。