PHILOSOPHY(フラットで自律的な働き方を追及する)

なぜフラットで自律的な働き方を良しとするのか

新規事業や迅速なサービス構築という答えの見えにくいゴール、特に「顧客を救う」というアバウトに聞こえることを組織の目的とする場合は、 階層的な組織ではなく、フラットな組織で現場に意思決定を委譲し、自律的な組織にしたほうが、より顧客と密に連携が取れ、 迅速に貢献できるという経験に伴い良しと考えている。 階層型の組織だと、おそらく提案や相談の大半がマネージャーを経由したものになり、迅速性や柔軟さが失われやすくなる。

規模の大きいプロジェクトだったり、日々が定型的な仕事の場合は、この限りではなく、階層型の組織の方が適しているかもしれない。 「フラットで自律的な組織」は、単に我々の業務(新規事業や迅速なサービス構築)に適しており、良しとしている。 そのうえで、「働く人の幸せ」「顧客にとっての価値」「経営者の幸せ」の観点から採用している。

権限移譲と役割の定義

エンジニアという職業の特性を考えると、人が決めたことではなく、自分で関わった意思決定を遂行するほうが納得がいき、動機づけとなる。 そして、その意思決定が間違っていた場合に、再度チェックし、改善する機会が自分にあればなおよい。 大規模なプロジェクトでは、ツリー型の組織が有効かもしれない。が、新規事業において小さなチームで戦う場合は、 フラットな組織体制で顧客と直接調整でき、関係性もより近いものである必要がある方がやりやすい。

フラットで自律的な組織になるためには、階層を無くすだけではなく権限委譲が必要だ。 ホラクラシー(ブライアン・J・ロバートソン著)でも言われているが、組織は目的のために役割を定義する必要がある。 すべての役割には　目的、領域、責務を定めることができる。具体例を挙げてみる。

• EC管理バックエンドシステムの担当
• 目的＝顧客の生産性や業務の行いやすさをバックエンドシステムを通じて改善し、救う。
• 領域＝顧客のバックエンドシステム、周辺システム、周辺システムとのIF。
• 債務＝短期、中期、長期的に業務改善を行っていく。業務を改善し、時間を増やし、生産性を上げる。

人間と役割を別々のものとしてとらえること、そして仕事の責務を個人で持たなず、役割に持たせる。そして、役割に対して権限を与える。 これによって、業務に問題があった場合、その人間(人間性)を責めるのではなく、役割の定義を問題とする。役割の定義に問題があれば、役割を再設計する形をとることになる。 失敗の起因が個人の人格のせいにならないという点でも、働く人にとって安心できる仕組みかもしれない。 また、明示的な役割で権限を与えられているので、現場の担当者が権限をもって物事を進めることができる。

ひずみが出てきたら再定義

「フラットで自律的な組織」は、すぐ成功するというものでもない。うまくいかない部分は「ひずみ」として現れる。 具体的には、顧客から思わしくない反応があったり、現場の担当者が困惑したり、うまく進められなくなったり。 「ひずみ」は、お互いの役割と責務を明確にする良いチャンスと考え、役割を再定義して、より機能するように改善していく。

自律＝業務に集中できる環境、条件を自分で考える

インターネットがあれば、どこでも仕事ができる今日、自分の働く場所と働く時間帯は自分で決めた方が幸せではないだろうか。 自宅でパフォーマンスが出ない人は出社すればいいし、個々人の意志、ワークスタイルを尊重した方が、エンジニアのモチベーションが高くなり、速度や生産性に好影響をもたらす。自己裁量でパフォーマンスを最大化する。 間接工数や社内的な政治を必要としないフラットな環境にして、技術研鑽に注力できるようにする。 他にも、給与は４半期で申告制(2016年度から)に取り組もうと検討している。

自律＝技術の選択は現場の裁量で行う

技術の選択は、現場の裁量に任せる。結果、最新のものを選択しやすく、モチベーションにも好影響がある。 単に好きなものを使うというのではなく、我々の推奨する環境で実装した場合、費用とスピードと品質、運用の手間に関してメリットがあるように、しっかりと伝える。 例えば、弊社だとAzureのPaaSを活用したほうが、迅速な開発、納期、監視コストなどでメリットがあるように伝える。 AWSや仮想マシンを並べて使う場合のコストとは同じではなく安くなる。 顧客、運用とそのような信頼関係、一致したゴールを持てるようにする。

自律のデメリット

フラットで自律的な組織は、管理側の管理コスト低下、エンジニア側のモチベーション向上というように 単にお互い楽になり良いこと尽くしではなく、例えば自己責任は増える。 自由な環境で最高のパフォーマンスを出すには自分に対する厳しさ(モチベーションの自己管理)が必要になる。 自分で自分の技術指針、実装方法を持てない人間は、居心地が良く無いかもしれない。 自己裁量についていけず、やめる人が出るケースもある。

完全に個人任せではなく、状況確認して、より良くするためにメンター的な立場は必要と考えており、定期的に相談を聞く形にしている。 完全な自己管理は非常に難しい。

権限移譲の喜び

私の実体験をお話ししたい。第9期目くらいまで、組織をフラットにするまでは、全ての意思決定に私が関与していた。 が、それは働く人にとっても顧客にとっても真に幸せなことではなかった。 私が15もプロジェクトを兼任すれば、質は大きく落ちるし、何より私は常に何らかのプロジェクトで張り詰めた状態で余裕もなかった。 顧客を救うには程遠いパフォーマンスだった。 兼任を増やしていくうちに、私は私が前職であまり好きでなかった火消人(各プロジェクトの英雄的な役割)に近いような役割を持ってしまっていた。 私は大手SIerにありがちな火消人に対して、そもそも炎上させるなと常々思っており、炎上案件が出て特定の人が解決する組織構造に問題があると思っていた。 自分が嫌で辞めた組織に近いようなことをしてしまっていたわけだ。

プロジェクトはそもそもちゃんと設計すれば独断的な英雄は不要で、適切に少数精鋭にすれば、皆が必要不可欠なスターティングメンバーになる。 そしてメンバーに権限を委譲しないと各メンバーの成長や経験値を奪うことになる。 楽をして働きたいと思っている人には変に聞こえるかもしれないが、エンジニア(特に弊社の精鋭)には 一見どんなに不真面目に見えても、確固たる成長意欲がある。 私はそれを信じ切っていなかったことになり、大きく反省した。 我々のエンジニアは週２回の日中、サッカーにいそしんでいたり、カフェで落ち着いた時間を持っても、開発運用で問題無いように作り上げている。 9年間、あれほど難しかった権限委譲も行ってみると、移行期を経て非常に楽になれた。 私以上のパフォーマンスを発揮してくれているメンバーを見ると非常にうれしい気持ちになる。

過程として権限移譲だけではなく、役割の明記が必要だった。先述の通り、役割を定義し、役割に権限を委譲する。 誰にどのような役割を期待するか、明示して伝える必要があった。 「＊＊を作ってくれ」ではなく、「＊＊のお客さんを救うことをしてくれ、現在の救うという意味合いは＊＊＊の課題を解決することだ」という目的の依頼に変わった。 これによって、単に作るというスタンスではなく、顧客を救うという目的から作るという行為を考えてくれるようになった。 現在は、各プロジェクトの顔ないし主担当も、私以外のメンバーが務めている。 問題があった場合は、役割の意味か設計が間違っており、個人を責めなくていいようになった。

プロジェクトの成功時にはハイタッチして、打ち上げパーティを

私は打ち上げパーティが何より好きで、その為に仕事をしているといっても過言ではない。 ので、SIerでありがちな、最終的な局面で責任範囲の擦り付けや、そもそも参加したメンバーが打ち上げに参加したくないと思うようなプロジェクトは絶対に起きないように最善を尽くす。

失敗パターンから学び、繰り返さない

組織の問題は、失敗パターンから学び、繰り返さないようにするのが、経営者の務めと考えている。

経営者のデメリット

フラット志向で、隷属せずに仕事できる相手とチームを組むいうことは、 志向の異なる顧客の場合(階層的な傾向が強かったり、独裁的な組織)だとうまく組めないこともあり、仕事を失う機会も出てくる。 経営者は仕事を失うことを恐れる傾向が強い。 が、私の役割は企業の哲学を全うできるような仕事を作ることでもある。それには哲学を徹底し、お金のために哲学が折れてはいけない。 我々の哲学が認められなかった場合、競争優位とならなかった場合は、自然に存在が不要になり、淘汰される。 という悔いのない覚悟を持つようにしている。