bon now

この記事はずっと書こう書こうと思っていたけど、「途中で書いたら多分言ってはいけないことを書いてしまう」とか「部分的に感情が乗っかってしまう」と感じることが多かったため、ある程度落ち着いて、すべてが終わったタイミングで書くことにした。
そんなこんなしてたら結構遅くなってしまった。(なんか思い出せないとこもあるかもしれない)

そして気づいたら入社して半年以上が経っていた。それだけの期間が経ったにもかかわらず未だ何も分からないし何も分かってないので努力が足りないとかなり感じている。そんなEM(Engineering Manager)としての最初の体験をここに記す。

はじめに

2月からの5ヶ月間で、僕は自分がEMとして担当するシステムの新機能リリースに携わった。そこから学んだことはとても多い。最初にそれらを述べ自分なりの結論を述べると、僕はEMとしてのスキルを到底持ち合わせていないということが明らかになったといえる。より正しくは「ある1つの目標に対しての遂行力は問題ないが、全体に問題がある」という評価が正しいかもしれない。

このせいで僕らのチームは散々な目にあっただろうし、プロジェクト全体も全力疾走で駆け抜けただけで体力を消耗しまくった挙げ句スクラム開発とは程遠い、バスケットボールでもやってるの？状態での似非スクラムだったのではないかと思う。もちろんレトロスペクティブやプランニング、リファインメントなどの儀式はスプリントの始まりと終わりに必ずやっていたが、実際一度立ち止まってガッツリと向き直る時間は0だった。

なぜこうなってしまったかについては最初に述べたとおり自身のスキル不足ではあるが、どうしてこのあたりの問題を放置したままにプロジェクトを進めようと思ったかを次章より述べていく。願わくばこの記事を見た方が、僕の決断の意図とそこにあった意図的なリスクの抱え込みや不安と後悔などを感じてもらい、自分にとって失敗のない、正しいプロジェクトの進め方について考えるきっかけになると幸いである。

問題点と原因の考察

そもそも個人のスキルが与えられた役割・能力と比較して不足している場合、人の取れる行動には制限がかかる。簡単にまとめれば「あきらめる」か「スキルの及ぶ範囲で頑張る」か、「とにかく頑張る」のどれかだろう。

ことに首切り文化の根強い、力こそ正義なアメリカ企業の文化圏においては、そもそもスキル不足の社員は最悪次の日に出社すると席がないなんてのは当たり前のように発生する。これは強制的にあきらめざるを得ない状況を作られるということである。しかし、日本の場合はそこまで厳しくないので、ある程度のスキル不足も自分でカバーしつつ周りの支援や協力を得ながらなんとか仕事できる場面は多々存在する。これは義理人情というものである……多分。そして幸い僕の置かれた状況は日本式だったので、僕は僕のスキルの及ぶ範囲でとにかく頑張った。その結果何を学んだのかを以下に箇条書きしてみた。

• チームの問題はEMの責任
• 犠牲にしても良いものと悪いもの
• 曖昧さは極力排除すべし
• フルリモートでの弊害は見えないコスト
• 他部署とのコミュニケーション閉塞による利害
• 文化の重要性
• 物事を決めるのに一番大事なのは信頼と責任
• 成功体験をリセットする

チームの問題はEMの責任

チームの問題はそれを率いるマネージャーの責任である。僕はそれを棚に上げ、チームのパフォーマンスが下がってしまったこと、チームでコミットした(と思ってた)ことを守れなかったことについて、チームに対して言葉を選ばずにそれを感情的にダイレクトに伝えてしまった。当時僕は、僕を含めたチームはもっと良い結果を作れると信じていた。ただしそれは個人的で一方的な要求だった。その結果自分にとってうまく行かなかったことをチームのせいにしてしまった。この要因は、自分の役目は正しく行えていたと思っていたからというのと、自分が「正しい」と思っていない行為を自ら行っていたことに対して自分自身ストレスを溜めてしまい、それらを解決するタイミングを作れなかったからだと思う。
その結果としてチーム内での僕の信頼が下がるという結果を招いてしまったし、チームとしてもいろいろな問題を先送りにしたままという状態にになってしまった。

ここでは、必要な説明責任について私が怠ったことが問題である。自分の期待、チームの期待、組織の期待というふうに様々な粒度で意識合わせをすることは結構重要であることを今回学ぶことができた。正直、今まで僕自身そういうのを「受ける側」としてしか仕事してきてなかったなーと思う。それは僕が実質的にリーダー(マネージャー)として仕事をしたことがなかったことも理由の1つだろう。あとは単純にそういう雰囲気作りみたいなのを本来であれば対面で作り上げていけばよかったのだろうけど、新型コロナの影響によりそういう機会がほぼなかった。実のところそのへんもマネージャーという立場である僕が率先してやるべきことだった。
EMはチーム全体の効率や環境を改善していくことに重きを置くことが求められると僕は思っているので、実装や設計にめちゃくちゃコミットするというわけではなくチームの各メンバーやチーム全体が滑らかかつ快適に仕事できる環境を用意することが大事だったのだ。わかってはいたけれども、それを促進するためのやり方を全く分かっていなかった。

犠牲にしても良いものと悪いもの

QCDという言葉は日本のSIerの間で頻出するワードである。Quality(品質)、Cost(コスト)、Delivery(納期)の3つの頭文字をとったものだ。この中で最も大事なものは 「Quality」だと言われている。今風の言葉に置き換えるとプロダクトファーストという感じで捉えていい気がする。

ユーザーに届けるシステムにおいて納期が遅れようがコストが膨れ上がろうが、使うことのできない品質(プロダクト)では意味がない。ただ現代では修正アップデートは家庭用ゲームでさえ頻繁に行われるようになっているので、正直なところ完全なる品質を最初から確保することの重要性は、数十年前よりも薄れてきていると思う。(なのでプロダクトという言葉に置き換えたほうが分かりやすいかも)

品質がある程度確保できた場合の他の優先度についてはプロジェクトによってバラバラだと僕は考えている。要するに全体のバランスが取れていればそこまで問題がないと思うので、チームやステークホルダーと会話して正しい優先度について議論することが必要だろう。
つまり、「バランスを取った上で最優先すべきこと」というのはプロジェクトの最初に決めることが望ましい。

今回のプロジェクトでは、僕は「リリースを優先する」= 納期と決めた。これによって本来であれば重要視すべきだった「品質」について省みる機会や程度を定めるための機会を作ることなく、とにかく納期を守るために前に進むことを優先することにした。立ち止まって省みたときに発生するであろう議論や改善の取り組み、および評価のサイクルはとても時間がかかると考えたからだ。
しかしながら振り返って思うことは、むしろより早い時点ですべての不明点や意識のズレについて、時間をかけてでも整理すべきだったということだ。「カイゼンジャーニーにもそう書いてあっただろ。ちゃんと読んだのか？」と言われると耳が痛いんだけど、現場は現場、本は本。納期を守る上で僕がそう判断しちゃったのだからしょうがない。

ちなみに上記の決め事やプロジェクトの現状をチーム全体で認識を合わせるために、プロジェクト発足直後にインセプションデッキを実施した。これは良かったと思う。ただファシリテーターやまとめるための議事録の取り方などのルールも特に決めずに突っ走ったこともあり(あと参加者全員がインセプションデッキをそこまで詳しく理解していなかったことも相まって)、うまく機能してないところも多くあったと感じている。
インセプションデッキについてもチームに不調が生まれたタイミングで何度でもやって良いと言われているように、チームが立ち止まる時間を作るのもスクラムやアジャイルには必要なことだ。この話を実際に体験して理解できたのは良かったが、もっと早いタイミングで犠牲にすべきものとしてはならないものの区別と、誤りを正すタイミングについてを理解しておくべきだった。つまり今回犠牲にできたのは「時間」だけであったのだ。なお、時間 = 納期 ではないことをここでは強調したい。納期を変えることなく、普段チームが使える時間を、開発以外の取り組みに対して有効活用することが求められる。

曖昧さは極力排除すべし

ここまで述べたように結局どんなにスクラムやアジャイル開発を進めたとしても、曖昧さの残る部分は話し合わない限り永遠にはっきりすることはない。アジャイル開発宣言でも最初にコミュニケーションの重要性が説かれているように、対話はとても重要である。アジャイルやスクラムで大事なのは「みんなの認識が同じであること」だと僕は思っていて、ルール化されていない暗黙知があったとしてもチーム全体でその答えが1つに定まることが望ましい。そこまで分かっていてなぜ失敗したのかというと、これは多分「僕だけが認識が揃っていると思っていた」というのが真実かなと考えている。

前述どおりインセプションデッキもやった、やらないことも決めた、やることは当人同士での対話で決まり、EMとしての僕は最終的な方向性について議論をし決定すること、そう思っていた。
だが現実はそうではなかった。実際はこれらのすべてについて「…と思っていた」という語尾が付くわけである。

また、僕はリリースを期日通りにすることを目的として行動していたため、おそらく他のメンバーが抱えていた問題点や課題について少し先の未来を見過ぎていたのではないかと思う。
要するに僕がメンバーに伝えていた解決策や提案は、「現時点を見ると方向性として曖昧である」と言えるが、長期的に見た場合にのみ目的がある程度明確であるという要素を含んでいたかもしれないということだ。これについては、僕が意図的に視座と視野を下げる必要があったと思うし、メンバーに対してそれらを僕と同じにするくらいの情報を与えコミュニケーションを取ることが必要だったと思う。僕が未熟だった(というよりは僕だけが一人突っ走った)ために、チームは暗中模索の状態で日々自分たちで様々なことを決定しなければ先へ進めないという状況になってしまっていたのだろう。

フルリモートでの弊害は見えないコスト

僕のプロジェクト期間はちょうど新型コロナが流行りだしたころから始まっている。そのため、入社して少し経ったあと全員がリモート勤務となった。そのせいもあり隣でメンバーが何をやっているかが全くわからない状況になった。

僕にとって完全リモートは初めての経験だったことと、そもそも入社してから日も浅いため、初めてずくしで誰に何を聞けばいいかわからない状況が長らく続くこととなった(今もわかってないことのほうが多い気がする)

これについてはもっとアクティブに行動すればよかったのだろうけど、メンバーのパフォーマンスを下げてまで自分に時間を割いてもらう必要があるのかという強い葛藤があったのは確かである。これは僕の「他人にかける迷惑は最小限にすべきだ」という信条のせいもある。なので僕は「わかる範囲で自分の経験から考える」ことを選んだ。しかしながら僕が現職でわかる範囲なんて微々たるもので、プロジェクトの現状を伝えるくらいしかできなかったのだ。

また、物事の判断を強く行うことができなかったのも問題だったと思う。これも新型コロナの影響がなければ実際に出社して、隣でメンバーの状況をみながら会話できただろうから、もう少し柔軟にできたかなと感じる。僕自身が優柔不断な面もあるのでその辺も考慮してメンバーと相談しながら決めるほうが早かったかなと思うけど、無駄に我慢して、わからないから一人で悩んで……を繰り返す日々だった。もっと周りに聞けばよかったしもっと周りに頼ればよかったと今は思っている。
なぜそれをできなかったのというと、多分僕のプライドの問題ではない。「このプロジェクトを前に進めるために、邪魔になる要素は徹底的に封殺する」ことを僕が選んだためである（自分の判断や理解もすべて）。

他にもリモートだとその場で誰かが困ってる状況であることもリアルタイムではわからなかったし、誰かのモチベーションが低下していることもわからなかった。本来であれば早い段階で1on1を毎週やるようにして人と会話して問題点や困りごとを逐一確認しておけばよかったんだろうけど、そういう時間も確保せず、人付き合いも何も振り返ることのないまま突っ走ったのは完全に誤りだった。そして、これらが引き起こす影響について完全に見誤っていた。結果的にプロジェクト完遂後も色々と引きずったままになってしまった。

フルリモートだと普段以上にコミュニケーションコストや認識合わせ、環境づくりのコストが嵩む。そしてこれらはすべてチーム間の信頼関係や安心感などに関連づいてる部分もあると考えている(いわゆる心理的安全性)。そのためそれらを促進できる何かをリモートで取り組むことはとても重要だと思う。特にチームという単位で行動するのであれば、チーム全体が一体感を持つためには特にだ。スクラムはガッチリ組み合うわけだから、対面が一番良いのは確かだ。対面では「普段見えないけれど見ようと思えば見える」コストが、リモートになることで「完全に見えなくなる」わけなので、今まで通りというのは通用しないのは明確である。

事後ではあるが、これらに対する施策として週1回のランチ会を始めたり、デイリースクラムで最初に雑談を挟んだりして業務以外でのコミュニケーションを促進することをやっている。(ちなみに月に1度OKRの振り返りとしてウィンセッションというものをやってメンバーの成果を褒め合うような場を作ってはいたが、それだけでは足りなかった感はある)

他部署とのコミュニケーション閉塞による利害

今回のプロジェクトでは、他部署とのコミュニケーションについて僕が意図的に閉塞したというところにも原因はあったと思う。その理由は、大きなチームに突然加わった小さなチームの些細な意見は、プロジェクト進行の妨げになると考えたからである。

既存のやり方でプロジェクトはたしかに推進できているが、後から参入したチームやメンバーから見ると非効率だと感じることはよくあることだと思う。それに対して改善提案することはとても大事なことだとは思うが、大きな組織の場合その提案についてどうするかの判断や導入や評価などにかなりの時間を要することを意識しなければならない。3人でやれることを30人でやれるかというとそうではない。改善提案が実際に運用され浸透されるまでのコストを考慮した場合、基本的には現状でもとりあえずプロジェクトを推進できる方法を選択するほうがコストが低く済む場合もあるだろう。これらを考慮したうえで、僕は今までのやり方を踏襲し改善は自チーム内のみに留めるように努めることにした。

具体的には自分たちのチームが自分たちの仕事に集中するために、他部署への多くの提案や要望をチーム内でストップさせた。そして自分たちだけでできる改善をまず取り組むことにした。この決断は結果としてチームの評判がすこぶる悪く良い行為ではなかったのだろうけど、ここだけは僕は間違えてはなかったと思っている。事実、他部署からの僕らのチームに対する評判はどこに聞いても良い評価ばかりだった。（既存のやり方に極力変更がないことを心がけつつ、問題のある部分は自分たちのチーム内だけで改善するという行動をしてたのだから、当たり前といえば当たり前である）

大は小を兼ねるという言葉があるように、組織は往々にして大きい側に従うことのほうがリスクも間違いも少ないと思っている。多数決だってそうだし、会社そのものの方向性も、より大きな成長のできる方向性を選択するほうが良い判断といえるだろう。ただし、間違いはどこにだってあるし改善すべき点も必ず存在するものである。だから僕らのチームが気づく問題は他のチームも必ず気づいているだろうし、解決しようという意識も必ずあったはずだ。でも多くのチームや人は大きいものに巻かれて、いつの間にか「やらなくてもなんとかなる」という方向に流れるものだ。それを正せるのは、後からやってきて声を上げることのできる空気の読めない新参者だろう。別の観点から見れば、むしろ僕らが既存チームの未来であると考えることもできるだろう。つまり僕らの抱えている問題は、いずれ既存チームも抱えるかもしれないということである。

僕は本来改善が大好きだし、問題点について地道に段階を追って修正・改善していくことをこれまでも長く仕事で取り組んできたつもりだ。つまり僕は他部署とのコミュニケーションを取ることのメリットについても十分に認識していたし、その弊害についても正しく認識していたと思っている。なので僕が今回のプロジェクトで行った判断自体は間違えてはいなかったと思っている。唯一、それを正しく説明する機会を設けなかったこと以外は。

文化を知り、文化に乗る

書籍のZERO to ONE やHARD THINGS にも書かれているように、企業文化はめちゃくちゃ大事だ。このブログの他の記事でも何度も書いてるつもりだ。そのくらい僕は文化について正しく認識していたつもりだった。

でも、現職の文化について僕は深く知るための時間を作ることを怠っていたといえる。いくつかのルールや守るべき矜持があることは知っていたけどそれを字面でしか理解していなかったのが今回の件で分かったし、日々の業務に忙殺されて、文化に乗るための自身の行動の仕方や考え方について考える余裕を失っていたこともよくわかった。皮肉なことに、「文化の大切さ」について自分がそれを守れていなかったことで、さらにその重要性について今回再認識したというわけだ。

文化を知らない人間が1人でもいると、お互いの信頼やコミュニケーションにおいても意思疎通に相違が生まれる。例えばAmazonは自社の文化について会議でも話題にするくらいには徹底していると言われているし、メルカリも会議中に自社の文化に沿っているかどうかの確認や発言が行われるという話は聞いている。僕ももう少しそのあたりを意識して、メンバーに投げかけるとか僕自身に問うとかできたわけだ。これらを怠ったのはただただ僕の甘えであり、ある意味では「自分は意識しなくてもできて当たり前」という慢心があったのかもしれない。

物事を決めるのに一番大事なのは信頼と責任

僕自身メンバーに含まれているとはいえ、メンバー全員に対して心無い言葉を投げかけてしまったのが最大の反省点なのはこれまで述べたとおりだ。これは僕のスキル不足・経験不足のすべてが招いた結果である。振り返ると、自分で色々と抱え込んでしまった部分が精神的に駄目な方に出てしまったのではないかと感じるところもある。とはいえ実情ではそんな悩みはさっさとチームメンバーに対して素直に様々な不安や悩みを打ち明けるべきだっただろう。もっとチームメンバーを信頼し、みんなで問題や課題を解決していくことを本来であれば時間をとってやったほうが良かったと思う。これはTeam GeekにもHRTの法則として実例が出ているとおりである。

また、僕の定めた目標や目的、その時の判断などに対してメンバーが納得の行く形で説明責任を果たす必要があったし、僕自身が何をメンバーに期待して、何に対して問題意識を持っているかをプロジェクトが始まった時点、あるいは問題が顕在化・顕著化してきた時点で定期的に振り返り&向き直りながら改善をしていく必要があっただろう。それらをせずに見て見ぬ振りを決め込み、自分の信念だけを忠実にこなしていく様は、メンバーからみると何をやっているんだろうと感じたかもしれない。そして気づかないうちに僕のメンバーに対する期待と、メンバーの僕に対する期待との差は広がり、溝は深まり、結局それが問題となって表面化することになったわけだが…….。

ただし、いろいろな問題をそのままにすることをメンバーが許容してくれたおかげで、良い面ではメンバーが開発に集中することができる環境を得られたかもしれない……という点もあると思う。「郷に入っては郷に従え」という言葉があるように、我々が問題だと感じるプロセスや仕組みであっても、他のチームや開発全体はとりあえず回っていることは確かなのだから。

成功体験をリセットする

成功体験はだいたいの場合物事の判断基準を鈍らせることに繋がると今回のプロジェクトを通じて感じた。反論はあるだろうけど、特に人の多く関わる開発環境や組織は、変数が多く存在するために不確実かつ不明瞭な部分もまた多い。そのため、過去の成功の定義をそのまま持ってきても、確実に適用できるという保証がない。

個人的にはこの成功体験をある程度均一化するために使われるのがフレームワークだと思ってる。開発プロセスでいうとスクラムがそうである。ただ、これらもやアジャイルの概念部分が抽象的に定義されていたり、人や組織、開発するものなどにより左右される部分が多かったりするので過去の成功を100%流用できるわけでもない。チームが変わってしまえばベロシティやSPのおおよその量が変わってしまうし、関わる組織（部署）が変わればコミュニケーションの形も変わる。

このあたりを意識して「やってみて、ダメそうなら考え方を変えてみる」という思考もまたアジャイルぽいと言うこともできそうだ。今回のプロジェクトで足りなかったのは「やってみる」という部分でそもそもやらなかったことだった。ただ、これについては今後様々な形で実践・実現していこうと思ってる。僕自身もまだまだ過去の成功体験を今のチームやプロジェクトに反映して評価することを一切やってない。そもそも僕の知見はほとんどがカンバンのプロセス運用なのでスクラムに適用する部分があんまりないというのも1つの理由ではある。とはいえスクラムである必要があるのか？という根本的なところも考えるには考える。まぁ、僕は今後も裏方に回るつもりなので、僕からの大きな改善があるとすればそれはチームメンバーが僕と同じことを考えたときに限られると思う。

改善に向けてやったこと

さて、その後の話し合いで改善に向けていくつかのアクションをチームメンバーと会話して定義した。

例えば議事録ドリブンでの打ち合わせやアジェンダ、TODOリストの読み合わせなどをするというアクションだ。これにより打ち合わせの認識の齟齬は減ったように感じる。ただし、中長期的な目標としてはどうしても曖昧になる場面はある。これは組織規模やシステム規模がある程度大きくなってくると顕在化するものだと思っている。このあたりはマネージャーが上司や他部署と連携して自分たちの組織の目標と自分たちのチームの目標との一貫性を都度見直す必要があると感じている。とはいえそれが簡単にできるのであればどんな組織も一律のKPIを持てるだろうし、OKRの設定についても悩むことはないはずだ。つまりそれなりに難しい。

目的は見失いやすいものだ。少しの変化も見逃さず説明と目標の共有もまた継続的に実施していく必要があるだろう。幸いなことにマネージャーは1on1の機会を各メンバーと持てるので、その場で色々と会話できるといいかもしれない。また、会社によっては360度評価だったり組織のウェルビーイングを図るためのツールがあったりするので、そのあたりを利用して問題点は何かに目を光らせるのも大切だと思う。

また、様々な意見や提案についてメンバーに決定権や判断を委ねる、もしくは相談して方向性を定めるというプロセスにも取り組んでいる(つもり)。これについてはすでにいくつかの改善提案や要望などを各メンバーから抽出し、僕が他部署や他組織へと掛け合うこともあるし、メンバー同士で「このやり方のほうがより良い」と判断したものに対しては実行してもらい、チームで評価しさらに改善しするというフローもすでに出来上がっていると感じている。これらは単純に僕らのメンバーがすでにとても自律的であることが影響しているので、簡単に真似できるかというとそうではないことに留意いただきたい。長くスクラムでアジャイル開発における基礎的な考え方が浸透しているからこそできるのである。

良かったこと

ここまで見てきたように全体的にはボロクソな結果だったなーと思うけれど、良かったことも少しはあった。

まずは機能を予定通りリリースできたことだ。新参者たちが協力を受けてがむしゃらに頑張ったとはいえ「予定通りにリリースできた」という事実は、ここだけを切り取ってみるとかなりのプラス要素である。それはつまりユーザーに対して適切な時期に機能を提供することができたことを示しているし、組織内としても組織全体が1つのリリース日をどの部署・チームともに遅延することなく完遂できたのだ。(リリース遅延や調整による延期が頻繁であった場合はより顕著にプラス要素として捉えて良いことだと思う)
おそらく今回プロジェクトに関わったメンバーの中で、プロジェクトが始まった当初から本気で6月にリリースを完遂できると信じ続けていたのは僕だけだったと思っている（他にもいたらごめんなさい……)

また、僕はリリースするまでの過程で「やらないことをやらない」という選択を何度も行った。これについては良くも悪くもここまで述べてきたとおりである。そしてそれらの「やらないことをやらなかったこと」に対するツケを誰が払ったのかといえば、他ならぬ僕のチームメンバーである。

僕のチームメンバーは自律して自走できる優秀なメンバーばかりだった。そして彼らの仕事ぶりに関しては、関わった他部署や他チームからの360度評価を見るとすぐに分かる。全員高評価ばかりだったのだ。欠点なんてなにもない。素晴らしいリーダー or エンジニアだという総評がほとんどで、任意記述コメントも称賛の嵐である。プロジェクトが一段落したあとに各組織の関係者の方々にヒアリングをしても「素晴らしい」という評価しかもらえない程度には客観的にも最高評価だった(お世辞かもしれないけど)。メンバー全員には胸を張ってほしい。そして、至らないマネージャーを5ヶ月間支えてくれてとてもうれしく思うし申し訳なく思う。

今回のプロジェクトでは、僕は誤った権限の移譲や、いろんな曖昧さを残したまま作業をメンバーに丸投げしていたことだろう。でも彼らの最高の仕事は、結果的に周りの人々を確実に幸せにしたしユーザーに最速でサービスを届けることに成功した。このことからも言えるように、僕の行動は僕が望んだものと一致しているかどうかはともかく、彼らの成長と彼らの周りからの信頼獲得に大きく寄与したということはできるんじゃないかと思う。もちろんプロジェクト全体を めちゃくちゃ前向きに捉えたら、の話だが。

ちなみに語るべくもないが、僕はプロジェクトで何も成していないので360度評価もまあまあヒドいものだった。でも、ある意味これは「狙い通り」の評価でもあるかもしれない。つまり僕が持たなかったリーダーシップや行動力のすべては、他のメンバーの高評価に変わったと捉えることもできそうだからだ。もし彼らが今よりも自律的でなかったら、おそらくこのプロジェクトは失敗していただろう。アンバランスな関係性であっても彼らがこれまで培った自律心によって、結局はチームの力が欠けた部分を補って余りある程に力強くプロジェクトを推進できたのである。

課題

今後僕に必要なのは信頼に足る発言力と行動力を得ることである。それはすなわち、エンジニア文化においては「技術力」と「リーダーシップ」あたりに集約される。
僕の場合どちらかといえば「技術力」が圧倒的に足りていないことは自明なので、そこを率先して伸ばしていく必要がある。でも、その時間が取れるかどうかは難しいところもある。そもそもの自分の役割(リーダーシップ)として不足している部分を補いながら他の不足点を補うためには、相当の努力と効率的な時間の使い方が必要だ。そしてそれは、結局自分あるいはチームや関係者に対して迷惑を掛けるリスクを多く持っている。とても難しい問題である。

とはいえ何事にも解決策はある。ひとまず短期的には自分の理想のエンジニアリングについて目標を持って取り組むことだ。目標なくして正しい目指すべき先を掴み取ることはできない。次にその目標に対して、実際に手を動かし、頭で考える機会を作ることに専念したい。これはどちらかというと本来の仕事ではなく自分の自由な時間で自分プロジェクトを作ったり、何なら副業でしがらみのない状態で純粋にエンジニアリングに向き合ったりする時間を作るということになるだろう。

個人的には「誰かを見倣う」という行動をあまり意識的にできないので、このあたりも強化したいとは思っている。例えばTwitterでフォロワー数の多い人の発言やその傾向あたりを分析するだとか、その結果を検証してみるだとかいうあたりになるかと思う。いやーしかしこれは難しそう……

あとは単純に知識の吸収とマインドフルネスあたりで自分の思考のベースをアップデートすること、および感情と行動の分離を促進させることは今後も続けていかなければならないと思っている。

最後に

僕は今回のプロジェクトを通して、再度「自分の考える最高のエンジニアリング」について考えるきっかけを得たと思う。例えばエンジニアとして必要なスキル、マネージャーとして考えるべきこと、自分より優れたエンジニアになるための目標設定などだ。これは文化を知る、文化を作る、人を知る、ものづくりを知る上で一番大事なプロセスだと今回の件で十分に理解したつもりだ。

正しいことに近道はない。僕はただ自分のチャレンジと自己満足のためにマネージャーという職に拘っていたののかもしれない。その結果色々と問題を作り出してしまったのは事実である。

ただ、こんな僕でも社内で実施されている360度評価で、たった1つだけすごく評点の良かったものがあった。

それが「チャレンジ精神」だ。

今回は失敗の連続ではあったが、みんなが僕のチャレンジを認めてくれたことの証拠かもしれない。結果的にはリリースを完遂したことだけが良い結果だったのだが、最初に自分が決めたその目標に全力でチャレンジできたことは、僕自身唯一の成功体験だったと認識している。ただ、チャレンジ精神とは別に「 目的なき「一生懸命」は、いちばん危険」という評価も受けてたので、このあたりは無駄に頑張った感は否めない。まぁ、実際は僕の中では目標は1つだったしそれに向かって一生懸命頑張った感はあるので、個人的にこれは認識齟齬の範疇かなと思ってる。そしてそれが最大の問題だったわけだけど。

最後に、今回のプロジェクトで僕と関わったすべての方々に対し心からの感謝を表するとともに、迷惑をかけてしまったチームに対してここで謝罪する。今後はチーム・プロジェクト・個人など様々な規模感でより一層の改善と成長に精進したい。