【レビュー】【メモ】『システムを「外注」するときに読む本』細川義洋 | 磯野ナニ平の研究ノート

磯野ナニ平の研究ノート

中小企業診断士/書評、音楽レビュー、他/40代

PJ成功のカギはコミュニケーションにあり

ちょっとクサいストーリー形式(萌えキャラ?)となっていますが、まあ言いたいことは理解できるしそこそこ笑えます。IT導入PJを頓挫させかねない代表的トラブルを取り上げて対応策やマインドセットを指南しています。そのポイントを一言でいえば、「トラブルの多くは要件定義フェーズにおけるベンダとのコミュニケーション不足がもたらす」ということでしょうか。本書の半分以上は要件定義フェーズに割かれており、問題の多くは技術的なものではなく意思疎通の齟齬(すれ違い)が原因であるとしています。問題の芽は早い段階で摘んでおくべし!という当然といえば当然のことではありますが、それがいかに難しいかは世に溢れる失敗PJたちが物語っているわけで、何事もなあなあのまま進めてしまうのは人間の性といえそうです。詰まるところ人間の注意力に依存するだけでは心許ないので、やはり何らかの仕組みが必要ということでしょうね。本書ではそのためのチェックリスト等のツールも紹介されています。

 

それでは以下、気になった箇所を拾っていきます。

 

業務フロー図を書くからこそ、今の業務の問題点が明らかになって、何を改善すべきかがわかるの。改善すべきところがわからないと、システム化すべき業務を判断できないでしょ?

改善すべきところがわからないままにシステム化を推進してしまう。これ、結構ありそうですよね。本来、何らかの目的を達成するための手段であるはずのシステム化。が、システム化することが目的になってしまっているパターン。そして、現状業務の一部を機械に置き換えただけ、という単純なIT導入に留まってしまうパターン。これではIT導入効果は乏しいものになってしまいますよね。

 

ベンダの作る要件定義書が正しいかどうかを、発注者が見極めなきゃいけないと

面倒がってベンダに丸投げ→後々トラブったらベンダのせいにする、はダメですよと。場合によっては発注者側に賠償責任が問われるケースもあるなど、訴訟リスクがあることも指摘されています。

 

システム開発プロジェクトは、発注者が望んだものを、品質良く、コストや納期を遵守して完成させることができれば、成功です。

単に完成させれば良いのではなく、QCDの観点から評価せよ、と。

 

システム開発請負の見積もりでプロジェクト管理工数を全体の10%と見積もってる。

わりと削られがちな部分ですが、「見積もり段階で5%を下回っていたら危ない」と著者は言っています。まあ頓挫してしまったら元も子もないですからね。

 

ITシステムはビジネスの主役になろうとしている。

組織のIT化は本業と同じくらいに重要な課題になっています。ITシステムの重要性は、コスト削減や情報共有のためにだけITを活用していた時代とは比べものにならないくらいに大きくなっています。ITを駆使してまったく新しいビジネスモデルを創出し、成功させることが、企業が生き残るための重要なポイントになっています。

これはDX的な視点ですね。

 

トップの方針を末端の社員まで浸透させる風土があります。どんな商売をして会社を儲けさせるか、そのために必要な商品・サービスは何か、業務プロセスはどうすべきか、体制やITはどうあるべきか、そんなことを繰り返し繰り返し、社員たちに研修やトップからのメッセージで徹底してるんです。システム全体の目的と意義を社員全員が認識してるんです。

システム開発への参加も本業なんです。協力するんじゃなくて、参加してるんです。新システムを実際に使うことになるユーザー部門のキーマンは、それまでの業務の中で本当に自分がやるべきことだけを残し、残りは周囲の人や派遣さんにもお願いします。ヒマなときに手伝ってやるなんて意識はありません。プロジェクトへの参加を人事考課の対象にもしてるんです。

システム化の目的を社長自ら全社員に刷り込む、ユーザー部門のキーマンの意識を変える、システム開発への参加を本業にするための体制作りと、その姿勢や実績を人事考課にも組み込む。

発注者企業にとってシステムは本業じゃないし、ベンダの人間にとってもシステム運用は決して楽しい仕事じゃない。いつ、やる気を失って悪さをするかわからない。

システム担当者のモチベーションを維持することも大切。

社員には、システム運用の担当が終わったあとのキャリアパスも示してあげる必要があるかもね。

担当部門以外はとかく他人事になりがちなIT導入PJですが、全社的な改革である以上、社内の協力を得るための仕組み作りは欠かせないでしょう。これは経営陣がどこまで本腰を入れるかで決まりそうですね。

 

チェックポイント会議は最初からプロジェクト計画に盛り込んでおいたほうがいい。発注者が主導してね。

確かに、遅延や未決事項の発生を前提にした会議なんて、ベンダからは言いにくいよな。

何ができていないのか?を都度確認することがコケないためにも重要だと。

 

ストーリーでは、事例として「御用聞きシステム」なるものが提案されています。

商品配達員が得意先の家を訪問して注文をとるサービスで、かつて町の酒屋がやっていたものを参考に思いついたものだった。

配達員に担当地域のお得意様を訪問させて顧客におすすめ商品を紹介する。そのおすすめ商品は、セール品や話題になっている食材だけでなく、購買履歴や家族構成を元に、その人が必要としそうな、または好みにあった商品をまとめたお客様ごとの「おすすめリスト」に記載される。配達員は、それを持って各家庭を回るのだ。

たとえば、購買履歴から味噌や醤油の切れる時期を見計らって「そろそろいかがですか?」と勧めたり、小学校に上がる孫がいるとわかればランドセルや学習用品を紹介する。そんな具合に、顧客のニーズに合った商品を勧め、注文を受けたらその場でタブレット端末から配送の手配をする、というしくみだ。

このサービスを日々の買い物が負担となる高齢者向けに浸透させようとしている。囲い込めれば、今後の高齢化社会においても安定した売上を確保できる。

 

メンバーのモチベーションアップのおまじないとしてフィーリングマップの作成が推奨されています。

1枚の紙にすべての意見を書いて「見える化」するからこそ気づけることです。