bonotakeの日記

ソフトウェア工学系研究者 → AIエンジニア → スクラムマスター・アジャイルコーチ

『質的研究を科学する 』を読んだという話

夜中の変な時間に目が覚めてしまったので、以前読んだ本の感想をおもむろに書き出そうとしてみる。2ヶ月くらい前に読んだやつだけど。

自分は今初めて質的研究というのをやろうとしていて、何かと言うとインタビューや自身の観察から得たログみたいなものを分析して何かしらの科学的な知見を得ようとする手法のこと。社会科学の世界でよく使われる。
ただ、自分は今まで自然科学な世界で研究することがほとんどで、こうした定性的データを自分の主観に基づいて分析したところで何かしら一般性のある客観的な知見が得られるのか、それは本当に科学なのか……という思いが最初は強かった。

そんな折にこの本に出会って、かなり腹落ちした。
この世に唯一絶対の真実があるかどうかはわからないが、自身の心のうちに起きる「現象」を十分説明できる「記述」を見つけることが科学である、という(構造構成主義的?)立場は自分の、特に数学で養われた感覚とすごくマッチしていた。
おかげでこの本を読了した後はそういった客観性の意識に悩まされることがなくなった。

こういった科学哲学的な本を好む人が自分の近傍にどれだけいるかわからないけど、自分の中ではとてもためになった、ということで紹介しておく。

『単体テストの考え方/使い方』が大変良かった話

支援先のジュニアエンジニアにテストの書き方を、それも、テストを書く意義から教えることになって、なんかいい参考書ないかなぁ、と色々物色する中で出会った本。

そこいらにある教科書的なやつは、大学レベルで教えるやつはどうしても現場の肌感覚から離れていたり最近の開発現場の事情とズレていたりするし、一方でもう少し実践的に、となると、やたら堅苦しくSIerのQA部門の人が読むような内容になってたり、あるいは特定のフレームワークに依った解説になっていたり、という感じで、ちょうどいい塩梅のものがなくてずっと困っていた。

この本には同値テストも状態遷移テストもカバレッジテストも出てこないけど、エンジニアが日々の開発でテストを書くための勘所、それも「どんなときにテストを書くべきか/書くべきでないか」「単体テストとe2eテストをどう使い分けるか」「どんなときにモックを使うか/使わないか」なんてあたりの、まさに自分が教えたかったけどうまく言語化できずモヤモヤしていた内容を明快に言語化してくれていて、すごく良かった。

タイトルには「単体テスト」と書いてはいるが統合テストの章もあって、単体テストの考え方の延長で統合テストをどう考えるか、単体テストとどう使い分けるか、について統一的な視点で書かれている。デシジョンテーブルとかn因子間網羅とか一切出てこないけど。

この本自体は中級者以上向けという感じがするので、最終的にはこの内容をかなり噛み砕いた初心者向け資料を作って、何とか凌ぐことができた。

アジャイルコーチ 兼 ソフトウェア工学研究者 になりました

最近、自分の身分について色んな所で五月雨式に明かしたり明かさなかったりしていたんですが、それで誤解を受けることも多く。
しかも転職ブログ的な記事を半年前に書いたばかりでその舌の根も乾かぬうちに……て感じだし、しかもこの記事未だにPVが多くて、それを読んでもらっているとなんか申し訳ない気持ちにずっとなっていたので。
なので一念発起して、現在の状況をきちんと明らかにすることにします。

今のメインの仕事はフリーランスで、アジャイルコーチをしています。
更に、スクラムを学術的に研究するため、今月から国立情報学研究所の特任研究員にもなりました。

なんでスクラムの研究を始めることにしたか、を今の段階で大っぴらにするのはちょっと恥ずかしかったんですけど、せっかくの機会なので書いておきます。

僕がスクラムアジャイルに本格的に触れるようになったのは2021年からで、今年に入ってから副業でアジャイルコーチをやっていたんですけど、その活動を通じて、本当にたくさんの新しい知見を得ました。
で、僕は元々長い間ソフトウェア工学の研究をやっていたので、そうやって得た知見をソフトウェア工学に還元したい、ってずっと思ってたんです。

でも一方で、できっこないと思っていたんです。スクラムは経験主義で「実践してなんぼ」の知識体系で、言語化が難しい知識も多く、学問の対象にするには向かない……と。

でもそんな折、今年論文誌に発表された、とあるスクラムの論文を読んだらめちゃめちゃ感銘を受けてしまって。
それで思わず著者にメールしたんですよ。こんな感じの↓

自分は今はアジャイルコーチだけど元ソフトウェア工学研究者で、でもスクラムの研究なんてまともにできっこないと思ってた。でもあなた達の研究はあまりに素晴らしくて、僕の思い込みをぶち壊してくれた。何なら自分もやってみたくなった。

……と書いて、その後に僕自身のアイデアをつらつらと書いて送ったら、欧州にいる2人の著者からノリノリの返信が返ってきて、以降メールで何か盛り上がっちゃって、いつの間にか、2人と共同で研究を進めようってことになってしまいました。

そのとき本当に色々悩んだのですが、ここまで来てこれに乗っからない訳にはいかない、乗っからないと一生後悔する、と思って、生活をほぼ研究中心に変えてしまいました。
研究のやりやすさを最大限に追求した結果、会社勤めを諦め、フリーランスアジャイルコーチをしつつ、コーチングするチームにお願いしてデータを取らせてもらうことにしました。
一方で、未だに読むのにお金がかかる分野の論文とか、個人で所有するには高すぎる研究用のツールなどにアクセスできるようにするため、知己の石川冬樹先生にお願いして、研究室に間借りさせてもらうことにしました。(実は4年前にも別の研究のために所属していたので、出戻りです)

……というわけでした。まだ研究は始めたばっかりで、果たして上手くいくのか、海の物とも山の物ともつかない状態なのですが、生暖かく見守っていただけると嬉しいです。

ちなみにその、僕が研究を始める切っ掛けとなった論文の解説と、もし進捗がよかったら今進めている研究の話を、来年1月のRSGT2024で喋れたら、と思ってプロポーザルを出しました。採択されたら喋ります。(よかったらLikeしてね)

confengine.com

Normanの概念モデルは的を外している 〜『優れたデザインにとってコンセプトが重要な理由』補遺〜

この記事は、MITのDaniel Jackson教授が書いたブログ記事 "Conceptual models missed the point "を、彼の許可を得て翻訳するものです。

ざっくりと訳したので一部こなれておらず、十分なクオリティではないことはご容赦ください。また、"concept" は以下の翻訳ではDonald Normanの『誰のためのデザイン?』(原題:The Design of Everyday Things) に寄せて「概念」と訳しています。「デザイン」と「設計」も適宜訳し分けています。


概念モデルは的を外している

2022/10/18
Daniel Jackson

大きな影響を残したDon Normanの著書『誰のためのデザイン?』は、ドア、電灯のスイッチ、冷蔵庫について語り、ソフトウェアについてはほとんど言及しなかった。しかし、Normanが見立てた診断とそれへの処方箋は、多く私たちの領域にもうまく適用された。

たとえば、ソフトウェアにおいて、ユーザーの意図と解釈をシステムのアクションと出力から分離する実行のへだたりと評価のへだたりは特に厄介であることが認識され、ユーザーインターフェイスウィジェットの選択にはNormanのアフォーダンスの考え方が取り入れられた。

おそらくもっと重要なのは、私たちがNormanの説得力のある議論に触発されたことだ。私たちはユーザビリティ・カルトのグルーピーとなり、ほとんどの成果物が明らかに無能なデザインであることに(時には自惚れながら、しかししばしば正当化されながら)憤りを表明し、私達はソフトウェアの仕事においてより良いものを作ろうと誓った。

しかし、改めて本を読み返すと、その処方箋がソフトウェアの設計においては、いくつかの重要な点であまりマッチしていないと思うようになった。2013年版では、オリジナルから25年後に、Normanは新しいデザイン思考の章を追加し、以下のように語った。

一人の人がこのように多くの分野で働くことがどうして可能なのか。それは、人のためのデザインの基本原則は、すべての分野を通じて皆同じだからだ。人は皆同じであり、だからデザイン原理も同じなのだ。 (『誰のためのデザイン?』より引用)

しかし、デザインは人に関するものだけではない。技術に関するものもあれば、人とその作成物の接点におけるものもある。異なる作成物には根本的に異なる課題がある。都市デザイン、グラフィックデザイン、工業デザイン、ソフトウェア設計はすべてデザインの形態かもしれないが、それらは異なるスキルと感性を必要とする。

Normanの冷蔵庫

私は常にNormanの冷蔵庫の例について疑問を抱いていた。概念モデルのセクションで、Normanは、標準的なアメリカの冷蔵庫の温度調節がユーザーに誤解を与えていると説明している。 よく「冷凍庫」と「生鮮食品」とラベルが付けられている2つのコントローラーは独立した温度調整を提供しているように思える。しかし実際には、1つはコンプレッサーのレベルを設定し、もう1つは各コンパートメントに流れる冷たい空気の比率を変更するものだ。

Normanは、これが設計上の欠陥であると正しく指摘している。信頼できる温度調整を行うのはほとんど不可能であるためだ。冷凍室の設定を低くすると、コンプレッサーの圧力が上がり、生鮮食品もより冷たくなり、サラダが凍ってしまう。生鮮食品をより冷たくしようとすると、冷凍庫からより多くの冷気が逸れ、アイスクリームが解凍される。さらに悪いことに、冷蔵庫の温度変化は安定するまで通常1日かかるため、一連の調整を行うには1週間かかる。

しかしNormanは、議論を通じ、この問題が主に冷蔵庫の冷却メカニズムの設計ではなく、コントローラーの見せ方――Normanが「システムイメージ」と呼ぶもの――の問題であると何度も示唆している。以下は彼の主張の要約である。

私の古い冷蔵庫の温度調節は非常に難しかった。なぜか?コントローラーが誤った概念モデルを示唆しているからだ。

これは非常に奇妙な主張だと思う。温度が調節しにくい理由は、適切なコントローラーが提供されていないためだ。コントローラーが誤ったモデルを示しているのは事実だが、それが問題であるなら、ラベルを変更することで修正できる。たとえば「全体的な冷たさ」と「冷蔵庫/冷凍庫比率」といったラベルに変更すればよい。それは理解しにくいかもしれないが、嘘ではないとは言ってよいはずだ。では、それは役に立つだろうか?全く役に立たない。

概念モデルの背後にある仮定

ここには、より明確な表現が必要な根本的な前提がある。Normanは、基礎となるメカニズムの設計をほぼ当然のものと考えている。彼の興味はメカニズムを再構築することではない。彼はそれはエンジニアに任せている。彼の興味は、デザイナーの概念モデルの「システムイメージ」をどのように投影し、ユーザーの頭の中にモデルを生成するインターフェイスをより良くすることにある。

この点では、Normanの本の元のタイトルである The Psychology of Everyday Things(日常の物事の心理学)の方がより適切である。Normanは心理学者として、ユーザーがメカニズムをどのように理解(または誤解)するかに興味を持っており、彼の著書の価値ある貢献は、ユーザーとメカニズムの間の「へだたり」を埋めるために、心理学的洞察をインターフェイスのデザインに活かすことができるという認識にある。

Normanにとって概念モデルは、具体的な現実から独立した心理学的な構造である。デザイナーは概念モデルを形成するためのゆとりをあまり持っていない。現実は固定されていて、モデルが正確であるためには、そこから大きく逸脱することは許されないからだ。

Normanが出演するオンライン講義はこの点を明確に示している。概念モデルの典型的な例として、水の循環が紹介されているのだ。

サーモスタット再訪

混乱した概念モデルの古典的な例が伝統的なサーモスタットである。多くの人々が、部屋が十分に暖かくない場合は、ダイヤルをトップにまで回すべきだと誤解している。しかし、これによって暖房システムがより多い、またはより熱い空気を生み出すわけではない。サーモスタットの設定は、暖房がオフになる温度を制御するだけだ。したがって、実際に必要な温度を設定すれば、同じくらい早く温かくできる。

Normanもこの例を使っており、私にとっては彼の主張において冷蔵庫よりもより説得力のある例だ。正しいモデルを採用すると、サーモスタットをより効果的に操作できる。温度が気に入ったら、ダイヤルを全開にしてから再び下げる必要はない。1回だけ設定すれば済む。

根本的には、基礎となるメカニズムには何も問題がない。それはユーザーのニーズを満たし、かつ、単純な部品(通常は温めると曲がるバイメタルの帯と、傾くと水銀が流れて暖房システムをオン/オフする水銀球が付いたもの)を使用して安価に作ることができる。低コストかつ効果的なメカニズムがあるので、デザイナーがこの現実を所与のものとして受け入れ、代わりにユーザーの概念と操作に集中することは理にかなっている。

しかし、ここでGoogle Nestのような最新のサーモスタットを考えてみよう。このデバイスには温度を読み取るセンサーがあるが、その制御メカニズムはソフトウェアで定義されている。センシングとスイッチングの両方を含む手頃な物理的メカニズムを作る必要がないため、設計者は自由に好きなように動作させることができる。さまざまなモードやスケジュールを設定したり、人の存在を認識したり、予熱期間を設定したりすることができる。

これらの動作は概念(スケジュール、休暇モード、ゾーンなど)に整理することができるが、これらの概念は心理学的な抽象化ではない。モデルの一部でもない。それらはソフトウェア設計における現実であり、ユーザーインターフェースと同様に変更可能なものなのだ。

ソフトウェアの概念設計

ソフトウェアシステムやアプリに「概念モデル」があるという言い方は誤解を招く。これは、ソフトウェア自体の現実とは異なるモデルが存在することを示唆している。実際にはそうではなく、概念のデザインはソフトウェア設計そのものなのだ。だから私は、ソフトウェアの "概念モデル "ではなく、むしろ "概念デザイン "について話すことを好む。

これは大きな視点の転換である。ソフトウェア・システムのユーザー・インターフェースから、その根底にある意味論へと私たちの注意を向けるのである。心理学は重要ではあるが、ユーザビリティを達成する上でそれほど中心的なものではない可能性を示唆している。そして最も重要なことは、それが、ソフトウェアの概念構造こそが本質であると指摘し、その構造がどうあるべきか明らかにするよう我々に求めてきていることなのだ。


(翻訳ここまで)

この翻訳は、先月出版された以下の本を皆さんにより深く読んでほしい、という思いから公開することにしたものです。 (丸善出版さんから献本いただきました。遅まきながらありがとうございました)

この本は、僕が以前(当時の勤務先の)ブログで紹介した Daniel Jackson の最新の著書 "The Essence of Software" の邦訳です。 以下がそのブログ記事で、当時ちょっとバズったので記憶にある人も多いかもしれません。

note.com

それから1年経って日本語版が出たのですが、書影を見たとき、僕は思わず、あっ、と心の中で叫んでしまいました。
日本語版のタイトルに「デザイン」という言葉を使っていたからです。
この本の翻訳にこんな罠があるとは、と、そんな事にここで初めて気づきました。

この本にとっては不幸なことに、日本語においてソフトウェアにまつわる "design" の訳は2種類あります。「デザイン」と「設計」です。
歴史的経緯から、ソフトウェアエンジニアは主に「設計」を使い、UI/UXデザイナーは「デザイン」という言葉を使ってきました。そして問題は、この本で扱っている "design" が意味するのはその両方だ、ということなんです。
もっと踏み込んで言えば、この本は「ソフトウェア設計」と「UXデザイン」を、「コンセプト」(概念)を依り代に統合させようという野心的な試みについて書かれています

実はこの本の内容は、特にソフトウェアエンジニアや、あるいはソフトウェア工学の研究者にはとてもインパクトを感じさせる内容になっています。
一方で、この本はdesignの訳語に「デザイン」を使い、タイトルにも使用しました。だからきっと、書店でこの本を手に取る人の多くはUXデザイナーなのではないか、と推測します。
UXデザイナーはこの本のタイトルを見ただけでは、もしかしたらピンとこないかもしれません。UXデザインにコンセプトが重要なのは当たり前のことだからです。

さらに言えば、この本はNormanの『誰のためのデザイン?』に大きく影響を受けていますが、同書はUXデザイナーにとっては必携の書と言っても良い古典なので、なおのこと、この本に何か目新しさを感じられないかもしれません。

以前そういった、この本の新しさがUXデザイナーには伝わらないかも、といったことを原著者のDaniel Jacksonとメールでやり取りをしていて、そのとき彼から紹介されたのが、上で翻訳したブログ記事でした。
この内容が、従来UXデザインで常識となっていたことと彼の主張の違いを非常にわかりやすく説明しているので、それで僕は彼に許可を得た上で、日本語版出版のタイミングで翻訳することにした、というわけです。(色々手間取って1ヶ月以上かかってしまいましたが)

UXデザインとソフトウェア設計を統一する、というのはどこか無謀に聞こえるかもしれませんが、彼の6月のブログ記事によると、この本の提案に従い、米国Palantirで「コンセプト」をソフトウェアモジュールとして設計し再利用する、といった試みが始まっているそうです。
また別の文脈で、AirBnbがプロダクトマネージャー職を廃止し、UXデザイナーにプロダクトマネジメントをさせる試みを始めたという話が最近話題を呼びました。時代の流れも実は同じ方向を向いているのかもしれません。

転職しますの記

このブログ記事はいわゆる転職ブログです。昨日3/16が現職の最終出社日だったので、公開するものです。

ただし、よくある転職ブログのように、元職場や新しい職場を大きく取り上げて評価することを意図したものではありません。

僕は転職活動をするのがこれで3回目になるのですが、今回は転職活動そのものがめちゃめちゃ面白く、ものすごく得るものが多かったので、その体験のうち公開できそうなところだけをとりあえず書き残そうという試みです。ちなみに長いです。

目次

どこに転職するの

そんなんどうでもいいからどこに転職するの、という人向けに先に書いておくと、4月からUbieで正社員として、プロダクト開発エンジニアとして働くことになりました。

現職のIdeinは今月いっぱいで正社員ではなくなるものの、4月から業務委託で、アジャイルコーチとして引き続きお世話になります。

また、先行して2月からmatsuri technologiesにてやはりアジャイルコーチを業務委託で引き受けており、アジャイル導入の支援と開発組織づくりのお手伝いをしています。

要するに、本業エンジニアやりつつ、副業でアジャイルコーチをやっていきます。

そもそもお前は何者なの

電機メーカーの研究所でソフトウェア工学の研究を長年やって、そのあとAIベンチャーに入ってML/AI関連ソフトウェアの開発を主に担当しました。
その後、ここ2年くらいはIdein社内でスクラムマスター/アジャイルコーチとして、スクラムにどっぷり浸かっていました。

昔にはなりますが、過去にAlloy本とかTAPLとかの翻訳をしています。

なぜ転職を考え始めたか

理由はポジティブなものもネガティブなものも色々あって、それが複合的に絡まってこうなった、というのが率直なところです。

そんなうち、ここでは特に鍵になった話をいくつか並べてみます。

1. いつ辞めてもいい、と思いながら仕事をしていた

まず下地として、スクラムマスターになってから、「いつ辞めてもいい」と思いながら仕事をするようになっていました。

スクラムマスター(SM)の仕事の1つに、チームの開発の障害になるものは排除する、というのがあります。それは、その「障害」が会社のエライ人や重要顧客からくる無茶な要望であっても同じなわけです。

そんな話を真に受けて、自分はCXOが数億円の予算を持ったクライアントをバックに無茶振りをしてきても体を張って突っぱねたりしていました。
当然ながらそういう行動はMPをゴリゴリに消費するので、SMって辞める覚悟をしてないとできない仕事やな、と思い込んでいました。

2. Ubieを知った

でも、本格的に転職という言葉が頭をよぎり始めたのは、Ubieという会社を知ってからです。 元々古い知り合いだったおおたまんさんがいつの間にかUbieに転職していたことから会社の存在を知ったのですが、この時点では特にすごく興味を惹かれたわけではなかったです。
ただ、おおたまんさん、前職で上場企業のCTO(CDTO)を務めていたのに未上場ベンチャーの1エンジニアとして転職していて、ちょっとびっくりした、というのはありました。

本格的にUbieに興味を持ったのは、この記事をたまたま見つけて読んだときでした。

note.com

ベンチャーが成長し規模が大きくなるほど、良くも悪くも「普通の会社」になってしまい、ベンチャーとしての魅力をどんどん失っていく、というのはどこにでもある話です。

それを、少人数のベンチャー組織を会社内に作ってその他と隔離する……なんて大胆な発想で手を打とうとするその意欲と言うか、組織開発への意識の高さに感銘を受けました。
そのへんは、現在ホラクラシーを採用していたりする点にも現れているように思います。

そんなこんなで、こんな会社で働いてみたい……という意識が頭の中にちらつくようになりました。

3. スクラムマスターとしてもっと場数を踏みたくなった

それと相前後して、ちょうどIdeinでSMを始めてから1年ほど経って、ここで経験を積むことの限界を感じるようになっていました。

SMをド真面目にやってみるとわかるのですが、とにかく経験がモノを言うんです。場数をどれだけ踏んで、どれだけ自分の中に引き出しを持っているか、がSMとしての能力に大きく影響します。
で、Idein社内ではスクラム屋さんとして本当に色んなことをやらせてもらったのですが、段々と、Idein社内で直面する問題に対処するのにIdein社内で得られる経験だけだと足りない、と感じるようになりました。

それで、スクラムのカンファレンスにもたまにちょこちょこ顔を出すようになったのですが、一方で「ぜんぜん違う会社に移って、そこで新たな経験を積むのもいいかな」と思うようになりました。

4. 諸々の事情で選考に進み始めた

とはいえ、Ideinでまだまだやっていく意欲も全然あったので、「当面転職の意思はないけど、少し先のことを考えて」色んな会社のカジュアル面談だけ受けて回るようになりました。

それがどうして本格的に選考に進む気になったかというと、1つは、自分のチームが担当しているサービスのローンチの予定がなくなった、というのがありました。
元々、転職を考えるならそのサービスが無事にローンチするのを見届けてから、という意識が強かったのです。それが、諸々の事情で社外向けのローンチが無期限延期になり、転職を先延ばしにする理由がなくなったのです。
(別にこの決定自体をネガティブに考えていたわけではないです、念の為。むしろ社内でじっくり育てたほうがいいフェーズだと思っていたし、実際、このプロダクトはそれで現在成果を上げつつあります。)

他にもまぁ、ネガティブな理由も作用するにはしました。その話は書いても詮無いものなので書きませんが、一時的なものだったし、会社を辞めるほどの内容ではなかったです。
ただ、他社の選考を受けてみようと思うには十分な理由にはなりました。

スクラム人材としてびっくりするほど評価された

話が相前後しますが、カジュアル面談ベースで緩い転職活動を始める際、まずきっかけとなったUbieは外せなかったんですが、一方で、もう少し可能性を広げてみたくて、いくつかのチャネルから他社も色々見て回ることにしました。

最初の時点では、普通のエンジニアとして転職活動するか、スクラムマスター(SM)やエンジニアリングマネージャー(EM)としてやるか結構迷っていたのですが、そのへんの意識を変えるできごとが、転職活動を始めてから起こりました。

活動を始めてみると、とにかくSMとしての引き合いがとても強いのです。特に、LinkedIn経由で外資からSM、もしくはアジャイルコーチの引き合いが死ぬほど来ました。

更にはカジュアル面談をしてみると、自分のSMあるいはEMのスキルがとても市場価値が高い、というのに気づきました。SM/EMのポジションでカジュアル面談を受けた、結構な数の会社から「ぜひうちに来て欲しい」という類のラブコールをもらいました。

選考が進んでダメだった会社ももちろんありましたが、そのうち複数の会社からのお祈りメールには「今回はどうしても条件が合わず見送りになったが、機が熟したらぜひこちらから声をかけさせて欲しい」なんていう、そうそう見ない言葉が書かれていました。

そしてSMのポジションでオファーをくれた1社は、自分の希望年収より約20%高い報酬を提示してくれて、死ぬほどびっくりしました。

自分がIdeinでやってきたことは決して間違いじゃなかったんだな、と、すごく自信になりました。

どうやって進路を決めたか

結果としてオファーをくれたのは、Ubieと、上述のSMポジションで高い評価をくれた会社の2社でした。それと現職に残るのも含めて、3つのオプションのうちどれを取るか、で悩むことになりました。
ちなみに、Ubieでは「コードを7,8割書く」エンジニアとしてのジョインを、他の2社はスクラム関連の仕事を期待されていました。

そんな中、僕の方からおおたまんさんに、もっとUbieの事を知りたいから話したい、色々話を聞かせてほしい、と相談したところ、そのおおたまんさんの計らいで、Ubieのオフィスに招いてもらって、一緒に働くことになりそうなエンジニアの方々と酒も交えながら一緒に御飯を食べることになりました。

そのときの様子が、とにかく印象的でした。みんな一介のエンジニアのはずが、自分のプロダクトについて技術だけでなく、事業や組織の目線で語れる人ばかりでした。僕は近年そういうのがエンジニアの理想形だと思うようになっていたんですが、それを地で行く人たちばかり、という状況に驚かされました。
そして何より、皆さんが本当に楽しそうでした。既に社員数250人程度に育った会社で、未だにベンチャーの空気感をちゃんと残していました。

自分がそのことを口にすると、同席していたとあるエンジニアの方が

会社が小さいうちはどんなベンチャーだってこういう空気感でいられるんだけど、会社が大きくなってもそれを維持するためにはとてつもないコストを払わないといけない。 僕たちは皆でそのコストを払ってるから、これが維持できてるんだよ。

てな感じのことを言われたのがとても印象的でした。

後から振り返ると結局、この食事の場が決定打になった気がします。この会社のオファーを蹴るのは損だ、と強く思わされました。

とはいえ、その後も結局ギリギリまで悩みました。SMとして自分を高く評価してくれている企業もあり、また自分のスクラム関連のスキルはすごく市場価値が高いらしいのに、それを本業にしなくていいのか、そこにオールインしてそっちのキャリアを積まなくていいんだろうか、という思いもずっと感じていました。

ただ最終的には、スクラム関連で自分が今まで獲得したスキルを活用しながら仕事するより、Ubieという独自のカルチャーを持つ会社に入って、自分自身がもっと色んな事を学びたい、という気持ちが勝ってしまいました。

あとこの時点で、matsuri technologies での副業が決まっていたのも実は最終決定に大きく影響しました。matsuriも当初は転職活動の一環で面談したのですが、トントン拍子に副業でアジャイルコーチングをすることが決まっていたのです。
それで、スクラムアジャイルのキャリアは副業にして、本業は普通のエンジニアでいいかな、と思えるようになっていました。

現職にも残るという選択

で、現職のIdeinに退職希望を伝える運びになりました。ただ、元々Ideinがどうしても嫌で辞めるのではないし、Ideinでは自分がスクラム屋さんとしてかなり色々な施策をやってるさなかで、このタイミングで僕が抜けて、僕がやりかけていた仕事が立ち行かなくなる、といった事態は避けたかったのです。
だから「辞めてからも必要なら業務委託でコーチングやります」というのも一緒に伝えました。

最終的に、Ideinとしてもコーチングしてもらうのはありがたい、と言ってもらえて、正社員でなくなるのと入れ違いで、アジャイルコーチの業務委託を引き受けることになりました。

他にも面白い体験をいっぱいしました

ここまではひたすら「上手く行った」話しか書いてませんが、裏では当然ながらドタバタも失敗もありました。

ある会社では、カジュアル面談で「ぜひウチに」とラブコールをくれていたにも関わらず、選考に進んだら1次面接で「ウチに合わない」という理由でバッサリ落とされて唖然としたとか。

他のある会社では、向こうからカジュアル面談のお誘いをもらって、こちらの条件を伝えつつ「こういう条件でいいならぜひ」と応じて面談したものの、結局その条件が気に入らなかったらしく10分で向こうが興味をなくして終了したとか。

他にも色んなことがありましたが、デリケートな内容も多いのでこれ以上は文章にはしません。 ただなんというか、普段外からは伺い知れない各企業の文化や風土や考え方などを、転職活動を通じて知ることができて、色々な意味で本当に興味深いものでした。自分が採用する側になった場合を考えても得るものが多かったです。

Findyさんにお世話になりました

最後に、今回の転職ではFindyさんにかなりお世話になりました。

今回はどうしても転職したいという状況ではなかったので、いくつかの転職サイトに情報を登録する以上のことはほとんどしてなかったんですが、Findyは

  • 届く求人案件のマッチングの度合いがその中で一番高かった(大ハズレがほとんどなかった)
  • ユーザーサクセス部の方のコンサルティングで、自社紹介案件かそうでないかに関わらずフラットなアドバイスを継続的にもらえた

というので大変重宝し、最後はめちゃめちゃ頼り切っていました。

Findyというとスキル偏差値ってイメージが強くて、それへの評価も色々だと思うんですが、こんなに転職活動をサポートしてもらえるとは(失礼ながら)正直思ってませんでした。
本当にありがとうございました。

2023.10.8 追記

ここから更に一波乱あったので、そのことを改めて書きました。

bonotake.hatenablog.com

Ubieは中途半端なところで辞めることになってしまい、申し訳ないやら何やら、色々な思いがあります。
ただ、少なくとも自分は辞めてもまだUbieのファンでいますし、今は社外から応援しています。

アジャイルコーチとスクラムマスターの集いで僕が得た学び

これに行ってきました。

www.attractor.co.jp

スクラムマスター、アジャイルコーチを生業とする人たちが集まる2泊3日の合宿で、一応OST の体裁を取っているが、2日目の午後にはもう単にみんなそこらで雑談しているだけにしか見えない会でした。

ただ、その雑談がとてもとても濃密で。

まだそのOSTが始まる前、「雑談しませんかー」と声をかけられ*1、軽い気持ちで応じて、なんとなく自己紹介程度に今やってることや感じている課題感をポロッと話したら、いつの間にか僕はコーチングを受けていて、10分後には僕は新たな気づきを得ていました。な……何を言っているのか(略 このネットスラングってまだ使われてるんだろうか

要するに、普段コーチングを生業とする人たちが集まって雑談すると、自然と勝手にお互いをコーチングしあうことになるわけです。
もし僕が、この3日間で僕に色々気づきをくれた方々にお金を払って業務でコーチングをしてもらって同じだけの気づきを得ようと思ったら、参加費の10倍で足りるかどうかわかりません。足りないんじゃないかな。

……という、本当に、ぜいたくな会でした。

で、楽しいなぁ、と思っていた3日めの朝、このaki.mさんのブログを読んでひええとなりました。

aki-m.hatenadiary.com

濃密とは言え、雑談のように話していた1日分の内容をきちんとまとめてこういう形でアウトプットしていて、その量が半端なく。
とんでもねーな、と思いつつ、そこではた、と考えてしまったわけです。

果たして自分は、このボリュームに伍するだけの何かを得たのだろうか、と。

それからは、僕は結局この会で何を得たのかなぁ、なんてことをつらつら考えながら帰路についていました。

疲れもあって結局、その自分の中の問いに答えられないままその日は寝てしまったのですが、朝起きて、振り返りと言えば聞こえはいいけど、合宿中に考えたいろんなことをずっと思い返していました。

それで、ああ、と思い至りました。
僕自身が、たくさんの思い込みやトラウマに囚われていた、ということに。

それを象徴する話が、1日目の夕食の際に交わした会話にありました。

この合宿には、いわゆるJTCから来ている人もたくさんいて、大企業でアジャイルやるの大変だよねー、みたいな話題になっていたと思います。

僕もかつてJTCに勤めていて、晩年は社内政治の多さに辟易としてたこともあって、その場で「自分がもし、古巣や他の大企業からコーチングを頼まれたとしても請けられないかな。社内政治しんどいし」とぽろっと口にしたんです。
そしたら、目の前に座っていた川口さんが「それは違うんじゃない」と言ってこられたんです。

社員だった当時と今は立場が違う。社員時代は直属の上司を介してしか意思決定者にアクセスできなかったかもしれないけど、今の立場でそんなことをしたらダメで、意思決定できる人を捕まえて直接掛け合えばいいだけ。
社員時代と同じようなアプローチしかできないと考えてしまうのはただの思い込みで、もし社員時代の辛さがトラウマになってしまっていたとしても、それを乗り越えないといけない。
トラウマと向き合うのは大変で辛いけど、辛さを乗り越えてフラットに考えれば、今の立場は当時と違うということは簡単にわかるはず。

本当はもっと長々と話していたけど、だいたいまとめるとこんな言葉をもらっていました。

これを踏まえて考えると、他の件も含め、自分があの場で話した自身の課題や悩みって、ことごとく思い込みやトラウマに起因するものだった気がします。
要するに、たくさんの感情に囚われていたのだと。
「人間って感情の動物だから」って、つい最近誰かへのコーチングで話した記憶があるんですけど、かくいう自分が感情の動物であることをすっかり忘れていました。

「それに向き合うのはアンガーマネジメントに似た何か」というのも川口さんからかけてもらった言葉ですが、自分に足りてなかったのはそれなんだな、というのが僕がこの合宿で得た最大の気づきだったかもしれません。

そういう意味では、僕のドロドロした感情ダダ漏れの話に耳を傾け、真摯にアドバイスくださった参加者の皆さんには、申し訳無さもありつつ、感謝しかないです。

ここずっと、僕は誰かの相談相手になるばかりで、逆の立場でこんなにたくさん相談に乗ってもらえたこの会は本当に貴重な機会でした。
願わくば、僕も誰かのなにかの気付きのきっかけになれていればいいな、と思いつつ。

*1:この会で初めてお会いした方で、一応お名前は覚えてるつもりなのですが、もし間違えていたら失礼極まりないのでちゃんと確認を取ってからお名前を記載します。

『コーポレートファイナンス第10版』を読み始めた

何かめっちゃ久しぶりにブログ書く気がしますが。
唐突ですが、とある人の勧めで最近これを読み始めました。

その人いわく、「シニアエンジニアは皆読んだほうがいい。自分が作っているものの価値を金の言葉で語れるスキルを持つと強い」だそうです。

何も考えず買ってみたら1冊800ページあって鈍器として使えるレベルで、それが上下巻の2冊あるんでびっくりしましたが、少しずつ読み始めています。今日は資本の機会費用という言葉を初めて知りました。 1日2セクション読んでいこうと思ってます。1冊だいたい60セクションあるんで、このペースを毎日維持すれば2冊を2ヶ月で読破できる…はず。

読んだからにはアウトプットしないと身につかない気もするので、もしかしたら今後この本について何か書くかもしれません。

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。