業務プロセス管理（BPM）は、ワークフロー（ワークフローアプリ）を把握するところから始まります。この『プロセス改善ストーリー』を参考にして、あなたも業務プロセス改善を始めてみませんか？
システムインテグレータ
「システム」 どういう意味？
なかなか回答に窮する“意外と難しい質問”である。およそ「複数の要素が組み合わせられ、全体として何かの役割を担うもの」なのだろう。「システムキッチン」はコンロ・流し台・収納が料理を助け、「物流システム」は集荷者・保管者・配送者がモノを運ぶ仕組みである。
「情報システム」でも似たようなもので、ハードウェア・ソフトウェア・通信ネットワークが“情報を出力する仕組み”に過ぎない。
しかし 「売上」、「ロイヤル顧客のリスト」、「最新の業務マニュアル」、「新製品に対する顧客の声、上位３つ」・・・考えてみれば当然の話ながら、ヒトが得たいと思う情報は数限りない。情報システムの組立屋（Integrator）が世に無数と必要になる所以だ。
委託者の不満
委託者が不満に感じる瞬間、トップ４！
- [提案段階] 提案のレベルが低い。て言うか無い
- [設計段階] 最新合意仕様がどうなっているのか分からない
- [検収段階] 納品物の品質が低い。テスト内容を聞きたい
- [運用段階] 問合に対する対応が遅い。たまに的外れ回答
以上は経験にこそ基づいているが、あくまでも著者の勝手な推測だ。何の統計データもない。また言うまでもなく、技術説明を受ける瞬間、契約の瞬間、見積の瞬間(!)など、他にも色々な瞬間で不満を感じる事もあろう。
さて・・・、手始めに「納品物テスト」に関連するプロセスにフォーカスし「委託者の不満」を解消したい。選択理由は簡単。他プロセスと比較して、人間能力への依存度が高くないタスクが多いからだ。たとえば「提案」に関連するプロセス自体が整備されていなくても、「委託者の満足」を得る人はいる。
ここではモジュール作成、モジュール結合、実機構築など、メンバは担当範囲の「成果」を出した単位でプロマネに報告する。そこを起点に検査プロセスが始まる。
このプロセスでは、プロマネの簡単な確認の後、任意の検査者二人が検査を実施し、検査報告を記録する。もちろん、どの単位どのタイミングで成果報告をさせるかはプロマネの腕の見せ所となる。
テスト実施内容
「途中の検査報告も、すべて納入する」
そこまでの“男気” を見せるプロマネはなかなか居ないと思うが、本来、納品物に対する「要素単位の検査報告書」は、システムタイムスタンプ付で提出したいものだ。
確かに「CMMIを取ろう」と唱えるのは躊躇するだろう。しかし「納品物の検査報告書も提出しよう」と言う勇気は、是非とも持ち合わせてもらいたい。このプロセスの場合、仮に納品物の要素が100個あるなら、検査者が二人いるので、「（100＋再検査回数）×2枚」の検査報告書が生成される事になる。ちなみに、SI事業全体を俯瞰すれば、テストや検査にかけるべき費用は全体コストの2割程度は必要だ。乱暴に言えば、100人組織には20人の検査部隊が存在することとなる。
※ CMMI： Capability Maturity Model Integration
「検査報告書」の存在は、特に担当営業としては有難い。現実、多くの担当営業はどんなものが出来上がったかを把握できていない。そして、クレームは一方的に受け付けるしかない。
しかし「検査報告書」があれば、委託者が納品物を検収したときに満足できなかった検収項目と、検査報告書の検査項目を比較する事が出来る。すなわち、委託側の主張と受託側の主張を比較する事が出来る。
言った仕様、言ってない仕様
「検査報告書」である程度は救われるはずの担当営業氏だが、人類永遠の課題「思い込み仕様問題」は解決されない。
すなわち、RFP・要求仕様書・要件定義書など、いずれの書類にも書き切れていないが、「委託側としては当然実現されると思いこんでいた仕様」が存在してしまう問題だ。
こればっかりは、地道に合意仕様をきちんと記録していくしかないのだが、「きちんと記録できる／しやすいプロセス」とは、如何なるものなのだろうか。
仕様書管理
プロセスのアウトプットが不十分であった時、
- 実行者が悪いのか？
- プロセスそのものが悪いのか？
のいずれであるか、をプロセスオーナーは見分ける必要がある。情報漏洩だの、勘違いだの、多くの人為事故は、プロセスそのもの（体制と言っても良い）を改善する事で発生確率を下げられる。
今、「最終合意仕様書が共有できていない」と言う状況は、文書管理プロセスの改善で少なからぬ変化が期待できる。草稿ベースに打ち合わせを行い、議事録と修正原稿をメールし、さらに長文議事録の行間指摘をメールしあっている現状を打破したい。
このプロセスオーナーのスタンスは、
- 打ち合わせは何度してもらっても構わない。
- なんならメール議論も好きなだけやりとりすれば良い。
- 「漏れなく記載する」と言う事に主眼に何でも実践して欲しい。
- ただ、「最終決定プロセス」だけは特定のルールに従ってくれ。
と言うものだ。おかげでルールが少ない。しかも最終決議をオンラインで行うと言っているだけだ。流れ自体は、議会での法案審議プロセスに近い。微細な誤植であれば、オンライン議事録で修正の内容を明記し、利害関係者が「同意する」と発言するだけでよく、対象書類を改変し再議論する必要はなかろう。
ちなみに、プロマネは議長役に徹するのが良い。また“穏やかなチャット”にするための十分な事前根回しが期待される事は言うまでもない。
変更管理
ルールと呼ばれるものはシンプルな方が良い。プロジェクトで定義すべき仕様の種類・本数は、案件によって異なる。場合によっては100ファイルを超えるケースもあるだろう。そして、その中にはプロジェクト実施中にやむなく更新される仕様もある。
しかし、新規法律にせよ、法律修正にせよ、全ての法律が議会を通過するのと同様、仕様の変更であっても必ず「最終仕様合意」のプロセスを経て承認されるようにしたい。
すなわち、何かもめごとが起きた時に、個人のメールボックスを探しまわるようなことはしたくない。
仕様決定と検収検査の他に・・・
さて、「不満瞬間」の残り二つ（1.および4.）も結論だけになるが、提案しておきたい。
- [提案段階] 提案のレベルが低い。て言うか無い
- [運用段階] 問合に対する対応が遅い。たまに的外れ回答
プロセス自体のブラッシュアップタイミング
「プロセス」はすなわち「ルール」でもある。ルールの改編は頻繁に行うべきではない。人数配分の変更等で対応できる場合も多い。しかしどうしても「滞留」や「ミス」が無くならない場合、プロセスオーナーは勇気を持って変更する決断をしたい。 [完]
