ベンダー発注する前提となる準備段階
ベンダーに発注するのは、どういった仕事でしょうか。
まず何を頼むのかが決まっていないといけません。今はどの段階でしょうか。
IT導入・システム開発を思いついただけの段階であれば、仕事を発注するというより相談から入るのではないでしょうか。
相談から入ったとして、やはりまだはっきりとやりたいことが見えていないということを認識したのであれば、そのまま発注するというのは待った方がよいでしょう。
ただし、相談にするにしても、有料でもう少し話させてほしいということもあります。
もう少し進んだ段階であれば、構想・企画ができているということになるでしょう。
企画書があれば、ベンダーに依頼することができます。
企画といってもやりたい側の企画ですので、実現の方向性については不透明なことが多いです。よって要件定義を進めたいということが多いです。その場合、要件定義で見積がぶれるため、発注を一旦区切りたいということが多いでしょう。
いずれにしても、発注にあたり、受注側の見積精度が高くできないと、お互いにあとで困ります。受注側のベンダーが何らか反応できるかどうかが、発注準備が十分かどうかの尺度となります。
外注ベンダーとの受発注関係における類型
- 発注側はエンジニアなし。100%外注。
- 発注側に保守エンジニアあり。プロジェクトを外注。
- 発注側に保守エンジニアおよびプロジェクトマネージャあり。外注なし。
- 発注側で主体的に進めることができるが、一部を外注。
例ではありますが4通り示しました。
外注依存度とも言えます。
ITエンジニア不足の昨今では、発注側と受注側でともにエンジニアが十分であることは、そう多くはないでしょう。
よって、どちらかに寄っている、特に外注側に寄っているケースのほうが多いのではないでしょうか。
社内で開発するノーコード開発のような形態ですと、社内のみの体制で進めることは多いです。
しかし、一定規模のシステム構築となると、発注側が十分に体制を組めるのは限定的です。
そうは言っても、発注した場合、発注側にもプロジェクトマネジメント責任が問われます。
よって、 外注する以上は、外注依存度が高い状態であっても、最低限の外注マネジメントができていないといけません。
発注側の役割と責任
プロジェクトとして発足した時に、受注側は受注した内容についての責任があります。
受注側が受注したとしても、発注した側も責任があります。
役割は、外注の類型にもよりますが、いずれの場合でも発注側責任は逃れることはできません。
外注依存度が低い場合は、ほぼ自らが実施するので、自らがほぼすべての責任を負っていることになります。外注部分は一部ですので、その一部において、受注側は責任を負いますが、プロジェクト全体としては発注側で責任を負う形となります。
外注依存度が高い場合は、IT導入やシステム構築に関係する役務の大部分を外注することになるでしょう。さらに、プロジェクトマネジメントも外注することになるでしょう。
大部分のプロジェクトマネジメントを発注していれば、あとは手放しで大丈夫かというと、やはり発注側にも役務と責任はあります。
仕様の確定やデータ移行については特に注意が必要です。
さらにプロジェクトマネジメントであっても、受注した役務範囲でのプロジェクトマネジメントであって、発注側としての目的に合致したプロジェクトマネジメント責任は残ります。
発注側役務に基づいた意思決定やマネジメントができるだけの体制を整えられないのであれば、実行にあたっては相当リスクが高い状態となります。
リスクが高い状態ではあるが、実行せざるをえないものであれば、発注側リソースの不足部分を別な外注に頼るということも検討できます。
ベンダー候補選定の方法
ベンダーを選定するにあたり、候補を選定します。
既存取引先からの候補選定
既存取引先から、今回のプロジェクトを依頼する候補を探すことは多いでしょう。
その場合、ある程度信頼関係があるということがメリットではあります。しかし、ある仕事は得意だったとしても今回は別な仕事であるため、得意とは限らないというデメリットがあります。
信頼できる相手だったとしても、今回としてどうなのかを検討すべきです。
実現できそうかという観点で、いくつか選定します。
新規取引先の候補選定
新規取引先ということでは、今回の発注領域が時に得意な相手を選ぶことができます。
しかし、逆に今までの信頼関係がないため、信頼できる相手かどうかは最低限クリアしないといけません。
その上で、今回の発注内容の実現性についての事前情報でまずは候補を選びます。
場合により、面談などを通じて探ります。
ベンダーの決定方法
取引先候補より提案を受けます。
提案は受注できる前提で提出されるため、その中から選定することになります。
ベンダー選定としては、要求の理解度、実現策の充実度、実行計画・体制の具体度、コストといった内容となります。
その他、機能面はセキュリティなどの非機能面についても、強調すべき点を比較項目とします。
コストは一番低いところがいいわけではなく、すべての項目を総合的に判断します。
要求の理解度は特に大事です。
理解できていなければ、実現されるものや計画・コストがすべて狂ってきます。
逆にベンダーの立場であれば、相手の要求を理解していることを示すことに注力しましょう。
すべてが整った上で、コストの比較を行い、より優位なところを選ぶことになるでしょう。
外注マネジメントにおける発注側のあるべき姿
発注側は外注した場合に、その仕事のすべてを掌握し、完全にコントロールできている状態が理想です。
そうであれば、何が起きても対応でき、目的を果たすことができます。
ゴールを明確にし、ゴールへの過程で起きた課題を是正しながら、ゴールまで導けるということです。
しかし、外注するうえで、すべてが自らでもできることを発注するというのは、実際は多くないのではないでしょうか。
自らできる領域の職人はいるが、人数が足りなくて、別な職人に頼んで、うまくいっているかどうかを逐一指導・確認しながら進めるというのが完全にコントロールできている状態だとします。
しかし、専門性や未実施領域の経験があることを期待して頼むことのほうが多いため、完全にすべてを把握してコントロールできる状態というのは困難です。
しかし、完全には把握できず、頼る部分があるとしても、最終的な目的に対する責任と発注側として理解すべき範囲を押さえ、ゴールに向けてコントロールすることができれば、理想に近い形でマネジメントしていると言えます。
そのようなマネジメント力は、別な事業においても役に立ちます。
パワーバランスによるマネジメントの違い
発注側と受注側ではパワーバランスというものが存在します。
カウンターとなる発注担当と受注担当、あるいはプロジェクトマネージャ同士との関係が、プロジェクトの命運に多く響いてきます。
発注している以上、発注側が偉いかというと、そうでもなく、受注側が優位になっていることもあります。
発注側が発注せざるを得ず、価格や納期も受注側で好きに決められるようなことも、時にはあります。
取引関係の政治的な関係で、パワーバランスができることもあります。
発注側は、普通は優位となりますが、実務上は、取引の優位不利に関係なく、別なバランスが存在します。
経験上、スキルバランスによる歪みが特に結果に大きく影響します。
バランスとして、発注側と受注側が強と強だった場合、協調できるようマネジメントしていくことが成功の鍵です。
強と弱であった場合、受注側の弱を是正させるようマネジメントしていくことになります。そもそも選んだのが誤りと言えます。
弱と強の場合が一番問題です。外注側の出方はいくつかあります。
発注側の弱を補って前に進めようとする場合があります。これはうまくいきます。ただし、追加請求される場合があります。
発注側が弱とわかっていながら、発注側に依存したままの状態の場合があります。これはうまくいきません。本来の力を発揮できず、弱化するということです。
あるいは、自分たちの守備範囲を決めてそこだけきちんと行う、という出方があります。これは普通なのかもしれませんが、プロジェクト全体から見ると成功していないことのほうが多いです。なぜならば、発注側の役務と合わせて全体のプロジェクトとなるからです。外注部分だけで完結することはないです。
弱と弱の場合は問題です。そもそも始めてはいけないプロジェクトでした。
成功する確率は極めて低いでしょう。他の者が介入しないといけません。責任者などの他の者は、常にリスクを見ながらマネジメントしていくことになるでしょう。
発注側ビジネス都合でのスケジュール
外注したベンダー側では、彼ら都合でプロジェクトを進めようとすることがあります。
要員の調達都合などがあることから、納期の調整などしてくることはよくあることです。
しかし、発注側としてスケジュールマネジメントするうえで、外注側の都合に合わせては、必ず遅れます。
というのは、発注側のビジネス上の都合があり、それに合わせて全体をマネジメントしていく必要があるからです。
例えば、新しい顧客特典を付与した機能をリリースするとします。
特典は8月1日利用分から発生するとします。
そうすると、外注側としては7月末までにリリースすればいいということで最悪考えてしまいます。
それすら守れないのは最悪ですが、ビジネスのスタートに合わせた、発注側の様々なイベントやマネジメントすべきことがあるため、それらを加味したスケールでマネジメントされていなければ、間違いなく遅れていくということです。
この場合7月10日に顧客アナウンス、7月20日にリリース意思決定があったとすると、そのイベントに向けた準備をしていくことを踏まえて、外注部分の仕事をマネジメントしていく必要があります。
契約で有利にする方法
契約では外注とのせめぎあいとなります。
外注側は請負範囲を少なくしたいと考えます。
しかし、発注側は固定金額・納期固定で発注したいと考えます。
少しでも有利に持っていくためには、時間を味方につけたいところです。
時間がないと、外注側も無理をするところが出てくるため、リスクを契約に反映してきます。
逆に時間があれば、時間をかけて内容を詰めることができるため、リスクを少なくすることができます。
実際の契約においては、請負契約でできるよう調整します。
発注側での努力が必要ですが、発注単位ごとに請負内容を明示できることで、請負範囲を増やせます。
また、準委任契約だとしても、成果物を求めるように契約します。
契約において、前提条件を沢山ぶつけてくることは多いですが、発注側としてはあくまでも完成責任を求め、前提条件は外せるよう調整します。
今般、ビジネス面でも技術面でもリスクのあることが多いため、安定した環境でのプロジェクトは少ないかもしれません。
そういう意味でも、アジャイルで進めることも多くなってきています。
アジャイルだからといって、いつまでも続けていい訳はなく、最初の要求リストと実行期間等を取り決められるよう、調整したいです。
受注側のマネジメントを有効に機能させる方法
外注のマネジメントにおいて、発注側がマネジメントを強化し、外注側をマネジメントすることが重要ですが、それ以上に重要なことがあります。
それは、外注側内でのマネジメントを有効にさせるということです。
プロジェクトマネジメントは発注側と受注側の両方に責任があり、両方ともプロジェクトマネジメントを実行していなければなりません。
お互いに実施すべき役務があるため、発注側としても、発注側役務のマネジメントが必要となってきます。しかし、それだけでは不十分で、お互いの役務が有効に絡み合い、全体として完成へと進められるようにマネジメントが必要です。つまり発注側はマネジメント範囲が広く、責任もあるということです。
よって、受注側内のプロジェクトマネジメントがうまくいっていなければ、手を取られて発注側のプロジェクトマネジメントもできなくなってしまいます。
したがって、発注側が自分のマネジメントを全うするためにも、受注側のマネジメントを有効にさせないといけません。
受注側のマネジメントの状況は、マネジメント計画を提示させることから始めます。
自分たちの仕事をどのようにマネジメントしていくかを、提示させ、そのとおり実行されているかを監視します。監視できるレベルにマネジメントされていることが前提ですが、監視できなければ、レベルを変えてもらいます。
監視の結果、うまくいっていなさそうであれば、上位者に告げるなどして、是正を求めます。
ミーティングマネジメント
外注ベンダーのマネジメントは、計画を提示してもらうことに始まりますが、以後はミーティングにて確認します。
ミーティングはただ実施すればいいというものではなく、実施にはテクニックが必要です。
まず、ゴールまで辿り着くように計画されたタスクのスケジュールを基にします。
タスクは実行者が割り当てられます。
タスクごとの進捗状況を把握します。進捗は定量的に捉えます。
タスクの中で、後続に影響する重要タスクがあります。それらは、重点監視します。
重要タスクに限って、発注側にも責務のあるタスクであることが多いです。
同時にタスクで発生した課題の発生と解決状況を監視します。
課題案件も実行者別に割り当てられます。
タスクがきれいに計画されていれば、情報報告もわかりやすくなります。しかし、実際にはタスクに不十分な点があり、課題が発生し、タスク組み換えやスケジュール見直しが発生します。
変更は当然発生するのですが、それらがうまくマネジメントされていれば問題ありません。
ミーティングでは、計画が妥当であり、実績が見えることが重要です。
そして、課題は発生していなくても問題です。課題が発生し、マネジメントされていることを確認できるようなミーティングにします。
議論し、取り決めた事項は記録し、タスクや課題として引き続きフォローできるようにします。
特に、外注マネジメントにおいては、発注側と受注側の役務や責任に関する問題やコスト上昇要因などに留意し、後から揉め事にならないようできる限り内容が見えるよう、ミーティング中に気を配ります。
ゴールを阻む事項の乗り超え方
ゴールを阻むものは課題として認識します。
リスクと思っていたものが発生することもあります。集団でインフルエンザになってしまうようなこともリスクの顕在化事象です。
課題は、発生都度考えるのでは遅いケースがあります。
よってマネジメントされている必要があります。
外注ベンダーのマネジメントにおいては、課題について、解決の道筋が立っているかを監視します。
課題の発生数と解決数の推移を見ることで、早期に課題化され解決に向かうという良い状態にあるか、あまり課題が発生せず、後半になって課題が積み上がる悪い状態にあるかがわかります。
問題が多数であったり複雑であったりすれば、臨時解決ミーティングにより、解決の早期化を図ります。
課題の発生と解決状況により、外注ベンダーの力量は図れます。発注側がマネジメントに優れていれば、いち早く察知し、是正することができます。
また、課題の多くは発注側にも関連する事項です。発注側起因の課題は、早期に解決し、外注側のタスクを進められるようにすることも、発注側マネジメントの一つです。
パートナーとして共に汗をかく
発注側と受注側である外注ベンダーとでは、問題が出たときは対立しがちです。外注側は、発注側の責任にすることは、多くの場合は難しいです。
発注している時点で立場的には優位にあります。だからといって、何でもやらせるといったスタンスでは問題があります。
途中で頓挫するようなことがあれば、少なからず被害を受けます。
発注しているとはいえ、パートナーと捉えるほうが、結果的に長い目で見て得をすることのほうが多いはずです。
パートナーのつもりで接していたら、外注側が調子に乗っていろいろ要求してくるということであれば、その時は切るしかありません。しかし、そのようなことも多くはなく、やはり良きパートナーになりたいものです。
その際の発注側のスタンスとしては、発注側役割を全うすることが重要です。
特に、注意すべきは目的との乖離のチェックです。
プロジェクトを進めていると、細部では目的と乖離する議論が進められることもあります。
決断が遅くなることで、プロジェクトがますます複雑になることもあります。しかし、解決にあたり、目的と乖離する方法に意思決定されるほうが、後ほど問題となります。
やるべきことはやり、決めるべきことは決めることで、よきパートナー関係を築きたいです。
外注ベンダーマネジメントにおけるありがちな問題
マネジメントが弱い
エンジニアはものづくりに集中し、技術的解決に着目します。その間、マネジメントが疎かになっているケースがあります。
マネジメントはそれ自身にスキルが必要なことですが、優れたエンジニアがすべてマネジメントできるとは限りません。
技術的に実現できると技術者としては嬉しいです。しかし、必要以上に工数を掛けてしまったり、期間を考えずに仕事してしまったりすることは問題があります。
マネジメントすることは、ゴールに向かって何とか進めていくことです。そしてプロジェクトはコストや期間、リソースの成約がある中で進めるものです。よって、いつ何を使ってでもいいものができればいいというものではありません。時に、妥協したり、交渉の上合意したりすることがあります。
そのようなマネジメントができているかどうかは、すぐにわかります。
では、マネジメントが弱い時はどうすればいいでしょうか。
強くなってもらうということが一番にあります。
しかし、選んで発注してしまったのだから、発注側がしっかりしないといけないこともあるでしょう。
お任せしてしまったら、相手もお任せしてきた
プロジェクトがダメになっていく典型的な現象です。
発注したのだからお任せしていい部分はあります。そのほうが受注側もやりやすい面はあります。
しかし、お任せにしきってしまっては、発注側がマネジメントできていない状況となってしまいます。
マネジメントされていない状況下では、得てして受注側も能動的にマネジメントしないという状況に陥ります。
そうすると、マネジメントされていないプロジェクトが、マネジメントされていないがゆえに実情が把握できず、手が打たれないまま、いつまでたっても終わらない、ということが起きてしまいます。
マネジメントされていないのがわかっていないに関わらず、逆にお任せしてしまう、つまり、きちんと指示できない人の指示を待っている状態になってしまう、ということが起きます。これでは、うまくいくはずがありませんが、時に起きてしまうのが実情です。
一見うまくいっているようにしか見えない
請負で発注した場合、外注側の作業はすべて把握できなくても仕方がありません。決められた期間で完成すれば問題はありません。
しかし、一見途中経過ではうまくいっているように見えていたものが、終盤になって実は終わっていません、となることがあります。
うまくいっているように見えたのは、二通りあります。
ひとつは、外注ベンダーでは本当にうまくいっていると思っていたということです。
もう一つは、外注ベンダーのマネジメントの問題です。未完成責任を表に出さないよう、うまくいっているの一点張りになるということもあります。
前者は、欠陥が見落とされ、終盤のテスト等で問題が顕在化し、結果手戻りが発生するものです。
後者は、困り者です。裏ではうまくいっていないに関わらず、表に出していません。裏で頑張っているのですが、頑張り切れなかったということも多々あります。もちろん、頑張って立て直してくれることも多いです。
どちらにしろ、表面的なマネジメントでは意味がありません。請負部分であっても発注側が別な手段でなんとかするなど、検討できることもあります。
お互い正直に取り組めなければ、パートナーにはなりえません。
根本的問題はマネジメントのみでは解決できない
外注ベンダーマネジメントを説明してきましたが、こう言っては元も子もないですが、マネジメントだけでは救えない問題があります。
マネジメント以前の技術スキルに関するもの等が原因の場合です。
スキルだけではなく、技術的な難易度の問題もあります。
それらも含めて、うまくいっているかを確認し、問題があれば是正を求めるというマネジメントを行っていけば、解決に近づくのは確かです。
しかし、みんなで寄ってたかって大丈夫か、と声をかけたからと言って、技術的な穴に落ちた人は、自ら出てこないといけないわけで、その力量がなければ、皆が穴に引きずり込まれることさえもあります。
よく知っている外注に頼んだが、それが仇となった
よく知っている人がいるので安心して頼んだ、ということはよくあると思いますし、うまくいくことも多いのは事実です。
しかし、よく知っている人だから頼んだのに、それがゆえに失敗することもあります。
よく知っている人は、頼りになります。ただ、一人のひとでしかないので、限界はあります。
限界を超えたときに、うまくマネジメントされれば乗り越えることができます。
しかし、職人気質集団だと、逆効果となります。つまり、その人の限界が全体の限界となり、結果失敗への一直線に向かってしまうということです。
発注側は、ノウハウやスキルがどこにあり、体制全般に行き渡る効果が出ているかも含めて、監視しないといけません。
一見よくできているアウトプットが実は一人のひとがすべて実施していて、それ以外の人は誤りに全く気付きもしない、という状態だと、誤りがそのまま作られてしまいます。
外注ベンダーマネジメントでの本当にやるべきこと
外注を頼まずにすべて自前でうまく回していければ、それはそれで理想的なことです。しかし、外注をうまく使っていけば、自分だけでは到達できないところに行ける可能性が広がります。
一方、外注に頼らざるを得ず、お任せしたい場面もあります。
IT導入・システム開発においては、発注側役務が多く発生し、請負先の外注ベンダーのみに責任を押し付けるのが困難なことも多いです。
よって、やはり発注側責務を全うしたうえで、外注側にもマネジメントを要求し、お互いゴールに向かっていける関係を築くというのが大事です。
パートナーと言っても友達というわけはないです。お互いいい仕事ができてよきパートナーとなれるのでしょう。
コメント