会社をはじめました

元同僚の山下と、二人で会社をはじめました。 というか、すでに始めていました。

ひっそりと始めて、既に2年が経過しています。

この2年間、非常に楽しく働いてきましたが、二人だけではできることに限界も感じるようになってきました。

この記事を書くことで興味を持ってくれる人が少しでも増え、あわよくば連絡をくれないかなという下心と、連絡がこなくとも、いつの日か興味を持ってくれた人の検討材料になればいいなという思いで、考えていることを書き出してみます。

今、何をしているのか

現在、僕たちはとあるスタートアップ企業で、フルコミットで開発支援を行っています。 一般的な受託開発やSESとは違ったスタイルで、

  • 正社員同様にチームに深く入り込む
  • プロダクト開発、採用、チームビルディング、カスタマーサポートまで、業務領域を限定しない
  • 単に指示されたことをやるのではなく、チームで最も意味のあることを一緒に考え、提案し、実行する

つまり雇用形態以外は、スタートアップの正社員と同様の働き方をしています。

山下は仕様をもらって開発するのではなく、顧客の現場に行き、業務フローを理解しながらあるべき仕様をPdMと一緒に模索しています。

僕はSREを軸にシステムの安定性や開発生産性を向上する役割を担ってきましたが、最近はクライアントの成長に合わせて、チームメンバーの壁打ち相手、新任リーダーのサポートなどEM領域での支援やAI開発の推進も行っています。

また、必要に応じてカスタマーサポートでお客様にチャットを返したり、採用プロセスに入り込んでカルチャーやスキルマッチを確認することもあります。

「今チームや会社にとって一番価値のあること」

を考え、提案し、実行していく。 これが僕たちのスタイルです。

おかげさまで、現在支援している会社からは高い評価をいただいています。

シニアエンジニアの採用競争が激化する中、領域を限定せずプロダクト志向でチームをドライブできる人材を有期雇用でまとめて獲得できるのは、支援先にとってもメリットが大きいのかもしれません。

幅広い業務領域に対してゼロベースで考えて提案していくのは大変ですが、裁量をいただき、日々成果を出しながら楽しく働けているのは、とても実感があります。

こうした働き方を認めてくれて一緒に取り組んでいただける支援先あってのことなので、本当に感謝の気持ちでいっぱいです。

なぜ会社をはじめたのか

一言でいうと「自分が働いていて楽しいと思える会社は自分が生み出すしか無い」と感じたからです。

僕と山下は、大企業とスタートアップのそれぞれを経験してきました。

大企業では、組織の一部に過ぎない感覚が強く、誰のための仕事なのか分からなくなることが多く、手触り感を感じることができませんでした。

大企業として安定的に経営し株主の期待に応えるのは素晴らしいことです。ただ、当時の若く安定を欲していない僕たちには魅力的に映りませんでした。（昔は「大企業なんて」という気持ちもありましたが、家庭を持った今、安定雇用を生み出している大企業の素晴らしさをやっと理解できるようになりました…）

その後、山下は起業を経てスタートアップへ、僕はスタートアップを転々とすることになります。

スタートアップで働く日々は非常に刺激的でした。

裁量も手触りもあったし、信頼できる仲間と一丸となってプロダクトを育てたり、他愛もない会話をする日々は、純粋に楽しかったです。

楽しい一方で、急成長を目指すスタートアップの宿命とも言える組織の歪みも体験してきました。

例えば、以下のようなことです。

  • 急激な採用によるカルチャー崩壊やミスマッチ
  • 無限に発生するコミュニケーション課題
  • 事業成長プレッシャーによる売上偏重の意思決定
  • 部門間のサイロ化（開発vs営業など）

急成長の過程で発生するこうした「歪み」は構造的な課題であり、完全になくすのは難しいと感じています。そして僕らにとっては大きなストレス源でした。

なぜスタートアップにはこうした歪みが生まれるのか。 急成長を求められる構造に置かれているからです。

社会課題を解決するには多額の資本が必要で、その調達のためスタートアップは多くの場合、ベンチャーキャピタル（VC）から出資を受けます。

VCは投資した資金を限られた期間で大きなリターンとして回収するビジネスモデルのため、投資先には短期間での急成長が求められます。

さらに未開拓市場では先行者利益が大きく、シェアを早期に獲得しなければ競争に敗れます。SaaSやプラットフォーム型ビジネスでは、スケールしなければ収益性も確保できません。

こうした構造が、スタートアップに急成長を強制し、結果として組織の歪みを生むことに繋がります。

もちろん、こうした課題に向き合い乗り越えている企業もたくさんあります。業界全体でノウハウが蓄積され、以前よりずっと良くなっているとも思います。

そもそも、この歪みは必ずしも悪いものでもありません。大きなことを短期間で成そうとしているのに、歪みを受け入れないのは都合が良すぎます。

そうしたロジックを頭では理解していても、目の前で様々なトレードオフが生まれている状況に疲弊していました。

特に僕は、こうした状況に不満を感じ転職を繰り返してきました。恥ずかしながら、これは経営者やマネージャーの怠慢だと考え、もっと良い会社があるはずと思っては退職していました。

結果としてそんな会社はどこにもありませんでした。

歪みは構造上仕方のないものであるし、経営者やマネージャーは完璧超人ではないからです。

スタートアップの経営者はプレイヤーからリーダー、マネジメントから経営へと一気にステップアップします。この変化に適応できる人なんて早々いません。

僕が怠慢だと評価していたものは、ただの苦悩・葛藤でしかありませんでした。そうした状況に大した伴走もできなかったくせに何を外からエラそうに評価していたんだと、今では申し訳ない気持ちと自分の無知さに恥ずかしい思いでいっぱいです。

経営者・マネージャーの方々は、成すべきことのために葛藤し、時に立ち止まることはあれども、前に進もうとしていた。それでも大きな壁ゆえに立ち止まってしまうこともあるのだと今なら分かります。

ここで一つ、根本的な問いに立ち返りました。

「自分は本当に何か大きなことを成したいのか？」

多くのスタートアップは社会課題の解決をテーマに掲げます。

社会課題を解決することは尊いし、貢献したい気持ちもある。でも、僕はそれを心の底から成し遂げたいほどの原体験や熱量を持っているわけではないのではないか？だから自分はこの歪みを耐えきることができないのではないか？とそう感じました。

改めて、僕がスタートアップに本当に求めていたものを考えると、頭に浮かんだのは、

「働いている時間を、楽しいものにしたい。」

という言葉でした。小さなスケールの感情かもしれませんが、この感覚の方がずっとリアルで等身大な気持ちでした。

大きなことを成したい人にとってVCから資金調達をして急成長を目指すというのは非常に合理的だと思います。一方で、そうでない人にとってはtoo muchであるのだと思います。

スタートアップは楽しかった。特に初期は。 でも急成長の渦中では、苦しさも大きかった。 なら、急成長の必要がない小さな組織をつくれば、もっと自由に、もっと楽しく働けるのではないか。

そういった思いを山下に伝えたところ、意気投合し、二人で会社を立ち上げることになりました。

これからやっていきたいこと

今後の方向性は、大きく2つです。

  • エンジニアリング支援事業を拡充する
  • 自分たちのプロダクトをリリースし、会社として自立を目指す

良い名称が思いつかないので、現在行っているフルコミットでの開発支援を「エンジニアリング支援事業」と呼びますが、この事業は柔軟な働き方、領域横断的な支援を通じて、クライアントにとっても自分たちにとっても価値の高いものだと思っています。

どの会社でも、プロダクト志向でシニアなエンジニアのリソースをまとめて確保するのは非常に難しくなっています。 仮に採用できても、期待したように活躍できなかったり、カルチャーとのミスマッチが起きることも珍しくありません。 そのミスマッチを解消するには時間もかかります。

こうした状況で、優秀な人材を有期雇用で契約できることは、クライアントにとって大きなメリットです。 その意味でも、エンジニアリング支援事業は高い価値を提供できると感じています。

また、僕達は家族との時間を大切にしながら働くことを重視しています。 若い頃のように時間の全てを仕事に費やしたり、大きなリスクを取ることは難しくなりました。家族に経済的なリスクを背負わせることもしたくありません。

そのため、限られた時間で堅実かつ安定した経営を目指しています。 これまで培った経験を活かし、不確実性を抑えながら価値を提供するこの事業は、私たち自身にとっても大きな価値があります。

一方で、今のエンジニアリング支援事業だけでは、働き方やその楽しさを完全に自分たちでコントロールするのは難しいという課題もあります。 お金をいただいている以上、「クライアントの期待に応えることが最優先されるべき」であり、期待に応えることが必ずしも自分たちが楽しいことばかりでは無いからです。どんなに方針として間違っていると感じていても決められたことに対してどうするべきかを考えるべきです。もちろん、その過程での提案は怠らないようにするという前提ですが。

そこで、今後は自社プロダクトをリリースし、より自由で自立した経営を実現したいと考えています。

とはいえ、正直なところプロダクト開発には苦戦中です。

僕達はそんなに器用なタイプではなく、また猛烈に働けるタイプでも、燃え盛る情熱を持っているタイプでもありません。極々普通の人間であるため、本業である支援事業に目一杯の力を注ぎ込んでしまいます。 それが悪いことだとも思っていないし、むしろそこでしっかりと価値を提供できることに喜びややりがいも感じています。

しかし、その結果プロダクト開発は時間やリソースの確保が難しく、モチベーションの維持にも何度も苦労してきました。

２人で力を合わせて進めてきたものの、人が増えた方がもっと現実的に目標に近づける手段が取れるのではないか。 そんな思いを感じてきているのが現在の状態です。

どんな会社にしたいのか

僕たちが目指しているのは、趣味のように楽しんで働ける会社です。 そのため必要だと考えているのが、次のような状態です。

  • 対価をいただける価値あるサービスを、裁量を持って持続的に提供できること
  • 急成長・急拡大を目指さず、なるべく少人数で構成された組織であること

一つのロールモデルとして、時雨堂さんを非常に参考にしています。 時雨堂コトハジメ · GitHub

たとえば、給与は職種に関わらず全員同じにしたいと考えていますし、評価制度も設けるつもりはありません。 人数が増えるほど信頼関係の構築は難しくなる。そして信頼が希薄な中では楽しい仕事は生まれにくい。だから、組織を大きくしていくつもりもありません。 また、人手が必要なビジネスモデルやプロダクト、大きな市場にも踏み込まないつもりです。そうした領域では大企業との競争になり、持続可能な形で価値を届け続けるのが難しくなるからです。 自然と、ニッチな市場に深みを持ったプロダクトを提供するスタイルに落ち着くだろうと考えています。

もちろん、多くの人に向けたプロダクトづくりも素晴らしい挑戦です。 ただ、大勢に向けるということは、最大公約数的な割り切りが避けられません。

一方、特定の人に狭く深く刺さるプロダクトであれば、そうした割り切りを減らし、こだわりを追求しやすくなる。 さらに、目の前の困っている人を直接助けることができます。

これは、ものづくりとしてとても楽しいことだと思っています。 そして「困っている人を助けたい」という姿勢は、僕と山下の根幹にある価値観でもあります。 この方向性とは相性が良いと感じています。

最近では、AIの進化によって少人数でも大きな価値を届けられる環境がますます整ってきました。 大企業でもスタートアップでもない、新しい働き方をこれからも模索していきたいと思います。

（もし興味のある方がいれば、私のX にでもご連絡ください）

2021年振り返り

年の瀬なので振り返っていく。

仕事

振り返ると充実してたように思う。脳をいっぱい回転させたし学びも沢山あった。あといろんなことをやり切れた実感がある。でも正直、大変なことも沢山あった😇

昨年末にロジレスに転職したので、今年はロジレスで正社員として過ごした一年だった。

ロジレスではCTOに次ぐ2人目エンジニアかつ、社員数も少ない状態だったので、本当に色んな役割で仕事をしたように思う。元々はSREをメインのロールとして期待されていたのでそこは当たり前にやったのだけど、コードも結構書いたし、事業戦略から逆算してシステムや開発組織がどうあるべきかを考えたり、人が増えていく中での開発フローを考えたり、Job descriptionを書いてエンジニアの採用を進めたり、振り返りを推進してたり、メンバーやCTOと1on1したり、カスタマーサポートをやったりなど、本当に色々手を出したなーと感じるが、必要に応じて都度役割を変えることが一番自分のパフォーマンスが出ることだとも思っていたし、実際に成果も出たので良く頑張れた1年だったのではないかと思う。

特にSRE系の業務が意思決定含めてとりあえず僕に任せておけばいいという状態になったのは良かったと思う。プロダクトの仕様を考えるところから実装やカスタマーサポートまでずっとCTO一人でやってきた中で、最近はバックオフィス系の業務やプロダクト開発の組織や評価者としての役割まで求めらるようになり、明らかにキャパオーバーなのは状態ではあったので、完全に手離れするものを一つ作れたというのは地味だが大きな進捗だったように思う。

あと今年は人の背中を沢山押した一年だったようにも感じる。

ロジレスはプロダクトがすこぶる順調に伸びていて、それ自体はとても嬉しいことである一方、組織や個人としては変化が求められることが多かったように思う。

こうした変化には不安やハレーションは付き物で、これらを回避するためにどうしても現状維持やその場しのぎを選択してしまいがちだが、その選択は多くの場合問題の先送りでしかなく、むしろより大きなツケとなって後に支払わされる時がくる。

そうならないようにするため、現状維持の誘惑に抗いながら都度変化していく必要があるのだが、これを一人で実践するのはとても難しい。なので1on1などを通してなるべく伴走することを意識した。

具体的には、話を聞き、共感し、不安を可視化し、対策を一緒に考え行動可能な状態にして、また課題にぶち当たってもらい話を聞き…を繰り返すといったこと行ったが、これが後押しになって起きたアクションが沢山あったように感じるので、結果的に個人や組織の変化を促すことができた実感がある。(同じくらい上手くできなかったと感じ悩むこともあった)

こういう取り組みは、時間もマインドシェアも奪われがちだし、僕らはまだ人数の少ないスタートアップなので、他者の変化やアクションを促すよりも自分自身がその部分を巻き取ってしまうことの方がコスパが良い瞬間もあると思う。ただ、僕はこの巻き取りによって、メンバー（特に初期からいるカルチャーを形成しているような人）のtry&errorの機会を奪うのはイケてないと思っている。今後どんどん優秀な人が採用されていった時に昔からいる人ほど優秀な人とのギャップに悩み居場所を失うからだ。カルチャーの核になっている人がいなくなった時に組織が受けるダメージは想像以上にでかい。あとは個人的な思いとして初期からいた熱い思いを共にした人が離脱せざるを得ない状況に追い込まれるのは単純に寂しいという思いと、今いる人達が変化出来ない組織が未来では変化できる理由ってある？という思いがある。

優秀な人とのギャップに悩むことになるのは多くはタスクアイデンティティの喪失であり、タスクアイデンティティの喪失は実務スキルが新しい人に比べて相対的に劣ることや、代替ポジションが無いことから生まれる。こうしたギャップが生まれた時に環境を変えることは一つの手だが、先に挙げたとおり強固な組織組成のためにはカルチャーの核になっている人が残れるに越したことはない。その一方でここへのフォローはあまり発生しないことには個人的に違和感がある。

もちろん致し方ないケースというのも多々あると思うが、カルチャーの重要さ、カルチャーが何によって構成されているかの理解不足、スタートアップとはそういうものだという固定観念や生存者バイアスなどから、安直に「お互いにとって退職がベスト」に繋がってしまっていないか？というのは常に気にしている。この判断もまた極めて難しい。

タスクアイデンティティは根本的にはその人のスキルが支えている。なので成長が必要であり、成長に必要な変化への抵抗をいかに無くするかが大事だ。多くの人は何が変化への抵抗になっているのかを自分1人で気付けない。もしくは気づいていても一歩を踏み出せない。だから他者からフィードバックされる場とそれを受け止めれるだけの信頼関係が必要だ。

少数ではあるが自分の周りに居る人達にはこういった場を提供できて、かつ一定成果がでたことはとても嬉しかった。あとこうした「背中を押す」スキルが上達した実感があったのはとても良かった。

2021年、自分の使命は果たせたのではないかなーと思う。

個人

娘

1番のトピックは娘が生まれたことだ。娘は本当にただひたすらに可愛い。同時に働き方や時間の使い方について改めて考えるようになった。界隈でもしばしば話題になるが、家族との時間を増やしていきたい気持ちがある一方、自分の成長が鈍化することへの不安はやっぱりある。僕の場合、仕事のマインドシェアの割合が高い状態であることによって、モチベーションが高く保てていた側面が大いにあるので、その割合が低くなったときにどうしていくかはまだ探り探りな状態だ。もう少し今の生活に慣れてくるとまた違ってくるかもしれないのでtry&errorしていきたい。

学び

今年見た本は以下のような感じ。

  • 恐れのない組織
  • 良く分かるACT
  • あなたのチームは機能していますか
  • １兆ドルコーチ
  • DMM.comを支えるデータ駆動戦略
  • プロダクトマネジメントの全て
  • 技術の創造と設計
  • 失敗から学ぶRDBの正しい歩き方
  • ユニコーン企業のひみつ

人の悩みを聞く中で、心理的安全や対人リスクが組織にどう影響を及ぼすのか、良い状態に持っていくためには何が必要なのか。悩みに悩んでネガティブな状態から抜け出すためには何をする必要があるのか。あたりの解像度をあげたかったのと、自分が所属しているチームや組織がどうあるべきなのかの解像度をあげたくて手に取っていた物が多い。この辺の話は今年一年でグッと理解度が上がったと思う。

特に、人間は他人の命がかかっている状況下でも対人リスクを避けてしまうことを優先するのだから、対人リスクを甘えであると考えるのは筋が悪い(自分自身が対人リスクを感じて何かできなかった時に甘えた行動であると辛くなっていた)と感じれたこと、人間のメンタル悪化は不安の無限ループから発生するから如何にループを止めるかを考えること、悩みは無限に湧いて出てくるものだから取り除くことを考えるのではなく上手く付き合う手段を考える方が良いということ、コーチャブルでは無い人間(厳密にはコーチングが効かないフェーズにいる人間)が世の中にはいるということ、あたりを知れたことは良い学びになったと感じる。

一方で技術的な学びは少なかったかもしれない。特段技術力を必要とする機会が少なかったこともたり、良くも悪くも手持ちのスキルでやれてしまった感がある。技術に関しては少し世の中にビハインドしてきている気もするので、来年はもう少し学びを増やしたい。

趣味

キックボクシングを始めた。大分太ってきたのと普通のジムにちょっと飽きたので何か新しい刺激を探してみたところ近所にキックジムがあったので入会してみたのだが、これが自分の中で大ヒットで今めちゃくちゃハマっている。フィットネスなのでスパーリング的なものはやらないのだが、サンドバッグやミットを思いっきり殴ったり蹴ったりするのがベンチプレスやスクワットには無い爽快感があったのと、練習していくに連れて徐々に自分のキックが強くなっていくことに達成感があるのと、程よく難易度があるのがちょうどいい。

僕の最近のYoutubeの検索履歴は「ミドルキック 蹴り方 ~~~」で埋め尽くされている。

来年はかっこいいハイキックを打てるようになりたい。

来年は

引き続き、家族と仕事どちらも楽しい時間になるように尽力していきたいと思います！

2020年 振り返り

今年も年末がやってきたので振り返る

今年はどういう年だったか？

2020年は良いことも一杯あったが、メンタル的にきつい時期が多かったなぁという印象だ。 新しいxxxというのが多くて、適応に苦戦したというイメージだ。

振り返りのために過去ツイートを眺めてたらこんなことを書いてた。いやー本当に今年は生きてるだけで偉かったと思う。

仕事

今年の初めはフリーランスで手伝っていたロジレスという会社で、色々活躍できたように思う。元々去年までは２社手伝っていたのだが、今年の初めからはほぼここ１社になっていて、やれることの幅が広がり集中できたので、楽しさが増したことが要因だったと思う。 ron4321.hatenablog.com

一方で去年の後半からEMとしてマネジメント一本で戦えるようになっていきたいという思いと、フリーランスという立場だと色んな所で線引きをしなければいけない感覚が煩わらしかったというのがあり、どこかの組織に根を張って活動したいと思っていて、EMというロールで働ける先を探していた。

EMとして働くにしても小さい組織での0->1を作るポジションだと今までとあまり変わらないので、今回は少し規模の大きめの会社でマネージャーとしてのフィードバックをもらえるような組織をもっていそうな会社に行こうかと思っていた。

いくつかカジュアル面談を受けていたら、意外とトントン拍子で話が進んで、4月にはフリーランスでお手伝いしてた会社を終了し、5月からはアカツキのEMとして入社した。

アカツキに入社を決めたのは、フィードバックをしっかりもらえそうだったこと、EMが複数人いて同じ目線で議論できそうだったこと、感情を大事にするカルチャーが好きだったこと、自分自身がゲーム業界の事業ドメインは詳しかったので貢献もしやすそう、PjMの知識や経験が積めそう、というところだった。

入社後は正直、大分苦戦したように思う。苦戦した要因は色々あるが、一番の要因としては、リモート環境で入社した中で信頼関係がうまいこと積み上げられなかったことにあると思う。 人と打ち解けたり、仕事上での関係性を作るみたいな部分はどちらかというと得意な方だと思っているのだが、考えてみると僕のソレはほとんどが物理でのコミュニケーションに依存していたし、リモート環境でどうやって担保すれば良いかは蓋を開けてみるとサッパリだった。色々悩みつつTryしてみたが中々パキッとは解決せず、現況だと時間をかける必要がありそうだと感じた。またチームや組織にとっても全員フルリモートは未曾有のチャレンジであり、そうした状況も複合して難しかったように感じる。 フルリモートワークはとっても難しい。

そういった苦戦はしつつも、CSMの研修を受けたり、ゲームのバージョンリリースのスケジュールやタスク計画を引いてリリースを主導したり、SREエンジニアの採用を要件定義から契約まで一気通貫でやったり、チームと組織に対してオンボーディングに関するフィードバックを行ったりと、楽しい瞬間も沢山あったように思う。

とまぁそんな感じでアカツキでEMやっていきだったのだが、実は11月にアカツキを辞め、12月からロジレスで正社員として働くことになった。

入社して半年程度しか経っていないアカツキを辞めて、ロジレスで働こうと思ったのは、

  • 元々、良い会社があればまたどこかでスタートアップには行きたいと思っていた。
  • 10人くらいのあらゆるものが整っていない今入るのが一番面白そうだった（もう半年たってしまうと面白さが半減してしまうかもしれなかった）
  • 毎週ロジレスのCTOと1on1をしていたので、入ったあとに活躍できるイメージもプロダクトが成長していくイメージもあった。腹を割って話せてたので信頼関係も積み上がっていた。他の経営陣ともちょくちょく話せたので、この人たちとなら0->1の組織を作ってみたいと思った。
  • 経営陣以外の今いるメンバーの人達も好きだし信頼感があった。優しい、利他的、他者や他職種との違いを意識したコミュニケーションをとれる人たちというイメージで、居心地の良さがある
  • ファイナンス面もある程度安心できた（資金調達もできてるし、売上もちゃんとついてきてる）ので、家庭へのリスクも少なそうだった
  • こんな良い状況での転職はまたと無いんじゃないかと思った

といったあたりだ。 一言で言うと「全然辞める気はなかったが、千載一遇のチャンスが来てしまった」からだ。 世がコロナじゃなかったらもっと迷ってたかもしれないし、選択しなかったかもしれないので、本当にただただ入社して半年後にタイミングが来てしまったというだけだった。アカツキはめちゃ好きだし応援してます。

ロジレスではCTOに次ぐ二人目のエンジニアなので、開発もガンガンやるつもりだし採用も組織づくりにも全てに手を出していくつもりだ。やらねばならないことが無限にあるし、課題もいっぱいあるが、着実に対処していけば良い未来が来るのが分かってるので前向きに楽しくやれている。

2020年は転職の決断を2回もしたそんな一年だった。

個人

個人的には、良く本を読んだ年だったように感じる。正確には数えてないが20冊くらいは読んだのではないだろうか。 読んで良かった本としては、

  • 「良い戦略 悪い戦略」
  • 「ザッソウ」
  • 「他者と働く」
  • 「なぜ弱さを見せ合える組織が強いのか」
  • 「アジャイルな見積もりと計画づくり」
  • 「マンガでわかる認知行動療法」
  • 「イシューからはじめよ」

このあたりだ。

特に「良い戦略 悪い戦略」「アジャイルな見積もりと計画づくり」「イシューからはじめよ」あたりは、仕事の役割上、計画を考えることが多かったのもあって学びが多かったように思う。

この二つの記事もとても参考になった。

aboutproduct.jp

megalodon.jp

実際の仕事でも、何か戦略であったりその計画を立てる時には、何が問題であるのかを正しく分析できるかが大きな変数になるので、何か課題を解決したい場合にも何事も現状を正しく把握することから始める。という振る舞いを強く意識するようになったように思う。 「推測するな計測せよ」は名言だなと改めて思った。

「ザッソウ」「他者と働く」「なぜ弱さを見せ合える組織が強いのか」「マンガでわかる認知行動療法」あたりは、リモート環境下でコミュニケーションや信頼関係の作り方に課題を感じていたことがきっかけで読んだ気がする。 細かくは色々あるが、得意な部分も苦手な部分も自己開示していくことが大事だということと、自分の強いところや弱いところを正しく理解することが大事だと感じた。つまるところいかに期待値をズラさない状況を自分の意思を介在させずにつくっていくかということだと思った。

来年はどうありたいか？

来年も公私共に新しいチャレンジが多そうである。ロジレスをめちゃくちゃよくしていきたい気持ちもあるが、同じくらい家庭も良くしていきたい。 きっとバランスに悩むので、関係する人たちと相談をしながらペースを作っていける、そんな状態を作っていきたいと思う。

来年も楽しく働くぞー

CSM(認定スクラムマスター)研修を受けた

CSM研修を受けてきたので、レポと感じたことを書く

なぜこの研修を受けたのか？

  • しばらくPMというかスクラムマスターというか、チームをサポートする仕事をすることが増えそうだった
  • 会社のEMの人たちがスクラムの話しを良くしているので、その輪の中に入りたいと思った
    • 個人としても良いプロジェクトマネジメントとは何か？について考えることが多かったので、良く知っている人たちと議論したかった
  • 軽いノリで受けてもいいか聞いたらOKをもらえた
    • まだ入社して２ヶ月弱の試用期間も試用期間という身だったので、懐の深い会社で本当にありがたいと思ってる

主な研修内容

受けたのはこの研修で、研修内容としては大きくこんな感じでした。

  • 事前学習
  • グループディスカッション/ワークショップ
    • スクラムの基礎を理解するためのディスカッション
      • セルフアセスメントシートをグループでディスカッションする
      • その他いくつかのテーマでディスカッション
    • チーム編成や組織編成を考える（コンポーネントチーム、クロスファンクショナルなチームの違いを理解する）ワークショップ
    • プロダクトバックログリファインメントのワークショップ
    • スクラムレファレンスガイドのクイズを作り、回答するワークショプ
    • LeSSを体験するワークショップ
  • ワークショップの補足的な説明
    • 講師の実体験からの説明
    • 動画での説明
      • マシュマロチャレンジ（経験主義の大切さ）
      • チョコレート工場で作業員がひた隠しにする（局所最適化の弊害）
      • etc...
  • アフターパーティー（任意参加）
    • 研修が終わったあとに時間がある人はどうぞというスタンスのQ&Aコーナー
    • 研修内容についてというより、現実世界での悩みに関して有識者に聞く場という感じだった
  • 認定試験
    • 研修後に行う
    • 50問のオンラインテストでちゃんと研修を受けて理解していれば難しくない
    • 日本語の翻訳がおかしくて分からない問題が2~3問あった

主に、事前学習で得た知識の理解をディスカッション/ワークショップ、講師からのフィードバックによって深めていく。ということ目的としていそうで、 座学のような時間はかなり短く、ほとんどがグループでのワークショップおよびディスカッションでした。（体感90%くらいはディスカッションでした）

コロナの影響によりオンラインでの開催で、ZoomとMiroを使って実施されています。

感じたこと

  • 解像度がグッとあがった
    • 用語の理解、各プロセスへの理解、思想、TDDやXPなど他のアジャイル開発手法との関連性などなど
  • スクラムは開発手法であり、思想であり、新しい働き方だった。
    • スクラムは経験主義に特化させたフレームワーク
    • 経験主義の実現には、クロスファンクショナルなチームをいかに作るかというのが、肝な気がしている
    • コンポーネントチームが主流な世の中とは、方向性が全然違う
      • 結果として、評価、組織設計なんかも合わせて変えないとワークしづらいと感じた
      • 世の中とズレているということは、そのチームに属した人のキャリアや市場価値が世の中とズレるということ -　既存の組織にあてはめる時にはそういう難しさがあるんじゃないかと思った
  • プロダクトバックログのリファインメントの難しさ
    • 「適切な単位（INVESTが満たされている）」のストーリーを作るということが肝になりそう。なのでリファインメントはかなり重要そう。
    • 「適切な単位」を作るには、かなり横断的な知識が求められるのではないか？
      • POがスーパーマンを求められる問題が出てきそう
      • ここをいかに関係者でサポートするかという課題がありそう
  • スクラムは個人的に目指したいものに近かった
    • 僕にとっての最高のチームの定義は、チーム全員が働くことへのモチベーションが高く、十分な給与が発生するだけの売上がたっており、不毛な争いが発生しなく（発生したとしても適切に対処できるスキルをもっている）、それらが持続的であること。
    • このために経験主義的なアプローチは必要不可欠だと考えていて、スクラムは一つの選択肢になり得ると思っている。少なくとも参考にできる点はかなり多いはずだ。
    • ので、これからもスクラムを継続的に学んでいくぞという気持ちだ

おすすめか？

  • スクラムについて用語はちょいちょい知ってるけど全体としての解像度はそんな高くない。くらいのレベルの人までにはオススメな気がする。それ以上だとやや退屈かも。
  • どの職種の人にとっても普遍的かつ有用な知識だと思うので、エンジニアに限らず、ビジネスサイドの人にオススメしたい。
    • この研修では多少エンジニア文脈の話しも出てくるが、大勢に影響は無いと思う

同じ研修を受ける人へのアドバイス

  • 事前学習はしっかりしよう
    • この研修は事前学習で得た知識の理解を深めることを目的としていそうでした。そのため、事前学習は前提条件になっているので、怠ると明らかに学習効率が落ちそうです。
  • セルフアセスメントシートは事前になるべく早めにやって送る
    • MJさんがベストエフォートで理解が間違っているところを指摘してくれます。
    • （僕は期限ギリギリで送ったので、ベストエフォートの範囲外になってしまったようで、特に指摘はしてもらえませんでしたw）
  • 正解を出すことではなく、理解を深めることを目的とする
    • 抽象度が高く、前提が定まっていない(正解が無い)ワークショップが多いですが、テスト問題のような形式で出されるのでどうしても回答を出すことや正解を出すことに捉われがちです。
    • この研修の目的はスクラムの理解を深めることだと思うので、なぜこの回答が正解とされているのか？などのディスカッションに注力するのが良いでしょう。
      • 特に短絡的に正解が出せてしまう問題について議論が発生しづらかったと感じました。
  • アフターパーティーに出よう
    • より実践的で生々しい内容について聞けます。すでに実践している、しようとしている中で課題を持っている人なんかは、研修内容よりこちらの方が学びが多いかもしれません。

※研修内容が変わる可能性はかなりあると思うので、あてにしすぎない方がよいです！

『プロジェクトマネジメントのトリセツ』を読んだ

読んだので読書感想文を書く。

なぜこの本を読もうと思ったのか？

どんな本だったか？

タイトル通り、プロジェクトマネジメントの全体像について書かれている本で、 プロジェクトマネジメントとはどういうもので、特にウォーターフォールモデルで実施する場合に、どういうフェーズに分かれ、何をすれば良いのか？が説明されていたように感じる。 説明とストーリーが入れ替わる形式で読み手としては入ってきやすい構成だったので、本当に「入門編」という内容だ。

所感

入門書としてはオススメ

一通り知っている内容だったので、正直、内容自体には目新しさや感動はなかった。もう少し実践的なHowな部分に言及されてる本だとフィットしたかもしれない。 一方で、網羅的かつ平易な本なので、入門書として誰かにオススメはしやすそうだ。

PERTやそれに変わる何かへの興味が増した

進捗管理的な話の中で、ガントチャートやWBSへの言及があり、その中でPERTについても話されていた。 私が今までいた職場でもガントチャートやWBSは良く使われていて、タスクの依存関係が分かりづらいというデメリットを何度も耳にした記憶があるが、思い返すとPERTを使うという話しになったことは一度も無かった。 そもそも情報処理試験以外でPERTを聞いたり見かけたりしたことが無いので、久々に聞いた単語という感じだった。

アジャイル開発が増えている昨今だが、ガントチャートやWBSを使いたい。というシーンは確実にあると思っているので、その時のデメリットを解消するための手段であるPERT図はなぜ使われていないのか？ 自分の観測範囲内だけの話しなのか、実践的ではないのか。ただ難しいだけなのか、ツールでうまいこと作れたりしないのかなど、そのあたりを知っていきたいと感じた。

大事なのは「情報の非対称性」をどう埋めるかをチーム規模や性質によって変えていくことなのではないか

この本に書かれているようなウォーターフォール的なアプローチでは手戻りが発生することが大きなリスクになる。 なので、誰が見てもわかるように、プロジェクト活動を分かりやすい単位で分割し、それらの役割、目的、必要性などを言語化し、ズレが出ないように定期的に認識を合わせる。といったことにコストをかける価値があるしやっていく必要があるのだと思った。

逆に小さなチーム/プロジェクトであれば、ここまで大袈裟にやる必要は無いはずなので、現状のチームの規模に応じて「情報の非対称性」の取り扱いを考えるべきなんだろうなと感じた

株式会社ロジレスでフリーランスをしたので振り返りを書く

振り返り ロジレス フリーランス

2019/04-2020/04の約一年間、株式会社ロジレス でフリーランスとしてお手伝いをさせてもらったのでその振り返りを書いていく。

お手伝いすることになったきっかけと関わり方

元々創業メンバーの方とのご縁で奥さんが働いており、奥さん経由で「ウチの会社のエンジニアがAWSで困っている」みたいな話を聞いたのがきっかけだったと思う。一度話を聞いてみたら、Aurora移行、DB設計、クエリチューニングあたりの相談相手がほしいということだったので、その辺りであればある程度力になれるかもと思いお手伝いさせていただくことになった。

当時はフルタイムの正社員だったので アドバイザリー + スポットで一緒に作業をする など副業的な関わり方からはじめ、その後フルタイムの会社を辞めフリーランスとなったタイミングで、週2程度オフィスでSRE業務のオペレーションをするようになり、最終的には週3になり、同時期にメンバーが増えてきたこともあり今までの仕事+チームビルディングにも関わるようになった。

どんなことをやったか？と振り返り

ということで、SRE業を軸に、採用戦略や中長期的な技術戦略の提案、チームビルディング系施策の提案と実施等々、幅広く色んなことをやらせていただいた。具体的には下記のようなことをやった。

SRE

セキュリティ系

  • VPN（Pritunl）の導入
  • SSM経由でEC2にログインする
  • AWSのRootアカウントでのログインの廃止 + Switch Roleでログインできるようにする
  • AuroraのAudit logの有効化
  • AWS WAFの導入
  • VPC/Security Groupの見直し

運用系

  • 開発/本番デプロイの自動化
  • クエリのパフォーマンスチューニング
  • WebサーバーのLaunch Template化
  • RDS for MySQLのAurora化

監視系

  • Cloudwatchベースの監視基盤の構築
  • NewRelic、DataDog、Mackarel等のManagedなサービスの比較検討
  • Datadogの導入
  • 監視すべきメトリクスの設計
  • ダッシュボードやアラートの整備

サーバーサイド開発系

  • PHP5.6から7.3への移行サポート
  • Datadog APMの導入
  • ローカル環境開発環境としてのDocker導入
  • ローカルデバッグの提案、導入

その他

  • オフィスネットワーク環境の構築
  • Saving PlansやRIを使ったコスト最適化
  • 主にSRE的な側面での中長期的な技術戦略の相談

SREの仕事はしっかり価値を提供できたのではないかと思う。 元々本業としてやっていたからというのもあるが、会社やプロダクトのフェーズ的に、特定のソフトウェアやサービスへの使いこなしよりも、無限に存在する未整備エリアを幅広く整え底上げしていくことの方がレバレッジが効くフェーズで、そういった仕事が私の得意領域でもあったのが大きな要因だったと思う。これがk8sでMicroservicesしてるアプリケーションのService Meshが煩雑になってきたからどうにかしてくれ。みたいな要件がメインだったら、コスパの悪い人感は否めなかっただろう。得意領域でアプローチするのは大事だ。

技術的な意思決定に関しても、うまくサポートできたと思っている。 例えば、

  • IaCは今のチームにとってはラーニングコストや運用の複雑化から発生するデメリットに対してメリットを享受しづらいから暫くやる必要はなさそう
  • 監視はAPMが入ったマネージドな物を使うとトラブルシューティング等の運用コストが劇的に下がるので特にメンバー数や選任のインフラエンジニアがいない今だからこそ多少のコストは許容して導入しよう
  • Auto Scaling/Healingによる高可用性、リソース効率の最適化によるインフラコストの抑制、セキュリティパッチのあてやすさなんかはBtoB SaaSとは相性が良いはずだし、Deployフローがオーケストレーションツールのレールに乗れることや、プロダクトを開発するエンジニア側がなるべくインフラをコントロールしやすい環境を作るのは運用の負荷を確実に下げてくれる等々、コンテナ化は複雑だけどそれなりのリターンもあるので投資する価値がある

という意思決定があった。他にも細々とした意思決定はあったが、どれも議論を通じてリーズナブルな結論を出せたと思っている。この意思決定自体が正解かどうかは神のみぞ知る。と思うが、ちゃんとメリットデメリットを考えて議論をして決めれたので、軌道修正の議論もしやすいはずだ。こういった議論のカルチャーを持ち込めたのも個人的にはポイントが高いと思っている。

それなりに成果に満足はしている一方で、上記のような機能的な状態になるまでやや時間を要してしまったことには課題感を感じている。そりゃあ機能的になるまでには時間はかかるものではあるが、その時間をもっと短縮することはできないのか？とは思うのだ。

結局機能的になるまでには何が必要だったのか？を振り返ってみると、一番大きな変数としては「対等に議論ができること」だったのではないかと思う。対等に議論ができるようになり始めると、本質的な課題について話し始めるようになるので比例して成果も大きくなる。逆に初期は局所最適的な議論が多かったように思う。これはつまり心理的安全性ってやつなので、改めて心理的安全は大事だよなぁと思っている。

では、なぜ対等に議論するまでに時間がかかるのか？だが、個人的には以下２つが大きな要素なんじゃないかと思う。

  • 相手にどう思われるか推測できない不安（無知/無能だと思われる不安、邪魔している/ネガティブだと思われる不安）から保守的なコミュニケーションをとってしまい、結果的に信頼関係の積み上げペースが遅くなる
  • 持っている情報に格差があることが要因でお互いの主張が噛み合わなかったりその認識合わせに時間がかかったりする。その失敗体験から議論自体を避けがちになってしまう
    • 例えば、プロダクトの売り上げを上げるためには？というお題があったときに、プロダクトの全体像を知っている人と全く知らない人とでは主張が変わるし、噛み合いづらい。そこでギクシャクしてしまうと次は権威を持っていない側がYESマンになってしまう的な話し。

つまり心理的安全性と情報の非対称性ってやつである。この二つを解決するためには、組織側、個人側どちらからのアプローチも必要だが、組織側としてはオンボーディングをちゃんと設計しましょうという話しになっていくと思う。が、今回は個人としての振り返りなので割愛する。

個人の動きとしての振り返りとしては、相手を信頼し、分からないことや不安なことは率直に聞く に尽きるなと感じた。 具体的なHowとしては、この時間がかかる構造を理解し相手に伝え理解してもらうことや、情報格差による無駄な衝突や認識合わせを防ぐために、MTG時にちゃんと論点が分かるアジェンダを作っておくこと、Working Out Loudしていくことが大事かなと思っている。

ただし、ここで注意しなければいけない、かつ難しいのは、率直に聞く = 伝え方が攻撃的/否定的であっても良い ということではないということだ。自分が相手のことを知らないように、相手も自分のことを知らない。相手に届く伝え方というのは選ぶべきだ。「自分のパーソナリティが理解されていないと本当の意図が伝わらないメッセージ」は使ってしまいがちでリスクが高い。

まとめ

  • Keep
    • 相手を信頼し率直に話す
    • 得意領域を見定め提供する
    • プロダクトや会社の目的を意識した技術提案をする
  • Problem
    • 機能的な状態になるまで時間がかかってしまった
  • Try
    • 相手を信頼し率直に話すが、伝え方には気をつける
    • MTGする際に論点をまとめたアジェンダを作る
    • Working Out Loudしていく

採用/開発組織

  • エンジニアの採用戦略の相談
  • 採用イベントへの参加
  • 開発人員の雇用形態等の相談
  • 中長期的な技術戦略の相談

採用/開発組織系は、相談にはのるものの、SRE業務がメインなことやフリーランスという立場上、私自身が推し進めるのが難しい側面も多く、情報のインプットが中心になりあまり大きな影響は与えられなかった。また実務としてはかじった程度というものも多かったので、インプットした情報自体も実体験が伴っていないようなものは説得力に欠けるというのもあったような気がする。

情報のインプットをするだけというのがそこまで悪いことだとは思わない（知らないことを知ることは重要だしいつか使う日に備えることも大事だと思う）が、エンジニア採用が進むと事業が加速することは目に見えていたので、インプットだけではなく実態も伴うようなフォローがしたかった。

これをしていくには、おそらく採用の全体像の解像度をあげることと、スタートアップのいつのフェーズでどんな人をとるべきかを理解することが必要そうな気がした。これらが分かっていると、必要性を説きグランドデザインを設計して提案することができる。

スタートアップの(特に初期の)人は、目先で捌かなければならないタスクが無限にあり、そのタスクを捌くことが圧倒的にROIに優れていることが多い。なので採用や組織系などの、重要だが緊急ではなくそれなりのコストが伴う性質のタスクに関して及び腰になりがちだ。この第一歩目をサポートできるようになりたいなと感じている。

まとめ

  • Keep
    • 情報のインプットはできた
  • Problem
    • 具体的なアクションには繋がらなかったことが多かった
  • Try
    • 採用の全体像の解像度あげる（実体験するのが一番早そう）
    • スタートアップに必要な人材とは？いつ必要？どうすれば採用できる？などの解像度をあげる

開発チームビルディング

  • DX Criteriaの実施と結果の考察/運用の提案
  • 朝会/定例MTG/振り返りの設計とlead

チームビルディング系は自分でも良くできたと感じるし、実際チームからの評判も良かったところだ。

細々としたものを含めると色んなことをやった気がするが、大きく影響を与えることができたのはDX Criteriaの実施と朝会や振り返りなどの会議体の設計だと感じている。

うまくいったきっかけはDX Criteriaの実施だと思う。これをCTOと一緒にやったことによって、組織としての課題感に共通認識が持ててて、その後の提案や議論の質がグッと上がったと感じる。CTOも「課題が可視化され明確になった」と絶賛していた。これからも定期的に実施して組織の状態をモニタリングしていこうとなった。

振り返りや朝会などの会議体の設計に関しては、どうすれば成功体験を得てもらえるかを事前に設計して臨めたことが主な成功要因だったと思う。特に、会議毎の役割、目的、なぜやる必要があるのか、心理的安全とはといったあたりをドキュメントに起こし丁寧に伝えたことと、tryの進捗を毎週追跡する形にしたこと、振り返りの振り返りをちゃんとやるようにしたことが上手く作用した印象だ。 実際に僕がやめたあとにも振り返りは実施されていて、振り返り自体の改善も進んでいるようだ。

CTO的にも振り返りをするカルチャーにすごくポジティブでいてくれているので、このまま会社全体にも浸透していきそうな気はするし、そのカルチャーの一旦を担えたというのは、めちゃくちゃ嬉しいことだし大きな成果だと感じている。

一方で、今回に関してはメンバーが振り返り自体にポジティブだったのでとても協力的だったし、そもそも1伝えたら10吸収して勝手に成長していく人たちだったので、正直、難易度としてはVERY EASYという感じだった。もう少し関係者の数や種類が増えていくと段違いに難しくなっていくような気はしているので、そういった環境でも価値を伝えられるように精進していこうという心持ちだ。

まとめ

  • Keep
    • 一緒に改善をしていく人と現状の認識を合わせる（DxCriteriaは良いフォーマットである）
    • 成功体験を意識した設計をする
  • Problem
    • 振り返りの難易度が上がったときにどうすればいいか分からない
  • Try
    • 事例にアンテナはっておくとか実際にやってみるとかした思い浮かんで無い

追記

この記事を公開した直後にすぐにお褒めのお言葉をいただいた…！(ちょっと盛りすぎですがw)

まぁでも、この記事にこれだけポジティブに反応してもらえるような関係性を築けたということが、何よりのKeepだなと思います。

EC2のSnapshotのLifecyclePolicyをコピペで設定するためのあんちょこ

AWS Tips

はじめに

EBSスナップショットのライフサイクルポリシーの作成は設定項目がそこそこ多いので、同じような内容で複数個設定しようとすると面倒だしミスも発生しやすくなります。

特に、IaC環境ではなくマネジメントコンソールで設定しなければいけない場合に大変です。 現在のお仕事先でもマネジメントコンソールを使って設定していて煩雑だったため、以降同じことをする時に楽なるようにコピペできるようなスクリプトを書いて見ました。

スクリプト

tagにサーバーのRoleが付いているという前提で、そのRoleに該当したEC2のスナップショットをデイリーで取得するようなポリシーを作る場合のスクリプトです。

# role名を書く
target_role=toraru_role

# 実際に作る
aws dlm create-lifecycle-policy \
--execution-role-arn "arn:aws:iam::$(aws sts get-caller-identity | jq -r .Account):role/service-role/AWSDataLifecycleManagerDefaultRole" \
--description "for ${target_role}" \
--state ENABLED \
--policy-details "$(cat << EOS 
{
    "ResourceTypes": [
        "INSTANCE"
    ],
    "TargetTags": [
        {
            "Key": "Role",
            "Value": "${target_role}"
        }
    ],
    "Schedules": [
        {
            "Name": "Daily ${target_role} backup",
            "CopyTags": true,
            "VariableTags": [
                {
                    "Key": "instance-id",
                    "Value": "\$(instance-id)"
                },
                {
                    "Key": "timestamp",
                    "Value": "\$(timestamp)"
                }
            ],
            "CreateRule": {
                "Interval": 24,
                "IntervalUnit": "HOURS",
                "Times": [
                    "16:00"
                ]
            },
            "RetainRule": {
                "Count": 30
            }
        }
    ],
    "Parameters": {
        "ExcludeBootVolume": false
    }
}
EOS
)"

ポイント

  • get-caller-identityを使うことでAccountIDを手動入力しなくても良いようにしています（そのためjqが使えることが前提です）
  • Shell ScriptでJSON内に変数を展開させるのは結構面倒で、試行錯誤した結果ヒアドキュメント経由が良さそうでした