自分が前に立つしかない

やはり、同じ失敗を３度もしたのは非常に良くないと考えている。

１度目は偶然かもしれないが、２度目があった時点で再現性のある失敗であり、３度目の失敗は、その反省を生かせていないか、地震や災害のような物で、数年周期で必ず発生するものと考えなければならない。４度目の発生を防ぐために。あるいは発生しても、そのダメージを抑えるために、抜本的に、自らの性格・あるいは生き方・あるいは環境。何らかの構造の変革が必要だと考なければならない。

私は運がいい。なんせまだ元気に生きてるし。万全、とまでは言わない物の、85%くらいまで回復してきた。

だからこそ、次こそは天に見放されるかもしれないと想定しなければならない。今まで頼ってきた道しるべとは違う道を模索して、生きていく必要があると考える。

その中で、一つ考えていることがある。

もう「自分が前に立つしかない」という事。

世の中には、経営センス・技術力・プレゼンス・人脈・学歴に優れている人がたくさん居る。 どんなジャンルのどんな分野でも、私より優れた才能を持つ人は、文字通り五万といる。

だから、その「私より優れた才能を持つ人」にリーダーを任せ、自分のなすべきことを進める事こそが、 最も賢く・正しい意思決定を組織にもたらしてくれると考えていた。

実際に、新卒で入ったリクルートと言う会社は、まさに「優れた業績を収めた者にリーダーをさせよ」という文化であった。それでリクルートという企業は非常に上手く回っていたんだと思う。人材市場での採用競争が激化し「優れた業績を収めた者」をリーダーに据える事が出来なかった組織から腐敗し、解体されていくのは何度も見た光景だったからだ。

しかし一方で、「優れた業績を収めた者にリーダーをさせたからダメになった」例もたくさん見てきた。ビジネスにおいて「優れた業績」は結果論でしか無く、運の要素も非常に強い。再現性のない成功はそのまま「生存者バイアス」となり、正しく現状が再認識されないまま、部下を疲弊させ組織が崩壊してきた例もまた、たくさん見て来た。

先駆者であったり、上司や先輩、組織のリーダーの言う事が正しいとは限らない。

もちろん、正しい時の方が圧倒的に多い。なぜなら、そこに至るまでに様々な経験や知識が蓄積されているため、より合理的な判断が下せる確率が高いのは間違いないだろう。しかし、人間である以上、所詮は天然のタンパク質でできたディープラーニングに過ぎない。学習していない物は上手く生成できないし、過学習の結果、丁度いい塩梅を超えた物を生成してくることだってある。

私の1/3生（半生と言うには早すぎる）を振り返ると、心身を壊すような失敗を三度した。

その３回はいずれも全部、「自分はAだと思うが、どうしてもBだと言うのならそっちを信じたい」と言う場面で起こってきた。 「リーダーを立てる」とはそう言う事であり、組織とはそう言う物なのだと今でも信じてるし、間違っていないと思う。

「思考停止しているだけではないか」と言う声も聞こえてくるかもしれない。その通りである。組織を前に進めるために思考停止したのである。船頭多くして船山に登る、船を進めるために、思考を止めたのである。集団の優先度を上げ、自己の優先度を下げたのである。そして、その意思決定と行動をしたのは、他ならぬ自分自身であり、その失敗の原因と責任は全て自分にある。

私は、自分の意思を曲げ過ぎた。友人・家族・組織。あらゆる人間関係で、自分の意思を曲げてきた結果が心身の崩壊であり、その反動が「1年間、誰とも関わらなくて平気」という異常な状態を生み出したのだと考える。これは、私個人の性格の問題であり、「それがbussorenre君の良さである」と評価してくれる人も居れば、「それが君の弱みでもあり付け入る隙を与えやすい」と注意する人も居る。

元々持つパーソナリティと、ポジションが付与するパーソナリティを合成することで、きっと、丁度いい塩梅になるのではないか。 自分の希望・わがまま・身勝手。そう言ったものをどんどん主張して、自分の意思を曲げ過ぎない事。かつ、集団のために意思を曲げ過ぎてしまう性格を生かす。

と考えた時に、「自分が前に立つしかない」という結論に至った。

「前に立つ」にも色々と方法はある。一応多分きっと私は分類上エンジニアなので、エンジニアリーダーとして、プロフェッショナルリーダー、テックリード、はたまたエンジニアリングマネージャーなど、前に立つ方法は色々ある。しかし、極論を突き詰めていくと、やはり事業を起こしてその代表をするところに集約されていくと思っている。

最も、優れた起業家なんて物は、「会社作りたい」と思った時点でもうすでに会社を作り何らかの事業を行っているのだろうが、私はそうではない。会社経営が向いているなんて思った事は一度もない。しかし、世の中には「雇われ社長」という言葉があるのだから、なんらかの後天的な学習によって、そこを成す事は出来るかもしれない。起業は若いうちにやれと言うが、EXITは50代でやれと言う声も最近よく聞くし。幸い、私の知人には起業家が結構な数居るので、ノウハウは手に入りやすい。

４度目の失敗になるかもしれない。

しかし、どうせ後は死ぬまで生きるだけなので、やってみて損は無い気もする。

前に立つときに一番大事なのは、後ろから刺されない事。

後ろから刺される不安を持ったまま前に立つことはできない。なので、次は、後ろからしっかりヒールしてくれるアコライト（ネタが古い）を探すことから始めていく。

リクルート退職した

こんにちは。はじめまして。そうでない方は大変お世話になっております。 @bussorenre です。

表題の通り、リクルートを退職しました。 2015年に新卒で入社して6年半近く居たことになります。

大企業を辞めたとなると、「なにか悪い理由があるんじゃないだろうか？」と邪推されがちですが、残念ながらそのようなご期待に沿う事は出来ません。むしろ、リクルートのOBOG、あるいはソフトウェアエンジニアを中心としたIT界隈の人達からすれば「なんで６年半も長いこと居たの？」という事が気になるのかなと思います。自分の反省と今後の展望を世界に垂れ流させていただければなと思います。

なぜ6年半も居たのか？（あるいは、6年半で辞めたのか）

まず、リクルートには「フロンティア」という退職金制度があり、これは一定期間の勤続年数を超えて退職すると、退職金が跳ね上がるという制度です。世間一般で言う早期退職制度のような物です。大体みんな退職金ボーナスを受け取るタイミングで退職します。（定年退職者が居ないと言われる理由の最も大きな理由がこのフロンティア制度なのではないかなと自分は考えています）

この制度は雇用側の視点に立つと、お金はかかるけど人材の流動性を確保し若返りを達成しつつ、かつ退職タイミングを見極めやすいという点で優れています。日本では正社員を解雇する事は非常に難しく、多くの企業が若返りに失敗する中、リクルートはかなり若い人を中心に回っています。

しかし、個人の視点に立つと、6年半というのは非常に長い期間でもあります。特に新卒でリクルートに入社する人は、将来的に起業を目指している方が非常に多く、「実践的な経験を身につける訓練所」として認識している人が強いです。そんな人達にとって6年半は非常に長く、ほとんど３年以内に辞めてしまう会社でもあります。

しかし、それが悪い事かと言われるとそうでもないと思っており、辞めていく同期を見送る際も「自分のやりたい道が明確になったのか。すげーな。頑張れよ」という気持ちで過ごしてきました。

同じグループ企業だけど、全然違う会社を３社経験したと思ってる

長い間いることになった理由は「自分が独立したり転職してまでやりたい事が明確ではなかったこと」もあるのですが、「新規事業開発室」「RMP」「Quipper」という全く毛色の異なる組織に属していたことも関係しています。

大企業ならあるあるな話ですが、事業部が異なれば当然そこにいる人も文化も変わるわけで、部署異動は、別の会社への転職と同じくらいインパクトのある環境変化でした。同じ「リクルート」というグループ企業ですが「新規事業開発室」「RMP」「Quipper」では大きく異なりました。最後のチームは某動画配信サービスからの転職者が多く、実質４社分の文化を経験したことになります。（本当か？

特に RMP のエンジニア組織は私にとっては非常に居心地がよく、同時にソフトウェアエンジニアとしても大きく成長させていただいた組織であります。上司・同僚の皆々様には感謝をいくら述べても足りないと思っております。

新規事業開発部から、RMPのチームへの異動を推薦をしてくださった竹迫先生（セキュリティ&プログラミングキャンプ 2009 の講師を担当してくださった恩師でもあり、社内のエンジニア組織のリーダーとしても私を育ててくださった恩師でもあります）。

前部署での失敗を引きずっていた私に「bussorenreくんには休憩と、自信をとり戻す時間が必要だ」と長い目で見てマネージャーを務めてくださった @rtsutakiさん。

「bussorenreくんは絶対Scalaのセンスがある。書けばわかる」とScalaチームに推薦してくださった、@ainoyaさん、@ma2k8さん、@mpon さん。

Scala 始めたての頃、非常に多くの私のコードをレビューしていただいた @y-yu さん

チームリーダー・スクラムマスターに推薦してくださった、マネージャーの皆様。

全然未熟なリーダーでしたが、一緒にチーム開発を走っていただいた、案件チームの皆様。バックエンド開発を中心としたScalaチームの皆様

最後、退職前のうだうだにマネージャーとして付き合ってくださった @suikwasha さん

あまり書くとエンジニアが全て列挙されてしまうので、よろしくないと思って端折ってしまって申し訳ありません（最初は全員列挙してたんですが、いやそれはそれでアカンなと重いバッサリ削除しました…）。ですが、開発チームの皆様には本当にお世話になりました。

コロナ渦で直接ご挨拶できなかったので、この場を借りて大きな感謝を申し上げます。

控えめに言って最高のエンジニア組織だったと思ってます。

なぜそんな最高のエンジニア組織を辞めるのか？

少なくとも私にとってはオアシスのような環境で幸せに暮らしてきたわけですが、この環境が成り立つためには大きく２つの条件が必要だと考えています。

• 事業が儲かっていること（成長していること）
• 高度に自己組織化されたチームであること

まず、金を稼ぐことは必須です。どんなに良いエンジニアを良い給料で雇用しようと思っても、事業が成功していなければ話になりません。私が所属していたチームはまさに成長の中にある事業でしたので、エンジニアに限らず、企画・コンテンツ製作・営業とあらゆる人材リソースに投資されていました。

一方、成長性がないと判断された事業は潔く撤退します。その判断の速さはリクルートの素晴らしいところなのですが、そうなったら後は滅びるだけです。そこで培った文化もプロダクトも除却を待つだけです。これはあまりにも寂しいし辛い。自分達で作ってきたサービスに自ら鉄槌を下す経験を何度かしてきました。

また、高度に自己組織化されたチームでないと、そこはただの温泉になってしまいます。つまり、自ら意見を持ち目標を立て、プロダクトの成長を技術視点で提案し実行できないと内製エンジニアに価値はなく、言われたことを作るだけのエンジニアになってしまうと、「じゃぁ外注のほうがコスト安いしオフショアでもやる？」となってしまいがちです。

「高度に自己組織化されたチームが事業の成長に貢献する」という状態になって初めて心理的安全性を生むチームとして成立します。

「自分は先輩や上司が築き上げてきた組織に乗っかっただけで、もしそのような環境がなくなれば死を待つだけだったのではないか？」という疑問が２年前くらいから生じていました。そうなったら転職ガチャを引けば良いのかもしれませんが、そこはエンジニアらしく、0から作ってみたくなったというのが、第一の退職理由です。

２つ目の理由として、上記の疑問を持ち始めたのと同時期くらいに、同期がだいたい辞めて居なくなりました。前節で述べたとおり、リクルートはやりたいことが見つかった奴から退職する会社ですので、「起業して会社が当たったら焼肉おごってくれ」くらいのノリで見送っていたのですが、いざ自分ひとりになると、さて、どうしたものか。と思い悩むようになりました。30歳になった今年、「もう30歳か。人生意外と短いかもしれないな」と感じ、「どうせ短いなら盛大にチャレンジしてから死のう」と思って会社を退職しました。

ソフトウェアエンジニアとしての成長ももちろんでしたが、ビジネス的な観点での成長。特に新規事業開発室に２年近く居たことは、かなり多くの視点を得て勉強になったと思っています。当時は事業リーダー達の思考プロセスが全然理解できず苦しんでいたのですが、今ではそれがわかると言うか、「あ～昔先輩たちが言ってたことは、こういう事だったのか！」と、毎日のように再発見を繰り返しています。

何人もの同期がベンチャー企業の経営層として奮戦しており、先を行く同期という存在ほど得難いものはなく、そのような様々な出会いがリクルート時代にあった事は感謝してもしきれないと思います。

退職して何をするのか？

ジザイエ という会社をやっています。今の所VPoE というポジションを担っていて、CTOは現在空席です。将来的に自分がCTOを名乗るかもしれませんし、別のメンバーが担当するかもしれませんし、外部から招致するかもしれません。完全に未定です。が、今現在は、ソフトウェアエンジニアのチーム全体のリーダーという立ち位置になります。

jizaie.co.jp

会社自体の説明がまだ難しく、多くのことを語るための準備を目下進めている、というステータスになります。（でも、ベンチャー企業が半年後に事業転換してることなんて当たり前だし、昨日までやってきたことと違うことを始めることはわりと普通だから、とりあえず今の状態を伝えたら良い気もする…？？？　ZENNA というサービスを運営してまして、それについてはぜひ 事業成長を加速させる開発業務に携わるフロントエンジニア募集！ - 株式会社ジザイエのWebエンジニアの採用 - Wantedly などをぜひご覧ください。エンジニア募集しております）

また、それはそれとして「エンジニアの育成」の活動にも再び注力していきます。これは僕の個人事業になります。 色々な方に手を差し伸べていただきながらここまで来れたので、少しでも誰かの力になることができれば、という思いでさせて頂いております。

具体的には Tech Train さんに、メンターとして登録しています。 https://techbowl.co.jp/techtrain/mentors/39

幅広く質問を受け付けておりますので、お気軽にご利用ください。

おわりに

ベンチャー企業の殆どが失敗すると言われている中、周囲では起業チャレンジャーが多く、当初はそのモチベーションの理由がわかりませんでした。成功している人もいれば失敗している人もいる。失敗しても何度も挑戦し続けるメンタリティは自分には真似出来ないと思ってました。しかし、今ではその理由がわかります。

結局、自分がやりたいことをやるには自分で環境を作るしかないのです。自らの生存に適した環境を生み出してきたからこそ、挑戦者は生存者なのであり成功者になり得るのだなと。 生きるためにやるのです。人生は短いのです。元気に生きていればこそ出来ることです。

失敗する気は毛頭ないけど、失敗したら笑ってケーススタディの一つにしてください。成功したらみんなで焼き肉だ！！！！

coordinate compression - 座標圧縮

アルゴリズムの概要

任意の配列の大きさの順序を保ったまま、その値を小さくする（圧縮する）

例えば、以下ののような配列があったとすると、座標圧縮によって のように値が小さくなる。

以下の手順で実現できる。

1. A を コピーして別のコンテナ（A'）に移し替える。 （a_dash = a でも、copy でもどちらでもよいと思う。）
2. A' を昇順にソートし、重複を排除する。（重複を排除するには、erase とunieque を組み合わせることで実現できる）
3. Aの各要素A[i] に対して、
   1. A[i] が A'のどの位置に存在するか、イテレーターを習得する。（ここでは二分探索（O(logN)）の lower_bond を使う）
   2. 取得したイテレーターを元に、添え字番号を取得する。（C++だと、itr - a.begin(); みたいな操作で添え字番号が取得できる）
   3. A[i] に 添え字番号を代入する

サンプル実装

#include <bits/stdc++.h>
#include <algorithm>

using namespace std;

#define rep(i, n) for (int i = 0; i < (n); i++)
#define long long ll
#define all(a) (a).begin(), (a).end()

/**
 * cordinate compression - 座標圧縮
 * 関係性を保ったまま、値を小さくする操作の事
 * 
 * Order(N logN)
 * 
 * 例
 *  A = { 8, 3, 5, 2}
 *  A'= { 4, 2, 3, 1}
 * 
 * Aの順序を保ったまま、値だけを小さくしている
**/

int main()
{
    // 入力例を用意 
    vector<int> a{8, 3, 5, 2};

    // A をコピーして退避させる。
    vector<int> a_dash = a;

    // A' を昇順でソート
    sort(all(a_dash));

    // A' から重複した要素を削除する
    a_dash.erase(unique(all(a_dash)), a_dash.end());

    // Aの各要素A[i]に対して
    // A' にA[i] が存在する場合、そのイテレーターを取得する。
    // Aの最初の要素のイテレーターで引くと、圧縮された値を得ることができる。
    rep(i, a.size()) {
        a[i] = lower_bound(all(a_dash), a[i]) - a_dash.begin();
        cout << a[i] << " ";
    }
    cout << endl;
    return 0;
}

ABC 213 C - Reorder Cards の反省

atcoder.jp

この問題の肝は、縦と横。すなわちA[h]とB[w]が独立しており、A[h]に対して座標圧縮、B[w]に対して座標圧縮をすればいい。

そこまでは分かっていたが、肝心の、座標圧縮がかけずに敗退……。
（そもそも座標圧縮という言葉すら知らなかった笑　やろうとしていたことは近いと思う）

Submission #24884196 - AtCoder Beginner Contest 213

おおよそ同じようなことをしようとしていたのだが…、詰めが甘い部分が多い。

また、「読み込んだHとW使ってなくね？あれ、俺の考えているアルゴリズムは間違っている…？」と思って思考をこらせてしまったのがよくなかった。もっと自分の考えたアルゴリズムを信じるべきだった。

調べなおして、書き直した結果がこちら。
Submission #24901109 - AtCoder Beginner Contest 213

DONEを定義するのではなくUNDONE を定義する

@bussorenre です。

スクラムで議論が難しい要素の一つに「DONEの定義」というものがあります。 「プロダクトが顧客にリリースされるまでに必要なすべての要素」のうち、スプリント中に完了できるものがDONE、できないものがUNDONE というすごくざっくりした定義をしたりしますが、「DONEの定義」という名前に引っ張られてDONEを定義しようとすると上手く行きません（実際上手く切り分けられませんでした）

そこで、とにかくプロダクトの企画からリリースまで、ありとあらゆるすべてのタスクを列挙していき、以下の３つに整理します。

• このタスクはチームの責務であると明確に言えるもの
• このタスクはチームの責務ではないと明確に言えるもの
• どちらとも言えない、わからないタスクや、今まで存在しなかった新たなタスク

「このタスクは開発チームであると明確に言えるもの」はそのまま「DONEの定義」に放り込むことができます。設計・実装・レビュー・テスト等、どんな組織でもおおよそ存在するであろうタスク要素は分解が簡単ですが、そうでないタスクも全然あると思います。

「このタスクは開発チームの責務ではないもの 」と明確に言えるものは、基本的にDONEでもUNDONEでもない、「やらなくていいタスク」として扱えます。しかし、このリストは定期的に見返す必要があります。「本当にやらなくて良いタスクだったのか？」「組織の境界がどうなっているのか？」という、スクラムチームの周囲を取り巻く環境を把握する唯一のコンパスになるからです。

そして、最後「どちらとも言えないわからないタスク」は「UNDONEの定義」になります。UNDONEは言い換えると負債です。UNDONE が積み重なれば積み重なるほど、プロジェクトはどこかで爆発します。UNDONE と定義されたタスクを、いかにして「DONEの定義」に落とし込み負債の解消に務めることが出来るかどうかは、スクラムマスターの腕の見せ所の一つです。

過去の経験上、しっかり意識していないと「UNDONE」に陥りやすいなと考えているタスクは

• リリース
• QA
• ドキュメンテーション

の３つです。特にドキュメンテーションは本当に難しいです。大真面目にやると、実際にコードを書く業務の３倍くらいはドキュメンテーションの読み書きに費やしていってると言っても過言じゃないくらいの膨大な量になるし、かといって適当にやると後から「このコードなんでこんな挙動しているんだ？」と言って、混乱のもとになって結果的にタイムロス（=負債）になります。また、一度ドキュメントを書いたから良いというわけではなく、コードと同様にドキュメントもメンテナンスされ続ける必要があります。このドキュメント保守が非常に厳しい。

ドキュメンテーションは「コード」に対するドキュメントの話だけでなく、あらゆる要素に対して発生します。例えば、コンテンツの管理（どこにどのファイルが格納されているか）といったドキュメントであったり、顧客対応履歴（ex.課題管理票の更新）であったり、そもそもプロジェクトに関わるファイルがあっちこっちに散らばってどれがどのファイルだったかわかりにくくなったりなど。

他にはenvファイルの更新（devとprodで違う値をどう確認するか）とかがUNDONE になったりするでしょうか。

「全体のタスク - UNDONE = DONE」という至極シンプルな計算で DONE を定義すると、DONEの定義に明確性が増し、またチームが持つ課題を認識しやすいと思われます。DONEの定義をにらめっこしてても良いDONEの定義はできません。

心理的安全性を生み出すスクラムマスターのムーブ

@bussorenre です。 ここ二週間くらい、プロジェクトマネジメントとディレクション、開発チームの組織の仕方、運営方法などについて色々回したり考えたりしてました。

心理的安全性とはなにか？を定義する前に、自己組織化されたチームについて説明する必要がある。

自己組織化されたチームとは、例によって江端先生(@ebacky)の言葉を借りると以下のような形になる。

 - チームのゴールが明確であること
 - チームの仕事や裁量の境界が明確であること
 - チームメンバーが，自分たちのやるべきことを自分たちで1秒以内に決定できること

そもそも自己組織化とは、あるランダムな状態にある構成要素が、構成要素間に働く相互作用により自発的に特定の秩序構造を形成する現象のことで、要するに統制する人（いわゆるプロジェクトマネージャーとか）が存在しなくても、自発的に何らかの目的のために自走し続けるチームを「自己組織化されたチーム」と称する。

チームメンバーが次何やるべきかを即決するためには、「チームあるいはプロジェクトの状態」が一瞥しただけで完全に理解できる状態でなければならない。アジャイルボード・カンバンなど、様々なタスク管理方法はあるが、それらは所詮ツールでしかなく、基本は「ほうれんそう」で、JIRAとかTrelloとかgithub issues に乗ってくるチケットリストはその副産物に過ぎない。

この情報共有の精度の高さ（抜け漏れの無さ）と心理的安全性の高さは非常に高い相関があると考えている。

上手く行っている時は良いのだが、上手く行っていない時に正しく情報共有されるかが非常に重要で、ミスや失敗や目標不達などを、きちんと周囲に共有できるか、また、それを良しとする心理状態にチームがなっているかが、心理的安全性の高さだと思われる。

この問に対して具体的な解は無いものの、ヒントのような、今までの試行錯誤から得たバッドノウハウが蓄積されてきたので共有します。

前提：チーム構成やメンバー構成など

組織の構成から考え直さないといけない、致命的なケース。

POとスクラムマスターを同一人物が兼任しない

スクラムの基本にして超重要かつ、これが達成されただけで問題の半分は解決すると思っている問題。散々スクラムで「POとSMは兼任しては行けない」と言われているのにも関わらず、結果的にスクラムマスターがPO的なムーブをしていたり、POがスクラムマスター的なムーブをしてしまうケースが非常によくある。

そのような事が発生する理由は多岐に渡るが、基本的には「スクラムマスター」というロールへの周囲（あるいはスクラムマスター本人）の理解不足が原因だったり、大企業において、どうしてもピラミッド構造の組織構造を作る必要があり、メンバーの上にスクラムマスターを担う人が位置付けられており、評価者を兼任してしまっている場合などがあげられる。POはROIに対する権限と責任を持つが、それ以上の権限はない。スクラムマスターに至っては、そもそもプロジェクトに対して何一つも決定権を持たない。

友人がアドバイスしてくれた「POとSMが兼任するとなってしまった場合、それはもはやただの圧にしかならない」という言葉にはかなり納得感がある。圧になってしまうと、チームが萎縮してしまい情報共有が素直になされない。

対策としては、上長含めチーム全員にスクラムについて学んでもらう（そのために資料を用意したり勉強会を行ったり研修の予算を確保したりなど）のが最も効果的だと思われるが、これはなかなか難しいし骨が折れる。端的に言って面倒くさい。

しかし、これを行うのもスクラムマスターのムーブの一つだと思う。

先程も説明したとおり、スクラムマスターにはプロジェクトに対しての決定権が何一つ無いのだが、POを兼任しているとなると、ROIの優先度高の項目に「チームのスクラムへの理解の向上」というプロダクトバックログアイテムを追加できると思うので、真摯にやってくしかないと思う。また、自分が上の立場に立ってしまったら、権限の委譲（そもそもスクラムマスターのロールを他のメンバーに委譲する）というのも視野に入ってくるだろう。

メンバーのスタンスが育っていない

これも基本にして重要な話なのだが、スクラムは「すべてのチームメンバーが、バックログやチーム・プロダクトの状況を見て判断行動できる」という前提に成り立っている。このスタンスに関しては研修プログラムや各社の人事評価精度によって様々な表現方法があると思うが、リンク&モチベーションの研修だと「STARの観点」と評されていたり、リクルートの評価指標だと「６つのスキルと４つのスタンス」等と呼ばれていたりする。つまり「上司からの指示がないと動けない」といったメンバーが居ると、そのメンバーは「チームに属している」と言えない。

また、この「スタンス」に関しては後天的獲得が難しい（歳を取れば取るほど習得が難しい）と考えられており、実際の肌感として自分もそう思う。（同じ人でもタイミングによってスタンスを発揮できない状態になってしまうことはある。例えば過労による燃え尽きであったり、病気等の体調不良であるなど。それら障害となっているポイントを見極め取り除くのは、スクラムマスターの仕事だと思う。）

対策としては、採用時にふるいをかける以上に効果的なものは無いが、「スタンス面が足りていないな」と思う人材が、精神的に若手であればあるほどチャンスは大きい。 「精神的に若手」とはどういうことかと言うと、「周囲の同僚にリスペクトを持ち、学び成長をを得ていこうとする姿勢」を持っている人材のことで、逆に言うと年齢が若くても学ぶ姿勢がない人はかなり厳しい。

スクラムマスターとして出来る事の一つに、自分がどういう働き方をしているのかを魅せるというのがあると考えており、スタンス面で未熟なメンバーのロールモデルの一つになるというのが唯一のムーブだと思われる。

日々の行動

前提の２つが解決すれば問題の80%以上は解決しているが、より具体的な行動指針として、意識してか無意識でかで、自分がやっているムーブは大きく以下の３つ

• チームメンバーとしてのロールを持つ
• 自分の弱みを見せる
• サーバントリーダーに務める

チームメンバとしてのロールを持つ

これは、スクラムの原則とは多少少しズレたところにあるが、POとSMの兼任ほどのバッドノウハウではない。スクラム体制の構築が甘かったり、周囲への理解を深めていこうというフェーズに有効。「あいつあれこれ言うだけで１行もコード書かねーじゃね―か」と言われるのを阻止する。

チーム内で最も技能や知識が豊富なエンジニアでありたいと思うが、そうでなくてもいい。むしろそうじゃなかったから良かったのかもしれない。周囲の同僚にひたすらコードレビュー等でミスや問題を指摘されまくってるからこそ良かったのかもしれない。

上手く行ってない時に、「上手く行っていない」と自分が言う事ができる。というか、そもそも自分がそれをできていないなら、心理的安全性の高いチームとは言えない。ミスったなと思ったら「ミスりましたすみません」というムーブを見せることが出来るので、スクラム初期にはチームメンバー兼任はむしろ良いムーブだと思う。

が、正直、率直な同僚の評価を聞いてみたい気もする笑

自分の弱みを見せる

例えば、僕は生活リズムが超乱れやすい。朝6時くらいから始業している時期もあれば、13時まで起きれない時期もある。が、この業界朝弱い人が比較的多いので、「わいも朝弱いんすよー」「じゃぁ定例遅めに設定するか」みたいな会話が出来る。

これに関しては、自分が意識してやってきたと言うより、同僚に自分も乗っかることが出来た。という側面のほうが大きい。彼らが居なかったらここまでフリーダムな会議体の設定は出来ていない。

簡単に書いたが、「自分の弱みを見せる」というのは実は非常に難しく、周囲に弱みを肯定してくれる同僚がたくさんいたからこそ出来たと思う。そうじゃなかったら出来ないし、出来なかった。「bussorenre くんなら出来るよ」というエンカーレッジを周囲の人がたくさんしてくれたからこそ、今のロールを担えている側面もあるし、自分も「〇〇さんなら出来ますよ」みたいなエンカーレッジをし続けていたいと思う。

サーバントリーダーに務める

多分、無意識でやっている。

よく自分はトイレ掃除に喩えるのだが、トイレ掃除なんてものは誰もやりたくない。しかし、誰かがやらないとアメニティが下がる超重要タスクで、正直、やってもまるで評価されない。直接的な営業成績が上がるわけでも、トイレ掃除をしたからコードが改善されるわけでもないから。

ソフトウェアエンジニアにおいても、トイレ掃除にあたる仕事があり、その主たるものの一つに「マネージャー」と呼ばれるロールのタスクがあると思っていて、他の業界は知らないけど、この業界はマネージャーになってもあまり良い事がなく、むしろ自分でコードを書く時間が相対的に減ってしまったり、そもそも人間と付き合うのが苦手だからソフトウェアエンジニアやってるのにどうしてみたいな、色々な闇の側面が強い。

が、誰かがこのあたりを整えることによって、他のメンバーが快適に業務に従事できたりする。「マネージャー」というロールのタスク以外にも、あれこれアメニティを上げるタスクはあると思うが、組織やビジネスの成長フェーズによってかなり違いがあると思うので具体的に何をどうするか？は一概には言えない。「全体を俯瞰して、影になっている部分に光を当てる」くらいの感覚なのかなぁ…？

冒頭この項目で「無意識にやっている」「評価されない」と書いたが、冷静に考えると、現状の自分はかなり評価してもらえている環境に居ると思っていて、だからこそ、特に意識せず、目の前の影に光を当てるというタスクに従事出来ているのかもしれない。

まとめ

色々偉そうな書き方をしてしまったけど、正直これが最適な方法なのかと言われると相当な疑問が残る。ここに書けなかった失敗したなと思う事もたくさんある。実際の評価は同僚に闇ブログとかを書いてもらうしかわからない。大事なことはチーム全体の一体感だと思っており、これが「なんか体育会系みたいで湿度高くて嫌だ」と思われる主原因でもあると思う。しかし、一体感を得たチームほど強いものはないとも思っており、いわゆる「一人の集合ではなくチーム」になれるのかなと思っている。

そのためには、ある種「弱み」みたいなものをちゃんと見せつつ、メンバーの弱みを理解しつつ、それでもなお結果を出すにはどうしたら良いか？を考えて行動できる人は真のスクラムマスターだと思う。正直全然できている気がしないが、それでも真摯に向き合っていくしかない。

あと、後半は書きながら「あれ、これ自分の力じゃなくて周囲の力じゃね…？？」と思いながら書いてた。実際、周囲の力があってこそなりたってると思う。この点に関しては、「つまり、あなたの職場環境が素晴らしいと言う事ですよね？」という問いに対して「はいそうです」としか言えない。いい職場です本当に。

自分もその「周囲の力」の１因子だと言うことで、その１因子がどういう動き方をしているのかを言語化したら、こんな感じになった。ということでどうかひとつご容赦ください。

天才ではない自分が「けしからん」ことを面白可笑しくやるにはどうしたら良いか？

こんばんわ。 @bussorenre です。

先日、情熱大陸 #1140「サイバー技術開発集団 統括・登大遊」 が放送されました。 tver.jp

隠れた天才が、ついに多くの人々に知れ渡ることになってしまったわけですが、この人は本当にすごい。頭がおかしい（※天才過ぎて常人には理解できないの意で使用しています）。高校生のときに既に、64のGoldeneye が好きすぎて似たようなゲームを自作したり、そのプログラミングノウハウを本にして出版したり、どういう用途にするつもりだったのかさっぱり意味がわからないけど、高校で放送された校内放送を全部録音してアーカイブ・参照できるようにしたり。

DirectX9.0 3Dアクションゲーム・プログラミング―DirectXを使った3Dアクション・ゲーム作成のノウハウ (I・O BOOKS) | 登 大遊 |本 | 通販 | Amazon

で、この人はさぞ物事を論理的に考えているのかと言うとそうでもなく、本人も以前にブログで書いているように、 インスピレーションや面白そうと思ったことを突き詰める事を優先しており、補助的に論理的思考を使っているように見える。

softether.hatenadiary.org

まぁ、色々書いたが、↑の記事を読むと、「結局こういう人の事を一言で要約する天才としか言えないよね」となるわけで。実際に登さんの天才性は、僕が今まで出会ってきた人の中で、頭50個くらい飛び抜けていると思う。

優秀なプログラマーとそうでないプログラマーの生産性は100倍近くも差があるともいうが（実際登さんは1万倍くらいあると思うが笑）、かといって登さんのような天才が１人いればすべての課題が解決するかというわけでもなく、そもそも、登さんは登さんしか居ないわけで、それでは組織やイノベーションがスケールしない。

ではどうすればよいか？と考えた時、2つのアプローチが思いつく。「天才を増やす」ことと、「天才をエミュレートする」ことである。

天才を増やす

天才を増やす方法として、古くから議論されているのが、浅く広くプログラマーを増やすというのが知られている。資料などでは、「裾野を広げる」となどいう言葉でよく表現されている。参考： www.ipa.go.jp

一見矛盾しているかのように見えるが、天才が存在する確率がN%だとすると、100人のプログラマの中に存在する天才はN人だが、1万人居たら天才が100N人存在するということになる。（実際はこんなに単純ではないと思うが）

後天的な教育だけではカバーしきれない無類の才能を発揮するからこそ「天才」と称されるのであって、母集団を増やす（裾野を広げる）ことが最も有効な技だと思われる。

このような観点から見た時、昨今「プログラミングスクール」と呼ばれる事業者が増えてきたことは、基本的に歓迎すべきことだと思う。今まで業界人が「好きな人は放っておいても勝手にやるでしょ」みたいな空気でやってきたのが、需給のバランスが完全にぶっ壊れて、「とにかく高速道路を整備しないと色々な事業が人材不足で死ぬ」となって、人材育成の必要性が急々急務になってきた。

もちろん、課題点も多い。転職詐欺みたいな業者も存在するし、企業から見たら「勉強した割にこいつ使えないな」みたいな人材が一定数居ることも事実だと思う。

しかし、「本当に良い高速道路なのか？そもそもこの道はちゃんと目的地にたどり着く高速道路なのか？」と言った議論・改善に挑戦し続ければ、いずれどんどん良くなると思う。既に業界にいる我々が、「プログラミングスクール卒とかｗｗ」とバカにするだけの老害になってはいけない。もちろん、スクール以外の手法・高速道路もどんどん整備しなければならない（それは地下道だったり飛行機だったりするかもしれない）

天才をエミュレートする

すごいざっくり言うと、「三人よれば文殊の知恵」作戦。

今日の本題。

仮に登さんの生産性が通常のプログラマの生産性の100倍だとすると、生産性1のプログラマを100人集めれば同等のパワーが出せるのか？と言われると否で、それは既に「人月の神話」等で徹底的に議論されているし、実経験としても、コミュニケーション遅延が発生したり、コンテキスト境界がぐっちゃぐちゃになったりで、実際100人居たとしても20 程度のパワーしか出ない。

そこで考えたのが、生産性が10のプログラマを3人集めて、（多少のオーバーヘッドを加味して）３人の合計生産性を20にする。このチームを5つ作る。そうすると15人で100になる。1台の化け物クロックCPUを作るのではなく、複数のCPUを用意してクラウドコンピューティングするイメージが近い。

3人よれば文殊の知恵作戦は成立するか？

さて、このような組織を作るときに必要なのは、統率ではなく、プロトコルである。

従来のSIer あるいは SESと呼ばれる形態の組織構造は、おおかれ少なかれピラミッド型で、最上位層から最下層へ指示を伝達して物事を達成しようとする構造をしている。

この構造だと、ボトルネックになるのはマネージャーと呼ばれる指示を出す人で、要はディスパッチャーに負荷が集中してしまい、一見スケール出来るように見えてスケールできてない。

そもそも、「ワーカー」と「ディスパッチャー」という、明らかに役割の違う2種類の人員を用意しなければいけない。これはスケールしにくい。また、今までワーカーとして機能していた人員が、「君優秀だから昇格ね」と言われてディスパッチャーに回ったとしても、全く異なる機能を求められるので、ワーカーとしては優秀だったけどディスパッチャーとしては全然機能しない可能性がある。これでは人材がスケールしない。

目指すべき姿は、プロトコルによってお互いがお互いに情報をやり取りしワークする双方向な体制。全員が同じプロトコルを使えると仮定すると、この組織はわりと柔軟にスケールさせることが出来る。と仮設を立てている。

特定の目的を達成するために各々が共通のプロトコルを用いて行動を行うことによって、いわゆる「チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ」という状態に持っていくことが出来る。この「共通のプロトコル」と呼んでいるやつは、具体的には巷では「スクラム」と呼ばれていたり、「アジャイル」と呼ばれている物だったりするかもしれないが、これは目的に沿っていれば正直何でもいいと思う。

しかし、言うは安し、寿司は旨しで、これを実現するには非常に大きな課題がある。それは、「何を達成するために我々は居るのか？」という目的の共通認識をしっかり持つことが難しいということである。ピラミッド型組織は良くも悪くも最上位のディスパッチャーが、「ジョブを割り振る」という方法で、組織の向きを統制することが出来る。しかし、双方向型の組織はこの機構が無いので、全員が同じ向きを向いて働いていますよね？というチェック機構が別途必要になる。

今の所、僕はこれに対する明確な回答を持っていない。1 on 1 をやる。360度評価をやる。キックオフやビジョンミーティングをやったり、ミッションをより明確に打ち出す、採用時にカルチャーマッチを重視するなど、各論はわかるが、仕組みとしてこのプロトコルに取り入れる手法に確信を持てていない。

ここで、「目的の共通認識をしっかり持つ」ために更にもう一つの仮設を立ててみる。それは、ほんの少しだけ天才の真似事をしてみる、ということ。

具体的には、登さんのように、「極論目的とかどうでもいいんです、（モチベーションのために）面白いからやる」ということなのだが、これを論理的に考えてパクろうと考えている時点で「論理的思考を破棄する」に反する。

自分がやるならどうすればいいかなーと考えてみるのだが、自分ならおそらく、突然好きなキャラのコスプレをして、中二病全開で「俺は世界の変革者だ。こんなことが実現したら、たいそうけしからん！面白くなりそうだ！」と叫んでみる。などをやると思う。この行為に多分論理的な思考はないと思う。多分。（追記：これを書いているのは深夜帯なので、夜が明けたときに自分がこの記事を書いたことを覚えていたら撮影してみようと思う笑）

それで場が白けたら、「調子に乗りましたすみませんでした」と言ってやめれば良い。そもそも「自分が面白い」と思わなかったらやらない。冷静に考えたら「いや無理でしょ」とか「いやだめでしょ」と言ったことを、普段やらないような言動でを全力で提案してみる。最初はくっそ恥ずかしいが、とりあえず言うだけ言ってみる。

2人乗ってきたら、自分含めてちょうど3人よって文殊の知恵作戦が立てれそうなので、やってみる。10人が乗ってきたら多すぎる。スモールスタートには向いていない。やめたほうが良い。あるいは人数を絞って3人で文殊の知恵作戦をすれば良い。

こういうのを繰り返し行っていくと、徐々に組織が同じ方向に向いていくんじゃないかな―と思っている。現状まだ思っているだけなので、実際にこれからやってみる。やっってみた結果は2021年の振り返りあたりで書こうかなと思う。

まとめ

• 1人の天才にすべてを依存するのは組織やイノベーションがスケールしない
• 天才を増やすには、裾野を広げるしかない
• 天才をエミュレートするには、徒党を組んで、かつ個々人が独立してワークするための「プロトコル」と「目的の共通認識」を保つ必要がある。
• 「目的の共通認識」を保つためには、突拍子も無いことを言ったりやってしてみて、人が乗ってくるか試してみる。程よい人数が乗ってこなければ辞める。

今日はかなり抽象的な方針だったり仮設を書いてみたが、より具体的な各論は試して見る過程で発見したり学ぶことができたら共有していこうと思う。

※ ご意見・知見などは全力でコメントやTwitterでお待ちしております。

追記：「生産性が10のプログラマを3人集めて20にする」。について

ここはもっと議論というか改良の余地があると思っていて、お互いの得手不得手を補い合えるような3人が集まったとすると、実際には10*3 の30よりも大きな50くらいまで生産性は出せるんじゃないかなと思っている。（いわゆる相乗効果を狙うという奴） だが、実際にこの相乗効果を狙うのは難しいパズルを解くのと同じくらい難しく、人材パズルの天才が必要なんじゃないかと思ってあえて考慮しなかった。

しかし、最後に書いた「目的の共通認識」を保つために、面白そうな事を面白おかしく言ったりやったりしてるうちに、自然と「自分は（君たちが持ってない）こういうところが得意だから、それを手伝えるよ」といったフォロワーシップのある人が出現してくる気もしており、人材パズルの天才は実は不要なんじゃないかという可能性もあると思う。

あと、天才と称される登さんでさえ、チームを組んでプロジェクトに挑んでいるのだから、天才で無い僕はなおさら徒党を組む必要があると思う。そのために人間同士のプロトコルについて勉強したいので、最近はEngneering Manager というロールにかなり興味がある。他の組織がどういうEMを育てているかめっちゃ興味がある。

追記２：モチベーションと努力について

結局のところ、↑で書いた手法は内発的動機づけに依存すると思う。誰しもが何らかの内発的動機づけを持っているわけではないと思う。一方、外発的動機付けによってとんでもないモチベーションとパワーを発揮する天才も居ると思っていて（私には真似できないが）、外発的動機づけのほうが優先度が高い人は、そういった天才を真似するにはどうしたらいいかを考えるのもアリなのかもしれない。

あと、モチベーションのベクトルの強さと、努力の量と質はかなり相関があると思っていて、結局「自分の好きなこと」じゃないと、深い努力につながらないのでは？という気もする。本当に些細なことから好きなことを見つけて努力や挑戦につなげる才能（メタ才能のような概念）も必要だが、それについては考えがあるので別途まとめてみようと思う