【システム導入編13:成功のための発注側とベンダの関係】
本マガジンの過去投稿は上記に入れています。
本マガジンは、ものづくりの現場でシステム導入する場合のポイントについて解説するシステム導入編です。工場のIoT推進部に配属された清史朗は、あるプロジェクトの担当になりますがなかなかうまくいっていません。そこに新米課長の紫耀もサポートに入って指導しながら、奮闘していきます。細川義洋氏著「システムを「外注」にするときに読む本」の内容を学びながら自分の立場にでどうすべきかを考えていきます。これまで要件定義と業務フロー図の作成について、そして、発注者として責任・姿勢、そして、ベンダの選びについて学び、さらに社内のメンバーの巻き込む重要性を知りました。今回は、第6章「システム成功のための発注側とベンダの関係」の前半を解説します。
・・・・・・
◆ベンダが勝手に作業していても黙認すると「合意」したとみなされる
👶：おはようございます。
🧒：おはよう。どうだいその後は？製造部の皆は協力してくれるようになったかい？
👶：はい。まあ少しづつですけど良くなってきています。積極的に参加というほどではないですが、時間を割いて協力をしてくれています。意味やメリットを私も伝えましたし、オーナーの工場長からシステム導入の重要性と要件定義とシステム導入における製造現場側の責任について話てもらったのでだいぶ良くなりました。ありがとうございます。
🧒：そうか。でも、ちょっと小耳にはさんだんだけども、聞いていいかな？
👶：はい。。どうしました？
🧒；この間まで、うちの要件定義は遅れていたのは私も知っている。でも、要件が定まっていないのにベンダは作業を進めいたと聞いたが、それは本当かい？もしこれから要件の一部が変わったとした、手戻りが大きく膨らんでしまう可能性がある。
👶：はい。でも、それはベンダが勝手にやったことで彼らがリスクを取ってやっていることかと認識しています。
🧒：ちょっと待て、それは違う。君が知っていたならば黙認の下で作業をしていることになるんだ。それで手戻りが発生したらうちの責任だ。
👶：え？そんな・・。
🧒：これまで何度も話しているが、ベンダと発注者側は一心同体だ。今回のようにベンダが進んで実施した作業を知らんぷりしていても責任はこちらにも発生するし、またベンダの効率が悪くプロジェクトが遅れてもこちらの責任だ。つまり、作業を止めなければならないときは躊躇せずストップしてもらわなければならないし、ベンダ側に指摘しなければならないことがあったらしなければならない。ちょうどいい、第六章ではまさに同じ問題が発生しているから解説していこう。
👶：あ、ありがとうございます。よろしくお願いいします。
🧒：第6章は、ホテル・ソユーズというホテルが舞台だ。ホテルソユーズは、新システムの開発・導入の最中だ。チェックインからチェックアウトまでのすべての管理のシステムを刷新するそうだ。そして、その仕事をアポロソフトという会社が請け負っている。ホテル・ソユーズの担当者は若田さん、そしてアポロソフトでプロジェクトマネジャーは、山崎さんである。そして、白瀬さんがここのコンサルに入っている。5章は割愛したけど、5章から白瀬さんは出向先で一人でコンサルをしている。美咲さんが会社で白瀬さんの近況を聞くところから今回の物語は始まっていく。
👶；独り立ちしているんだ。。すごいな・・。
🧒：美咲さんにホテルソユーズのシステム開発の近況を聞かれて、「業務自体の見直しがだいたい終わって、やっとシステムの要件定義に入ったところだ」と答えるんだ。でも白瀬さんはちょっと不安に思っている部分があるという。
👶：でも要件定義の進め方だったら、エンジェルサイトでやった時に同じようにすればいいですよね。
🧒：ああ、その通り現状業のAs-isを見えるようにして、問題点洗い出して、To-beの業務を書いていく。その中でシステム化する範囲を決めたら機能要件や非機能要件を抽出する。まあ、それはセオリーなんだけども、実際そんなにうまくいかないじゃん。いろいろベンダとの誤解があったり、現場の意見が変わったり、トップの意見が変わったりさ。セオリー通りなんていかないわけだ。
👶；確かに、今回も勉強していますし本も読んでいますが、同じ状況に置かれてそのまま使えることなんてほぼないですよね。参考書にはなるけど、教科書にはならないですよね。
🧒：そう。その通りだ。そこで、白瀬さんは美咲さんに相談に乗ってもらうことにした。ちなみに二人は休日にラグビーの試合を見にいきそこで会話をするんだ。
👶：ラグビー？
🧒：白瀬さんは全国大会で優勝するチームで活躍していたラガーマンのうようだ。だけど、今回はそのラグビーの話は割愛して、システムに関するところだけ解説していくよ。本の中ではプロジェクトで起こることをラグビーに例えて解説しているからもっとわかりやすいけどね。読んでみて。
👶：解りました。
🧒；早速、美咲さんは白瀬さんに「問題はなんなんだ」と聞く。そして白瀬さんは、ホテルソユーズの要件定義が遅れていて、そしてアポロソフトが勝手に作業をしているんだけどそれを伝える。
👶：え。。私と同じ状況なのですね。。やはり、これもあるあるなのか。。
🧒：そして、美咲さんは、「発注者は、ベンダが勝手に作業を進めた段階でやめるようにいうか、やらせるなら「手戻り費用」は払えないと伝えなければいけないと白瀬さんに明言する。」同じだね。
◆チェックポイント会議
👶：え。でもさっきも思ったのですが、、私が言うのも変なのですけども、それベンダ側が困りませんか？要件は決めてくれないのに納期が迫ってくる。ベンダは大損する方向になる。その分まで発注者側が負担してくれればいいが、会社対会社ではそれも困難な場合があります。
🧒：そう、その通り。だから、要件定義が予定通りに終わりそうにないときでも、そういう事態に備えてチェックポイント会議を開くことを薦めるよ。
👶：チェックポイント会議？？
🧒：予定通りに次の工程に移れるか、残っている問題はないかどうかを、発注者側とベンダが一緒に確認するんだ。最優先事項はすぐに対応すべき当面の問題を見つけること。
👶；最優先は解りますが、残った問題はどうするのですか？
🧒；残った課題一つ一つについて、いつまでに、誰が、何をするか決めてそこまで終わったらとりあえず工程完了とするんだ。なお、チェックポイント会議の議題は下記だ。
□要件など未決事項はないか
□未決事項があれば、いつまでに誰がどのように決定するのか？
□未決事項への対応で、スケジュールや工数が計画時と変わるか？それは需要可能なレベルの変更か？
□未決事項の対応は、技術・スキル面でも可能か？
□未決事項への対応により、影響を受ける他の要件はないか？
👶：なるほど、でもあまりにも未決事項が多くなると・・どうするのでしょうか？
🧒；その時は、スケジュールや納期の変更、一部機能を落とすことをチェックポイント会議で合意すればいい。ＱＣＤが絶対ならマンパワーの追加投入や費用の追加も考えなければならない。
👶；プロジェクト自体が見直しということですね・・。あらま・・。
🧒；ああ、でもお互いに合意の上なんだからプロジェクトの健全性は取り戻せる。これが大事なんだ。結局うまくいってしまえば、多少の追加費用は笑い話に変わる。
◆「システムの専門家」相手に発注者はどこまで質問すべきか？
👶：なるほど。プロジェクトの進捗管理の具体例ですね。実際に私も実施してみます。すみません、ぶっちゃけついでにもう一つ気になっていること相談したいのですけど。
🧒；いいよ。なんだい？
👶：製造部で、元々ベンダに勤めていてシステムに詳しい方がいるんですけど、その方率先して参加してくれるのはありがたいのですが、ベンダに対して結構厳しいというか、各種データ間のインターフェースだったり、データベースの正規化についてベンダさんのやり方にいちいちケチつけるていろいろ言っちゃって、ベンダさんから「それはこちらの仕事だからいろいろ言わないでくれますか？」と始まってしまって空気悪くてしょうがなくなる時があるのです。
🧒：ははは、白瀬さんも本の中で同じ状況になっているよ。なるほど。でも、そんなことも起きているのか。どう思っているの？
👶；私は、細かい技術論になったらああだこうだ口出さないほうがいいと思うんですよね。餅は餅屋というか。
🧒；私は、そうは思わない。もちろん技術的な話は最終的にベンダが責任を持つけど、それを決める過程では発注者だって口出してかまわない。そして、そのやりとりがベンダを育てることになることもある。そもそも、顧客対応に出てくるベンダのエンジニアは、すべての技術について深く知識をもっているわけじゃない。データベース、ネットワーク、言語、セキュリティ、OSやハードウェア。顧客対応のエンジニアは一通りの技術を持つジェネラリストであっても、それぞれの技術のスペシャリストではない。
👶：表に出てくるエンジニアの技術的な見解には間違いもあるということですか？
🧒：ケースバイケースだけども、言いたいのは盲信してはならないということなんだ。疑問や提案があるのであれば躊躇せずぶつけていい。たとえ嫌な顔をしても発注側が問題を出してベンダに勉強してもらうくらいのつもりでいんだ。モヤモヤが消えるまで質問にゃ注文を繰り返すことで、発注者もベンダも今のやり方の正しさに自信が持てるようになっていくんだ。本の中で美咲さんもそう白瀬さんにアドバイスをしている。
👶；なるほどです。。でも、そこには人間関係というか信頼関係が必要ですね。
🧒：そう。そこには心理的安全性が必要なんだ。やっぱり。もし、心理的安全性が高くない状態で、質問ばかりしていたら責められているように感じメンバーはうまく機能しない。根性が座っている人ならなにくそで頑張るが、そんな人は今は少ない。いかに心理的安全性を確保しながら指摘を行っていくかが重要なんだ。ただ厳しく質問するだけでは、精神的に追い込んでしまう場合があるからね。お互いね。
👶；わかりました。
🧒：よし。今日はここで終了だ。次回はパッケージソフトを自部署に適した形で導入するためにどうしたらいいか解説するよ。
・・・・・・・・
今回は、ベンダとの関係性について解説をしました。かいつまんでいうと、会社はまたいでも同じチームとして腹割って話す。問題は見える化する、そしてプロでなくても客観的に問題だと思ったら話あるということですね。そしてそこには心理的安全性が必要だと思います。さて、次回は、パッケージソフト導入について解説したいと思います。次回で本書の内容の解説の最後になります。その後、本マガジンのまとめを実施して次のマガジンに行きます。ものづくり経営編として、三枝匡氏の「ザ・会社改造 340人からグローバル1万人企業へ」について対話形式で解説したいと思います。（悩んだ結果、、予定変更することしました・・。すみません。）
なお。下記の固定記事に、このnoteのコンセプト、これまでのマガジンについて解説しています。
番外編マガジンもあります。よければ💁♂️
#製造
#理論と実践
#ものづくり
#成長
#5S
#トヨタ生産方式
#ジャストインタイム
#自働化
#リーンプロダクション
#ザゴール
#制約理論
#ドラッガー
#ビジョナリーカンパニー
#アドラー
#コーチング
#情報リテラシー
#要件定義
#会計
#損益計算書
#決算書
#損益分岐点
#原価低減
#平準化
#両利きの経営
#両利きの組織
#心理的安全性
#グーグル
#推薦図書
#システム
#発注側
この記事が気に入ったらサポートをしてみませんか？