システム開発の一部を協力会社に依頼することがある。依頼する内容は、一部なのか、丸投げなのか、私自身様々なパターンを見てきている。
最近私が、久しぶりに協力会社と共同で行う業務の旗振りをした。予定している全ての作業を期間内に終わらせるのは無理である。
このようなときにどのように協力会社に関わったかといことを、過去に自分自身が受注側の要員として理不尽な思いをし、迷惑を受けたことを交えて、協力会社との関わり方について述べたいと思う。
1.協力会社に協力してもらうスタンスで、無理のないよう業務を分担
自社で進行しているシステム開発プロジェクトの一部の作業を、自社に常駐する協力会社に依頼し、お手伝いいただいたことがある。協力会社に依頼するときは、窓口要員を経由して、窓口要員から実際に作業を行う要員へと伝えられる。
最近私が、久しぶりに協力会社と共同で行う業務の旗振りをした。製品を新たにリリースする前の確認工程だ。ただ、確認内容が多くあり、全ての確認を期間内に終わらせるのは無理である。協力会社要員にも、対象の製品仕様をあまり詳しくない方もおられる。私を含め、誰でも知見に濃淡はある。
全ての作業のなかから、自分自身を含む自社要員にて対応する箇所、協力会社様にて実施していただく箇所を洗い出し、分担した。
自社で実施したほうが良い作業内容、協力会社にて実施していただけそうな作業内容、協力会社様にて実施していただいたほうが良い作業内容、業務の特性と人間それぞれの得意・不得意を考慮し、全体として最も効率が良い分担を考える。まさに、パズルみたいなものだ。
自社要員なら時間がかからない作業を、協力会社の方が時間をかけて行うのは勿体ない。自社要員でも協力会社要員でもかかる時間が同じなら、協力会社要員に依頼し、自社要員は自社要員が得意とする領域に時間を裂きたい。このようなことを意識した。
2.進捗を確認し、スケジュール、分担、優先順位の変更を臨機応変に！
協力会社とともに作業する期間は、協力会社の窓口要員から、毎日の進捗と残作業を一覧表にしたものを毎日提供していただき、日々の進捗と残作業を私が確認した。
協力会社要員を活用しても、溢れる作業がある。そのような内容で、優先度を下げることができるものは後回しにして、自分が作業をすることも行った。他の作業で代替えできるものは、代替えして、その作業を省略することもあった。
この期間内に、予期せぬトラブルもあり、協力会社要員に迷惑をかけてしまい謝罪したこともあった。協力会社のほうも謝罪してきた。お互い様という感じだった。協力会社要員が体調不良で数日休暇したこともあった。イレギュラーなこともあるものだ。責めても致し方ない。さらに以降の分担や優先順位を見直し、臨機応変に進めた。
協力会社に技術はあっても、システム固有の仕様を熟知していないケースはある。私自身も熟知している領域もあれば、そうでない領域もある。協力会社に作業を丸投げして、協力会社要員が長考して、工数が膨れ上がることだけは避けたかった。そのため、不明点の質問はデータベースに入力していただき、誠意を持って回答するようにした。私自身で解決できないところは、他のメンバの協力を得た。
当該プロジェクトが終了した時点で、溢れて終了しなかった作業もあった。元々協力会社要員にお願いしようとした作業で、依頼元である私が引き取った作業もあった。優先度が低い内容は、システムのリリース後に引き続き確認作業を私自身で行った。
元々、開発規模自体が当初想定したよりも大きく、スケジュールに収まりきらないことはわかっていた。いつものことながら、いけないとわかっていながらも、私自身は長時間労働にてカバーした。しかし、協力会社要員には無理を強いることなく、優先度や濃淡をつけながらやり切った。
3.協力会社に作業を丸投げする依頼者は反面教師とすべきだ！
協力会社との契約形態がどのようなものであれ、最終的には自社（依頼元）が責任を持たなければならない。協力会社はパートナーだ。下請けではない。下請けという言葉自体を嫌う管理職もいる。良い志だと思う。
発注側のリソース不足を賄うために発注先に単純な作業を依頼する場合でも、発注側が一部保有しない技術に対する知見やサポートを得る場合でも同じだ。どちらにしても「協力してもらう」という姿勢が欠かせない。
私は昔、作業を丸投げされたこともある。初めて見るソースコードの解析を丸投げされたことは複数ある。下請けというよりかは、下請け等の感覚はなく、私の方がポテンシャルが上位ではないかと思ったこともある。そのことを理解している依頼元もあれば、理解せず単にコマのように扱う粗悪な依頼元もいる。
o08usyu7231.hatenablog.com
依頼元は偉いわけではない。単に、依頼しているだけである。依頼先に作業をしていただいているわけである。常に、パートナーである。「依頼してやっている」、「発注してやっている」という傲慢な態度はいけない。でも、こういう奴は未だに一定割合生息している。
上述のケースで依頼元から協力会社に対しての最悪な対応として考えられるのは、立場の力関係を利用し、「完成」「責任」「契約」等と言った言葉を盾に、圧力でもって仕上げさせることだ。中には、このことを「厳しさ」だという意見もあるが、単に「理不尽」なだけだ。
もちろん依頼を受けた協力会社側は「責任」をもって作業しなければならないわけだが、そのようなことは誰でもわかっている。しかし、これを悪用して無理を押し付ける依頼側におけるモラルの問題の方を、私は目の当たりにしたことが少なくなかった。
私が冒頭で述べたプロジェクトとは対称的で、依頼する側の振る舞いとして、反面教師とすべき事例をリンクしておく。実際、私はこれを反面教師としている。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
システム開発ではないが、建設業における協力会社との関係についても類似の問題を抱えており、関係性の構築は重点課題だ。
4.プロジェクトを成功させるには協力会社をブラックにしないことだ！
協力会社と共に、プロジェクトを成功させるための一つの条件としては、協力会社をブラックにしないことだ。この文章だけを見れば、人間なら誰でもわかる当たり前のことだ。しかし、実際できていない。できていない依頼元をよく見る。これができなければ、プロジェクトが失敗するか、協力会社の犠牲の上に業務を成り立たせるだけだ。
協力会社をブラックにすれば、たとえ自分たちがいくらホワイトであっても、そのツケは必ず結果に跳ね返ってくると心得るべきである。協力会社のみならず、多重下請け構造も同じだ。取引先に、いい加減な依頼の仕方をすれば、成果はその程度だし、劣悪な条件で依頼を受け入れてくれる取引先は、ブラック労働によって成り立たせている企業である可能性が高い。
例外として、協力会社に丸投げできるのは、協力会社要員が対象分野に関して熟練レベルであるときのみである。私は過去、協力会社側の立場であったときに丸投げされた案件でも、依頼者よりも私の方が熟練だったこともある。ただ、これでも協力会社の作業や完成品に対する責任は、依頼元が持つのが一般的だ。
協力会社にできるだけ負担をかけず、できる範囲のことをお願いするといったスタンスの企業もいる。協力会社とのあるべき関係性は、主従関係ではない。協力関係だ。
技術の多様化や人手不足により、自社だけで開発をクローズできるケースは少なくなってきている。顧客のニーズに応え、顧客を大切にするマインドは根付いているのだが、このマインドは協力会社も同じであり、協力会社をブラックにしてしまう要因が自社にあるのであれば、自社がブラックと言われても然りだろう。
最後にこれと類似する話であるが、システム開発の発注者としての知っておくべきことを別記事にしているので、こちらも参照いただきたい。
o08usyu7231.hatenablog.com
