採用に悩む零細ITサービス事業者の話

はじめに

恥ずかしながらなのですが、福岡で採用した人（あるいは正社員採用を見据えて業務委託した人）が続かなくて、これまでのところ数週間で「合わないですね...」でサヨナラになってしまっています。うちみたいな零細企業では、人を1人採用すると育成や各種手続きに随分な割合のリソースがとられますし、辞めたら辞めたで業務の調整に奔走しないといけない。せっかく採用したのにすぐにいなくなってしまうのは、ものすごく効率が悪いのです。それで、もっと当社のスタイルを事前に伝えた上でなるべくフィットする方に来ていただいたほうがよいということで、このような記事を書いています。

コタエルのOdoo事業

うちではOdooというベルギー発のオープンソースの統合業務システムの、導入および運用保守のサービスを提供しています。この事業は2013年に香港で始め、しばらくの間は日本国外のお客さまをサポートして日銭を稼いでいたのですが、日本にも徐々にお客さまが増えてきたこともあって2018年に福岡に会社を設立し、現在この2拠点を中心に活動しています。

Odooは旧来のERPシステムに比べてとてもスピーディに導入できるし、拡張性も高いし、コストも抑えられるしで、よいところがたくさんあります。オープンソースのERPシステムとしては、ここ数年世界でダントツの人気を誇ります。しかしながら、Odooは日本市場では徐々に認知度が高まってきてはいるものの、まだあまり知られていません。理由はいろいろありますが、Odoo社が日本市場向けの販売活動を積極的に行っていないことや、日本市場向けのローカリゼーション等のコミュニティ活動を行うプレイヤーがほとんどいない（現時点で、オープンソースのコミュニティ活動は実質当社でしか行っていない）ことが大きいと思います。

Odooは製品としては非常によくできていて、当社もお客さまのあらゆるニーズに対応するための引き出しを多数持っていますので、日本で使えないことは全くありません。僕は日本の中小企業が基幹システムの導入を検討するときは、まずOdooから試してみるとよいくらいに思っています。海外に目を向けると、SAPのような代表的なERPシステムからOdooへの載せ替えのケースも増えてきていると認識していますし、僕自身もそういうプロジェクトに携わったことがあります。製品としての将来性は高いと思うのですね。そしてここまで小さいながらも日本でOdooのマーケットが育ってきたのは、当社の活動によるところも大きいはずです。

Odoo人材の現状

なのですが、日本にはこのアプリケーションを熟知して使いこなせるコンサルタントやエンジニアがほとんどいないのが現状です。Odooのマーケットの可能性に比べると、随分と人材のプールが小さい。そんな中で採用するとなると、必然的にOdooの未経験者を採用して育成しなければなりません。

また、うちのOdoo導入手法は、ウォーターフォール的なアプローチが取られがちな基幹システム導入の世界において、かなりアジャイル寄りで、コンサルタントもそれなりに深くOdooの仕組みをコードレベルで理解した上で効率よくプロジェクトを遂行していくことが求められます。また、Odooのエコシステムをサポートするために行っているオープンソースコミュニティでの活動には英語でのコミュニケーション力も必要です。ですが、巷のいわゆるERPコンサルタントの多くはそういうスキルセットを持ち合わせていません。ですのでERPコンサルティングのバックグラウンドをもった人を採用したとしても、キャッチアップしなければならない部分はそれなりにあるのだろうなと思います。

僕としては、ざっくりとはじめの半年はコストばかりで、そこから徐々に成果を上げてもらってコストを回収していき、1年でトントンにもっていければ悪くないくらいの時間軸で捉えています。長ければ2～3年かかることもあるかもしれません。とにかく時間がかかる前提でとらえています。スキル的にフィットする人材が市場にいない中で採用するとなると、どうしてもそうなります。

一方で、うちに採用方面でのブランド力はほとんどありません。単なるイチ零細企業なわけです。Odooが伸びてきていることもあり、お客さまからの引合は多数いただくのですが、採用方面は現状は残念ながらさっぱりです。そういうことも踏まえて、うちで採用する人には条件面で恥ずかしくないものは提示します。

僕らが大切にしているもの

これまでのところ、何かしら判断に迷うような状況で何を大切にしてきたかを振り返ると、次のようなものに落ち着きます。

• 価値を生むこと
• フェアであること
• オープンであること

これまで明文化できていたわけではないのですが、普段の行動やこうありたいとイメージしている姿の根底に何があるのかを突き詰めると、こういうことなのだろうと思いました。

1. 価値を生むこと

僕はチームメンバーに、やっていることが「価値を生んでいるのか？」という問いかけをよくします。

何をもって価値があると判断できるのか。僕は価値は原則マーケットに軸足をおいて判断するものと考えています。ここでいうマーケットには大きく3つあります。「サービスを購入してくださるお客さま」、「うちのチーム」、「うちの事業が依って立つエコシステム」です。それぞれ課題をかかえており、それら課題を解決することに価値があると考えています。

2. フェアであること

ずるいことはしません。お客さまに対しても、チームメンバーに対しても。何がフェアであるのかの解釈は人それぞれ違うことがあるかもしれません。そういうときは事実を洗い出して、社会通念に照らし合わせて、どうすべきかを考えます。僕らがフェアでない条件を押し付けられることがあったら、徹底的に対抗します。フェアであることができない組織は、どこかで無理がきて、継続的に価値を生むことができなくなると思います。

3. オープンであること

個人情報等センシティブなものを除き、チーム内では原則すべての情報を共有します。オープンソースコミュニティでの活動にも積極的に関与し、オープンソースを利用するだけでなく、コミュニティに還元していきます。オープンであることは「フェアであること」を担保します。言い換えると、オープンでないところにはフェアではない何かが潜んでいると考えます。

誤解を恐れずに言うと、「自由」「多様性」「創造的」「楽しい」みたいなものを一義的に大切にしているわけではないです。多分うちは他の大多数の会社に比べると大分自由だし多様性があります。課題の解決には複雑なパズルを解くような面白さがあって、その作業自体創造的とも言えると思います。（楽しいかは人次第なので、敢えて言いません。僕は楽しいけど。）でもこれらは、上記のようなことを愚直に求めてやっていると副次的に現れてくることに過ぎません。

価値を生むための行動

「価値を生む」という一見漠然とした命題を与えられたとき、始めからそれを実行できる人は多くありません。ですが、これは次のようなサイクルを習慣づけることで実行できるようになるものと考えています。

1. 何をすれば価値があるのかを把握する（マーケットの課題を見つける）
2. 具体的な目標を定める（アウトプットを定義する）
3. 目標に到達するための手順を洗い出す
4. 手順を実行してみる
5. 必要に応じて３、２、１に立ち返る

基本的なことのように見えますが、始めはなかなかうまくいきません。まず「何に価値があるのか？」への認識がいきなり一致することはまれです。

チームとして何に価値を見出すのかは、前述のとおり3つのマーケットを軸に判断します。ですので、マーケットを理解することが不可欠です。それをせずに価値が生めることはありえません。

新しいメンバーへのアプローチとして、僕からマーケットの課題をきれいにまとめて説明するようなことはしません（時間も限られているので）。目標設定をしたり作業手順を指示したりすることも、なるべくしません。自分で仮説設定して、上記のサイクルを回していくよう伝えます。

実際にはプロジェクトの中で作成したチケットを割り振ったりしますので、１と２は飛ばして３からやってもらうことも多いのですが、あくまで１からできるようになることを目指してもらいます。１ができていないと、結局チームとして動く上で管理コストやコミュニケーションコストが余計にかかってしまうからです。

ちなみに僕とメンバーの間に価値判断のズレがあり、メンバーが自分の判断の正当性を主張する場合、僕はとりあえず話を聞くのですが、大抵の場合、自分の意見を押し通すことになってしまいます。経営からの観点の有無であったり、誰が結果責任を負うのかを考えると、必然的にそうなってしまうのですね。

アウトプットのスピード重視

上記のサイクル、価値への認識が一致していなかったり、新メンバーに何ができるのかよくわからない初期の頃ほど高速に回す必要があります。

まずはどんなに雑な形であれ具体的なアウトプットを早いタイミングで出すことが肝要です。具体的なモノがでてくると、あるべき姿に照らし合わせてどこにズレがあるのかが明確に見えるようになります。ズレが見えさえすれば、そこを埋めていく作業をしていけばよいのです。その過程で価値のすり合わせをし、課題を洗い出して、次のサイクルに進んでいけます。

いくら新メンバーがOdooの勉強を頑張っていても、アウトプットが何も出てこなければ、その人の実績はゼロのままなのです。実績がゼロの人に対して、今何ができて、これからどんな成長曲線を描くのかを理解するのは不可能です。

僕の観察範囲では、多くの人は放っておいたらこれと逆のアプローチをとります。明確なアウトプットのイメージを持たずにOdooの機能を勉強するところから始めてしまいます。結局Odooの勉強は不可欠ではあるのですが、具体的な着地点のイメージをもった上での勉強とそうでないものには、効果に天と地ほどの差が出ます。

アウトプットを出すと何が起こるか

具体的なアウトプットが出てくると、僕や既存メンバーからはいろんな質問が投げかけられます。

• 「これでやりたいことは何？」
• 「これができることにどういう価値がある？」
• 「どうしてそれに価値があると思う？」
• 「（別のアプローチでなく）このアプローチをとったのはなぜ？」
• 「これでレビュワーはテストケースが理解できるの？」
• 「どうしてこれだけ時間がかかった？」
• 「これをお客さんに課金するのはフェアなの？」
• 「次はどうすれば改善できる？」

などなど。

「なぜ」を掘り下げていくことに慣れている人にとっては何でもないことだと思いますが、そうでない人にとっては結構不快に思うところかも知れません。別に叱られているわけでもないけれど、ダメ出しされていると思ってしまう。詰められていると思ってしまう。日本的な「空気」を重視する職場環境しか経験していない人は、おそらくそう感じやすいのだろうと思います。

正直、ここからうちになじめないという結論に達して辞めてしまうケースは多いです。

そうなるととても残念ではあるのですが、それはそれで仕方がないことだと思っています。コンサルタントとしてお客さまにサービス提供する仕事である以上、自らのアウトプットに批判的な視点を持つことは必要不可欠で、内部でのレビューに耐えられないようであれば、適性がないので続けない方がよいです。

エンジニア採用におけるギャップ

Odooのサービスを効率よく提供するには、ソフトウェアエンジニアの素養やスキルが必要な場面が多々あります。なのでエンジニアの採用を試みたりするわけですが、これがエンジニアであるがゆえにうまくいかないことも多いように思います。

エンジニアであるがゆえにというのは語弊があるのかもしれません。ですが、エンジニアの志向や傾向として（当然人や役割により違いますが）、

• 開発が好き
• 顧客とはあまり直接会話しない
• チームでワイワイしながらプロダクトを作りたい

みたいなものはありがちかと思います。それがうちでは、

• 価値を生むのに開発ありきではない
• 顧客とよく会話する（認識合わせのコミュニケーション多い）
• チームはサポートするけれども自走を求められる

という具合です。要はうちではコンサルタント的な仕事の比重が大きくなります。なのでエンジニアとしてのアイデンティティが強い人ほど求められることとのギャップを感じてしまいがちなのだろうと思います。個人的には、適性がありさえすればエンジニアがコンサルタント的な役割をカバーする方が、その逆よりも最終的に求められるスキルセットに到達するのは容易な気がしますが、仕事への向き合い方を変えるのは結構難しいのだろうなと思います。

成果を求められるプレッシャー

もう一つ、新メンバーにプレッシャーを感じさせる大きな壁が、「あなたがどれだけ売上やチーム資産の蓄積に貢献できるのか？」の問いかけです。

現状うちの売上の大半はタイムアンドマテリアルでのコンサルティングサービスなのですが、このやり方だと、否応なしに誰がどれだけ売上貢献しているかが明確にわかります。なので、「あなたのコストはこれだけなので、売上貢献の目安としてはこのくらいですね」といった期待値と、実績の比較がしやすい仕組みになっています。要は、よくも悪くもごまかしがきかないんですね。

前述のとおり、始めから自分のコストをカバーしてもらうことは期待しておらず、時間をかけて成果が出せるようになってもらえればいいのですが、どのような成長曲線を描くのかの説明は求めます。そこで思うように成果が伸びていなければプレッシャーになりますよね。これも当たり前の人にとっては当たり前のことなのですが、過去に成果をシビアに求められる環境（達成困難なノルマを課されるといったことではなく、成果が明確に数値として出されるという意味で）に身を置いたことがない人にとってはつらく感じやすいポイントかと思います。

どういう人だとうまくいくか

これを言うと拍子抜けな感じもしますが、「ずるくなく、気配りができ、継続ができる人」だとうまくいく可能性が高いと思います。必ずしもどんなスキルをもっているというレベルの話ではないのですね。

ずるい人は論外で、うちとの相性は最悪です。「ずるい」だと語感が悪いですが、もうすこしマイルドにすると「ごまかす」になるかと思います。うちは「フェアであること」、「オープンであること」を大切にしているので、ごまかす人は馴染めません。この「ごまかす」というのは、あまり自己認識ができないもので、本当はモラル的にダメなのだけれども咎められないからやってしまっていて、それが習慣になっているというものは結構あると思います。タバコのポイ捨てとか。そういうごまかしを違和感なくやる人は、仕事の能力に関わらず、いてほしくないです。

「気配りができる」は、「周りのニーズを汲み取って適切な対処がとれる」と言い換えることもできます。これは仕事でなくとも、普段の生活の中で訓練できることでもあります。路上で倒れている人がいたら声かけるとかですね。周りのニーズを汲み取るという習慣は、仕事の上でも、何に価値があるのかを判断する土壌を作るのに非常に役立ちます。うちは特にマーケットの課題を起点に行動に落とし込むことを大切にしています。気配りができるからといって成果に直結する動きがとれるとは限りませんが、少なくとも何に価値があるのかのすり合わせが、そうでないケースに比べてスムースにできるでしょう。

継続ができるのも大切です。単純作業を繰り返すような継続ではなく、価値あるアウトプットが出せるまで軌道修正等含めて作業を積み重ねていくという意味での継続です。うちでの仕事では、1つの価値ある成果を出すのに、多くのハードルをクリアすることが求められます。特に勘所がつかめていない初期の段階では、作業の差し戻しを何度も求められることもあるでしょう。それでもフィードバックをポジティブに捉えて完了まで持っていく気骨であったり素直さのようなものは必要です。「できた」と思って提出したものが拒否されることに抵抗を感じて反発する人やモチベーションをそがれる人は結構いて（これまで経験を積んできたと自負している人ほどその傾向があると思います）、それだとチームとしてパフォーマンスが上がらないし、無駄に疲弊してしまうんですよね。

現在まだチームがとても小さい中で、「上記のポイントを満たしているけれども未経験の人」と、例えば「相当技術力が高いけれども気配りできない経験者」のどちらかを選ぶ状況になったら、僕は前者を選びます。

コタエルのよいところ

ここまでこの記事を読んでいる人には「うーん、難しそう」と思われそうですが、壁にぶつかりながらも価値を生むための行動サイクルを愚直に回していくことができる人にはよい職場ではないかと思うんですよね。適性がある人が続けていれば成果は必ずついてきますし、一旦自走できるところまで至った人には割と自由に仕事してもらってます。

• そこそこよい報酬（25歳で550万円/年など。人によります。）
• 残業なし
• 完全フレックス
• リモートOK（条件あり。）
• 英会話レッスン（英語はよく使います。）

現状わいわい楽しく仕事をするような雰囲気の職場ではない（いつかそうなるといいなあ）のですが、いろんな意味でごまかさない環境なので、ここで成果を上げることができれば将来にわたって通用するビジネススキルは身につくと思います。

あと、ここでは小さいながらも事業を作っていくことに、直接的に関わることができます。経験を通じて経営者的視点を持つこともできますので、将来自分でも起業してみたい人にとっては面白い環境なのではないかと思います。