#えむけーろぐ

間違った事を書いていたらやさしく教えてください

EM4-5週目: 体調不良とサマーインターン、人の成長に向き合うことの尊さとマネジメントドメインの拡張

3週目の所感を書こうとしたら体調不良になりそこから2週間。39.4度の高熱と関節痛、咳や悪寒で新型コロナを覚悟したが、検査したら陰性。結局、喉が細菌に感染したことによる炎症が原因だったっぽい。今は回復しているが、咳が少しだけ残っている。

blog.m6a.jp

4週目は微熱や咳と戦いながら、翌週のサマーインターンの準備と体調回復に努めていた。もう、レポートラインのメンバーたちには先に宣言しておいた。今週・来週は体調不良とインターン関連で忙殺されて何も出来ない予定ですと……。彼らから見た僕はもはやただの1on1おじさんだったであろう。この週、余暇の時間はすべて体調回復に費やした。お陰で咳もほぼ収まってくれた。ゲホゲホしてる人がインターンのメンターをやるのも嫌だろうからどうしたもんかなぁと思ったが、本当に良かった。

というわけで5週目。サマーインターンのメンター業で1週間が終わった。月曜・火曜はリモート、水木金はオフィスというハイブリッド形式だった。詳しくは書かないが、僕から見る限り学生はみんな大満足で帰ってくれたようで、手応えはある。インターンの目的のひとつに「参加学生の夏の成長や学びを最大化する」というのがあり、これはまさにこの1ヶ月で得たマネジメントスキルのうちの成長支援について力試しをする良いチャンスであった。期間中は毎日、参加学生が昨日より成長することにフォーカスしてメンター業務を行っていた。

今回、メンターをやる前に1ヶ月EMとしての訓練を受けていて本当に良かった。こういう仕事を捌いていくのはむしろ得意な方だ。だけど今回は、「捌く」よりも高いレベルでメンターをすることが出来た気がする。人の成長に向き合うということを主要業務にしてから1ヶ月。本業では1週間単位のイテレーションを回していたそれを、インターンでは日報と日報へのFBコメント、そして面談を通じて1日単位のイテレーションを5セット回すというような捉え方をすることが出来ていた。学生個人や即席のチームがまさに毎日「昨日より成長する」のを見ていて、改めて人の成長に向き合うことの楽しさ・尊さを感じることが出来た。自惚れかもしれないが「EMになる前の自分だったら絶対こんなFB出来てないな」というFBをいくつもすることが出来た。マネージャーとしての1on1を何度か経験する中で少しずつ得た成長に向き合うという軸・問いかけを繰り返す中で成長阻害要因を見つけていくための話の組み立て方など総動員することが出来た。もちろんまだまだ僕自身もっと精度を高めなければいけないのだが、これまでで一番うまくメンターとして振る舞うことが出来たと思う。

 

さてそういうわけでEM最初の1ヶ月が終わった。個人や組織の成長に向き合った1ヶ月だった。特に個人の成長に向き合うことについては、なんとなく方向性を掴めつつある気がする。もちろんスキルとしてはまだまだなのだが、なんだろう、あぁこの感じでやっていけばいいんだなを掴めたというか。

一方で、手を動かすリーダーだった時はなんとなく出来ている気がしていたプロジェクトマネジメント的なところが、逆にマネージャーになってからどうすれば良いのか全然わからなくなってしまった。単に成長に向き合う方に比重を置いていたからだとか、体調不良とインターン準備が重なっていたからだとか言い訳は思いつくが、その言い訳が通じなくなる今後もどうしたらいいのかまったく検討が付いていない。ひとまず毎日朝会・夕会で「その方向でええんやで」を言う人になっている。少し手を動かす余裕が出来ればなんとかなるものなのか、あるいは手を動かさずにプロジェクトマネジメントする術を身につけるべきなのか。全く謎である。

とはいえこの壁にぶつかるのは良い兆候だとも思う。慣れてきたと書いている個の成長に向き合うというのは、ピープルマネジメントという領域に属する業務だ。ひとつのマネジメントドメインについてある程度の自信がついてきたからこそ、プロジェクトマネジメントという別のドメインに目が向くようになったということだと考えると、成長してるっぽい良い話に聞こえる。プロジェクトマネジメントってどうやって勉強するのかよく知らないが、プロジェクトマネジメントの勉強をすれば良いんでしょうという方向性が見えているのは安心感がある。

 

EM6週目はまるっと休暇をいただく予定なのと、EMになった所感をdumpするのは最初の1ヶ月位と決めていたので、この記事のシリーズは一旦終わり。ご愛読ありがとうございました。俺たちの戦いはこれからだ!*1mktakuya先生の次回作にご期待ください*2

EM3週目の所感を書こうとしたらめっちゃ熱出た

EM全く関係なくめっちゃ熱出た コロナかな 明日病院行く

というわけで所感を雑に箇条書き

  • 個の成長に向き合うことへの慣れ
  • ひとまずメンターとして行う1on1への慣れ
  • 30分の時間全力で個の成長に向き合うということはできるようになってきた
  • あとは深掘る質問や与える示唆の質を上げることだがこれはただ単に勉強不足
  • 勉強不足って言っちゃうとネガっぽいが
  • 自分の中で引き出し増やしていくこと、そのためにマネジメントや技術、ビジネスやキャリアいろんなことについて学べば良いだけっていう先が見えてるという意味でポジ
  • おすすめされた3分間コーチも読んだ。良かった。良い心構えや具体的なHowToを得られた。
  • タイトル的にちゃんと1on1の時間とか確保してる我々にはマッチしないのではと思ったがそんなことなく普通に使えるプラクティスや心構えが詰まってる
  • 次はチームの成長に向き合うことへの課題
  • 振り返りで頭フリーズ
  • KPTで出たProblemに有効なTryを出せないとか
  • どう話を運べば良いのかわからなくなる時がある
  • そういやEMなる前から個の成長に向き合うことはしてたけど、チームの成長に向き合うのはやったことないかも
  • メンバーとしてやってるのはやってるけど
  • ということでチームの成長に向き合うことについて勉強してみよう
  • ところで最近本当に自分がバカに思えて仕方がない
  • EMという役割の変化とともにチームで扱う技術スタックの変化が同時に来たため
  • これがもし役割だけ変わってチームで扱う技術スタックはRailsとかならもっと気持ちの余裕あった気もする
  • とはいえEMのJob descriptionの再現性の要件に組織や技術スタックが変わっても同様のパフォーマンスが出せることって書いてあったからまぁ初手変にハマりすぎちゃうよりはいいのか?
  • 他にも色々書きたいことはあるがスマホからの更新で指疲れたし一旦これで

 

EM2週目

EM2週目が終わった。先週、初週の所感を書いたのでこの先1ヶ月くらい毎週の気持ちをdumpしていこうかな。

blog.m6a.jp

今週は全社エンジニアのハッカソンイベントだった。自分は参加してないのだが、レポートラインのメンバー達のチームは無事受賞していた。流石!そういえば、本社の元CTOが「マネージャーは、部下の成果を自分の成果だと思うこと」みたいなのを言っていた気がする。とすると、これは僕の功績でもある!?……だとしても時系列的には元EMの功績か……。

さてそのハッカソンイベントに参加していない自分はこの1週間何をしていたかというと、ひたすらワンオペ問い合わせ対応と今後の方針の検討やら、新方針に合わせてチームが翌週以降何をすべきかの整理やらなんやらをしていた。1週目は正直今週何していたかの記憶が危うかったのだが、なんか今週はちゃんと覚えている。成長したってコト?

今後の事業や組織の方針について、今までは議論の結果を共有される形だったのが、決める側になった。大枠はゼネラルPdMみたいな人を筆頭にしたPdM陣が決めてくれているので、僕のような下っ端EMは大枠を理解し、そして自分たちの組織だったり職能だったりにアジャストする感じだろうか。もちろん大枠に対して意見してはいけないわけでもないし、求められているのだろうが、うーん、理解するので今は精一杯だ。

もうひとつ自分の心境というか向き合い方に変化があったのが、「これを理解してメンバーに説明するとしたらどうだろう」という視点で事業方針に向き合うようになったことだ。事業と現場とのインターフェースとして振る舞い、メンバーの伸ばしたいスキルややりたいことと事業の進捗をなめらかに接続するのが求められていることと思っているので、それをうまくやるにはみたいな時点で意見質問その他ツッコミを入れられるようになった。

まぁ前回の記事にも書いたとおり今はいろいろ大変革期みたいなので、「これをメンバーにどう説明するか」と同時に「これ言ったらどんな顔するだろうか」ということも考えてしまい、正直ちょっと病みそうだ。ただこれはむしろEMとして必要なことで、メンバーがどう思うのだろう・どう考えるのだろうという推測の精度を上げることはむしろ主要業務とのこと。この推測は何かを共有したときにされうる質問や反論を考えることに繋がるわけで、そうなると確かに先に推測して潰しておくというか、FAQとして自分の中に持っておく必要はあるわけだ。

以上がEM2週目の感想というか所感というかな文章だ。さて3週目はどんな感じになるだろうか。

ロードオブマネジャー

8月14日(月)の週から、エンジニアリングマネージャー(以下EM)になった。

記事とは関係ない

1週間やってみた感想を雑に残しておく。数ヶ月・数年後とか、あるいはEMの更に次のキャリア*1に進むときとかに見返せるとおもしろそう。

変わらなかったこと

  • チーム運営をすること
  • チームビルディングをすること
  • 外部チームとの窓口になること

もともとチーム運営的なところはかなり任せて頂いていたので、上記のようなところは特に変わっていない。

変わったこと

  • 1on1をメンターとして実施するようになったこと
  • メンバーの個人目標を気にするようになったこと
  • マネージャー定例という場に参加するようになったこと

まだ1週間なのでこんなものか。これから目標設定が始まったり、評価のことを考えるようになったり、モチベーション高く働けるような支援をしたり。そういったことをするようになると思う。

前述の通りチームビルディング的なところはずっと仕事としてやってきていたので、今のところ大きく感じる差分はメンバー個人の成長に対して責任を持つようになったというところ。とはいえ、EMになって新しく増えた仕事に関しては、僕の上長が伴走してくれる。かなり心強くて助かる。

その他雑に

メンバーとして入社し1年半くらいやってからEMになるというのは、既にある程度信頼関係の出来ているところでマネジメントの経験を積めるということ。これはかなり心強いことだと思う一方で、お互いにちょっとやりにくいというか、戸惑うところもあると思う。

ちょうど良いタイミングなのか悪いタイミングなのか、今は組織の大変革期にあるようだ。短期での色々な変化に、自分がついていくことすらも大変だ。これからは、自分がまず理解し納得した上で、組織全体とチームをつなぐ必要がある。いきなり完璧に出来るとは思っていないが、試行回数を増やさないと一生うまくなれない。いろいろとアクションを起こしていきたいと思っている。

自分は結構、変なプライドが高いというか、まわりの人に「この人はいろいろうまくやってるな」と思われたがりなところがある。だが、マネジメントという仕事に関しては新しい仕事すぎて、もはやそんな変なプライドを持ってしまう余地がない。これが逆にいい感じに作用してくれて、うまくいかないことどうすればよいかわからないことはどんどん上司や他のマネージャー達に聞くことが出来ている。今後ある程度慣れてきても、この姿勢は継続していきたい。これは弱みを晒すってことではないし、うまくいかないからといって叱責するわけではない、問題が小さいうちに共有すべきみたいなのは上司にも釘を刺されたところだ。

コーチングのスキルについて

まずは、新しく増えた仕事である個の成長に向き合うということに貪欲にチャレンジしていきたい。そのために必要なスキルが、コーチングスキルだ。

1on1めちゃくちゃおもしろくて、僕と部下の1on1のはずが、僕の上司も同席してくれている。なんだそれ、1on1on1じゃんとか思うが、これがなかなか良い。30分の時間のうち、25分は普通に僕と部下で1on1をして、最後の5分で僕の上司から1on1全体に対するフィードバックを頂ける。「◯◯と返したところ、自分だったらこう返すかな。この方が、個の成長に向き合うという1on1の目的に即しているので」とか、「これは組織の振り返りの話だから、レトロとかでやれば良い、もうちょい個の成長の話をしよう」とか言ってくれる。ただの雑談の場になってしまいがちで、かつその状態に対するフィードバックをもらえないがちな1on1を通じて、こうしてコーチングスキルを日々磨いていけるのはとてもありがたい。

チームの振り返りの場にも同席してくれている。1on1が個を対象としたコーチングの場であるならば、振り返りはチームを対象としたコーチングの場だ。もちろんチームには僕も含まれているので、実は1on1よりも難しいかもしれない?上司の受け売りで、振り返りを正しくワークさせることがチームを強くすることに繋がると信じている。現状僕の認識は振り返り=KPTみたいなかなり低いレベルにあるので、勉強していこう。

おわりに

というわけで、EMファーストインプレッションをここに残しておいた。

この記事は土日に書いているし、金曜に上司との1on1をしたなこともありウキウキ気分な記事になってはいるが、ぶっちゃけしんどいこと・しんどそうなことも多い。

とはいえEMをやってみることによって得られるものは大きいと思っているので、まずはいろいろと楽しみながら試行錯誤していければなと思っている。

www.youtube.com

*1:単にVPとかCXOとかだけでなく、マネジメントやらないという方向に進むかもしれない

Podcastの配信システムを自前のものから別の配信サービスへ移行した #yuru28

Podcastの音声配信を、Rails + S3 / CloudFrontで構築していた自作のものからART19に乗り換えた。

移行前のシステムについて、まとまった文章を書いたことがなかったなぁと思ったのでメモがてら書きつつ、今後どうART19と並行運用していくのか、みたいな話を書いていこうと思う。

旭山動物園(北海道旭川市)にいたあひる ※記事とは関係なし

はじめに

学生時代の友人と趣味でやっているゆるふわPodcastは、Webサイトから音声配信、管理画面や分析ダッシュボードまですべて自前で開発・運用していた。

yuru28.com

当初はWebサイトをJekyll + GitHub Pagesで構築・配信し、音声配信はSoundCloudにおまかせという感じだったのだが、「仕事でRails使うし自分でメンテして好き勝手にできるRailsアプリを持っておきたい」というモチベーションでWebサイトや音声配信システムを自分で開発・運用していた。

最初のcommitは2020年4月

自作の配信システム + Podcast CMS

自作の配信システムの概要はこうだ。下図で示したのは音声配信の仕組みのみだが、WebサイトやPodcast CMS(Vue製のSPA)向けのAPIも同じRails Appに同居している。

Podcast 音声配信システムのシーケンス図

音声配信を自作したモチベーションは、冒頭に書いた通り技術勉強が大きな割合を占めている。それに加えて、音声配信を自身のコントロール下におきたいというのがあった。

音声配信を自作すると、コンテンツの設定・配信まで一連の作業をすべて手中に収めることができる。「音声を別のプラットフォームにアップロードし公開予約をしたあと、Webサイト側は別でページの公開設定をして……」といった作業、「現状の再生数やリスナー数を知るために、Apple Podcast ConnectとSpotify for Podcasters、Google Podcasts Manager、その他諸々……の数値を足し合わせて集計する」といった作業から開放される。

音声ファイルの公開予約とエピソードのWebページの編集・公開予約は同じ画面で簡単に設定できるし、プラットフォーム横断で再生数を取得し、自分の好きな単位(時間・日・月や曜日ごとなど)で集計するなんてことも簡単なクエリを書けばすぐに算出できる。

自作したPodcast CMS
Podcastの分析の様子(Redash利用)

この配信システム + Podcast CMSは、自分が開発者であると同時に、自分が最大のユーザーである。自分の作業を改善したいとなったとき、新しい技術を試したいとき、誰に依頼するでもなく自分でいろいろできるのはとても楽しい。

過去に、この配信システムについて発表したときの資料がこちら。
※ 当時はAmazon Lightsailのオブジェクトストレージを利用していたが、AWS S3の方が安いしラクということに気がついて乗り換えている。

speakerdeck.com

下記にいくつかシステム開発の記録の記事を貼っておいて、移行前の配信システムの話は終わりにしようと思う。

blog.m6a.jp

blog.m6a.jp

blog.m6a.jp

移行の動機

ここまでで書いた自作の配信システムだが、実は2023年6月から、音声配信部分を別システムのART19に移行している。ART19は、Podcast配信と収益化のSaaSで、2021年にはAmazonに買収されている。

www.itmedia.co.jp

移行の理由は、Podcastのプロデュース等を行っているスタートアップPitPaさんのエンジニアPodcastネットワークに加入させてもらったからだ。

prtimes.jp

2023年7月以降、ゆるふわPodcastのエピソードを聞くと音声広告が挿入されていると思う。時期によって適切なコンテンツを動的に挿入しているのだが、これはART19のシステムを利用して提供しているため、自作していたシステムも乗り換える必要があったのだ。

並行稼働期の概要

というわけで、音声配信部分のみRails Appで提供するのをやめて、ART19に移行する必要が出てきた。とはいえ、Webサイトはちゃんと活かしたい(自分のドメインで配信したい)ので、そっちは引き続きCMSで管理しRails Appから配信する必要がある。つまり、自作のシステムとART19の並行稼働が必要になるわけだ。

音声配信の部分は、自分で配信していたRSSフィードへのアクセスをすべてART19にリダイレクトすることで解決した。下記のようなイメージだ。

Rails App / ART19並行稼働時のシーケンス図

一方で、「音声を別のプラットフォームにアップロードし公開予約をしたあと、Webサイト側は別でページの公開設定をして……」という作業が増えてしまった。幸い、ART19は開発者向けのWeb APIを提供しているため、利用させてもらうことにした。

用意されているのは参照系のみだったので、ART19 -> Rails Appという片方向のみの同期を行い、RailsのDBにはあってART19には無い項目(出演者情報など)を手動で入力するというオペレーションの改善を行っている。

ART19 -> Rails App同期のSlack通知を起点にRails App上で追加の操作を行う

RailsのDBにはあってART19に無い属性(スピーカー)は手動で管理画面から埋めている……

今後

Podcastとしてコアの部分である音声配信を外部のプラットフォームに任せてしまっているので、正直サーバーサイドを廃していわゆるJamstack的なWebサイトにしてしまっても良いと思っている。

が、オペレーションの改善は続けつつ、ART19とRails Appの並行稼働は続けたい。

Podcastという趣味で使う道具を自分で作って改善していくということは続けたいし、それをRailsという大好きなフレームワークで出来るということに大きな意味があると思っている。まぁ、企業の営利目的の事業だとそんな話通じないだろうけど……趣味なので、いいでしょう。

とはいえ現状のようなART19上で設定してRails Appで追加設定するなんてオペレーションはさっさとやめてしまいたい。データはすべてART19からsyncするようにして二重オペレーションを無くしつつ、Podcast以外の付加価値の部分(例えばサポーター向けのWebサイト。現状文字起こし検索しかない。)を拡充していくとかが落とし所かなぁ。

おわりに

気がつけば今年の5月で4周年を達成していたり、先日はEP200を達成していたりと、よくもまあこんなに続いているもんだと思う。こんなにもPodcastが続いたのは、いつも一緒に収録してくれているメンバーや、出演してくれるゲスト様、そして聞いてくれているリスナーのみなさんのおかげだ。それと同時に、「自分の趣味で使う道具を自分でつくる」という、一種のDIY的な要素がめちゃくちゃ楽しかったというのがあると思っている。

今後も楽しくPodcastとものづくりを並行して続けていければなと思う。

「さすが○○出身なだけあるね」と言われるようなチーム

特に意味のない牛(星野リゾート トマムにて)

僕のチームの後輩氏について、何をするんでも事前のお膳立てをしっかりやるタイプだな〜と思って見ている。チームに新しく何かを導入するとき(開発プロセスに関するもの・アーキテクチャ等技術に関するもの問わず)、必ず定義や考え方とそれらをこのプロジェクト・チームにapplyするとなったらこうしましょうみたいなのが書かれたガイドのドキュメントを用意して、読み合わせしてくれる。

それはものすごく素敵なことだよなぁ、というのを今日上司との1on1で話したら、それは彼が元いたチームがみんなそうしてたからってのもあるとのこと。5月頭に書いた長文にもある通り、今のチームは4月に新しく出来たチームで、所属メンバーはみな前職ならぬ前チームがあるのだ。なるほど彼は前チームで得たやり方を自身の血肉とし、しっかりこのチームでも実践してくれているというわけだ。

思えば彼の元いたチームは、各種プラクティスをまずは定義から原理主義的に、僕の所属企業でよく使われる言葉で言えば「守破離の守」をしっかりやる文化のチームであった。もちろん彼自身の素質とか努力とかがベースにあってのことでそれを否定するわけではないのだけど、「さすが○○チーム出身なだけあるな〜」という感想を抱いた。

エンジニア組織をつくる文脈で、「いつかこの会社を旅立ち別の会社に転職していく人たちが、『さすが○○出身だね』と言われるような組織を作りたい」みたいな話をしていたりするのを見聞きする。ちょっと前には「○○マフィア」みたいな呼称も流行ったり*1。「さすが○○出身なだけあるね」と言われるような会社や、その状態を目指す会社はたくさんあるけれど、自分がいま関われる範囲でいうと、そういう状態のチームを目指すっていうのはひとつの指針としてありだなぁと。

かれこれこのチームも3ヶ月弱やってきて、スクラムの各スプリントについて、透明性・検査・適応のループを回していきながら日々自分たちの仕事・プロダクトを改善していくという流れには乗ることが出来てはいる。直近は属人化解消なんて言い訳をつけてスクラムマスター交代制みたいなのをやってみている。その取り組みの目指すポイントとして、いつかこのチームが解散してメンバーが散り散りになったとき、「さすが○○チーム出身なだけあって、良いスクラムマスターをしてくれているね」なんて言われるようなそんなチームにする、というのを設定してみても良さそうだなぁと思ったのであった。

近況:チーム開発、チームビルディング

最近は開発チームのリーダーを任せてもらいみんなでワイワイ楽しく仕事をしている。

特に意味のない青い池(北海道 美瑛町)

4月から結成されたチームで、最初の1週間はスプリントゼロと称して設計とドキュメンテーション、チケット作成・見積りを進めた。全員で同期的に、だ。2週目は実装に進んだが原則全員でモブプロ。3週目には二手に分かれて原則ペアプロで開発を進めた。4週目にはペアプロを基本としつつも、スプリントゴール達成・スプリントタスク完遂のために最適なアロケーションを適宜試す、みたいな感じでやっていた。結果、かなり良い雰囲気でチーム開発を進めることが出来ているような気がする。

 

これまで在籍してきたチームでは、スキルセットやドメイン知識、コードベースの理解の偏りがあり、タスクがお互いに交換可能になっていないという、いわゆる属人性の高い状態が続いていた。その状態を脱しようといろいろと施策を試してみても、いろいろな理由で結局うまくいかない。これは現職に限らずどこの職場でもそうだった*1

スキルや知識の平滑化には時間と体力がいる。一人で気持ちよくコードを書く時間を捨ててペアプロ・モブプロをするのは大変なストレスのかかる行為*2だし、さっさとコードを書いてリリースすれば良いと思ってしまうような実装タスクについてチケットを書くのはひたすらにめんどくさい。互いに「自分がやった方が早い」「○○さんにやってもらった方が早い」と思っているチームにおいては、多大な労力をかけてスキルや知識の平滑化をしたとして「その先に何があるの?」がよくわからず、このコストをかけることへの納得感が醸成されないのだ。

結果、スプリントゴールに紐づく重大タスクなのに1人しか出来る人がおらず、重大タスクにアサインされたメンバーが爆死するのを指をくわえて見つめることしか出来ないチームメイト……という構図が出来上がっていく。もちろん、代わりに問い合わせ対応を取るとかそういう間接的(かつ、超重要!)な貢献はしているのだけど。

 

そんな中、4月から新しいチームで新しいプロダクトを作るというチャンスが舞い降りてきた。しかもリーダーを任せてもらえるということだったので、これは大チャンス。というわけで、冒頭に書いたような進め方をやらせてもらった。まずは遅さを許容し全作業を同期的に全員でモブプロ・モブ作業するという制約を設けた。チーム内での目線を合わせるためだ。ここでいう目線を合わせるとは、開発対象の事業やプロダクトはもちろん、プロセスや互いのスキルセットなどチームに関わる全てだ。そしてみんなの目線が合ったところで徐々に制約を外しつつ、最終的にはその瞬間で最善の手をチームで話し合って決めて取る、というやり方をとった。

その瞬間の最善を取る、を愚直に実行しているので、さっきまでやっていたタスクのペアを組み替えてやる、なんてこともある。そういえばスプリント初日に切ったチケット通りではうまくいかないということが判明して、いきなりチケットの書き直しをしたこともあった。それでもコンテキストスイッチのコストを最小限にすることが出来ていると思っている。これはスプリントゼロで設計・ドキュメンテーションをじっくりやったことに加えて、開発開始以降もチケット作成・見積りやプランニングにしっかりと時間をかけてみんなの目線を揃えたからこそだ。

スクラム開発の三本柱に透明性・検査・適応というのがあるけれど、この1ヶ月はまさにこのループをうまく回せていたんじゃないかという気がしている。やるべきことについてみんなの目線を揃えチケット化するというのは透明性を確保するということだし、透明性があれば問題が小さなうちから検査で発見することが出来る。正しい検査で小さなうちに問題を発見できれば、それだけ適応もしやすい。透明性・検査・適応が大事、という話はそれこそ耳にタコができるほどされてきたけど、それらが担保された状態がどういうものなのかを体験したことがなかった。そして今回、体験することが出来た。

これは僕たちチームにとって非常に大切な成功体験だと思う。僕に進め方を任せてくれた上司、スピード低下を受け入れ属人性排除のためのチャレンジをすることを許してくれたPdM、そして常に自分たちの仕事を良くしたいという気持ちを忘れず、共にプロセスにフォーカスして改善することに付き合ってくれたチームメイトに感謝だ。

あとは、この流れを今後も継続し改善していくことが重要だ。正直、今回は新しいチームかつ全く新しいプロダクトでまっさらな状態から始めることが出来たからうまくいった(と思っている)だけなのでは感もある。だから、今回得た成功体験を元に、なぜうまくいったのか・もっとよく出来るところは何かを振り返って、再現性を持たせる必要がある。たまたま今は新規プロダクトの開発に集中させてもらっているけれど、徐々に既存プロダクトの改善や運用保守業務も入ってくるし、この新規プロダクトですらしばらくしたら改善フェーズに入っていく。チームのメンバーだって今のまま変わらないとは限らない。

 

人間にとって、これまでのやり方考え方を変えるのは非常にコストがかかる。他人から求められるならなおさらだ。今までの僕は人にやり方考え方を変えることを求めるばかりで、そのコストを払ったその先についてきちんと説明出来ていなかった。今回のこの体験によって、コストを払ったその先のベネフィットを得ることが出来た。これで今までよりは少しくらい高精度な説明が出来るようになるだろう。

この1ヶ月とても大変だったけど、上記の成功体験を得ることが出来たのは、僕のキャリアにとって、そしてチームにとってなかなか良い通過点だったと思う。

*1:無駄にいろんな職場を見てきたおかげで、こういうことを言うことが出来る。偉そうに。

*2:ちなみに自分の場合は一人でコードを書くよりもペアプロの方が圧倒的に早い……。。