2021.10.02 テニスの記録

熱中症になりかけた

 日差しがあって気温も25度は超えてるけど風が少し冷えるかと思い長袖長ズボンでテニスすることにしたが、たぶんこれがいけなかった。テニスが始まると風はあるもののさほど冷たくはない。なんか体力落ちたかな、すごいバテるな、とか思っていたら「顔が赤いですよ」と終わった後に言われた。そこで初めて熱中症になりかけてたのかもしれないと思った。

 今日のコーチは比較的強めな球を打ってきて、足が止まらないように頑張れと追い込んでくるタイプの人だった。自分がクラスの中では比較的打てる方ということもあったかもしれないが、こちらが絶妙に届かないところとか、反応が遅れると打ち損じるような球を打ってきた。個人的にはこういう練習のほうが体力も付きそうなのでありがたいが、他の人はどうだったのやら。自分より年配の人とかもいるので倒れないかと心配になってた。

 今回も前回同様、比較的サーブはミスが少なかったが、熱中症気味ということもあってか、以前気をつけていた3点をちゃんとできていると感じた頻度は少なかった。最後の方に肩が上げにくいなとも感じたので、体力は引き続き課題になりそう。

 ストロークにおいて指摘を受けたのは、少し高めのボールに対して、落ちきるまで待ってから打つのではなく、高い打点で可能ならば打ち込むように攻撃的な返球ができると良いという点。おそらく、高い打点で打つと失敗する可能性が上がると思って、無意識にボールが落ちきるのを待っていたのだろう。しかしこのままだと攻撃的な返球ができないままなので、相手に圧力をかけられない。今後は意識して高い打点で打てるときはしっかりと前に出ながら打ち込めるようにしていこう。

 指摘を受けたわけではないが、今回はボレーがうまくいかなかった。ボールに反応できて入るものの、早い返球がこちらもできておらず、相手にとってチャンスボールになってしまうことがしばしばあった。ボールがラケットに当たったときにラケットをしっかりと握って固定することがまだちゃんとできていないからだろう。ボレーはずっと苦手にしているので基礎からなんとかやり直して相手にチャンスを与えない状態にしたいところ。

 ラリーをしている最中に足を滑らせて盛大にすっ転んだ。特に怪我はしていないがかなりびっくりした。慌ててコートの外に逃げてった。今日は熱中症になりかけたりと厄日なんかもしれん。

社会人10年の振り返り(6年~10年)

 前の記事の続きになります。入社してから6年ほど、自信は打ち崩され仕事の面でも大きな成果が出せず、評価は並といった状態が続いた。チームとしては技術力が高く会社への貢献度合いもある程度あるものの、自分は何もできていないという思いが強まっていた。

 新しいHadoopクラスタの構築は先輩方の努力のおかげでなんとかリリースでき、運用フェーズとなってしばらくして、利用者が増えてきたことによる運用コストがチームの課題となっていた。以前自分はHadoopクラスタを利用する立場であり、利用者側の状況もある程度想像がつくだろうということで、運用コスト削減を目的としたチームを組み、自分がそのリーダーという立場になった。率先してリーダーになったというわけではなく、立場を変えることでなにか成長のきっかけが得られないかという試験的な面と、もしもうまくいくならチームとしても嬉しいし、うまくいかなくてもさほどダメージはないといった、わりと消極的な背景から与えられた環境であった。それでも、自分が不甲斐ない働きをすれば自分のチームに配属された人にも悪影響が出てしまうので、やれることをやろうと意気込んで取り組んだ。

 6~8年目、リーダーという立場によって今まで経験したことのないタイプの業務を経験した。特にメンバーとのコミュニケーションに関する業務、キャリアについて一緒に考えたり、成長のポイントはなにかを相談したり、今までプロダクトを対象に観察していたが今度はこれが人になった。これが自分はうまくできなかった。チームと言っても用意された人員は自分を含めても3, 4人、決してメンバーが多いわけではない。ひとり若手がいて、他は自分よりも年配のシニアエンジニア。若手とのコミュニケーションでは、仕事へのモチベーションを上げてもらうことに苦労した。コーディングをたくさんして開発がしたいと本人は思っているが、配属されたのはHadoopクラスタという大きな箱の構築と運用がメインのチーム。運用コスト削減のためにツール開発はあるものの、それは若手のモチベーションを大きく引き上げるような仕事ではなかった。程なくしてこの若手は、担当したツールをリリースした後、よりコアな社内ツールの開発をするチームへと自ら志願して異動となった。仕事を通してなにか成長の手助けができたのか今でも疑問が残り、申し訳ないという気持ちもある。

 年配のエンジニアのうちひとりは、そもそも運用コスト改善のチームへの配属が、自身のスキルセットに対してあっていないと考えており、この配属に対して不満を示していた。運用コスト改善は主としてツール開発をすることになるのだが、この人のスキルセットは運用に関するスキルが広く、そして深い。異動をしてもらった理由のひとつに開発をしてもらうことでさらにスキルセットを充実させ多様なキャリアを目指せるようにしようという狙いであったが、本人にとってはこれが余計なお世話だった。スタートから関係性が良好ではない状態で「コミュニケーションにおいて、伝え方などを改善するとより評価が上がるのではないか」といった提案をしたときに「コミュニケーションにおいて私に課題があるならもうやりとりはしなくてもよい」と突っぱねられ、しばらくは最低限の業務連絡以外のやり取りを拒まれる状態となってしまった。他の年配のエンジニアの方も、自分より十分にスキルがあるものの、昇給昇進などに興味を示していない人たちだったため、最終的には業務連絡以外の人事的な相談というのは実施しない状態となった。あまりチームとして良い状態とは言えなかったものの、技術の高い人達が集まってはいたので、自分がタスクの細分化とその計画をしっかりと用意すれば、タスクを期限内に消化するということはできていた。アウトプットが出ているだけに「まぁキャリアやモチベーションは本人に委ねなければならない部分もあるか」と割り切った考えもするようになっていた。しかしこのチームが良いチームとも自分から言えない状態だったので、ある程度区切りが良いところでチームを解散することを上司に提案し、自分は再度役職のない状態に戻った。Hadoopクラスタの運用業務を中心とした仕事にしばらくは没頭し、他人の将来を考える必要がないことに少し安堵していたと思う。自分は他人への興味関心が低いのだとこの期間を通して実感した。

 8~9年目、上司からこんな2択が投げ込まれた。

「今のチームで続けるか、隣のデータ可視化チームにヘルプとして移るか、どっちがいい?」

隣のチームではGoogleAnalyticsのようなものを内製で用意し、自社の様々なウェブページからログをHadoopクラスタに集め、集計、可視化するといったことをしていた。入社時に自分が配属されたチームと似たようなことをしているが、使用しているソフトウェアなど環境はだいぶ異なるものだった。このチームの特に集計部分の人員が足りておらず運用がきちんとできていないということだった。上司には「どっちでもいいですよ」と回答していた。今のチームで大きな貢献はできないかもしれないが、ベースの技術力が高いチームなので、しがみつき続けることで個人として成長は可能だろうと思っていた。一方で仮にヘルプに入る場合、触れたことのないソフトウェアの知識を得ることができるため、Hadoopに偏ったスキルセットをより広いものにできるかもしれないという期待もあった。どちらも悪くはないだろうと考えてはいたものの、明確にこちらが良いと言えるほどの差はなかった。というよりは自信がないことでどっちに転んでもそこそこの成果しか出せそうにないだろうな、と消極的に考えていた。

 隣のチームへの異動が決まった。このチームにとっては待望の助っ人がきてくれたという嬉しさがあったようで、かなり丁寧にもてなされた。この期待が自信のない自分にとっては逆に怖かった。期待を裏切れないというプレッシャーがのしかかってきていた。問題の集計部分について、チームの人にレクチャーを受けながら状態を調べていったところ、とにかくやばかった。使われているソフトウェア(Apache Druid)は本来想定されていない使われ方をしており、ソフトウェアに適さないサーバの選出、集計において必要になるCPU・メモリ・ディスクは無駄に消費されてコストが掛かっている。想像以上にやばかった。とんでもないチームに入ってしまったと後悔した。しかもこれがすでに定常稼働して社内向けとはいえサービスを提供しているというのだから驚愕だった。一回停止して設計からやり直したい、設計した人を殴りたいと思った。データプラットフォームと言われるようなデータを毎日変わらず提供し続ける環境を、動かし続けながら、設計段階で見落とした問題解消のために改善しようと思ったとき、設計時よりも十倍、あるいは十数倍のコストがかかると言われている。まさにそのコストがかかる作業をやらなければならないのだ。こうなった要因として見えてきたのは、設計者が Apache Druid というソフトウェアを使用することを重視して物事を進めたということ。手段が目的となって進められたせいで、本来実現したいことはいびつな形で、かなりコストがかかる状態でなされていた。エンジニアにはこういった事はよくあって、興味のあるツールを知ると使いたくなる傾向があり、他の手段をきちんと検討しない手抜きの設計によって運用のフェーズで多くの人を困らせることになる。チーム内でこれをきちんと指摘する人がいればよかったのだが、設計段階で指摘を受けたという話は聞かれなかったので、チームに対する不信感が芽生え始めていた。

 チームの異動に際して、自分には以下の3つのミッションが課せられていた

  • 集計環境の改善
  • 集計にかかるコストの削減
  • 他チームとの関係改善

集計環境の改善、コストの削減は、すでにあるものを動かし続けながらひとつずつ直してくという作業になるのだが、最後の「他チームとの関係改善」というのがまた面倒なものだった。当時集計について担当していた人が、Hadoopクラスタを運用するチーム(自分がもともといたチーム)やプロダクトの関わるチームとのやりとりにおいて、自身のやりたいことが通らない場合に態度が悪くなり、チームとしての印象を悪くしてしまっているという問題があった。これを当の本人はあまり自覚しておらず、なまじ知識や技術があるために同じチームのメンバーは指摘がしづらい(なにか言っても持論を展開して面倒になるので避ける)という状態だった。他チームとの集計に関するコミュニケーションの窓口としてこの人が立ってしまうと関係が改善されないので、代わりに自分が担当するということになった。さらには、問題となっている人にきちんと発言できるのが社歴やスキル的にも自分のみなので、他チームとの関係悪化の要因があなたの話し方にある、というのをどこかで伝えて自覚さなければならなかった(自分がいつまでも窓口になるわけにはいかないため)。これはさすがに上司がやれよと思ったが、理詰めで話してくる相手に対して辛抱強く耐えるコミュニケーションを上司が得意としないため、自分がやらざるを得なかった。

 環境の改善、コストの削減、やり始めてみると新しいソフトウェアについての知識を得ることが楽しく、物量はあったもののその分やりがいを感じられるものではあった。集計という大きなしくみ全体を自分に丸投げされたものの、逆に自分のペースでことを運べることができ、同じチームの他のメンバーの作業の影響も受けにくいものだったので、周りを気にする必要もなかった。集計の問題の人物とときおり考え方の違いで議論することはあったが、以前のように泣くほどヒートアップすることはなく、むしろ向こうが「好きにすればいいんじゃないですかね」と話を打ち切るので、言われたとおり好きにやらせてもらった。この人の設計ミスやつたないコミュニケーションの尻拭いを自分がさせられていると考えると気分は良くなかったが、自分のやったことで確実に環境が良くなっていくというのは楽しかった。他チームとの関係改善については、今まで業務で関わった人が多いこともあり、窓口が自分となったときに過去の経緯を聞きつつ「あの人の言うことはさておき実際はこうしたほうがいいよね」というやりとりでだいたいは解消された。問題の人物には「途中で議論を投げ出すと関係性は悪いままだ」ということを議論を投げ出すたびに言い続けたところ、相手の意見を聞く姿勢が少し出てきたように思う。1年ほどかけて Apache Druid を含む使用しているソフトウェアのバージョンアップや集計コストを大幅に削減でき、運用の体制も整い始め、上司からも信頼を得られて昇給もあってと、異動前に想像していたよりは良い状態に持っていくことができ、少し気持ちも上向きになっていた。

 9~10年目、上司とチーム体制が突然変わった。以前記事でも書いたが、自称スクラムマスターと新リーダーによってもたらされたチームの変化は、自分にとっては理不尽かつ負担が大きいものであり、チーム内不和を生む要因となった。集計の運用体制を1年かけて作ってきたにもかかわらず、チームのあり方を変えられたことにより、運用体制も一度白紙に戻され、結果としてこの期間の集計に関する運用はほとんど自分が手を動かすことになった。みんなで開発も運用もできるようになろう、と掲げられて体制が変わったのだが、そもそもみんなが運用できる準備ができておらず、準備のための時間もほぼ取られることはなかった。この体制変更はさすがにマズいだろと指摘し代替案の提案もしたが、検討しますと言われただけで行動に移されたことはなかった。他のメンバーはこの状態に対して声を上げることはなく、自分ひとりが騒いでいるような構図となってしまい、チーム内で孤立した。転職を本気で考えた。新しい環境に対して一定の知識を身につけた自分にとって、このチームに居続けることはもはやメリットはなかった。

 チームに対しての不信感が高まっているとき、会社内で人員募集の知らせを見つけた。業務内容はAWSを使用したクラウドベースのデータプラットフォームの構築・運用といったもので、自分のデータプラットフォームに関するスキルセットと重なるものがあった。これまで実機(オンプレミス)をベースとした環境での業務経験が多い一方で、世の中ではクラウドベース、サーバレスの環境開発が増えてきているので、どこかでこういった環境を対象とした業務を経験しておきたいと考えていた。まさに自身の成長という点においても、この人員募集の内容はとても魅力的だった。すぐに応募を投げてた。1人しか募集していないというのが不安ではあったものの、こういう人材が世の中に少ないということも知っていたので、たぶんいけるんじゃないかなぁとだいぶ楽観視していた。めちゃくちゃ偉い人との面談で少しやらかしたかなと感じる点はあったものの無事通過。募集がかかってから1ヶ月かからずチームの異動が決定するという異例の早さだった。良縁というのを実感したように思った。異動した後どうなるか次第な部分はまだあるけれど、つらいチームを抜けられる、新しい挑戦ができるということが自身のモチベーションを引き上げた。

 そして現在、自分は無事にチーム異動を果たし、新しい環境での仕事ができるようにたくさんの資料を読み進めている最中となる。今これを書いている日が異動して初日なのでまだまだこれからといった状況。前のチームはヘルプで入ったという形だったので、自分ごととしてとらえきれなかったという気持ちも正直あったが今回は違う。上司に当たる人も今回はその名が業界で広く知られている実績をのこし、行動指針について明確な価値基準を明示している人。以前のチームの上司やスクラムマスターのようなことにはならないだろう。チームへの不安を抱くことなく新しいことを学びながらプロダクトの成長に貢献することに没頭できると信じたい。

 長々と3パートに分けて振り返ってみたが、気持ちの浮き沈みが激しく、特に下がるときは急降下していっているなと改めて確認した。主たる原因が環境によるものならまぁ仕方ないとも思えるが、リーダーになったときや成果が思うように出せていない時期とかはまだなにかやりようがあったのではないかと思い返すことが何度もある。自信がなくなったのと同時にどこかで、自分にはできないだろうと無理をしないような振る舞いを続けていたものと感じる。仕事に対して真剣に向き合わない結果、良い循環が生まれず気持ちもなかなか上向きにならなかったのだろう。これを繰り返さないためにも、新しい環境では常に考えることを止めず、自分のできる精一杯を出し続けるようにしていきたい。

 これを書く当初、データエンジニアとして長くやってきて、データを扱う環境がこうなったよね、みたいな話になるかなと思ったが気持ちの面を思い返すばかりだった。改めてデータ周り、特に大規模なデータを対象にした集計環境について振り返ってみると、最初に属していたチームで実施していた集計と、ヘルプで入ったところで実施していた集計は、使用しているソフトウェアが違うだけでほとんど同じような集計を実施しているというのが個人的には印象深かった。ヘルプで入ったところの集計をみたときに、この集計の問題点は5年以上前に自分が設計したときに抱えた問題点とほぼ同じであることがわかり、同時にソフトウェアがいくら高度なものになったと言ってもみんな同じような課題にぶつかるのかと、集計を担当する部門の進歩の無さに落胆したものだった。データの利活用については会社として早い段階で取り組んではいたものの、おそらく設計当初、集計環境について構築や運用を長く経験した人はこのチームにいなかったのだろう。データの集計を長期に渡り構築・運用することは、精神的にもかなり負担がかかる。自分もHadoopのチームに移ったひとつの要因がこの精神的負担だった。扱うデータは大きくなるが、必要なコストは下げなければならない。運用フェーズに新しく入ってくる人にとってはトラブル対応が主な仕事となってしまい、何かを作りたいというエンジニアが残り続けることはほとんどない。業務委託や契約社員のような外部の人を雇う形でつなぎとめることはできるが、いずれソフトウェアが古くなってきたときに対応ができず、止めざるを得ないだろう。データエンジニアとして長期役割を担える人はとても貴重だと思う。だからこそ自分に当初ヘルプが投げられ、新しいチームでも人が必要になったのかもしれない。この領域で頑張り続けることが自分のデータエンジニアとしての差別化できる可能性なのかもしれない。

 ここまですべて読んでくれた人がどれだけいるだろうか。自分の振り返りが主目的なので、読まれることをあまり想定せずに書いており読みにくい部分もあったろうと思う。それでもここまで読んでくれた人にはただただ感謝しかない。こういう10年をみんなはどのように感じるのか聞いてみたい気持ちもあるので、もし筆者と話す機会がある人は、率直な感想を聞かせてもらえると嬉しい。いろんな考え方を知ることで、今後の10年を少しでも良いものにしていきたい。

社会人10年の振り返り(3年~6年)

 前の記事の続きになります。入社してから3年ほどは順調にステップアップできており、成長に応じた仕事の任され方もされ、仕事に対する不満というのはほぼない状態でした。この頃から、所属しいるチームのみならず、周辺のチームとのやり取りをする機会が増え、より広い視野で仕事を見るようになった。ここからの3年が自分にとってひとつの大きな転機だったと感じている。

 データを集計し可視化するチームは自分の所属するチームのみではなく、目的ごとに様々なプロダクトがあり、プロダクトを管理しているチームがそれぞれ存在していた。これらのチームがひとつの部署にまとまっており、アクセス解析ツール開発といった総称になっていた。この部署の中で集計に関するバックエンド環境を一新しようという取り組みが始まり、自分もそのプロジェクトの一員として参加させてもらえた。普段のチームメンバーとは異なり、各チームの集計関連プロダクトの開発・運用実績のある人達が集まっていたので、どんな話ができるのかという期待と、自分はやくにたてるだろうかという不安があいまった心持ちでいた。

 実際にプロジェクトが始動して、古株のエンジニアがリーダー的な立ち位置になりいろいろ相談を進めたのだがなんとも状況がよろしくない。その時の自分は良くない雰囲気を感じ取りながらも何がどうだめなのかというのを明確にすることができず、行動を起こしてみるも空回りというのを繰り返していた。今改めてこの時の状況を振り返ると、プロジェクトに参加したメンバー全員が、バックエンドを一新する必要性については理解があるものの、バックエンドをどういう状態に持っていくのが良いのかということが考えられていなかった。多くのログを受け入れられるようにすればいいのか、それとも集計に関するアルゴリズムを見直してコストを下げるべきなのか、いくつか課題はあがるもののそこに適切に優先順位をつけられておらず、それにより提案が上がっても良し悪しの判断ができない(判断基準が明確ではない)といった状況に陥った。自身の実力不足を知るひとつのきっかけでもあるが、アクセス解析ツール開発にいる古株エンジニアがこれというのもどうなの?という疑問も同時に湧いた。この部門に居続けることへの危機感のようなものをいだいた。

 この状況を見かねてか、隣の部門の方々の協力を得られるようになった。この部門はデータを集約するための仕組みを構築・運用することを主としたチームが集まった部門。ウェブページで発生するたくさんのログデータを、できるだけ漏れなく、できるだけ早く、できるだけ大きな箱に集約し、自分たちのようなデータを集計・解析する人たちがアクセスしやすいように環境を整えてくれている。ここの部門の人たちが非常にデキる人の集まりで、特に「大きな箱」を構築・運用するチームは技術力の高い人が集まっていた。当時では国内でもあまり利用例のなかったHadoopクラスタというのを大規模に運用しており、技術難易度の高い取り組みに果敢に挑んで昼夜問わず仕事をしているような様子から「修羅の国」と他のチームからときおり言われていた。大変なチームだからあそこに配属されたくないと思う人達が多かったと思うが、自分はこのときこのチームに入ってもっと実力をつけられないかと考えるようになっていた。集計についてより深く知るために、データの置き場所になっているHadoopについて知りたい、そう言って半年ほどの移行期間を挟みながら Hadoopを構築・運用するチームに入社4~5年頃に参画する。

 所属して実際にタスクをやってみてわかった。必要な知識の深さ、タスクの難易度、どれも今までと違った。チームの人の協力を常にもらいながらなんとかタスクをこなす日々。さらに運用についても今まで以上に会社内に影響のあるプロダクトを対象としているため、Hadoopの障害が起こったときはチームで一丸となってできるだけ早くなんとか復旧させるというのが求められた。しかしながら、当時のHadoopに関する運用ノウハウはまだ世の中では少なく、ソフトウェアよりも環境に依存した障害が多かったため、問題点の特定とその解消には常に困難を極めた。この時期は本当に鍛えられたと思う。そして同時に自分にとっては恩師とも言える上司との出会いもあった。役職としては上司になるのだが年齢は自分よりひとつ下、しかし仕事の能力で圧倒的な差を感じた。論理的な思考能力に長けており、状況に応じて最善と思われる判断が適切にでき、コーディングなどのエンジニアとしての能力も高く、人当たりもいいので皆が遠慮なく話しかけることができる。大規模な障害が発生したときに30代40代のエンジニア含めた20名ほどを巻き込んで対応について取りまとめたりという実績もあった。多くの人がこの人に信頼をおいており、自分も同じように早い段階から大きな信頼をおいていた。

 Hadoopを扱うチームに入ってしばらくして、上司と自分の評価について話す機会があった。今までの仕事の実績評価に基づいて昇給昇進のような話と合わせて、もっと成果を出すためにどうするのが良いかといった話もされる。そこで自分が言われたのは

「論理的に話をすることが苦手のように見える」

「以前のチームの上司から聞いたんだけど 『ときどき何を言いたいのかよくわからないことがあった』と言ってて、たぶんこういうのも論理的な思考ができていないことが要因じゃないかと思う 」

 衝撃だった。何を言われているのか理解するのに少し時間がかかった。自身の成長課題について今まで考えることはあったものの、全く予期しない方向からの指摘だったのでしばらく固まった。次第に涙も出てきた。以前のチームのメンバーと何でも言い合える良好な関係を築けていると思っていたので、「遠慮なく言ってくれていいのに」という思いと「言えないような距離感だったのかなぁ」という感情が渦巻いてさらに涙が出た。このときに、今までの自分の行動を振り返って、あのときも自分は変な主張をしていたのではないかとか考えるようになってしまい、自信というものを完全に消失した。ただ、この指摘を面と向かって伝えてくれた上司には感謝しかなかった。伝える側の精神的負担も大きいはずであり、以前の上司のように伝えないという選択肢もある中で、きちんと伝えてくれたことが嬉しかった。このときからしばらくはロジカルシンキング関連の書籍をあさったり社内のセミナーとかいってみたりとトレーニングを続けてはみたものの、自分ではイマイチ実感がなく自信もなくなっているので、まだできていないだろうからもっと訓練しないといけない、と考えるようになっていたと思う。論理的思考能力については未だに自分にとって成長の課題となっている。

 5~6年目、HadoopやHadoopの周辺技術について学びつつ、構築・運用の業務を続けていた。Hadoop関連の知識は底が見えないほど深く、それでいて常に新しい技術が入ってくるため徐々に広くなっていく。Hadoopというソフトウェアの理解だけでも大変というなかで、新しく大規模なHadoopクラスタの構築という大きな仕事が始まった。これはデータセンターにおけるサーバ・ネットワーク構築といったインフラの内容も含んでおり、インフラ周りの知識についても身に付けなければならないプロジェクトだった。インフラを専門にしているチームはあるものの、必要なサーバ・ネットワークスペックや、どこにどれぐらいのサーバを置くかといった設計はこちらがやらないといけない。Hadoopクラスタの構築はチームとして経験はあったものの、規模が今までより大きく、扱うHadoopのバージョンが違うなど、初めて取り組む範囲も広かった。自分以外のプロジェクトメンバーはインフラに精通している人が多く、自分はただただついていくことがやっとだった。新しい知識を得ることは楽しかったが、予想と異なる事象が発生したときに、適切な判断や行動をすぐに取ることができず、躓いたらとにかく聞くしかないといった状態。不甲斐なさを痛感していた。

 そんなとき、このプロジェクトのプロジェクトマネージャーと設計関連で話をしているときに意見の対立が発生してしまいお互いに感情が高ぶった状態になった。相手が持論を並べて「この設計が理想だ!」と言い切った後、自分は相手の言いたいことはわかるが実際の状況を踏まえた上で理想の状態にはできない、妥協点を模索しないといけない、ということを主張しようとしたのだが、うまく言葉が整理できず少しの間黙ってしまった。これが相手の怒りをかってしまい相手はさらに言葉をまくしたてる。自分もどうにかしなければと感情が更に高ぶったときに、涙が出ていた。自分でも驚いたのだが、相手も驚いたようでお互いに何も言えなくなり、自分は一旦トイレに駆け込んで感情の整理をしようとした。笑い上戸で笑ったときによく涙も出るなと思ってはいたが、どうも自分は喜怒哀楽の感情が高ぶると涙の形でまずは出てしまうらしいというのをこのときに学んだ。プロジェクトマネージャーとはこの後きちんと和解でき、今でも顔を合わせるときは笑って話ができる間柄となっている。実力的にも他のメンバーと比べ劣っていながら、精神面でも脆さがあるなと感じ、今後このチームでやっていけるのかと不安をいだいていた。

 人からの印象というのはなかなか聞く機会がないもので、社内の人事的な仕組みによって上司と部下の間では定期的に話す機会があるものの、チームの中ではそれなりに関係性ができていなければ聞くことはできない。ましてやチーム外からコメントを貰うというのはさらに難しい。コメントを得られたとしても抽象的な内容がほとんどだろう。自分が以前アクセス解析ツール関連の部署にいたときに少しお世話になった偉い人とひょんなことから話す機会があった。このときに偉い人は自分に

「なんだか静かになったね」

とひと言まず言ったのがとても印象に残っている。どういうことですか?と聞いてみると

「以前はいろんなところに顔を出しており、いろんなところで君の名前を聞いたが、最近はそいうのが少なくなったように思う。」

悪くなったと言いたいわけではなさそうで、ただそのように感じたというのを伝えられた。言われたことを考えると、顔を出すコミュニティは以前に比べて減っており、今のチームでは目立った成果が出せていないことで自分の名前が上の人に広まることもない。偉い人の耳には確かに自分の情報が入りにくい状態になっていた。ここで更に気づいたのは、面白そうなことがあればとりあえずやってみるというのを以前はやっていた、やろうと思うモチベーションがあったのだが、今は似たような企画があってもモチベーションが上がらず手を上げることはしないようになっていた。気持ちが下向きになっていることが行動にも影響を与えており、人からの評価という面でも影響を与えていたことを実感した。目の前のタスクをこなすことに一杯一杯であったため、悩むような余裕はなかったが、気持ちが以前のように上向きになることはしばらくなかった。

 3年目~6年目の出来事について思い返してみた。書き出してみるとやはり印象深いことが多かったからかだいぶ長くなってしまった。今の自分を自分足らしめている出来事がこのあたりにあったなぁと改めて実感している。やはりこの時期はつらかった。自分で選んだ道ではあったものの、想像以上に精神的にきた。もし体力もなかったらたぶん倒れてたんじゃないかと思う。残り4年ほどはおそらく一気にかけると思うので、振り返りの記事としては次で最後。

社会人10年の振り返り(初年~3年)

 今の会社に新卒入社で入って10年ほど経った。いい区切りでもあるので社会人になってから今までを少し振り返ろうと思う。まずは今の会社を選んだきっかけから社会人3年くらいまでを思い出して書いてみる。

 大学で時系列データから情報を読み取るといったことをしていたので「データが見たい」と就活ではよく発言していた気がする。書類選考や初期段階の面接は突破するものの、終盤の面接で自分はこれがしたいってことを言いまくったらだいたい落ちた。それでもめげずに頑張ってようやく採用してもらえたのが今の会社。というかこの時期にデータ解析について取り組んでる企業がほとんどなかったというのが背景にあるのかなと今となっては思う。マイクロソフトとか楽天とか、当時選考で残ってた企業でそれなりにデータを持っているところしか残ってなかった。

 入社して研修も終わり、最初に配属されたチームはサービス内の検索ボックスで検索されるときに発生するログを集計し可視化する社内向けプロダクトの開発・運用をするチーム。データを扱う部門に配属されたのは100人ぐらいの新卒のうち自分を含めて5名ほど。他の同期はわりとざっくりした開発チームにまとめて配属とかになっていたので、データが見たいですと面接で言い続けてよかったと実感した。配属されたチームは自分を含め6名ほどの構成で、先輩方は比較的若い方が多く、30代のエンジニア1名を除くとほかは20代の方しかいない。年齢が近いこともありとても話しやすい環境だったのは、新社会人の自分にとってとてもありがたかった。

 大学でデータを集計して可視化することはすでに経験していたものの、このチームで扱っているデータの規模は大学のそれとは比較にならないほど多い。ただ足し合わせるような簡単な集計でも普通にやると数時間かかってしまうので、並列分散処理の仕組みをうまく使わなければならず、この辺の知識を身につけることに最初は苦労した。データベースに関する知識についても、少ないデータ量で使用するのであれば細かい設定を気にする必要はなかったが、このチームで取り扱うデータ量では安定稼働させるための細かいチューニングが必要だったり、さらに深い知識が必要になった。同時に、開発経験があるといっても書いたコードの量は多くなかったので、チーム内ですでに出来上がっているシステムの理解や、日々上がってくる改善コードの理解にも苦労していた。それでもやりたいことができているという実感だったり、新しいことを覚えるのが楽しいと感じることが多く、ただただ目の前のタスクをこなすことに充実感を得ていた。

 勤めている会社の社員が数百人いたこともあり、仕事に関わらず社内にはさまざなコミュニティが存在する。仕事以外での関わりももっておきたい、いろいろとやってみたいと当初思っていたので、テニスやフットサルのスポーツのコミュニティ、勉強会のようなコミュニティ、ぷよぷよなどのゲームコミュニティに参加して、休みの日にチーム以外の人達と交流したりしていた。この交流のかいあってか、比較的広く名前を覚えてもらえて、仕事の会議でコミュニティの人と偶然出会うといったこともしばしばあった。今思えばかなり活発に動いていた。1~2年目で知り合った方を通して貴重な体験をさせてもらったり、いろんな話をして価値観の共有ができたので、この時の活発な行動はやっててよかったと振り返ってみて強く思う。

 同じチームで2年ほど過ごし、社内プロダクトについて理解が深まってきたところで、ある程度大きめのタスクも任されるようになった。当時担当していた社内向けプロダクトを規模の拡大などに対応するためリプレイスするというプロジェクトが進んでおり、その集計部分に関するシステム設計を任された。また、コード管理に当時はSubversion(SVN) が使用されていたが、より管理がしやすいと話題になっていたGithub に移行したいですと自分が提案し、この移行プロジェクトについても自分が任される状態となった。プロダクトを0から作ることや、コード管理システムの移行というのは初めて取り組むことだったので、今までやっていたタスクとは一味違い、何が正解なのかわからない中で、手探りでやらなければならないという難しさがあった。先輩とたくさん相談し、ああでもないこうでもないと頭を抱えたのをよく覚えている。

 当時の自分の精一杯を詰め込んだ設計はなんとか認められ、Github への移行も大きな問題は起こらず、リプレイスのための実装がある程度進んだときに先輩から「Github でのコードレビューしやすいね。移行してよかったよ」と言われたことがめちゃくちゃ嬉しかった。設計については実装が進むにつれ「ここはこうじゃないか?」と見逃していたものがいくらか発見されたものの、大きなトラブルも起こらず実稼働までこぎつけることができた。大きなタスクの成功は大きな達成感を得られるだけではなく、昇給など目に見える形でも返ってきた。大きなタスクに限らず日々の運用業務なども含めた自身の働きにより、このチームにおける自分の存在意義を見出したような感覚があり、このチームに自分はなくてはならない存在になれたのではないかと考えていたと思う。このときのことを今思うと、かなりポジティブ思考になっており、悪く言うと調子に乗って若干天狗になっていたかもしれない。

 まずは就活から3年ほどをざっくりと思い返してみた。細かい出来事はだいぶ端折っていますが、仕事においては、目の前のタスクをこなし続けることに集中した時期だったように思う。仕事が楽しいと感じており、気づいたら深夜残業してたということもよくあった。仕事以外でもいい形で人とのつながりを職場で作れていたので、悩みというものを抱えていなかったと思う。とてもいい時期ではあったものの、自分がここ10年で特に印象に残っている時期はこの3年ではなく、この後の3年のほう。この後はさらに長くなると思うので今回は一旦ここで区切る。

2021.09.25 テニスの記録

定期的にテニスを予定しているものの、天候や他の予定が重複したことによる振替などで最近は1ヶ月近くテニスをしていないということもあった。これだけ期間があくと以前スクールで教わったこと・指摘を受けたことを忘れていたりしていたので、テニスをした後はできるだけ言われたこととか印象に残ったことを残すようにしたいと思う。

今日はサーブが好調だった。以下の3点の意識がしっかりできてたことが要因と思う

  • 膝をしっかり曲げ地面からの反発力をボールに乗せる
  • トスを丁寧にし、もしぶれたらちゃんとやり直す
  • ボールのインパクト時のラケットの面の向きに問題がない状態にする

フラットサーブの調子が比較的良かったのでセカンドのスライスサーブを試す機会が少なかった。

ラリーにおいてコーチから指摘を受けたこと

  • 後ろの足のためを意識することでボールに力がさらに乗る
  • 前に出手から打つ動作をするときに前傾姿勢になっておりラケットの振りが安定していない

自分のショットがどうも弱くなる傾向があったので、後ろ足のためについて今後気にするようにしてみる。前傾姿勢については以前も指摘を受けた部分なので、繰り返さないようにしたいが、ボールを追うことに必死になって意識から外れてしまう。思考にもう少しゆとりができるように体力もつけていきたいところ。

テイルズオブアライズやったよ

 発売から約2週間、ストーリーをクリアしたのは 9/17でだいたい70時間ぐらい。これに加えて裏ボスやらトロフィーコンプをしたのが9/22でだいたい80時間ぐらい

 ヴェスペリアやグレイセスと比べると、サブイベント込みの内容量は少ないなって印象ではあるものの、ゲームをし始めるとやめ時がわからなくなるほど熱中して遊べるいい内容だった。謎が謎を呼ぶといった感じで、最初は謎が多いままではあるものの、進めるたびに少しずつ分かってくると同時に新たな疑問が生まれてきて、またそれが気になって先を進めたくなってというのが繰り返し終盤まで続いて、あんまり夜ふかしはしないつもりでいたもののいつの間にか深夜の2時ってことがよくあった。めっさ引き込まれる感覚がとても楽しい。

 世界観を理解するためにたくさんの聞き慣れない単語が出てくるのに、世界観の理解に苦しむといったことはなく、自然と理解できるようになっているのは没入感の高さから来ているものかもしれないが、とてもよく調整されているものと思う。まぁすでに忘れてしまっているものいくらかあるかもしれないが、それでもストーリーの全容を理解するのに必要な情報は適度に理解しやすいタイミングで散りばめられているのだろう。もしくは、真実がわかったときの驚きや楽しさが上回り、覚えることを苦にしていないのかもしれない。情報過多で苦しむといったことが無く、ストレスなく進めることができた。

 最初は謎めいた部分が多く特殊な世界観の中で繰り広げられる感覚があったものの、中盤からは王道のRPGだなぁと感じるようになっていた。そう感じさせたのは、アルフェンの性格がひとつの要因だったのかなと思う。ファンタジアのクレスを彷彿とさせるような真っ直ぐさ、生真面目さがあって、味覚音痴だったり武器防具に目がないような面白い一面もあり親しみやすい。また、愛する人の苦しみを消し去るために敵と対峙する構図もジャンプ漫画みたいだなと感じて王道と思う要因になっているのだろう。王道がなんなのかといった部分は自分でもだいぶあやふやではあるものの、テイルズオブアライズを一言で表現してくださいと今言われたら「王道のRPG」といってしまいそう。そろそろ王道がゲシュタルト崩壊してきた。

 戦闘が楽しいんだよなこれ。雑魚敵相手ならいくらでもコンボが続けられそうなほど技を繋げられるし、倒すときはかっこいい協力技(ブーストストライク)でド派手に決めて、次の相手にはカウンターレイドで瞬間移動して攻撃を継続、戦闘開始から終了までの爽快さがたまらん。ボス戦はうってかわって相手が怯みにくいため、ヒット・アンド・アウェイを繰り返し、ダウンしたすきを狙ってアルフェンのフラムエッジで大ダメージを与えたり、ひたすらみんなで殴りまくってダメージを蓄積させる。大勢が崩れないかどうかハラハラしながら戦ってたなぁ。

 ただちょっと戦闘では気になることがいくつかあって、前衛2人にしたとき操作していない方の前衛がよく倒されてしまうということがあったため、中盤からはアルフェン、シオン、ティオハリム、リンウェルの4人でほとんど戦闘してたんよな。これによって戦闘に出ていないキャラクターの技の習熟度があまり上がらず、特にキサラは100レベルに上げたあとになっても新たに技を覚えたり戦闘に関する称号が取れずに残るといった状態になってた。自分がもっとうまく操作してればキャラクターの格差は防げたんだろうなと思いつつも、戦闘が大変になって高価なグミを使い切ってしまう状態が怖かったのでキャラクターを変えられんかった。戦闘中にキャラクターを変えられるエクシリアみたいな仕組みがあるともうちょい出さしてあげられたとは思う。

 他に気になった点として、秘奥義のあとにコンボを継続することが困難なところかな。秘奥義を放ったあと相手と距離が空いてしまう状態からリスタートとなるため、コンボを続けるためには距離を詰めるまでにブーストアタックなどでコンボが途切れないようにしないといけない。戦闘の爽快さが良いだけに秘奥義後の間がより目立っているのではないかなと思う。

 まぁ気になるといってもここまですごく楽しいものが出来上がってるからこそ気になっているってことであって、100点満点で採点してくれと言われたら95ぐらいはつけると思う。残り5は欲張っていいならここをこうして欲しいなって感じ。テイルズを今から始める人がいたら、これからはアライズを全力で勧めるやろな。

 トロフィーコンプ、称号コンプ、修練場もすべてクリアしたので、あとは攻略本が出たときに周回プレイしてみるかなといったところ。余裕があれば琴葉姉妹使って実況動画とか作ってみたいなとも思ってる。いやぁ5年待ったかいがあった。

2021.09.18 テ勢麻雀の記憶

 この記事は2021.09.21 に記憶を探りつつ書いてるので事実と違うこと書いてるかもしれんが許して。

 この日の麻雀は、何半荘やったかは覚えとらんのやけど、1位をけっこうとれて合計+90でおえることがでけた。嶺上開花であがることはできんかったんやけど、カンチャン待ちでリーチしてたのがけっこうあがれたんよな。自分含めて3人リーチしてる状況でもカンチャン待ちの最後の1枚をツモったんは熱かった。みんなが「嘘やろ!?」「これに負けるか!」って悔しがってたのみたんはなんともいえん嬉しさがあったな。まぁ自分もめっさ驚いてたわ。テンパイ即リーが最強かもしれん。

 天気は台風が近づいてたこともありけっこう荒れてて、目的地に向かうための電車は各駅停車しか動いていないという状況。いつもの出発時間と比べて1時間ほど早くに出たものの間に合うかわからんって感じやった。それでも臨時急行が設けられ、それにタイミングよく乗れたこともあり、集合時間に間に合うことができた。あとになって思い返すと、この日は運がいい日やったから間に合ったんかもしれんとすら思う。

 雀荘について体温チェック。デコを見せてはかる体温計で35.9℃とか低めの数値を他の人が出してるの見て「みんな低ない?」ってコメントしてたら自分は34℃やってオーナーさんが驚いとったな。自分ゾンビかな?まぁ以前も34℃を叩き出したことはあったからみんなからは「また!?」って感じに言われとったな。自分のおでこは冷えピタでも内蔵しとるんやろか。

 この日はテイルズオブアライズが発売されてから1週間ほどしかたっていないこともあり、話題は最初からアライズのことでもちきり。この時点でクリアしているのは自分だけだったので「自分の機嫌を損ねるとポロッとネタバレしてしまうかもしれん」とプレッシャーをかけまくったな。まぁここでみんなとの確執を作るのも嫌だったので自分なりに発言には気をつけるようにしていたつもりではおったんやけど実際どうやったんやろ?自分よりもつっしーの方がポロっと言うてしまってたようにも思うが。

 みんなのプレイ進行度合いを確認して、パーティメンバーが6人揃ったところまであたりなら話して良いってことになって、アライズの気に入ってるところとか話しながら麻雀してた。長い技名とかをすでに覚えてるあらさんとつっしーはすげぇなって思いながら聞いてたわ。クリアしてるからすでに何度も聞いたはずやのに、自分はあやふやにしか覚えとらんかった。特にあらさんはティオハリムを気に入った様子で、イベントのセリフを通して暗唱しとったな。今後もあらさんからはティオハリムのワンシーン再現が聞けそうで楽しみ。自分も含めみんな話すのに夢中になって、麻雀の方はけっこう注意散漫やった気がする。なかでも顕著やったんはしっぽらさんかな。よく「なんも考えてなかった」って発言してた気がするわ。テ勢雀士にはテイルズの話題を振ることで集中力を落とすことが効果的。

 アライズから引用した言い回しで今回印象に残ってるのは「壁を壊す」と「石付き」あたりかな。「壁を壊す」はアライズのなかでもけっこうネタとして使われてることもあってか汎用性が高いと思う。今後も危険な牌を捨てるときとかに何度もみんなから聞かれる言葉となるんやろな。「石付き」はすでにWiki入りされとるけど、何かしらマウントをとれたときに蔑称として使う感じになるやろか。レナ人が「石付きと麻雀してくる」と言ったときには他のレナ人から「仲いいのか悪いのかわからん」と言われること必至。

 けっこうたくさん話したはずやねんけど、数日経つとやっぱ思い出せんもんやな。次回はみんなアライズをクリア済みのはずやしネタバレ解禁でもっといろいろ話が膨らむやろうし楽しみやな。テ勢雀士たちは新たにアライズからどんな引用を生み出すのかも期待が高まる。むしろ自分はわりとやりきってしもうたから、覚えとるか不安やわ。

自称スクラムマスターとの遭遇と学び

 久々に書きます。あまりにも自分にとって衝撃だったので、今後同様のことが発生した場合にうまく対応するため、振り返って改善点を洗い出すことを目的として書いています。自身の経験をもとに書いてはいますが、自身の印象・記憶をもとに書かれているものであるため事実と異なる内容が含まれている可能性がありますのでご了承ください。

こんなスクラムマスターからは逃げよう

 結論から先に書きますが、以下の項目に複数該当するような自称スクラムマスターからは逃げましょう。おそらく自身の抱えるタスクのための時間は搾取され、不要な責任を背負うことになります。よほどやっていることに意味を見出していない限りは、可能な限り早くに逃げる決断をおすすめいたします。

  1. チーム状況について観察・理解・課題発見する前に「スクラムをやりたい」と言い出す
  2. チームにスクラムを導入するにしてはスクラムマスターとしての知見が乏しく、他にサポートできる人もいない
  3. スクラムマスターとしてやることよりも、スクラムマスターという役割を理由にやらないことを列挙する
  4. 技術領域において手を動かさない(障害対応時に他の人が手を動かしているのを見てるだけ)
  5. 改善を目的としてメンバーのやることを増やすが、減らすことを考えない(○○について考える会を定期的にやりましょうなど)
  6. 提案される改善策に対して「効果が見込めない」と反論されても「とりあえずやってみましょう」と強行する

 細かい点を言い出すときりがないので際立った点のみを上げています。詳細についてつらつらと以下に書いていきます。

背景

 自身が所属しているチームについてまずは簡単に説明します。とあるプロダクトを開発・運用しているチームで、プロダクトを構成する3つの要素ごとにグループが分けられているようなチームでした(UI, API, インフラなど)。それぞれのグループにだいたい4,5人のメンバーがおり、プロジェクトマネージャーとチームのリーダーがグループ全体を見ているような構成となります。グループ内の人によっては複数のグループをまたいで担当するような人もいます。

 ある日、リーダーが交代になると同時にチームの体制を変えるという話が伝えられた。主な変更内容としては以下の4項目。変更の目的は既存の体制の抱える課題を解消することになります。

  1. プロジェクトマネージャーの責任負担が大きいので、プロジェクトマネージャーをなくす
  2. コンポーネントごとに分けたことでグループをまたいだ案件の進行について課題がでてきたため、コンポーネントごとに分けていたものをやめて大きな案件をベースに2つのグループに分ける(各グループに各コンポーネントを見れる人がそれぞれ所属する)
  3. グループごとに開発サイクルに差があり全体の進捗度合いが見えにくいため、全体でスクラムをベースとした共通の開発サイクルを導入し、プロジェクトマネージャーだった人がスクラムマスターを担当する
  4. みんながすべてのコンポーネントについて理解を深めプロダクト全体を把握できるメンバーを増やす

 体制変更については新リーダーとスクラムマスターの相談によって大枠を決め、この宣言のあと1ヶ月ほどの期間で他のメンバーとの話し合いで詳細を詰めていくとのこと。

 このチーム自体は5年近く続いている状態ですが、メンバーの入れ替わりが激しく、最初からチームに所属していたのは前リーダーを含めて2, 3人程度。自分もこのチームに所属したのは約1年前で、ひとつのコンポーネントを運用するにあたり人が足りないから来てほしい、グループの状態を立て直して欲しいという助っ人としての参画でした。参画してからは運用を担当するコンポーネントのグループ内でのコミュニケーションがほとんどだったため、他のグループの状態やチーム全体の状態についてはあまり把握できておらず、上記の課題を伝えられても「知らなかった」という感想と、所属グループの状態がようやく安定してきた時期でもあったので「変更が必要なのか?」という疑問が生じていました。

対話期:課題の深堀りで高まる疑念

 体制を変えるという話がされたあと、実際に体制を移行するまでに1ヶ月近い時間があったので、その間にスクラムマスターと新リーダーに体制変更前のチームの課題について詳細を聞いてみた。

Q. プロジェクトマネージャーをなくすとのことだが、責任の所在はどこにいく?

A. メンバー全員が平等に責任を持つ

Q. 各コンポーネントを担当しているグループが担当領域についての責任を持っている状態だったはずだが、プロジェクトマネージャーの責任の負担とは具体的になにか?

A. グループをまたいでの認識を合わせたり優先順位付けがグループによって異なったりしていたので、それによって発生する調整が大変だった

Q. 自分が所属していたグループではそのような課題を認識していないが、自分が気づいていないだけ?

A. 主に他の2グループ間で問題が発生していた

Q. プロジェクトマネージャーがやっていたことは誰が引き継ぐのか

A. 都度メンバーの中から担当者を決める

 プロジェクトマネージャーの責任負担が大きいということについて確認したところ、自分が所属していない2グループ間の調整が負担(2つ目の課題に相当する)でありこれをなくしたいというのが本質的なところだった。問題の2グループだけをまとめればよかったのではないかと提案をしたがその後検討されず、プロジェクトマネージャーが大変だからやめたいと言っているだけではないかと聞くと返答は得られなかった。また、プロジェクトマネージャーがやっていた作業もメンバーに振られるとのことで、メンバーの負担が上がることが予見された。

Q. 開発サイクルを揃えるとのことだが、揃えないことによって具体的にどう問題なのか

A. スクラムを導入するにあたって開発サイクルを揃えたほうがやりやすい

Q. どうしてスクラムが良いと言えるのか?

A. 1グループがスクラムのような開発サイクルを実施していて良さそうに見えるので全体でやろうと判断した

 明らかに手段が目的になっているケースである。自分が所属するグループはスクラムを採用してはいないが、開発サイクルにおいて特に問題などはなく、むしろ成熟してきた時期でもあったため、チームを再編してスクラムを導入するという点についてメリットがあまりなかった。こういった点から、スクラムマスターはチーム全体を見て判断しているというよりも、自身が見ている範囲のみで改善策を提示しており、方法論についても「よさそう」という曖昧な判断基準で決定していると自分には感じられた

 「みんながすべてのコンポーネントについて理解を深めプロダクト全体を把握できるメンバーを増やす」については、長期的に考えれば理想な状態なのだろうということは理解できる。しかし自分は他のコンポーネントに対してあまり興味を持てていない、担当コンポーネントもまだまだ深く知るべきことがあり専念したいと考えていたため、他のコンポーネントに対して知るために時間を取られることが億劫であった。これについては自分自身の身勝手な考えなので、チームとしては学びの時間さえ確保できれば特に問題はないと判断していた。メンバーの入れ替わりが激しい状態が合わせて改善されればより効果は高まるだろう。

 スクラムを導入するにあたって、書籍などでは「みんなが同じ立場で遠慮なく発言できるような信頼感が大事である」といったことがよく書かれているが、自分はスクラムマスターや新リーダーに対してこの時点ですでに信頼を失いつつあった

混沌期:スクラムマスターとの衝突とチーム不和

 疑念は高まりつつも体制変更実施日を迎えた。あまり話したことのないメンバーとやり取りしつつ、約半年間で実施すべきタスクについて各コンポーネントの情報を出し合っていたのだが、ここで問題が生じる。

全体のスケジュール作成と管理を誰がどうやるのか

 これまでは、コンポーネント別の各グループごとにやることをリストアップして予定を作成していた。グループごとにまとめ役となる人がおり、自分もその1人だった。体制変更後はそういったまとめ役はどうする想定なのかとスクラムマスターに聞いてみると

「グループ内で決めてください」

 都度決めるというのはこういうことかと初めて理解した。普段から話をあまりしていない人同士、かつ隣のコンポーネントについてはこれから理解していくという段階でもあるため、率先してまとめ役になる人もいなければ他の人を推薦するという人もいない。スケジュールに関することに限らず、細かい決め事をするときは常に「誰がどのように決定するのか」という点で足踏みした。このように、スケジュール管理や決定することといったプロジェクトマネージャーが今まで実施してきたことが宙ぶらりんの状態になるのだ。

 スクラムマスターに「このような場合はどうすべきか」と訪ねてみると「グループのメンバーが納得行く形でグループ内で決めてください」という返答のみで、スクラムマスターは静観するのみであった。そういうものなのか?と自分でも疑問に思ったのでスクラムに関する記事や書籍を自分でも読んでみたが、自分が見た範囲ではスクラムマスターと合わせてプロジェクトマネージャーのような立場の人がいるケースがほとんどで、重要な決定やメンバーが判断に迷った場合の決定権に責任を持つ立場の人がいた。スクラムマスターにプロジェクトマネージャーを立てたほうが良いのではないかと相談してみたが、「とりあえずプロジェクトマネージャーは無しでやってみましょう」としか返答がなく自分の提案は棄却され、スケジュール管理の面については自分が「このままだとタスクが進まないので一旦自分の方でまとめます」と消極的な理由で立候補して担当することになった。その後も似たような状況に陥ることは何度もあり、これはマズいと思うものは自分が名乗りを上げて作業することになった。結果として、プロジェクトマネージャーがやるような仕事の一部をコンポーネント管理のヘルプとして参画している自分が実施し、時間を取られてしまうこととなった。

 スクラムマスターがスクラムについてどの程度事前知識を得てきたかという点で疑問が湧いたため参考にしている書籍など聞いてみたが「これからみんなと学んでいこうと思っています」という返答のみであり、知識を得ること自体積極的に実施していないことがわかった。さすがにそれはどうなのかと他のメンバーも同席しているミーティングで訴えたところ「スクラムについてチームで学ぶ時間をもうけよう」という提案をされた。共通の参考サイトを事前に見てきて、その場でどうスクラムを導入するのかについて相談するとのこと。すでにチームとして走り出してひと月以上経過している状態でこのような提案が出てくること自体どうかしている。チームの今後に大きな不安を抱いた。そして実際にそのミーティングが開催されたが「読んでは見たものの抽象的な内容が多く具体的にチームに落とし込むことが困難ですね」というまとめになってしまい、「今後も定期的にスクラムをチームに導入するにあたって考える会をやりましょう」という判断となった。このときには自分は、チームの体制の話については極力時間を割かないようにし、担当するコンポーネントの改善に務めることを決めており、この定期的なミーティングに対しても「タスクを消化することを優先するため不参加」と伝えていた。しかしこれが逆に、他のメンバーから「チームの体制改善に対して最初は異議を申し立て荒波を立てたが、最近は積極的ではなくただ荒らしただけ」という評価を受けてしまう。

静寂期:表面上はチームが上手く回る

 体制変更直後は荒れたものの、やることを決めてしまえば各自が着々とそれらを進めるのみとなったため、チームの体制について話す機会は少なくなった。この段階になって体制変更によってもたらされたメリットがひとつ見えてきた。

 複数のコンポーネントをまたいだ大きめの案件を進めていく中で、以前の体制であればコンポーネント間の確認においてかなり時間が経過してから認識違いが発覚するといった問題が発生していたが、体制を変更してからはコンポーネント間の確認をする機会が多くなり、認識違いをかなり早い段階から検知することができていた。体制変更の目的のひとつでもあった課題解消が目に見える形となって現れたのだ。

 自分が担当するものと異なる領域のメンバーと接する機会ができて思うようになったのは、この優れたメンバーがいるからこのチームは現状を保っていられるのだということ。細かい決めごとや以前はプロジェクトマネージャーがやっていたことを、自分だけではなくメンバーが分担してやるようになっていったことで、自身の領域のタスクをこなしながら、チームが上手く回るように尽力していた。

 メンバーが尽力している中で、スクラムマスターが積極的にチームのために行動を起こしているのかというと、自分が見える範囲では特に仕事をしているようには見えなかった。スクラムマスターに率直にそのことを聞いてみたところ「自分はあまり関与せずチームが成熟するのを静観しようとしている。自律した組織を目指しているので指示などをすると逆効果と考えている」という返答だった。たしかに、メンバー同士で積極性が出てきているようにも見えるが、プロジェクトマネージャーをなくしたことによって宙に浮いているタスクをメンバーの責任感から取りにいっているだけなので、いわばメンバーは尻拭いをしているのだと自分はとらえていた。チーム体制についてこのタイミングで意見してもチームにとってメリットはないと感じたので「そうですか」と返答しただけで話し合いの席から退いた。

再燃期:スクラムマスター動きます

 大きめの案件も終盤に差し掛かり、各コンポーネントの開発が佳境となっている中、スクラムマスターが突如動き出した。

「新しくツールを導入してチーム体制について意見交換しやすいようにしたい」

 タスクの整理などでホワイトボードにポストイットを使って状況を整理する手段があるのだが、それをリモートでもできるようなウェブツールの導入を提案してきた。メンバー内でも使用したことのある人はおらず、ツールについての理解から始めないといけない。スクラムマスターとしての自分の役割はチーム全体の支援であると自身で語っていながら、開発が佳境となっているこのタイミングでその提案はチームにとってマイナスではないかと呆れて、「今は何もしてくれるな」とメッセージを投げていた。

 これも自分の意見は聞き入れてもらえることはなく、ツールを導入しての相談が実施されたものの、数回行われただけでツールの継続利用は見送りとなった。さすがにこの提案には他のメンバーからも不評だったようだ。自分はその会議には参加していないので、どのような話し合いが実際されたのかは知らない。加えて、スクラムマスターが主に主催する会議では議事録をまともにとっていない状態なので、過去のやり取りがどこまで残されているかも定かではなく、今後同じようなやり取りのための無駄な会議が開かれることもリスクとして存在している。

 案件の終盤では部長などの偉い人たちに対して、この案件がこういう形で終わりますので承認してくださいという会議が開かれる。承認が得られなければ指摘された内容に合わせて修正する必要があるため、スケジュールが変更になるという重要な会議。この会議の資料を作成するというタスクがあったのだが、これも今までプロジェクトマネージャーが実施していたので宙に浮いた。過去に同様のタスクを実施した経験があるのは元プロジェクトマネージャーのスクラムマスターのみだったため、スクラムマスターに「みんな開発で大変な状態で他に人もいないので担当できないか」と依頼したが「スクラムマスターの役割ではないのでやらない」という返答だった。せめて雛形だけでも過去のものを参考に用意できないかとこちらから譲歩してみたものの、これに対してもやらないの一点張り。やってもらうために言葉を尽くすことも億劫だったため、しかたなく自分が資料を用意することにした。

 スクラムマスターの「自分はやりません」という主張はこれだけに限ったものではなく、技術領域における重要な判断や、グループ内で決まらなかったことの決定など、とにかく本人が思うスクラムマスターの役割ではないものは徹底して手を動かさなかった。

終わりに

 いきなり終わりになってしまい戸惑うかもしれないが、まだ自分はこのチームから脱出できておらず、日々スクラムマスターからの悪影響をどのようにしてかわすかということを考えさせられている。当然、チームから抜けることも考えてすでに行動に出てはいるものの、まだしばらく時間が必要といった状態です。それでも3ヶ月以内にはなにがなんでも脱出しておきたい。そうでなければ精神的にやんでしまいそうなので。

 スクラムというものについて、おそらく言葉を知っている人の数だけ理解のしかたがあるというほど抽象的なものだと思っている。自分はスクラムというのは「導入するぞ!」と積極的に取り組むものというよりも、2週間程度の開発サイクルを軸として、チームとして繰り返しタスクの洗い出しと担当ぎめ、実施した内容の確認、予定と実績を評価して予定の見直し、振り返りといったことが実施できる状態になっていれば、結果的にスクラムっぽくなっているという考え方でいます。こういった価値観の違いからそもそもこのスクラムマスターに対して批判的であったのではないかと言われると否定はできない。ただ、スクラムマスターを自称する人のアクションについては注意深く見たほうが良いとは思う。その人がどのようにチームを評価し、どういったチームにしたいのかということを事前にしっかりと理解することがうまくやるには必要だ。自分はこの事前の相談が十分に実施できなかったことにより、案件を進ませながら相談するといった時間的にも精神的にも余裕が持てない状況が生まれていた。

 ここまで読んでいただきありがとうございます。かなり勢いに任せて書いたものであるため、理解に苦しむ内容も含まれていると思いますが軽く読み流しちゃってください。不要なチームの不和など、自分のコミュニケーション能力の乏しさによって招いた問題というのもあるので、今回の経験をもとに自身の改善に努めたいと思うばかりです。しかしながら、人の考え方を変えるということは非常に困難なので、自分の取れる手段の中で「逃げる」ということもきちんと選択できるように余裕を持った状態にしておきたい。

ガーラ湯沢スキー場休業のため岩原スキー場に振替えで滑ってきた

2020.02.22 友人たちと日帰りでガーラ湯沢スキー場でスノボーをしに行ったのだが、当日の朝から現場は強風が発生しており、ガーラ湯沢スキー場が休業となった

しかも休業連絡を知ったのが現地に向かう新幹線の中だというのだから友人たちと大慌て

案内をよく見てみると振替スキー場というのがあるらしく、ガーラ湯沢からシャトルバスが出るとのこと

新幹線の中で振替についていろいろ調べた中では過去の記録などから以下の情報を断片的に確認

  • ガーラ湯沢のリフト券が他のスキー場で引き換えられる
  • レンタル自体はガーラ湯沢で実施

ガーラ湯沢駅について改札を出たところのすぐ横にリフト券売り場があり、そこで詳細について聞くことができた

  • ガーラ湯沢でリフト券を購入し、このリフト券を振替先のスキー場のリフト券に交換してもらえる
  • レンタルと着替えをガーラ湯沢で行い、荷物をガーラ湯沢のコインロッカーに保管
  • ウェア、ボードなど滑れる状態でシャトルバスに乗って振替先のスキー場に向かう

スキー場の選択は当日の開場状態にも依存するが、この日はガーラ湯沢スキー場以外のスキー場は営業しており自由に選べる状態だった。そこで自分たちは過去に行った経験もある岩原スキー場へ行くことに決め、岩原スキー場行きのシャトルバスに乗り込んだ(過去に骨折をしたたんばらスキー場としばらく勘違いしてた)

ガーラ湯沢スキー場は最初にゴンドラに乗ってゲレンデに行くこともあり、休業の条件として風の影響を受けやすい制限がかかっていたものと思われる。そのため他のスキー場は通常通り営業しているという状態がうまれたのかもしれない。

岩原スキー場に到着しリフト券を交換、いざゲレンデへ

早朝は風も吹いていたらしいのだが、ゲレンデについて見ると雲が広がっているものの徐々に晴れてきて気温も上がり、リフトの上でも暑さを感じるほどの状態だった

雪が少ないことを心配していたが、軽く滑ってみると比較的滑りやすく転倒しても痛みを感じない程度にはふかふかとしている状態で、 雪のコンディションとしてはとても良い状態

天候や外出自粛の気運が出始めていた時期ということもあってか、人の数も少なく滑っている間も人と人の間には大きくスペースができるほど悠々とすべることができ、山の上に行くほどそれが顕著に見受けられた

骨折していたこともありしばらく運動から離れていたので、久々のスノボーでどうなることかと不安になっていたが、滑ってみるとわりと体が覚えてくれてた

滑り始めてみるとやっぱり楽しい。軽快に滑り降りていく疾走感、周りの景色もよく見え雄大な風景に気分も良くなる

たまに制御できずに転倒はするものの、雪のクッションが守ってくれるので怖くない。練習にはもってこいの状況なので、エッジを立ててきれいに曲がるという練習をしばらくしてたが、右から左に流れるターンの部分でどうもバランスを崩しやすい感覚がある。この課題を確認したところでお昼休憩

お昼に頂いたのはステーキ丼!

約1500円とメニューの中では少し値は張るが、動いたあとに肉を食いたい衝動に任せて注文し、これが大正解

お肉がめちゃくちゃ柔らかくそれでいて肉と香辛料の味がガツンとくる一品。タレのかかったご飯もおいしく量は大盛りぐらいあったものの問題なく完食

ドクターペッパーは見つけたら買ってしまう呪いのかかった友人とノリで購入したが、パッケージが何故か異なるというハプニングが発生。内容は特に問題なかったものの、都会に出てしまったイケイケなパッケージと田舎に残り続けた馴染みあるパッケージとして見た目の違いを楽しんだりもした

お腹も満たしたところで午後の滑りに

リフトに乗っている最中に経験豊富な友人にきれいに滑るにはどうするかについて訪ねてみると

「スノボーを習っていた人から、エッジを立てたときに返ってくる感覚があるという話を聞いた」

という他の知り合いから教授されたアドバイスを受けた

ボードのエッジを立てたとき、ボードがもとに戻ろうとする力が働きそれに従うときれいに戻れる。転倒する人はもとに戻ろうとする力とのバランスが取れず転倒してしまうのではないか、とのこと

何を言われているのかさっぱりだったものの、もとに戻ろうとする力というのを意識して滑ってみると、たしかに立てたエッジが戻ろうとする感覚が足から伝わってくるのを感じた

この力に従うようにボードを戻すと体制が自然ともとに戻る。重心がずれるなど起こるとこの力に従うことができずもとに戻せない

今まで自分は、自全身の状態を注意深く意識することでバランスを取っていたが、ボードの力のかかり方に従うようにと意識することで、重心が後ろに行き過ぎて倒れるといったことが少なくなったように思う。この感覚を知ることができたのが今回の大きな成果だ

しばらく滑っていると黒い雲が出始めてきたので混雑回避も含めて早めにガーラ湯沢スキー場に戻ることに

ガーラ湯沢スキー場は銭湯もあり、ロッカーで着替えなど必要なものだけをもって脱衣所に向かうことができる。ただこの銭湯、ロッカーと脱衣所の区別がわかりにくくなっており、ロッカーのところですべての服を脱ぐのかと最初は勘違いしていた。張り紙がありよく見ると脱衣所は更に進んだところと書いてあり、最低限の着替えとタオルなど以外はロッカーに置いておく決まりのようだ。このあたりはちょっと分かりづらい

銭湯の洗い場は10程度あり、自分たちが入ったタイミングは特に混むといったこともなかったが、30分違えば混雑しそうな人の混み具合だった。比較的少ない入場者だったことを思えば、ピーク時は地獄絵図となりそうだ

荷物をまとめて新幹線で帰路につく。すべての道具を持っているとレンタルでお金はかからないが移動時の負担がやはり大きい。次は荷物を宅配などに委ねることも検討しなければ。

久々のスノボーはめっさ楽しかったなぁ。ある程度滑れる感覚も取り戻したしもっと滑りたいと思うものの、新型コロナの感染拡大防止などを考えると今シーズンは難しそう。来シーズンは今シーズンで滑れなかった分も合わせてたくさん滑るぞい!∠( ゚д゚)/

Go言語勉強します

ボイスロイドによるSplatoon2の実況、通称ボイロトゥーンの動画を作成してて、セリフを打ち込んだあとの画像選び(PSDからボーズなどを決める作業)のときに

「セリフから自動的に適当なPSD画像にしてくれるようにできないかな」

そんな戯言をTweetすると・・・

( ゚д゚) ・・・

(つд⊂)ゴシゴシ

(;゚д゚) ・・・

(つд⊂)ゴシゴシゴシ

(;゚д゚) ・・・・・・・・・・

開発者ご本人様からリプライ!?

これはやるしかないですね。開発言語はGo言語で今まで触ったことないですが、いい機会なので勉強してやりたいことができるようにしたいと思います。

PullRequestあげて取り込んでもらえたりしたら夢のようではあるけれど、やろうとしてることけっこう複雑になりそうやから分離して用意することも検討しとかんとな(;・∀・)

いやそれにしても驚いた。言うてみるもんやな。。。