そろそろ冬ですね。
こんにちは。夏には弱いが冬には強い、バックエンドエンジニアのまさくにです。
さて、「台東砂漠に我が名ありィ！ ア！ この俺様がァ！」と、ことさらに自分の役職について歌舞伎かのごとく見得を切るようなシーンはまだないのですが、僕はいまユニットリーダーとチームリーダーを兼任しております。いわゆる浅めの中間管理職ですね。
対外的にリーダーとして動くようなことはあまり多くはないのですが、人事に関わることとして、少し前に下記のようなインタビューを受けました。どうでもいいんですが、この記事、タイトルに悪意ないですか？
やりがいはない。毎日出社して偉いなって思っている。
あきと
ただ、やってきたこと、目指す場所に関してはさらりと流してしまったかもしれません。そこで今回は、ユニットリーダーになってそろそろ一年経ったということもあり、組織とメンバーに対してどのようなアクションを起こしてきたか、今後起こすべきと考えているかをしたためたいと思います。
同じような組織を構築するときの参考となれば幸いです。
目次
LIGの組織体制
さっきからユニットユニットと言っているのですが、ユニット何ぞというと、職能の集まりのことです。LIGはディレクター、デザイナー、フロントエンドエンジニア、バックエンドエンジニアなどの集合を「ユニット」と表現しています（ユニットは他にもあります）。
Webサイトを制作しようとすると、それらの職能が稼働することとなり、LIGは下記のような体制が敷かれています。
右下の白丸が一人ひとりのメンバーだと思ってください。メンバーは複数人のマネージャー、複数人の役員が管掌するチームという縦軸と、職能からなるユニットという横軸に属しています。各チーム、各ユニットにはリーダーが一人ずつ、いまはアサインされています。（リーダーが複数人の時代もありました）
チームは事業と売上を支える単位です。各チームには売上目標が設定され、プロジェクトを推進させることでそれを達成していきます。LIGでもっとも多い案件である「Webサイトを構築する」という観点でいうと、上記の4つの職能は必然的に集まることになるため、チームがうまくハマれば、こまわりの利く動きでスピーディに目標達成、課題解決が可能となります。
ユニットは技術と成長を支える単位です。チーム体制だけですと、個人が培った技術共有ができない、技術者としてのキャリアパスが不明確になる、職能間でのコミュニケーション不全、などの問題が発生しがちなので、それらを解決することを目的としてユニットは存在します。
つまり、LIGでは職能型とチーム型のいいとこ取りをするための体制が敷かれている、ということですね。これは僕が入社する以前から構築されていた体制で、今も原則的にこの方式が保たれています。
現状の体制で抱える課題
上述の体制で過ごすうちに、僕は課題を感じ始めていました。
当然なんですが企業は資金がないと存続できません。上述の組織体系でいうと、売上を稼ぐ体系がチームにあたります。まずこのチームが機能しなければ売上は稼げず、LIGは容赦なく即死することになります。このためチームリーダーは常に背水の陣でプレッシャーに耐えながら、売上を上げていくことが求められます。
ただ、その力がどうしても強すぎて、必然的にユニットの活動、コミュニケーションは後回しになっていました。バックエンドユニットとして話すのは、何かWordPressで困ったことがあっただとか、過去の案件で似たようなことはなかっただとか、そういう話を浅くするための関係性になっていて、ユニットが「何かに向かって進んでいる」という実感はありませんでした。
短期的にはチーム主体でぜん動することに問題はなく、そういうフェーズが絶対的に必要だと思います。しかし長期的に見たとき、ユニットの力をチームと同等に高めていかなければ、技術的に何も進歩もないことからサービスも硬直し、キャリアパスも考えられないため人が離れ、組織の弱体化は免れないと考えています。
要するに感じていたのは、ユニットが目論見通りに機能していない、という大問題でした。
ただ、この種の問題は、大小の違いこそあれ、どの会社でも発生しているのではないでしょうか。チームとユニットはそもそも存在意義が異なり、違うアプローチで会社を発展させていくことを目的としているので、大切なのはパワーバランスを保つことだと考えます。
下部組織の意義を確立するために
上記のような課題感から、現状の体制のまま売上と成長のバランスを保つために、僕はまず「ユニットのパワーをチームと同等に引き上げるべき」と考えました。そのために下記のような施策を皆の協力のもと進めました。改善が必要だと考えたトピックは大きく分けて三つ。ビジョンの共有、コミュニケーションの構築、体制の変更です。
ビジョンを言語化する
まずユニットのサブリーダーであった時期から動き、当時のリーダーと考え抜いたのがこれでした。
LIGには社名自体に「Life is Good」というビジョンが掲げられています。とてもキャッチーで、誰も忘れないインパクトあるビジョンなのですが、ユニットから見ると相当に遠いビジョンでした。そこで、バックエンドとしてのビジョン、達するべき景色を再定義することにしました。
まずバックエンドとしてのビジョンは「Life is Good」から逆算できなければなりません。「Life is Good」のためにLIGがあり、Web事業部があり、チーム、ユニットがあるからです。下位組織の総計が「Life is Good」であるべきです。そこで幾夜も考えて、出来上がったのが下記のビジョンでした。
「一億円の課題を解決できるチームにする」
金じゃねーか！ あれこれいって結局金じゃねーか！ と思われた方も多いでしょう。ちょっと待ってください。弁明します。当時のLIGは一億を超える見積もりを立てることはほぼありませんでした。それは案件規模の条件に左右はされるのですが、僕らが抱えられる技術的な難易度も億単位を見積もることができなかったためです。
ソフトウェア開発はよく建築に例えられますが、自分のスキルで作れる建築物はどのレベルか、想像してみたことはありますでしょうか。僕個人でいえば、たぶん、犬小屋は建てられますね。プレハブみたいなものも建てられるでしょう。一般家屋もたぶん問題ありません。
そこから先、たとえばベッドタウンにある大きめのお寺を建てるとか神社を建てるとかのレベルはどうでしょう。あのレベルの同等のソフトウェアですと、おそらくスタートアップのWebサービスとかでしょうか。ものにもよるけれど、まだたぶん頑張ればいける。
でも世の中にはもっと信じられないものが人の手で建てられています。レインボーブリッジやスカイツリー、サグラダ・ファミリア（未完）、パーム・ジュメイラ（島）、ルーブル美術館など。もちろん資金力がケタ違いですが、それらも人の手が作ったのは事実です。そのレベルと同等のソフトウェアというと、おそらく人類の発展に寄与する医療システム、もしくは兵器のシステムなどになるでしょうか。
僕は正直、それらを作れないでしょう。しかしそのようにして、自分が作れるものを金額換算したとき、自分にはいくらの価値があると自分は思っているのか、という思考実験はとても大切な感覚だと思っています。それらを考えたとき、僕らはエンジニアとして一億以上のサービスを恒常的に提供できるチームにしたい、と思いました。
もちろんただ一億円のモノを作るわけではありません。一億円の課題を解決するんです。そのためには商材が一億円の価値を持つクオリティであることはもちろんのこと、一億円をいただけるサービス、コミュニケーションを適切に提供できること、そもそも解決することで顧客にとって一億円のメリットを生み出す課題を発見することなどが含まれます。これがちゃんと、いつもできるチームにしたい。
そういう意味を込めて作成し、メンバーに共有しました。ビジョンは共有するだけではダメです。ことあるごとに共有して脳裏に焼き付けることももちろん、リーダーがそのビジョンに即して物事を決定しているという姿勢が大切なので、僕自身が常に心がけるようになりました。お前、選択がバラバラじゃねーかとなると、メンバーは敏感に感じ取り、信頼を失っていきます。
ビジョンに近づく戦略を考える
まずは今の組織体系で夢物語であるアベレージ億レベルの課題を動かせるようにする。そのビジョンに達しようと思うと、様々に足りないもの、自分たちにいま必要なものが見えてきました。その逆算のもと、いまのバックエンドは、設計力の向上、インフラ力の学習、実績の獲得を戦略の柱として置き、重点的に強化することにしました。
設計力の向上
それまでWordPressでのサイト構築がメインストリームであったこともあり、0->1での、システムの設計ができるメンバーが少ないことが課題の一つでした。これができるメンバーを増やさなければ、システムの要件定義、設計段階でメンバーが限定されるため、事業のボトルネックとなってしまい、スケールしません。全員が要件定義、データベース定義、クラス設計、インフラ設計、作業見積もりの考え方から、設計書のドキュメント作成までこなせる状態が望ましいです。少なくとも、自分で考えられ、適切な人員に説明できる能力を底上げしたいと考えています。
インフラ力の学習
これも事業の変化に対応するためというのもあるのですが、弊社ではインフラエンジニアやSREと呼べるようなメンバーが存在しません。それぞれのバックボーンから多くのことはできるのですが、一億円に届くためにはアプリケーションを乗せる土壌であるインフラの理解は不可欠であると考えました。PaaSやサーバーレスなどのアーキテクチャも含めて、ここでは「インフラ力」と表現してあります。それらを適切に取捨選択し、構築できる能力を高めていきたいと考えています。
実績の獲得
これまでの二つとは毛色が違うのですが、いま事業変化の中にあって、これまで従事したことがない作業が発生することが多くなってきました。そのときに過去の実績と照らし合わせてみて、「これはできる、これはできない」という判断ができること、「できること」の枠を増やしていくことで殻を破っていく必要があると考えました。また、実績がなければ営業活動にも影響が出ます。まずは着実に実績を蓄積し、自分たちの自信とすることが必要だと考えました。
リーダーの行動指針を明文化する
自分がリーダーとなってから、メンバーに対する自分の行動指針を明文化しました。
理由は二つあります。基本的に仕事のリーダーって前任者の業務を継続するものだと思うのですけれど、昨日までと同じことを漫然とおこなっていても現状の停滞感は変えられないだろうと思ったのが一つ。もう一つは、メンバーとのイーブンな関係性構築のためです。
「何かをするから何かを返してくれる」というものが人間関係のベースにあると思っています。それは会社と社員、リーダーとメンバーの関係性でも変わることではありません。よくある「こうすれば部下は動く」というような、秘孔をついて働かせるようなテクニックとは、同じことをおこなうにしても視点が「動かす」ところにあるため、僕は肌が合いませんでした。
「どうすればメンバーのバリューを最大化できるか（take）」がよく語られるのも大切、というかそれがリーダーの職務だとは思うのですが、それ以前に「リーダーや会社はメンバーに何をするのか（give）」を明確化すべきだと考えました。
メンバーは上司を選ぶ権利も変える権利も持つべきだと考えます。このため、現実があるからままならないことも多いかもしれないけれど、リーダーはこれを方針として、このために動いてきます、ということを文書化しました。いわゆるマニフェストですね。これが気に入らなければ、俺を切るか、辞めてくれ、と極論、そういうことになります。一方的ではないイーブンな関係とは、そういうことだと思っています。
その関係性実現のため、「ユニットリーダーからの約束」として、メンバーには1on1（1対1の面談）や評価面談のときに、下記を提示してあります。
- 必ず月に一度 1 on 1 を行います。
- 個人とチームの成長を誰よりも考え、最強のチーム作りに尽力します。
- メンバーの人間性、技術力を、依存することなく信頼します。
- メンバーが携わっている案件のアウトラインを把握し、相談に乗ります。
- 空疎な賛成よりも、意義ある反対を歓迎します。
- 楽観的で明朗、しかし厳格な評価を心がけます。
これもビジョン、戦略と同様に常に頭の中に置いてあり、自らの言動を決定するとき、振り返るときに有意義に働いています。「まずは自分から」という姿勢でいたかったのでリーダーの行動指針を初めに考えたのですが、ビジョンが決まったら、「メンバーの行動指針」を明文化するのも一般的でしょう。
個人目標と会社の成長ベクトルを一致させる
LIGでは個人目標を前期後期で立てて、その達成を評価の軸の一つとしているのですが、今までそれを決める段階でビジョンが語られなかったこともあって、その「個人目標の目的」が曖昧でした。
LIGはとても多様的な組織で、それ自体が素晴らしいバリューです。しかし、多様的な組織とは何をしても許容される組織のことではありません。それはただのカオスであり、組織だっている必要がありません。多様的な組織であっても、ビジョンを設けることによって、メンバーに対して常に強い磁場を発生させ、組織が大意ではベクトルを持つ必要があると考えています。
そのため個人目標は、それぞれのキャリアパス、得手不得手を加味しながらも、ビジョンに対するマイルストーンである必要があると考えました。つまり個人がやりたいことを達成するだけでは不十分で、それを達成することがイコール組織の成長につながることを目標に据えられるように設定することを心がけています。
前述の通り、目先の強化対象は、設計力、インフラ力、実績です。たとえば設計が得意なメンバーは、それを他メンバーへレクチャーすること、インフラに興味があるメンバーにはインフラの資格を取ることを提案すること、などの本人の意向を加味しながら会社の方向性に沿うようにバイアスをかけます。これによって、その目標を個人が達成したとき、自動的に組織が一つ歩を進められるようになります。
それから個人目標を個人だけで閉じることを止めようと思い、ユニットで公開することにしました。個人目標は当たり前なのですが、個人が達成すべきことになります。しかし「個人の達成」という枠組みでありながら、その実、仕組みづくりやメンバーへの共有など、一人で片付かない課題が多く出てきます。
このため、ユニットに紐づく目標であれば仲間内で公開し、必要があれば仲間のサポートで一人の目標を達成していく構造にしました。これはまだ結果は出ていませんが、エンジニアは公開文化があるので、おおむね良い影響を与えるだろうと考えています。
コミュニケーションの面積を増やす
当たり前に大事だって思われているコミュニケーションなのですが、そもそも僕がなぜコミュニケーションを大事だと思っているかは、下記のような5つのことを考えているからです。少し本流から離れてしまうので、折りたたみ要素にしました。（IEやEdgeではそのまま表示されているかと思いますが……）
コミュニケーションが大事だと思う5つの理由
業務の効率化
一人で業務が回せるのであれば、特に組織に入る理由はありません。しかし一億円のプロダクトを作るには、基本的に複数人がプロジェクトに携わる必要があるでしょう。12人月の仕事を半年で終わらせるためには、計算上2人必要になります（現実的には3人以上になると思います）。この場合、個人の得手不得手、状況によって分業が必要になります。これは個人の能力をお互いに知っていて、話し合いが円滑におこなわれている必要があります。
リスクのキャッチアップ
たとえば僕らの組織体系上、各自が行っているプロジェクトに関してはなかなか知ることができません。この状態ですと、基本的に人間は失敗を隠す生き物ですから、知ったときにはすでに致命傷ということがままあります。これを避けるために、適切な頻度、粒度での状況把握は欠かせません。これを把握することで、リソースの集中や交渉などのテコ入れをすることができ、チームとしてリスクヘッジをすることが可能になります。また、「結果的に組織に守られている」という安心感は、メンバーからの信頼感を得ていくためにも必要不可欠なことで、コミュニケーションを好循環させます。
チームでの解答の提出
人間は間違います。議論は意見の押し付け合いではなく、「もっとも確度の高そうな組織としての答え」を導き出すために必要になることです。このため「チームの総意を話し合った」ということが、その結論の正誤以前に大切になる場合が多いです。前述の「ユニットリーダーからの約束」に、「空疎な賛成よりも、意義ある反対を歓迎します。」が入っている理由がこれです。僕は余裕で物事を間違います。間違いだらけの人生なのです。あとフロントのこともわかりません。その部分において僕は弱いのだから、誰か強い人と話し合いたいです。このおこなわれるべき議論は、そもそも日常的なコミュニケーションで、メンバーの視点や認識の理解、働き方のスタンスが共有されていないと失敗しがちです。
報告、提案の円滑化
社会人として、報告や提案は当たり前のことなのですが、どういうときに報告すべきか、その粒度とタイミングは非常に重要になります。これは上長からすると、もちろんプロジェクトの状況把握、コストの確認、リスクヘッジ、リソース配置などの当面の課題に対する理由はあるのですが、将来的に権限を移譲できるかどうか、業務をスケールできるかどうか、という意味においても重要です。
昔は人に仕事を任せるのは苦手で自分が手一杯になってしまっていたのですが、最近ようやく人に仕事を任せることができるようになってきたと思います。そうしなければ業務が溢れてしまいます。
この「任せた」状態のとき、僕がメンバーに求めるのは、任された仕事を完遂させること、完遂させるまでの問題を排除すること、僕が必要ならそのタイミングで駆り出すこと、そして僕に適切な粒度で経過報告することです。報告と提案はメンバーの義務であると同時に権利でもあり、それが気軽にできる状態となるには、慣れと日頃から双方向のコミュニケーションが必要だと考えています。
選民意識の醸成
これは極めて悪い言い方をしています。
言葉を変えるとすると、「俺たちってサイキョー」を内側から感じ、組織への帰属意識、矜持を強め、成果を最大化することです。僕は優れたチームが熱狂的に成果を出し続けるために、無意識下だとしても「この俺たちってサイキョー」という認識が非常に重要だと考えています。
よく女子大生達が「ワタシたちって変わってるからねー」と笑っているのを街で見かけますが、海賊王のグループでもない限り、冷静に見ると他のグループと比べてみても、何ら変わっていないのではないでしょうか。ただ、このとき彼女達は自分のグループに「最強感」を感じているのだと思います。僕はこの一種の選民意識である「最強感」のあるチームを作りたいと思っています。
冷徹に冷酷に内省すると、個人主義と思われがちなLIGという組織において、もっとも成功しているのが実はこの部分だと思っています。「俺たちって変わっててサイキョー感」が良くも悪くもLIGは非常に強いです。これを心地よく感じる人、感じない人がいるでしょう。まぁ実際変わってると思うんですけれど、僕が感じているだけかもしれません。
お互いに認め合い、リスペクトし合えなければ、最強のチームはできません。このリスペクトを醸成するためには、それぞれの仕事、仕事へのスタンスが明らかになっている必要があり、そのために継続的なコミュニケーションが必要になります。
端的に言うと、「コミュニケーションは大事だから大事なんだ」でご理解いただけると思います。その大事なコミュニケーションを確保するため、コミュニケーションを時間×濃度の面積と捉え、それを広げる方法を考えました。
まず濃度を高めるにあたって、大小に関わらずメンバーの課題感をフォローアップするために1on1を月イチで設けました。ほぼ雑談に終わることも多いのですが、メンバーの課題感、現在の仕事、自分の状態をヒアリングするようにしています。
毎月実施していると、一ヶ月で同一人物でも心境やスタンスが変わってくるのが分かります。その変化を言語化してもらうこと、課題があれば一緒に検討すること、エスカレーションすることも大切な職務です。
次に炎上防止、課題共有のきっかけ、それから各自の業務を僕が理解する（≒評価の情報を仕入れる）ため、朝会をおこなうことにになりました。これは最初から朝会だったわけではなく、最初、プロジェクトの課題報告を月イチでおこない、それで足りなかったので、週イチでおこない、それでも足りなかったので、朝会をやってみようという流れで、結果的にコミュニケーションの時間を補っています。
ちなみにコミュニケーションは数（タイミング）が多い方が好印象をもたれやすい（ザイオンス効果）というものがあります。こちらも絶対的に必要なことなのですが、これは日常的に気をつけているというか、仲間とは日々バカ話をしているので、まぁいっか、と思っています。
勉強会のスタンスを変える
LIGには各ユニット、週に二時間、フリータイムという仕組み、カルチャーがありまして、この時間は何に使ってもよい、ということになっています。案件で書いたコードのレビューをしてもらうもよし、自分の考えた設計を見てもらうもよし、AWSのリソースに関する質問をするでもよし、自主的にあがった課題に対してユニットで時間を使うことを許されているということですね。
ただ、これがうまく回っていませんでした。エンジニアたるもの積極的、自発的であれ、というのはその通りなのですが、案件の忙しさからこの時間は後回しになることが多く、参加者二人、やることなし、みたいな状態になることも少なくありませんでした。
まず行ったことは一ヶ月の始めのフリータイムはプランニングの時間とし、この一ヶ月のフリータイムは何を行うか、をみんなで検討することにしました。あらかじめ予定が立っていれば、それに参加したいというメンバーがバックエンドに限らず、フロントエンドからも増え、リーダー不在でも進めることができるようになりました。
またこの習慣が根付いたころに、もっと体系立った知識を広げる必要があると考え、フリータイムを使って何かを作ろう、ということになりました。受託開発は前述の通り、顧客に開発要件を縛られます。ですが、普遍的なバックエンドとして必要な知識を会社は学んでもらう必要がありますし、それがビジョンの達成に近づけることだと考えました。
今は各グループに分かれ、何かを設計から作っている段階になります。これも吉と出るか凶と出るかはまだわかりませんが、刺激的なスパイスにはなると思います。
組織構造を変える
ここまでユニットリーダーとしての立場で語ってきましたが、冒頭で述べた通り、僕はチームリーダーでもあります。基本的にバックエンドはWebサイトを作るとき、最後のリリースのエンターキーを押す役割を持っていました。
しかし、当時、前工程の遅れがバックエンドにのしかかる上、そのときにならないとどんな設計のものがバックエンドに渡ってくるかわからない、それなのにバックエンド同士でサポートができない、バックエンドの能力が上がらず高度な設計ができない、といった問題が多発していました。
そこで会社の時流が変わったということが大きかったのですが、けっこう無理を言って、バックエンドだけのチームを作ってもらい、そのリーダーにもなりました。バックエンドユニット≒バックエンドチームという体制を作ることで、メンバー間の共有体制を強め、サポート体制とレベルを上げていく、ということができるようになりました。
ただ、前述の通り、チームは売上を追わなくてはなりません。バックエンドエンジニアなんて営業力がゴミみたいなもんなんで（超偏見）、ずっと赤字が続いておりましたが、先月やっと単月黒を達成することができました。ありがとうございます。
これは単価が高い上流工程ができるということ、実はデザインをのぞくエンジニアリングの工程をバックエンドのメンバーはできちゃうことが大きかったと思います。メンバーが凄い頼りになります。来月は赤の想定です。頑張りますが、あらかじめ謝っておきます。ごめんなさい。
最強のチームを目指して
上記までのことを実施し、成果のすべてはまだ分かりませんが、バックエンドの成長曲線は確実に上向きとなり、客観的なことだけで言えば、下記のような効果を得られるようになりました。
- いままでメンバーを選ぶ必要のあった業務を、全メンバーアサイン可能となった。
- フリータイム（勉強会）の参加率が向上した。
- リスクのある案件をメンバーがエスカレーションできるようになった。
- リソースの過密度を各メンバーが把握できるようになった。
- リーダー（自分）が細やかな評価コメントを書けるようになった。
……などです。
他にも主観的、潜在的な効能は出ているでしょうし、デメリットも多数発生しているのではないかと思います。ただ、まだまだやりたいことも打てる施策もいっぱいあります。評価を変えたいし、戦略的な採用をおこないたい、チーム≒ユニットの体制が正しいとは思っていませんし、メンバーが増えてきてチームを割るべきだと思っていますし、教育体制を整えたいですし、それから語弊を恐れず言えば、リーダーを交代できるようにしておきたいです。リーダーって大変ですね。
その上で大切だと思っていることは、これまでの歴史を否定しないことです。先人たちの様々な試行錯誤の結果に僕らは立っています。現時点の結果だけ見て、切り捨てることは簡単です。ですが、それは僕らの歩みを止めることにもなりかねません。未来の僕らが、今の僕らを見て否定するような奴らになっていたらと思うと足がすくみます。
先人たちの試行錯誤は体制や制度として残っています。それが現時点で良い悪いはありますが、ただ淡々と、変化を受け入れていくこと、そういうマインドを下地に改善を繰り返すことが大切だと考えます。最強の僕らがビジョンに向かって進んでいくために、みんなでよく考えて、できるだけ仲間を大切にできる方へ。そして、できるだけ楽しくなれる方へ。
そのようなことを考えた一年でしたし、引き続き考えていきたいと思います。
さて、長々とご精読ありがとうございました。この辺で、すみませんね、お約束のコンバージョンボタンを置かせてもらいます。LIGのバックエンドでは、仕組みづくりが大好きなプロジェクトマネージャー気質の人、テクニカルディレクター気質の人、バックエンドの人を求めています。もしご興味がありましたら、僕らと一緒に働いてもらえませんか。
それでは、台東砂漠に我が名ありィ！ ア！ この俺様がァ！
バックエンドエンジニアのまさくにでした。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
