IT開発（コンサル）に関わる話ー発注側を育てたい（偉そう...）
ITに限らずですが、外部委託する際のポイントは、どこまで行っても発注側スタンスにあるなと思うという話です。以下の続編になります。
カテゴリ
ビジネスやら事業に関すること
人、組織、集団と関係性に関すること
前提
またしても言い訳がましくなりますが、あくまでも私が見える世界での、私の実経験に基づく学びと見解であり、一般論・普遍的な話では全くない点をご了承ください。
「金払ってるんだからちゃんとやれ。出来が悪かったら払わねーよ」とか
「追加で金払えばやるんだろうな」（と言いながら無茶案件を無理矢理通そうとする）とか
「金もらってるからまぁ後はうまくやればいい」とか
そういう信頼関係とか相互尊重がない現場も（自身の経験を含めて）沢山ありますが、、まぁ、ここでは、その手の双方の人間性に依存する話は抜きにして、「仕事の進め方」的に取り組みたいことのみを言語化します。
また、内容次第では、「それは全部自前（内製）でやる」というポリシーの会社さんとかもありますが、あくまでも外部委託していただける会社様との関係性構築の話とします。
要約
特に関係性を構築する最初の段階では、発注サイドからの
「ITとかシステムとか分かんないんだよね」
的な所から仕事を引き受けること自体は避けられないとしても、、、いい成果を出すとか、長く良好な関係を作っていくには、段階的にクリアしていくべきことがあるだろう。という話を書いてみます。
特に、多くの企業にとって、ソフトウェア開発＝「投資案件」となるはずなので、投資案件の決裁者・実行レベル責任者を立てていくことは、何よりも重要なはず（…なのにできていない）というケースへの処方箋を少しでも言語化していきたい思いです。
最も強調したいこと
目に見えるもの・・・自動車や不動産の購入にしろ、工場などの設備投資にしろ、「よく分かんないけど金使う」ことはないはずです。
もちろん、使い勝手や見た目のデザインとコストなどが優先され、耐久性や保守性といった内部構造や細部まで把握されることは少ないとは思いますけど。。。ITの丸投げ事案と比較すれば、大抵自分事のはずです。
個人的見解では、日本人は、「目に見えるものの価値を重要視する」傾向があると考えています。逆に言うと、ウィルス等を含め、目に見えないモノへの勘所や興味が弱い。
とはいえ、「投資」なので、
予算（イニシャル＆ランニング）・費用対効果・耐用年数
と言ったことに対して、「責任を持つ人が決裁する」はずです。
こういったことから考えても、
「ITだけ例外」なのではなく、ハードウェア同様に「投資案件」としての意思決定やトレースを発注サイドに持ってもらえるように、受注サイドからも働きかけていく必要がある。
…というのが、両方の立場を経験した私が思う「発注サイドを育てたい」という根本です。
話の進め方
とりあえず、理想ー現実ーギャップを埋めるという形で論点をまとめないと訳わかんなくなるので、その順に話をしていこうと思います。切り口は、
● 体制
● 進め方
● 評価方法
あたりで。
プロジェクト体制
最低条件
ザックリ言うと、TOP同士だけは信頼関係がある状態
YES/NO判断の裁量を持っていただける方がプロジェクトオーナーである
受注側にも責任範囲を明確に説明し、請けることが可能か不可能かの線引きは明確にしてくれる人が立つ
受注側には、専門分野については必ず解決してくれるスペック・ノウハウがある
→ この3つがない場合は、さすがに。。。体制作らない方がいいなという思いです。
理想的条件
まぁ言い出すとキリがないですが・・
うまく行かない時のリカバリ方法が協議できる
実行主体となる方は、受発注側共に専任である
実行主体者はほぼ全領域をカバーする知見を持っている
発注条件が明確→ 結果、1つの箱ごとの役割も明確になる
責任者・実行主体・担当者・関係者等の体制図が絵面だけではなく機能している
→ どれも重要過ぎる話ですが、、、揃っていることは少ないはず。
→ ＋これはITに限らず「新規事業」全般に同じことが言えるはずです
ギャップの埋め方
● 最初にやることは「リカバリ方法の協議」体制を作ること
● 次に作る・立てる必要があるのは、（育成込で）実行主体者かなと
その方の条件として重要視するのはこういう感じです。
（上ではなく）周囲との信頼関係・パイプ
業務知識やIT知識への理解＝論理的判断
↑ここに大きな隙間↓意識高い、頭いい、その他ポジティブ系要素
上記に含まれないその他の人間性とかは無視。
絶対アカン系
キーマンやチーム全体に、以下がまん延すること。。。
威圧系・評論家系・意志がない系・範囲区切る系（隙間が分かっていても拾わないこと）・ヒラメ系
など
→ こういう世界からは、逃げるに限ります。
プロセス
最低条件ーその1
体制と同じことでもあるのですが、
「うまく行かないことを前提とするリカバリ」＝「振り返り」
これを継続的かつ実質的に意味がある形で行うことが、とにかく必須要件だと思っています。
最低条件ーその2
ウォーターフォール型であれば確実に成功できること
日本企業の大半においては、2020年代の今においても、ウォーターフォールで成功の型を作ることが何よりも大事だと思います。
ウォーターフォール？そんなの古臭い・・・という話は当然あるのですが、エンジニアも営業マンも経営者も「絶対に抑えるべき基本」というのは存在します。
ITプロジェクトにおいても、同様のことがあり、それがウォーターフォールだと私は強く思うわけです。そして、これが意外にもできない。。
規模の大小ではなく、まずはウォーターフォールであれば確実に成功する。これなしに、いきなりアジャイルに飛びつくのは、
・キャッシュフローを考えずに経営するとか、
・アルゴリズムの重要性を知らずにソフト開発をするとか、
・相手のこと調べずに営業するとか、
くらいに、「無謀なこと」です。
理想的条件
フェーズはとにかく小さく切る＆やり切る
目に見える部分の合意＆具現化を優先する
ローンチ日を決める。その上で、柔軟に変更する
変更プロセスを厳格に決定し、最重要視＝振り返りの最も高度な運用
VUCA時代においては、
「やること決まっていないんだから走りながら考えるんだよ」
とか言っちゃうわけですし、実際そう思います。
ただ、計画や振り返りの重要性を抜きにした「走りながら」は、特に以下の2点で危険です。
● 極論、逆走する可能性もある
● 何かやってるけど、いつ何が出来上がるかさっぱり見えない
ということで… 相互の信頼関係があるよっていう前提下で、
「小さく堅いウォーターフォール」を大量に組み合わせ
適宜「変更プロセス」をしっかり盛り込む
ノウハウを積み上げ、その案件流のプロセスマネジメントを確立する
というのが、不確実な案件に対しての参画としては最強と考えています。
最終的には、契約関係の立場を越えた、
受発注的立場に関係ないコトに向かうプロジェクトチーム＆プロセス
が作り上げられると最高ですね！！（難しいですが）
ギャップの埋め方
とにかく計画段階の話を丁寧に取り決めることに尽きると思います。
プロトタイプ・PoCをやりやすいところから優先する
優先度の議論をしっかり行い、「ゴール」イメージを共有するところに時間をかける
3か月or半年後の姿をまずは相互に共有する
進め方に関する各種議論を丸投げされないように常にリスクとセットで発注側の頭に入れる
プロセス系議論はオープンに行う
絶対アカン系
一番ダメかつやってしまいがちなのは、全体進行はウォーターフォールである（≒納期が決まっている）が、
フェーズ毎（特に上流工程）に決めるべきことを決めずに次フェーズに進むことを「アジャイル的・スピード重視」とか表現してしまうことです。
評価方法の相互合意
これはシンプルだと思っています。
受注側（開発チーム）の基本評価はQCDです。絶対軸というよりもバランス感の問題ですが、要するに「コスパ」を分解した話。
チャレンジ要素が強いとか運用に近い領域だと、プロセス評価が大事になったりしますが、アウトプットのコスパはQCD分解かと思います。
ただし、これは「受注側としての理論武装」にすぎません。
発注者との関係性をよくすることを前提とする場合、絶対的に評価軸は「投資対効果」であるべきです。
これは、内製チームがある場合の1社の中の社内論理のことだけじゃなく、受発注の関係においても同様だと思っています。
東京五輪で2000億円の国立競技場を請け負った業者さんが、コスパを気にしない。。なんてことが仮に露見した場合、いくらQCD的に業界水準だったとしても、業者側が叩かれてもおかしくないと私は思っています。
もちろん、発注側の組織委員会その他に色々問題があるわけですが、
仮にこれを請け負うなら、
受注側だから知りえないとか責任がない、ではなくて、
その投資対効果が見合うのかを受注側も一緒に見ていく
納品したものは、発注企業側の資産になる。
という前提で、評価軸を決めるべきです。なので、C=コストは、必須＋QDよりも、ROIや貢献度をより重要視して発注側との関係性を考えるべきである。
これは、歩み寄るも何もないかなと思います。
（番外編）
発注側がROI気にしていないような会社or責任者さんだったら、関わらない方がいいな。。と自虐的にも思います。（かつてそういう事案がゼロだったわけではないので）
まとめ
改めて書いてみて、
もちろんこれだけじゃ全然足りないだろーとか、
受注側も育ってないだろーとか、
発注側にIT経験者いない場合どーすんだとか、
お前の頭で今ホットなことだけ書いてるだろーとか、
まぁ、、ツッコミどころは多いなとは思いました。
ただ、自分の頭の整理にはなったので、良しとして、記事を時々読み返して継続的改良をしようと思います！