はらへり日記

腹に弾丸

notion-sdk-jsをチョット便利に使えるnpm package書いた

書いた

www.npmjs.com

notion-sdk-jsとは

Notion APIを叩くためのTypeScriptのライブラリ。多分公式。

github.com

何を解決したいのか

Pageを作成するAPIを叩く際にJSONを組み立てるのがめんどくさいのが一番だった。

型定義で守られてはいるものの、ドキュメントを見ないとまず書けないし後は書く分量がどうしても多い。

例えばHeading 1, Paragraphの2つだけで構成した下記のページを作る

こんなページをAPIで作りたい

この場合、こんなコードを書く必要がある。

import { Client } from '@notionhq/client';

const client = new Client({
  auth: 'YOUR_NOTION_API_TOKEN',
});

await client.pages.create({
  parent: {
    databse_id: 'DATABASE_ID',
  },
  properties: {},
  children: [
    {
      type: 'heading_1',
      heading_1: {
        rich_text: [
          {
            type: 'text',
            text: {
              content: 'Section1',
            },
          },
        ],
      },
    },
    {
      type: 'paragraph',
      paragraph: {
        rich_text: [
          {
            type: 'text',
            text: {
              content: 'I am ',
            },
          },
          {
            type: 'text',
            text: {
              content: 'engineer',
            },
            annotations: {
              bold: true,
            },
          },
        ],
      },
    },
  ],
});

長くないですか?僕は長いと思って毎回書いてられん…と思ってしまいました。

また、地味に仕様上めんどくさいなと思ったポイントとしては文字列を渡す際、ほとんどはRich textを配列形式で渡す必要があることです。

上記のコードから抜粋すると以下です

await client.pages.create({
  // ...
  children: [
    // ...
    {
      type: 'paragraph',
      paragraph: {
        rich_text: [
          {
            type: 'text',
            text: {
              content: 'I am ',
            },
          },
          {
            type: 'text',
            text: {
              content: 'engineer',
            },
            annotations: {
              bold: true,
            },
          },
        ],
      },
    },
  ],
});

ここで配列で渡す理由は、文章としては1つでも文字1つ1つにDecorateion(Notion APIの言葉で言うとAnnotations)が振られる可能性があるため、それを仕様として吸収するために配列形式になってます。

Notionの仕様上、しょうがないのは納得できたんですがAPIを利用時に毎回そこそこ大きめなObjectを羅列するのは辛いなと思いました。

ちょっとでも楽しようと思って作った

と言うわけで作った。

www.npmjs.com

先ほどのコード例はこれを使うとこうなる。

import { BlockObjects, RichTextObjects, CustomTypes } from '@sota1235/notion-sdk-js-helper';
import { Client } from '@notionhq/client';

const {
  heading1,
  paragraph,
} = BlockObjects;

const client = new Client({
  auth: 'YOUR_NOTION_API_TOKEN',
});

// Use helper methods when create page
await client.pages.create({
  parent: {
    databse_id: 'DATABASE_ID',
  },
  properties: {},
  children: [
    heading1('Section 1'),
    paragraph([
      RichTextObjects.richText('I am '),
      RichTextObjects.richText('engineer', {
        bold: true,
      }),
    ]),
  ],
});

さっきよりは書きやすい & 読みやすくなりました。

この量だと書けばいいじゃん、となるかもしれませんが実際に作りたいページはもう少し複雑なのでこれがあるだけでだいぶ書き味が変わるはずです。

下記ページに大体のBlockのサンプルコードを載せてるのでそちらを読むとよりイメージが湧くと思います。

Example page for notion-sdk-js-helper

地味に面倒だと思ってた文字列の配列に関しても、少しでも楽に書けるようfunctionの入口はstring | RichText | RichText[](RichTextの型)を受け付けつつ、各部分でその部分を吸収するようにしました。

await client.pages.create({
  parent: {
    databse_id: 'DATABASE_ID',
  },
  properties: {},
  children: [
    paragraph('text'), // stringだけ渡すのでもOK
    paragraph(RichTextObjects.richText('engineer', {
        bold: true,
      }),
    ), // RichTextだけ渡すのでもOK
    paragraph([
      RichTextObjects.richText('I am '),
      RichTextObjects.richText('engineer', {
        bold: true,
      }),
    ]), // RichTextの配列もOK(これが元々の仕様)
  ],
});

これでだいぶストレスフリーに書けるはずです。

※ サンプルコードを書いてて気づいたけどstringRichTextが混ぜこぜの配列も渡せるようにした方が楽そうなので改善しておきます

作るにあたり

ここからは苦労談義なので興味がなければ読み飛ばしてください

型定義をどうするか

ブロック1つ1つのObjectを生成するfunctionsを作るにあたり、それぞれのブロックの型定義が欲しくなります。

notion-sdk-jsは結構、堅牢な型定義があるのでそれを利用すればすんなりいけるだろうと思ったら「これが欲しい…!」と言う型はexportされていませんでした。

exportするだけだしPull Request出そうかなと思ったんですが質問はなぜかメールでしか受け付けておらず、質問してみたら「いいアイディアだね!いつかは検討するけど他にもいろんなfeature requestがあるから待っててね!(意訳)」と言う感じの回答が返ってきたので本家のコードを直すのは諦めた。

代わりに欲しい型を取り出すAdHocな方法を教えてもらったのでいまいちとは思いつつそれを参考に型定義を作った。

具体的には以下のファイルに色々書いてて、読むと分かるんですがあまり綺麗な方法ではないです。

github.com

Undocumentedな仕様がたまに紛れてる

直感的にはいけそうなんだけど、実際にAPIを叩くとうまくいかない部分がちょいちょいありました。

つまるところ、notion-sdk-jsの型通りに使ってれば壊れることはないので利用者は特に意識する必要はないのですが例えばColumn Listの子BlockにTableは突っ込めないという制約があったりします(手動で書くと当然作れる)。

まとめ

  • 楽したいので自分のために作ったけど似たような需要があれば使ってください
  • メンテナンス頑張りますけどバグってたらIssueかPRください
  • 普段お世話になってるyhatt/jsx-slackから発想を得たりしました。JSXで書けるようにしたらおもろそうだし勉強になりそうだなと思ったけど流石に高級だなと思って愚直に書くだけの実装にとどめました

10Xに入社してから1年とちょっと経ちました

2021/8/16入社だったので1年とちょっと、経ってました。

sota1235.hatenablog.com

この期間、個人として新たにチャレンジさせてもらいたくさんの成功と失敗から色々学んだので思い出せる範囲でざっくばらんに記録しておこうと思います。

書きながら、これはうまくまとまらんというか別記事に切り出したいと思うものもたくさんあったのでそういうものは別記事でコツコツまとめていこうかなと思ってます。

あと私自身、結果はどうあれたくさん頑張ったなぁと思って書き始めた記事ではあったんですがやっぱりチームメンバーにもめちゃくちゃ恵まれてたよなという気持ちもあり巧妙なチームメンバーへの感謝記事になった感もあります。10Xいい会社デスヨ。

サマリ

  • Software Engineerとして入社して機能開発をコツコツやった
  • 色々あってTeam Leader兼Managerになった
  • 優秀なメンバーの大いなる成果のもと、走れるチームになってきた
  • 家庭の事情でお休みに入るため、Managerからメンバーに戻った

という感じの1年とちょっとでした。

Software Engineerとして入社した

入社の経緯やモチベーションは過去に書いた通りなんですが、入社時の私から会社への期待値を一言で言うと「自身が体験したことのない体制や雰囲気の中でゴリゴリ開発を進めていく」という環境でした。

入社してからの実態としては期待と概ね同じ、もしくはそれ以上で各々が各々でひたすらIssueを解きままくる侍スタイルな環境で、気持ちとしては一刻も早く成果を出さねば…!という気持ちで最初の最初の2、3ヶ月は過ごしてました。

自分は性格上、自分自身にプレッシャーを過度にかける傾向があるので特に入社してからの一定期間は不安が強かったんですが、10Xメンバーが積極的に私自身の良いポイントと改善していくべきポイントを大人なコミュニケーションで伝えてくれたので心理的安全性が高かったなぁと思います。

また、各メンバーが会社のClutureやValueを強く体現しているので自分がそれに染まれるスピードも早くて、このサイクルは維持していきたいなという気持ちです(こういうのは何も手を打たないと基本的には採用の加速やメンバー増加に比例して薄まっていってしまうと思う)。

本当にダイジョウブカナーと思っていたDart/Flutter開発に関しても言語自体の敷居もそこまで高くないことと、サンプルコードが山ほど社内にあるのでそこまでつまづかずにキャッチアップできたかなと思います。Flutterに関してはWeb Frontendをやっていたのがかなり良かったなーという所感だったのと公式ドキュメントをなぞれば3, 4日くらいで完全に理解した状態になれると思います。

いろいろあってLeader兼Mangerになった

2021/08 - 2021/12までの間は1人のSoftware Engineerとしてゴリゴリ働いてましたが、2022/01からは組織が新しい体制に移行し、Platform Development TeamというチームのLeader兼Managerにアサインされました。

組織変更の経緯は弊CEOの下記記事がわかりやすいです。

yamotty.tokyo

アサインされた理由は結構シンプルで当時、システムの守備面周りでやいやいうるさく言っていて、じゃあLeadershipを持って色々進めてくれ!という感じかなと思ってます。Tech Leadの経験はありましたが、組織によってLeaderに求められる役割は変わっていくし、Managerは初だったので抵抗が無いわけではなかったですが任されたらやる気を出してしまう単純な性格ではあるのでちょっと頑張ってみるか!という気持ちで引き受けました。

僕が思う10Xの良さであり、大好きな文化の1つとして「抽象度の高いIssueをメンバー、チームに降ろしていく」スタイルがあります(この辺り、いつか 言語化.fmで話します)。

この時も例に漏れず、「開発・運用基盤を整えることを目指すチームを組成する」という壮大なミッションと解決すべき具体的なIssueのいくつかがチームに託されました。

最初の3ヶ月(2022/1~3)

チームミッションとIssueの整理

まずはチームに託された「開発・運用基盤を整えることを目指す」とはどういうことなのか。ミッションとIssueの整理から取り掛かりました。

壮大に見えたこのミッションですが、当時Stailerの機能開発・運用保守を進めていくにあたって既に発生していたIssueを解決する手段として一番抽象度の高い表現が「開発・運用基盤を整える」だった、という整理を私の脳内ではしています。

じゃあ具体的に発生しているIssue、これから発生するIssueってなんだっけ?を整理していくと以下のような感じでした。

  • 既に発生していたIssue
    • プロダクトのフェーズがLaunchからGrowthへと変わり、求められるプロダクトの品質水準が上がってきているがそれに追いつけていない
    • 開発のスループットを上げるための仕組みが整っていない(高速で安全なリリースができる仕組み、検証環境の準備、システム上の責務・運用境界線の適切な分離)
    • サービス可用性を担保するための監視やOn Call体制が構築されていない、Alertが割れ窓状態になりつつある
    • パートナー(契約企業)からセキュリティ面でのニーズが強まっていたが、それに対する明確な解答を社内で用意できていなかった
  • これから確実に発生するIssue
    • システムの成長に合わせてエンジニアリング組織も成長する必要があり、それを見据えたアーキテクチャやインフラ、リリースから運用、監視までの設計をしていかなければいけない
    • セキュリティ面の要求がより高まり、内部ガバナンスの強化やプロダクト自体のセキュリティレベルの向上およびそれを実現するための体制構築が必要になる

Leaderとして最初に取り組んだ仕事は、チームメンバーと協調しこれらのIssueをどういう形で打ち返していくのか。このような類のIssueを継続的に解いていくチームに求められるミッションとは、を定義していくことでした。

チーム体制の検討

これらのIssueを並べた時、それを解くために求められるスキルセットや進め方の最大公約数は少なく専門性が必要だと感じました。

そこで当時のチームではサブチームという形で専門性を切り口にチームを3つに縦割りし、各サブチームごとに独立しながら動く体制を構築しました。

具体的なサブチームは以下の3つです。

この体制で走ってみてどうだったか。結論から言うとこのサブチーム体制はある程度、意図した通りに作用した側面があったかなと思っています。チームを割って意思決定の人数を減らすことで各サブチームの動きは相対的には素早く動けていたと思います。

一方で以下のIssueも顕在化しました。

  • 各チーム、未来に向けた取り組み以外のタスクに多くの時間を取られていた
    • 過去に積んできた負債改善、チーム体制変更に実態が追いついていないことによる兼務の常態化、チーム変更の過渡期ゆえの割り込みタスクの多発が主な原因でした
  • Development Processチームの取り組みはAs Platformではなく、機能開発チームの一部として実装されるべき役割であることがわかってきた
    • このサブチームが具体的に取り組んでいたのは開発サイクルの改善(仕様を作ってからリリースされるまでのプロセス改善)が主でした
    • この取り組みは一部はPlatform Team的な立ち回りが最適ではあったものの、いくつかは実際に機能開発チームに所属し、内側から改善していく方が良い取り組みもありました

また、自分のチームだけではなく組織全体としてもチームの切り方や責務の配置が最適ではないというIssueがありました。

これに対し、次のQではチーム体制の刷新、メンバーの再配置を行うことになりました(後述します)。

初めての評価

私はLeaderであるとともにManagerでもあったので、人事評価も担うべき責任の1つでした。

それまでの10Xでのエンジニアの評価はCTOが全て担っていました。この状態では評価者が1人のため、評価者ごとに評価基準の解釈がずれて社内で評価の整合性がずれるということは起きづらいです。そのため、評価基準は良くも悪くも精緻に言語化する必要がない状態でした。

この背景を踏まえると私含めた当時のManagerの評価における重要なミッションの1つは「会社の評価制度を踏まえて、どのように評価を行っていったのかCTOの脳内を開示し、言語化し、エンジニアリング組織として整合性を担保した適切な評価を行う」ことでした。

これが上手くいったのかどうか、どれだけ上手くいったかはここでは語りませんが(聞きたかったらご飯誘ってね)、少なくとも最適な成果を上げることはできておらず、エンジニアリング組織としていくつかのIssueが浮き彫りになったタイミングだったと捉えています。

  • 組織の拡大、事業の成長に評価制度のアップデートが追いついていない
  • (私個人)評価の適切さを説明するための言語化ができておらずメンバーに納得感を持ってもらうための材料をマネージャーとして用意しきれなかった

「チームの成果」へのFocus

チームLeaderである以上、何よりもFocusすべきなのは私個人がうまくやれるか、ではなくチームが目指すべき方角へ最速で走れているかを常に確認し、それを実行しきるために必要な全てのことを成し遂げることです。

今はこれを明確に意識することができますが、当時は私にこの意識が持てておらず、3ヶ月終わった時にはチームが出した成果と会社としてチームに期待したGoalのAlignができていないというIssueが発生しました。

このIssueは内部的に以下の2つのSub Issueが含まれていました。

  • チームがボトムアップで必要だと思い、成し遂げた成果を組織にraiseしきれておらずQ末にゴールとずれていた
  • 組織からの期待値を整理、言語化しきらずにチームを走り始め会社からの期待値とチームのゴールがAlignできていなかった

このIssueは明確に私が改善すべきポイントであり、かなり反省しながら次Qに望むことになりました。

最初の3ヶ月のIssueまとめ

最初の3ヶ月で顕在化したIssueをまとめます。

  • 組織全体で見た時、チームの持つ責務の一部が最適な配置になっていなかった
    • 開発プロセスの改善は私たちのチームではなく、機能開発チーム内で実装すべきではという仮説が有力だった
  • チームがFocusしたいことにできていない状況があった
    • 負債改善、兼務の常態化が主な原因
  • 評価制度が組織・事業のフェーズに追いついていない、もしくは調整が必要だった
    • 私自身もAs Managerとして評価に関する説明責任を十二分に果たすための振る舞いができていなかった
  • 会社から期待されるチームの成果とチームとして目指したい成果のAlignが十分にされていなかった

次の半期(2022/4~9)

前回の3ヶ月間のIssueに対して

前回の3ヶ月間で顕在化したIssueに対して、まずは私の立場でできることを順に行っていきました。

  • 組織全体で見た時、チームの持つ責務の一部が最適な配置になっていなかった
    • これは私のチームだけでなく、他のチームでも一部顕在化していた
    • CTO-Manager間で協議の上、新しいチーム体制を検討しメンバーの再配置を行った
    • 結果として私のチームはReliability, Securityサブチームはそのまま。Development Processサブチームのほとんどのメンバーは機能開発チームへ異動した
    • ただしQA(Quality Assurance)の領域はメンバーが入社前だったこと、As Platformとして開発チームに関わっていくことがBestと判断し私のチームのサブチームとして新しく設立した
  • チームがFocusしたいことにできていない状況があった
    • 負債改善に銀の弾丸はないので引き続き取り組むことをチーム内で合意した。一方でこの必要性の認識を組織内で揃え、明示的に投資すべき領域として上長であるCTOと強く握るプロセスを踏んだ
    • 常態化していた兼務に関してはメンバーからヒアリングを実施、CTO-Managerの場に持ち込み責務のあるべき配置を議論した上で引き継ぎ先を明らかにし、その引き継ぎを実行するためのサポートを行い始めた
  • 評価制度が組織・事業のフェーズに追いついていない、もしくは調整が必要だった
    • 実際の評価プロセスでメンバーからもらったfeedback、私自身が感じたIssueをCTO-Managerの会議体でraiseし、評価制度のアップデートの検討を開始した
  • 会社から期待されるチームの成果とチームとして目指したい成果のAlignが十分にされていなかった
    • Leader(=私)がQ初めに取り組むべきプロセスをプロトコル化し、実行した
    • 具体的には当たり前のことを当たり前にやる、という話、以下の手順で取り組んだ
      1. 会社のFocusを咀嚼する
      2. チームに伝えた上で目標設定のオフサイトを実施
      3. 会社FocusにAlignしたもの、チームとしてボトムアップに取り組みたいものをチーム目標に反映
      4. 上記のドラフトをCTOに共有、レビューをもらい適切にアップデート
      5. 週次のweeklyでチームでそれを追っていく、進捗が芳しくないものがあればLeaderとして原因を調査、ブロッカーを取り除いたり目標の修正を行っていく

ここに書いたことに取り組みつつ、この6ヶ月間はチームとしての実りが生まれ始めた期間だったと思います。

Reliabilityサブチームの立ち上がり

厳密にはReliabilityサブチーム(a.k.a SREチーム)は2022/1に立ち上がっていましたが、チームらしく絶え間なく成果を生み出し始めたのはこのタイミングだったかなと思います。

product.10x.co.jp

anchor.fm

これが成し遂げられたのは私の力ではなく、2022/1-3の期間でチームアップの仕込みを愚直に行ってくれた@_tapihさんと、4月からReliabilityサブチームのLeaderとしてチームロードマップ作成のLeadから足元の取り組みのLead、戦略策定をOwnershipを持って取り組んでくれた@babarotさんのおかげです。

また、ソフトウェアエンジニアでありながら自身の強い課題意識からReliabilityサブチームに所属してもらい、かなり色々と無茶なIssueを任せているにも関わらず成果を出し続けてくれている@horimislimeさんにも本当に助けられました。

Securityサブチームの立ち上がり

再掲にはなりますが、Securityサブチームは2022/1に立ち上げたものの、最初の3ヶ月間は実際に手を動かすより社内のIssue集めの箱や、スポットでのIssue解決を行うような動きが主でした。

product.10x.co.jp

この動きから、メンバーの兼務を解消したこと。私自身が少し小慣れてきて手を動かす時間を作れるようになってきたことから徐々にProactiveな取り組みを行えるようになりました。

特に10X初期からソフトウェアエンジニアとして活躍している@swdyhさんにはセキュリティの専門知識がない状態からスタートしたにも関わらず、いろいろなキャッチアップを進めながら、他チームのサポートもしながら少しずつ成果を出してもらいました。

それもあって2022/7-9の3ヶ月間では会社としてセキュリティ上のリスクとその実態を正しく認識できる状態になり、会社の目標にセキュリティに関連した目標を設定され、事業としてもチームが明確に必要であることを証明できたタイミングでした。

speakerdeck.com

Qualityサブチームの立ち上がり

最初の3ヶ月間、開発の品質と生産性にFocusしてくれたDevelopment Processチームから一部切り出される形でQualityサブチームを2022/4のタイミングで立ち上げました。

このチームはこのタイミングで0から立ち上げた、というよりは入社前から業務委託としてコミットしてくれていた@tarappoさんが入社して、本格的に立ち上げてくれたチームです。

その立ち上げの爆速っぷり、素晴らしさはすでにたくさんの記事があるのでそれを読んで欲しいですが、「10Xの開発組織のアウトプット品質を事業の未来を見据えながら担保していくチームを作ってくれ」という抽象度も難易度も高いIssueに対して明確な回答を1つ1つ積み上げてもらいました。

10x.co.jp

product.10x.co.jp

また、途中で入社してくれた@iizima(twitterわかりませんでした)さんも@tarappoさんが積み上げたものを解像度高く爆速で理解した上でゴリゴリ成果を出してもらいました。

振り返ってみると

こうやって書き出してみると、この6ヶ月間は「私がこうしたからチームが劇的に良くなった」ということはあまり無くて、各サブチームに権限をほぼほぼ移譲しつつ、各所で生まれる大小様々なブロッカーをひたすら取り除いていくというのが主な立ち回りだったと思います。

一方でチームを早いタイミングで縦割りにして、責務を明確に分けたのはThink 10xないい手だったと思います。

この立ち回りができたのはひとえにメンバーがひたすら優秀だったのが一番だなと思ってます。感謝…!

評価制度は改善されたか

Managerの立場として決して蔑ろにしてはいけない評価制度のIssueについてですが、結論から言うとエンジニアリング組織だけでなく10X全体として評価周りの類似したIssueが顕在化しており、エンジニアの評価制度だけ改善するのではなく組織全体として評価制度を大きく刷新されることになりました。

詳しい内容はCEO yamottyの以下の記事が詳しいです。

yamotty.tokyo

Managerの立場として、この制度の更新や解きたいIssueの設定とそれに対する手段は相対的には間違いなく良くなっており、実際の評価プロセスも最初の評価時よりは良くなっているのではないかと思います。

一方で現状が最適化というと決してそんなことはなく、この先もIssueを検出し、1つ1つ対処してきつつ事業や組織の変化にも対応していくことが求められるので、引き続き自分の見える景色でのIssueは会社にraiseし続けたいなと思ってます。

まとめ

全然まとめられずに時系列で取り組んだことを書いてきたんですが、書いてるうちにもっと他にも書きたいと思うことが山ほどあるくらい色んなチャレンジをした期間だったなと思います。

失敗も山ほどしましたが、優秀なメンバーと共に働けたこともあるし、自分が引いたいくつかのレバーのおかげでチームが良くなった部分もあるのかなと思える楽しい期間だったなと思います。

昔は「EMって忙しそうだし調整めんどくさそうだし人間扱うの絶対めんどくさそう…」と言う偏見に満ち溢れた意見を持ってましたが実際やってみると扱うべきIssueの抽象度が上がっただけで問題解決をしないといけない、と言うのはソフトウェアエンジニアとそこまで本質的に違いはないんじゃないかなと思いました。

※ 自分自身の意識付け次第で単なる調整者に陥ってしまうことも十二分にあるかなとも思います

余談:Managerとしての成果

9ヶ月間、Managerとしてやってきた中で結構悩んだのは「私がManagerとしてチームにいることで出たインパクトって何があるんだろう…?」ということです。

例えば「この取り組みは自分が関わってたけど、実際の成果を出したのはメンバーの能力のおかげだったり、他チームが頑張ったからだよな…」みたいに考えたりします。

ManagerはICと比べてリリースしたPull Requestの数、ApproveされたDesign Docの数みたいなアウトプットが少ないです。

今、立ち止まって理由を考えてみると解くべきIssueの形や性質、領域が変幻自在というのがある気がしていて、ある月は評価制度に思いを馳せ続けることもあればある月は採用計画、ある月はメンバーの兼務タスクの解消の調整をしているし、ある月はPlaying Managerとしてコードを書いてたりします。

また、Managerとして評価を受けられる場面もICに比べると少ないと思ってます。コードレビューみたいに指摘がもらえるチェックポイントがあればいいんですが、実際にはいろんなプロセスで問題解決に臨むし、時にはClosedな場所で動く必要があるし、またICに評価を求めた際、ICの置かれる状況次第で「いいマネージャー像」も大きく変わっていくと思います(し、実際はその像が明確な人はほとんどいなくてフィードバックすべきことが思い付かないことが多いと思います。自分もそう)。

個人的にこの答えはエンジニアリングマネージャーのしごとの回答がしっくりきています。

マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット

マネージャーは自分一人で完結して動いて、その結果大きな成果が来るパターンよりチーム内外のメンバーとコラボレーションすることで成果にどれだけ大きな係数を掛けられるかというパターンが多いと思います。これを認識しておくとこの先、Managerをやるときに自分が出すべき成果と求められる振る舞いをより精度高く認識できるはずと個人的には思ってます。

Managerからメンバーへと戻った

そんなこんなで9ヶ月間Leader兼Managerをしましたが、2022/10からICに戻りました。

理由は後日公表しますが、家族の事情(Good Newsの方)で、まぁ後日公表します。

最後に

何かを伝えたいPostというわけでもないですが、もともとManagerをやりたいと思っていなかった立場からManagerにチャレンジした上で感じたことは以下です。

  • Managerの立場でも、責務が問題解決であるうちは楽しく働ける。むしろ課題の難易度が上がるのでやりごたえがある
  • 一度Managerをやっておくと視野がかなり広がる
    • Managerをやるチャンスは世の中の構造上、決して多くない。チャンスがあればチャレンジを推奨したいです
  • Managerとしてどう走り出すべきか、のいい資料が無くて最初は苦労しました

この記事でアカウント名を上げてないメンバーにも、チーム外の一緒に仕事してくれたメンバーにもとても感謝しています。まだまだ未熟ですが今後ともよろしくお願いします。

言語化能力を養うべくPodcastを始めました

tweetでもよかったんですが140文字では少し足りないなと思ったので雑に記事を書きます。

言語化.fmというPodcastを始めました

友人である@d_dateと一緒にはじめました。

anchor.fm

きっかけ

初回の収録でも喋ったんですがここ2,3年、自分と考え方や文化が近いメンバーと働く機会が多くなってきました。

それはいいことなんですが、そうなるとコミュニケーションが割と雑でもいろいろとうまく回る感があってそれに自分が甘え続けた結果、自身の言語化能力が年々下がってることに気づきました。

言語化能力なくても仕事できる場所に居続ければいいじゃん、という考え方もありますがさすがに100%雑なコミュニケーションでチームメンバーとして成果を出せるわけはないし、考え方や文化圏の違う人と働くこともある(し、働きたい)のでこれはまずいなと思った次第です。

なぜPodcastなのか

いくつか案はあると思うんですが自分の中で確固たる考えはあるのにうまく言語化できないな、というものがあるときはシンプルに言語化が得意な人に壁打ちすると整理されたりするかなー、そしたら信頼できる人と定期的にお喋りできるといいな、と思ってのPodcastです。

わざわざ公開しなくてもいいよねという考えもありつつ、等身大の自分の考え方を残しておくと後々便利かもなという気持ちもあり一旦やってみるかという感じです。

アウトプットは正義

基本的には私がうだうだと喋ってるのをdate氏がいい感じに捌いてくれるPodcastになってますが、暇な人とかは聞いてみてください。

2021年振り返り

いろいろあった気がする

  • 転職した
  • いろいろ治した
  • ライブにたくさん行った
  • 入籍した

転職した

株式会社ELYZAから株式会社10Xへ転職した。

詳しくは書いたのであまり語らないですが楽しく働いてます。

前職もオフィス移転して拡大したりと粛々とやっているみたいなので自分も負けずに粛々と来年もやっていこうと思います。

sota1235.hatenablog.com

sota1235.hatenablog.com

いろいろ治した

歯医者からの親知らず放置できません宣告をきっかけに億劫になってた健康対策をいろいろとやった。

主に以下。

  • 親知らず2本抜く
    • いずれも水平埋伏歯で下側
  • 健康診断で引っかかってた肝臓系の改善
    • 平たく言うと脂肪肝(お酒ほとんど飲まないのに…)
    • 食事管理と筋トレした
  • 鼻詰まりと鼻炎アレルギーの手術
    • 鼻中隔湾曲矯正術 + 下甲介粘膜切除術

はっきり言ってそれぞれそれなりにしんどかったけど人生がまだ続くのであれば一番若い今やっとくのが楽だろうということでやった。

特に鼻の手術はなかなか興味深い上にあまり体験談がwebに転がってないので別記事で書く予定。

ライブにたくさん行った

これは今年に限ったことではないんだけどライブにたくさん行った。

コロナ下でライブ事情どうなってるねん、という人が大半だと思うのでざっくり説明するとライブ自体は2021年の9月頃から復活してる一方、依然として厳しい制約下の下、なんとか運営しているのが現状。

特に感染状況が厳しいタイミングでは規模の大きいものは中止を余儀なくされたものも少なくなく、元通りになるまでの道のりはまだまだ長いかもなぁ、という感じです。

とはいえ音楽業界もライブをしないと文字通り死んでしまうし私みたいなライブキッズもライブが無いとメンタルが死ぬので今できる形で開催し続けているという感じ。

今年行ったライブは以下にまとめました。

scrapbox.io

個人的ベスト3を勝手にまとめる

9/27 Love Like Pop vol.22

コロナ渦になってから初めてのaikoのライブ。推しの生存を確認できてボロ泣きした

結婚おめでとうございます。

12/19 ポルノ超特急 Day3

好きなアーティストであるROTTENGRAFFTYが主催してるフェス。

本来はもみくちゃになってあざだらけになって帰ってくるようなフェスだが当然、声も出さずに立ち位置が指定された状態での開催だった。

トリでの演奏が本当にエモすぎて泣いた、一生ついてく。

5/2-5 JAPAN JAM 2021

ゴールデンウィークに行われた野外フェス。当時は感染状況が芳しくない状況である一方、このフェスの主催者の状況も本当に厳しくて中止でなく開催が決断されたフェス。

そのこともあって期間中は朝のワイドショーなりSNSでボロクソに叩かれたりして複雑な思いを抱えながら参加してたけど、そのタイミングで参加してたからこそ参加者のモラルが本当に高くて感動したイベントでもあった。

余談

余談だけどコロナ渦になって自分の好きなものが叩かれる側に回ったことでなんというか妙な悟りを開いた感があってコトに対してやさしくなった気がする。

禁止されてても飲食店を開店してるのも生きるためだし、出社するのも生きるためだし、政治家も叩かれるために政治してるわけじゃないし少なくとも自分は理解の浅いまま蚊帳の外から石を投げるような人間には絶対になりたくないと思わされた1年間だった。

みんなマジで生きてるだけで偉い!!!!!!

入籍した

対面で会った人とかには伝えてるんですが今年の3月に入籍しました。相手は一般女性です。

元々、同棲してたので特に生活が激変したわけではないですが穏やかに過ごせています。

来年は

ここ2年くらい、自分自身のアップグレードが滞ってる感がすごいので今一度、帯を締め直す1年にしたい気持ちが強い。

会社が成し遂げたいことに自分がついていけるよう頑張るぞい。

あとは物理の自分もアップブレードしていきたいので運動のお誘い待ってます。

最後に昨日ノリで行ったら最高だったほったらかし温泉の写真をのせて終わりです。良いお年を!

f:id:sota1235:20211230222931p:plain
ほったらかし温泉からの景色

近況報告その2 - 10Xに入社しました

前回のあらすじ

sota1235.hatenablog.com

10Xに入社しました

8/16から10XでSoftware Engineerとして働き始めました。

10x.co.jp

なぜ10Xなのか

次の会社を探す際、軸にしていたのは以下の2点でした。

  • 共感できるプロダクトを作れること
  • プロダクト作りのことを考える時間を多く取れること

これを実現できる組織の中で10Xに入社することにしました。

Stailerというプロダクト

10Xは現在、小売チェーンのECの垂直立ち上げを実現するStailerというプロダクトを主軸にしています。

stailer.jp

このStailerへの共感が強かったのが入社理由のうちの1つです。

自分は関わったプロダクトでどれだけ人を幸せにできるかがモチベーションにつながるのですが、Stailerはその面において大きな可能性があると感じてます。

Stailerを一言で表現するなら小売事業者のECの垂直立ち上げをするサービスなんですが、ECを立ち上げる際の現実世界は想像以上に複雑で難易度の高い世界です(この複雑さはメルカリ、ELYZAで痛いほど知りました…)。

この高難度なサービスを、ECを立ち上げる事業者、ECを利用するお客様にひたすら丁寧に向き合い、ここまで成長してきたStailerをシンプルに「すごいな…」と思いました。

また、今がまだまだゴールでなく旅路の途中で、会社の言葉を借りるなら事業を10xするのはまだまだこれから、というところにシンプルにわくわくした、自分も力になれるなら参加したいと思った次第です。

10Xという組織

10Xは選考プロセスにトライアルがあります。

product.10x.co.jp

このトライアルでは社内のSlackやNotionを開示した上で自身でイシューを決め、それに取り組むという内容なのですがこの過程で強く感じたのがValueの浸透具合、そしてメンバーが高いレベルでそのValueを体現していたことです。

その結果、プロダクトのイシューを素早く見定め、プロダクトアウトし、少しずつ着実に、しかし非連続にプロダクトを成長させる組織ができていると感じました。

正直なところ、今の実力で自分が10XのValueを体現し、アウトプットが出せるか不安だったのですが、それでもチャレンジし、Stailerの未来を自分の手で作ってみたいという気持ちが強く入社を決めました。

入社してどうか

まだ2週間程度ですがとても楽しいです。楽しい。

CEOのyamottyさんがやってるZero Topicで直近に10Xに入社したメンバーがゲストの会をこっそり聞いてたんですが、それで予習した通りどかんとでかいイシューを任されて早くアウトプットしていかねば、という気持ちです。*1

軌道に乗ってるプロダクト作りに関わるのが地味に久々なので勘を取り戻しつつ、DartとFlutterを勉強しつつ、10Xメンバーとして早く胸を張れるようにならねば、と思う毎日です。

転職活動

special thanks

前回の転職時にあまり休みを取れなかったので今回はゆっくりいろんな会社の話を聞きました。

忖度なしにおもしろい会社ばかりでいい時代になったなーと思います(今までの自分が無知だったのもあると思いますが…)。

最終的に正式に選考に進んだのはドクターズプライムと10Xで、最後は本当に迷ったうえで10Xにしました。

ドクターズプライムでは1ヶ月近く業務委託として働かせてもらったうえに、同社経由でメドピア社の新型コロナウィルスワクチンの職域摂取に参加させていただきました。

ドクターズプライム社、メドピア社ともにありがとうございました🙏

ドクターズプライム社、本当にいい会社ですし10Xとはまた違った形で世の中をよくしようとしてる会社なので興味ある方はぜひ。

drsprime.com

(転職報告で他社の宣伝するのどうなんだと思いつつ、素直におすすめできるのと恩を返したいというエゴから書きました)

宣伝

もちろん10Xも一緒に働ける仲間を探してます。

フェーズとして本当に面白いタイミングに入り始めてると感じますし、合う人はとことん合う組織だと思います。

興味ある方はぜひお声掛けを!

jobs.10x.co.jp

*1:新入社員は1ヶ月程度経ったらこのPodcastに出演することになってる