見出し画像

エンジニア組織(持)論

どうも、ピザは好きだけどピザパは苦手なエンジニアIWAOです。

新規サービスを開発したいんだけど、「エンジニア採用がうまくいかない」、「どういう組織にすればよいか分からない」といった悩みは、長らく僕の耳に入ってきます。

そこで今回は、エンジニア組織の構築経験を踏まえ、組織目線、エンジニア目線の両軸で、僕が組織づくりでアドバイスしているポイントをご紹介したいと思います。

先に結論を言うと、組織に「共通の価値観」を醸成することかと思っています。下記の3つの目標を設定することで、エンジニア組織は、共通の価値観の醸成に成功すると思っています。

・開発に集中できる環境
・知人のエンジニアに推薦できる組織
・リーダーシップのあるチームづくり

前提としては、「なぜエンジニアを採用するのか明確になっていること」です。逆に、これらの目標達成が困難な組織は、無理せずに開発を外注したほうがお得かと思います。

最後に伏線は回収してますが、持論成分多めですのでお手柔らかにお願いします。ではいきましょう!

開発に集中できる環境

エンジニアはとりわけ学習を繰り返す職業です。それは時代やトレンドの流れが早く、常に新しい技術をキャッチアップするためです。ですから組織としては、仕事に集中できる環境を用意することになります。

たとえば、受験シーズンに遊び呆けていると学習を妨げますよね。他の受験生はその時間を勉強に投資してます。家族は、机や参考書を用意したり、夜食などの差し入れなど、勉強に集中できる環境を提供します。

同じように組織は開発に集中するための環境を用意します。それほどお金も時間もかからないですし、難しくないと思っています。具体的なポイントを以下に書いておきます。

雑務を減らす

仮に高単価なエンジニアが、雑務を延々としていたらどうでしょう。無駄なミーティング、議事録作成、アカウント管理、ウェブサイトやブログの更新、データ入力、ネットワーク機器保守などなどです。

大事な雑務だとしても、別チームなどを配置し依頼すれば事足ります。それにも関わらず、エンジニアが開発以外の雑務を行っている組織は、エンジニアの潜在的な不満が高いケースが多いです。

付加価値を増やす

他社の募集要項をみてみましょう。すると、エンジニアが効率よく仕事ができる環境づくりは、進化していることが分かります。フレックス制度は昔からありますが、最近はリモートワーク制度は当たり前になっています。

他にもリフレッシュ休暇、希望PC支給、サブディスプレイ支給、アーロンチェア支給、書籍購入、資格推進、週休3日制、ハッカソン合宿、勉強会など組織のカルチャーによって様々です。

いずれにしても、エンジニアが開発に集中するために何ができるかを考えている組織は、生産性が高く、またエンジニアが集まる組織になっている印象です。

ハードワークを理解する

また、エンジニアは製品の開発をするプレーヤーであり、かつプロジェクトをけん引するマネジメントの役割を担うことがあります。

プレイングマネージャーは非常にハードです。マーケットや顧客、チームやステークホルダーと向き合いながら、コストを最小限にしつつ、ミスをしないように開発しなくてはならないです。

これらを組織で働くメンバーに理解してもらうだけでも、組織の雰囲気は変わることは想像できると思います。組織は、エンジニアの業務を理解し、組織として学習・改善する「謙虚さ」が求められると考えています。

  • 組織に理解力・学習力があると働きやすい

  • 環境を見れば組織の謙虚さを判断可能

  • リモートワーク制度は適切な指標

知人のエンジニアに推薦できる組織

エンジニアは長らく人材不足と言われています。そのため、多くの組織ではエンジニア採用にリファラル採用制度を導入しています。結構な額のボーナスだったりしますが、それくらいエンジニア採用は難易度は高いです。

お金目的で知人を紹介する人もいるかもしれませんが、本質は組織を良くするために採用をしていますので、建設的なエンジニアは、製品だけでなく組織を良くしたいとも考えています。

従業員満足度

既に働いているメンバーは、組織の良いところも悪いところも知っています。内部の組織課題を把握しているメンバーが「うちの組織は最高」と、知人に言えるのであれば組織づくりは成功と言って良さそうです。

「あなたはこの商品を親しい友人や家族にどの程度すすめたいと思いますか?0~10点で点数を付けてください。」

顧客満足度調査

この質問は、マーケティングで使われる顧客満足度調査の有名な質問です。商品を組織に置き換え、従業員満足度の数値と理由を明確にできれば、組織の課題が見えてきます。

たとえば、1on1やワークショップなどで「知人を紹介できない理由は何か」をテーマに議論すると、製品の品質、開発プロセス、製品戦略など、エンジニアならではの専門的な視点からの指摘が集まります。

心理的安全性

とりわけ、心理的安全性の高い組織は、質の高いディスカッションができます。攻撃性がなく、他責にしない意見を整理すると、組織としてやるべき課題が明確になってきます。

そのときに大切なのは、組織は受け身にならないことかと思います。批判的な意見を恐れるあまり、「ただの不平不満だろ」とか「指摘は勝手に提案するべきだ」「指摘が上がってこないなら問題はない」みたいに、無視しないことでしょうか。

なぜなら、組織も人体と同じで、痛みが出てから病気に気づくのでは遅い場合があります。大切な身体で健康を維持したいなら、自発的にヘルスチェックをしたいですよね。

たとえば、経営陣は尊敬する人の指摘は聞き入れますが、赤の他人の指摘は無視するでしょう。それは対象を尊重しているかどうかの違いです。組織はメンバーをひとりの人間として尊重することが必要ですね。

  • 顧客満足度だけでなく従業員満足度も上げようとしていること

  • 心理的安全性の高い組織は組織課題を発見しやすい

  • 社員を尊重できる組織であれば無視しない

リーダーシップのあるチームづくり

エンジニアにとって、クオリティ(品質)の担保が最重要ミッションの一つです。エンジニアがつくった成果物は、直接ユーザの手元に届くので、組織としても品質はエンジニアに丸投げできないですよね。

ものづくりは「より良い製品を、満足できる価格で、希望する納期までに届けること」がミッションになるかと思いますが、組織は何を準備すればよいのでしょうか?

コミュニケーション

組織の成立条件は以下の3つと言われています。

共通の目的(ミッション)
伝達(コミュニケーション)
協同意欲(エンゲージメント)

チェスター・バーナード

組織は、ユーザとのコミュニケーションのために、マーケティング、顧客サポート、UI/UXなどの「伝達」機能を提供します。また、メンバーとのコミュニケーションのために、目標管理や評価面談などの仕組みも必要になってきますよね。

オープンなコミュニケーションとか、情報の透明性とか、多くの組織が実施しています。優れた組織は、情報の非対称性を解消するために、何ができるかを考えている印象です。

エンゲージメント

各メンバーが同じ目標を持って、協力し合うことが「協同意欲」です。チームワークですね。チームにおける関係性は「エンゲージメント」と表されます。そのチームの舵取り役がリーダーというのが、一般的な構造です。

組織としては、完璧なリーダーがいれば事足りると思いがちです。しかし、現実的に完璧なリーダーはいないので、メンバーのエンゲージメントを高めるためには、リーダーシップのスキルが必要になってきます。

リーダーシップとは、組織の使命を考え抜き、それを目に見える形で明確に確立することである。
リーダーとは目標を定め、優先順位を決め、基準を定め、それを維持する者である

ピーター・ドラッカー

理想的なチームとは、各々のメンバーがリーダーシップを持っていることかと思っています。過去にもリーダーシップのあるメンバーで構成されたチームは、働きやすく、クオリティの高いアウトプットになります。

リーダーたることの第二の要件は、リーダーシップを、地位や特権ではなく責任と見ることである。優れたリーダーは、常に厳しい。
ことがうまくいかないとき、そして何事もだいたいにおいてうまくいかないものだが、その失敗を人のせいにしない。

ピーター・ドラッカー

リーダーシップとは、シンプルに言えば責任感があり、人のせいにしないことです。そして、リーダーシップで最も重要な要素は信頼です。

リーダーに関する唯一の定義は、つき従う者がいるということである

ピーター・ドラッカー

信頼は人に慕われているかどうかで測ることができます。マネジメントの父はさすがですね。そもそも信頼できる組織がつくる製品は、安心して手に取ることができますよね。小売でもアパレルでも家電でもそうです。

つまり組織は、信頼できる仲間を集めることを目指すと良いと思っています。IQよりもEQを重視する採用が増えているのも納得ですね。

  • 経営陣やリーダーで組織の信頼性が測れる

  • 組織への信頼性が高ければ仕事への意欲は高まる

  • 組織への信頼性が高ければより良い製品を開発できる

まとめ

長くなりましたが、言いたいことは組織をひとりの人間と捉えると、組織にも人間的なふるまいをすることが求められると思っています。

今回挙げた「謙虚」「尊重」「信頼」の3つが行動指針の人は、魅力的で、できるビジネスマンが想像できます。

そして、これらの3つの行動指針は、Google「Team Geek」という2013年の本に書かれています。三本柱と呼ばれるソーシャルスキルです。組織うんぬんは歴史など、経験から学ぶことが多いですね。

謙虚(Humility) 
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。 

尊敬(Respect) 
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。 

信頼(Trust) 
メンバーは有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。

『Team Geek』p.15より

ギークなエンジニアにとっての行動指針かと思いますが、組織の各メンバーが同じように行動できれば、エンジニアにとって魅力的な組織になる、という仮設を検証してきました。

いかがでしたでしょうか?このnoteが、より良い製品づくりのお役に立てれば幸いです。ではまた!

この記事が気に入ったらサポートをしてみませんか?