bussorenre Laboratory

hoge piyo foo bar

自分は運が良かった

2024年。自分が思っていたよりも早く世界が動いている。

自分の心の時間が2018年で止まってしまっていて、前に進めずにいる。という主観的な理由もある。しかし、それとは関係なく、そもそも世界全体の見通し以上に動きが早いという、マクロ的な視点もある。

常々、自分は「運が良かった」と思っている。

「運が良かった」要因は大きく三つ。

最も大きい要因として、「好きな事/得意な事」が「成長産業」に近い分野にあった事。しかし、これはもう終わりつつあり、IT業界は成長産業から成熟産業に移りつつある。自分が思っていたよりも急速に成熟産業に移っている。非常に危機感を覚えている。

次に、世界の流れが追い風だった事。全体的に見れば世界は平和だったし、日本は好景気のサイクルの中に居た。好景気。と言っても、大規模金融緩和の中で無理やり発生した好景気の中に居ただけなので、それが良かったかどうかはさておき、その恩恵は多分に受けたと思う。

最後に、若かったこと。「若いうちの失敗は取り返しがつく」とよく言うが、本当にその通りだと思う。若いうちの失敗は取り返しがつきやすい事は間違いない。

しかし、これらはまさに生存者の「生存バイアス」である事を肝に銘じて、次の30年、60年に備えなければならない。私を助けて来たこれらの「運」は、もうない。4度目の失敗は、それこそゲームオーバーだと真剣に考えている。「死ぬまで生きる」を全うできないかもしれない。

運が味方をしている内に優位を取れればよかったが、私はそれが出来なかった。

だからこそ悔しい想いをしていたのだが、だからといって諦めたら本当にそこで試合終了である。勤めて冷静に、かつ直勘を信じてまっすぐ行かないといけない。寄り道している暇がもう多分ない。

まず、自分という個体が持つリスクを徹底的に下げていくしかない。今まで解決できなかった自分の問題を徹底的に解決しないといけない。なりふり構わず、それをなんとかしないといけない。

自分が前に立つしかない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

リクルート退職した

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

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

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

なぜ6年半も居たのか?(あるいは、6年半で辞めたのか)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

退職して何をするのか?

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

jizaie.co.jp

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

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

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

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

おわりに

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

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

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

coordinate compression - 座標圧縮

アルゴリズムの概要

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

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


A=\{8, 3, 5, 2\} \\
A'=\{4, 2, 3, 1\}

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

  1. A を コピーして別のコンテナ(A')に移し替える。 (a_dash = a でも、copy でもどちらでもよいと思う。)
  2. A' を昇順にソートし、重複を排除する。(重複を排除するには、eraseunieque を組み合わせることで実現できる)
  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を定義しようとすると上手く行きません(実際上手く切り分けられませんでした)

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

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

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

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

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

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

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

ドキュメンテーションは「コード」に対するドキュメントの話だけでなく、あらゆる要素に対して発生します。例えば、コンテンツの管理(どこにどのファイルが格納されているか)といったドキュメントであったり、顧客対応履歴(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の観点」と評されていたり、リクルートの評価指標だと「6つのスキルと4つのスタンス」等と呼ばれていたりする。つまり「上司からの指示がないと動けない」といったメンバーが居ると、そのメンバーは「チームに属している」と言えない。

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

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

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

日々の行動

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

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

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

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

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

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

自分の弱みを見せる

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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