引き受けないお仕事の基準

たまたまお仕事の断り方という記事を読んだ。ひとり会社を経営してもうすぐ5年が経とうとしている。うちの会社では過去に1度、大きな失敗を経験してふりかえりを行った。その際に引き受けないお仕事の基準というものを社内で作成した。その失敗に至った原因の1つとして、本来引き受けるべきではないお仕事を受けてしまったと後になって反省した。

時代の流れや人手不足もあり、システム開発やプログラミングのお仕事はまだまだ好況にみえる。うちのような零細企業でも、実際に引き受けられるお仕事より依頼の方がずっと多い。そして残念ながらせっかくいただいた依頼をお断りすることもまた多い。

引き受けないお仕事の概要

経理の本に書いてあったやるべきではない取引

起業したばかりの頃に読んだ次の経理の本にも「やるべきではない取引」として次のリストを提案していた。

このリストも一般論としてそのまま使える。うちの会社で実際にあった話しで信用できない相手との依頼を断ったことがある。

大学時代の同じ研究室の友だちがあるお仕事を手伝ってほしいと言ってきた。事前に晩ご飯を食べに行って、うちの会社の単価を伝えてお互いの条件があうならよいと伝えて、友だちからも取締役に伝えて予算は確保済みだと私は聞いていた。その後に正式に面談をすることになった。

友だちと、その友だちのチームのマネージャーと3者面談を行い、契約の交渉はマネージャーが行うという段取りとなった。そして、そのマネージャーから実際に届いた内容が次になる。

このとき提示された金額は、事前に伝えておいたうちの会社の単価の 2/3 だった。さらに先方の期待するスキルセットを満たしつつ、2/3 の単価すら確定はできないと念押しで連絡してきた。

この依頼は丁重にお断りすることにした。

友だちとそのマネージャーのコミュニケーションが取れていないことは一目瞭然であるし、どちらの問題かは追及しなかったが、とても不快な思いをして2度とこの友だちからの依頼は受けないと決めた。過去に実際にあった信頼できない相手からの依頼になる。それ以来、その友だちとも会っていない。

ある失敗プロジェクトのふりかえりから策定した基準

これも知人の、ある新規事業の立ち上げの開発案件に携わった。すでに別件で他のお客さんのお仕事もしていたため、週3日の契約で新規事業のお手伝いをすることにした。詳細は省くが、先方では新任したばかりの COO がプロジェクトオーナーとなり、4ヶ月で COO が解任されてプロジェクトそのものが中断となった。CEO が言うにはスキル不足でクビにしたという。

そのシステムの開発は私1人だったため、新規事業の立ち上げをうまく進められなかった原因の一端は当社にもあると考え、開発した途中段階の成果物を当社が買い取るという建て付けで、いただいた報酬の半分を返還した。契約は準委任契約であるため、先方から返還を要望されたわけではないが、当社のけじめとしてプロジェクトの成功に寄与できなかったため自主的に提案して返還した。これは当社の大きな失敗の1つとして歴史に刻まれている。

その際になぜ失敗したのかを自社でもふりかえりを行い、この案件は最初から引き受けるべきではなかったと反省した。次のリストのいくつかの項目は先に書いた大きな失敗のふりかえりから得たものでもある。

• 自分自身の目指すキャリアの延長上にないお仕事は引き受けない

• 自分自身が楽しめそうにないお仕事は引き受けない

• 会社の理念や方向性、価値観にあわないお仕事は引き受けない

• すでに在るモノ (システム、アセットなど) を維持していくだけのお仕事は引き受けない

• すでに開発メンバーが十分にいて人手が足りないのを補うだけのお仕事は引き受けない

• 権限委譲がなくて私が開発の initiative を取れないお仕事は引き受けない

• 未知のお仕事を引き受けるときは他のお仕事と兼任しない

このリストに1つでも引っかかったら引き受けないというほど厳格に運用しているわけではないが、こういったリストをあらかじめ作っておくことで、依頼が届いたときに切り分けや議論のポイントを効率よく判断できる。

零細会社こそお仕事を選ばないといけない

一般的に逆に思えるかもしれないが、本当の意味でお仕事は選ばなければいくらでもある。なんらかの理由で急ぎで運転資金や生活費を稼ぐ必要があり、仕事の内容を精査できない状況はあるかもしれない。それは向こうから依頼がくるのではなく、自らがそのお仕事を選択しているので別に構わない。

本稿で議論したいことは望んでいないお仕事が依頼としてやってきた場合、一見、依頼してくれた方への配慮や感謝の念があり、なるべく引き受けてあげたいと思ってしまうことに対して、簡単に判断してはいけないということを私は学んだ。

それは零細企業ほど他社のお手伝いにさけるリソースが小さく、それをいっときの雰囲気で判断してしまうと、中長期でみてうまくいかないことがある。むしろ、そのお仕事が失敗したとしても、自社にとっての収穫や価値のあることを慎重に選ばないといけない。先の当社の失敗経験でいえば、結果的に2ヶ月ただ働きしたこととなり、何も得られるモノはなかった。

なぜお仕事を引き受けないのか

業種・業態に関係なく、一般論として、お仕事の品質を左右する要素の1つにどれだけ準備できるかだと私は考えている。そして多くのケースで準備には時間を要する。言い換えると、どれだけ準備時間を設けられるかでもある。もし準備という言葉がピンと来なければ、その業務の対象にどれだけ勉強時間をさけるかと言い換えてもよい。

もちろん業務そのものは受託開発であり、準委任契約であり、先方の事業やシステム開発のお手伝いをすれば報酬をいただける。しかし、それだけでは自分の会社をやっている意義が薄れてしまう。自社のビジネスをやる時間を削ってまで他社のお手伝いをするのであれば、そこから自社も得られるモノがないとモチベーションが大きく異なり、ひいては準備や勉強時間の差になって現れてくるというのが私の経験からの学びでもある。その結果、品質の低い成果物を提供することとなり、自社の信頼も失墜させてしまう。

理想的にはモチベーションの有無で成果物の品質を左右すべきではないというのは建前として理解できる。実際に私もそんなことを公言したりはしない。しかし、定性的にはそういったことが起きることを前提として契約や業務の建て付けに組み込むべきだとも考えている。結果的にその仕組みで品質が上がるのであれば誰も損はしない。

まとめ

会社を起業された方、とくに小さい会社ではなるべく早く、引き受けないお仕事の基準を作ることをお勧めする。

最近、私の知人で起業した方がいる。その方は上位の意思決定者がめちゃくちゃなことを指示して、現場が混乱したり反発したりしてうまくいかないというシステム開発の、間に挟まって双方の隔たりを調整するといった、中間管理職のようなお仕事をされている。その会社の社員ならともかく、起業してまでそんなお仕事しなくてよいのではないか、もっとよいお仕事が他にあると思いますよと、私は助言したことがある。

私のリストで言えば、権限委譲を受けられないお仕事は引き受けないと明文化している。しかし、その間をつなぐお仕事に価値がないかというと、評価されにくいが尊いお仕事だとすら私自身も考えている。知人の話しを聞いていて、その知人は立場の隔たりの間をつなぐことに自身の価値を感じて、起業前と似たようなお仕事をしているのかもしれないなとも思えた。

会社という法人の価値観を育てよう。

リファレンス