ある程度いいエンジニアでありたいかもしれない

雑記

ふとしたときに、ぼーっと考える

会社（や評価をする人）は何をもって「このソフトウェアエンジニアはいい」って判断するのがいいんだろうなぁって。むずかしくない？入社前じゃなくて、入社した後のこと。自社ウェブサービスを開発しているソフトウェアエンジニアのこと

特に伝えたいことも答えもなくて頭の中のメモ

分かりやすいならいい

その人の開発したものが、バグだらけだとか、そもそも設計ができないとか、そういうのだと分かりやすいからいい。まずは、バグを減らそうねとか、設計ができるようになっていこうね、という話

あと、やってることが周りから見えないとか、コメントとかが攻撃的で一緒に働いてる人が嫌な気持ちになるとか、まぁ、そういうのも「違うよね？」って言えるし、コンピテンシー評価で伝えていけたらよさそう

ある程度のモノができている場合は、どうだろう？

もっと早く作ってほしかった！

って考えるかもしれない。確かに、単にスキルが低くて開発スピードが遅かったのかもしれない。ムダが多いのかもしれない

でも、ある程度スキルがある場合は、技術的負債とのトレードオフをいい感じに決断して、外から見える開発スピードが少し落ちていたのかもしれない

本人の開発スキルとは別で、他の部署とのやりとりが必要で時間がかかったのかもしれない。でも、そのあたりのスキルが高い人は、他部署とのやりとりもスムーズに進められるのかもしれない

もっと早く作ってほしかった！といったときに、基準は何になるんだろう？見積もり？じゃあこうかな？

見積もりどおりに作ってほしかった！

作る前に「これぐらいで作ります」って言うやつ。これは、わりと多いのかなと思う

不思議なもので、見積もりで3ヶ月くらいかなと言って4ヶ月かかると、あんまり印象よくないのに、同じものを5ヶ月かかるって見積もって5ヶ月で作る方が印象がいい。不思議ではないか

そうなってくると以前もブログに書いたけど、3ヶ月くらいかな？と思っても5ヶ月かかるって言って5ヶ月かけて作るようになるのかもしれない

5ヶ月って言っても4ヶ月くらいでできるんじゃないの？みたいなことを言い出す人もいるかもしれない

そうすると6ヶ月って言っておいて、5ヶ月でできるんじゃないの？って言われて、じゃあ5ヶ月でがんばってみます、みたいな会話をするようになるのかもしれない

自分が言ったものがスキル判断の基準になるというのは、なんとも便利な仕組みなのかもしれない

それがいいものなのかどうか

そもそも、ある程度のモノができている場合は、それがいいものなのかどうか自体、すぐには分からないのかもしれない

3ヶ月後に何かトラブルが起こったときに、ログが何も出てなくて困るかもしれない。アラートやログがめちゃくちゃたくさん出てて何がなんだか分からないかもしれない。ちょうどいいログが出てて、すぐに解決できるかもしれない。アラートを飛ばす必要もなく、自動でリカバリーするように設計してあるかもしれない

その人がいなくなった後もスムーズに開発が続いているかもしれない、フレームワークの載せ替えもノートラブルでサクッと終わるかもしれない、3年後も同じスピードで開発を続けているかもしれない

見た目は全く同じリンゴなのに中身が違う

でも、熟しているものが常にいいとは限らない。ときには、中がスカスカでも今すぐ手に入るものが必要かもしれない。その辺りの判断も、スキルがある程度ある人は上手なのかもしれない

やっぱり、モノでは判断しづらいのかもしれない。となると…

がんばりを見よう

ってなるのかもしれない。8時間ちゃんとがんばって仕事をしているか？最近はリモートが多いから、チャットツールでオンラインかどうかをずっと見ていればいいのかもしれない

うーん、やっぱり、そういうのを見てもなぁ…という気がするので、僕は「がんばり評価」の話には興味がないのかもしれない

じゃあやっぱりモノに戻ってきてしまうので

ある程度の

ある程度のモノを、ある程度上手に作ってる場合、「ある程度いい感じだね」って言って、ある程度評価してくれたら、僕はある程度満足なのかもしれない

そんな風にして、お互いに背中をあずけて開発をしていけるような、ある程度いいエンジニアでありたいかもしれない

特にどこにもたどり着くことなくこの話は終わり

この記事を書いた人は

こんな本も読んでいます

books.rakuten.co.jp

RSGT2023に参加。Day1、Day2メモ。

RSGT2023に現地参加してる。Day1、Day2が終わって、今日はDay3に参加予定。早くに目が覚めたのでさらさらっと思い浮かんだことを書き留めておく。

Day1

クリエーションラインのスポンサーセッション、サムライブルーが、やたさんだって全然気づいてなかったｗ心が強すぎる。かっこよかった

Davidさんのキーノート。TDDのところだけ熱量が違って笑った。すごい好きなんだなー！

いっしーさんとひろみつさんと、オフラインでは初めましてのご挨拶。おふたりに会うのが今回の参加の大きな目的のひとつだったので嬉しい。

おのさん、さとりゅー、なかさんがいつも通り相手をしてくれて、嬉しかった。おのさんは久しぶりだったから、目を合わせてくれなかった！（冗談です

きろーさんと、関西で肉食いにいこーぜーってなったので、帰ったら連絡しよっと。

銀行DXのセッション。さらっと言ってるけどめちゃ大変だったんだろうなぁ。CなんとかO（忘れた）、にスクラムマスター研修受けてもらったってすごい。しかも銀行の。

いっしーさんの、組織改善のお話。とてもよかった。事前にスライドのレビューをさせてもらってたので内容は知ってたんだけど、実際に聞くと、お話がとても分かりやすくてすごくスムーズに頭の中に入ってきて、すごいなぁってなった。

なこさんの、運用業務とスクラムのお話。課題と対策とその結果の次の段階のグラフがまとまってて、すごーってなった。各対策も、わかるーって感じだったな。スクラムのリズムの中に運用入って回してるの良いね。あのスピードのお話で通訳さんどうなってたのか気になるｗ

aki.mさんが話しかけてくれた。わー！エネルギー体じゃなくて、本物が存在したんだー！って気持ちになった。ご挨拶だけだったので、今日お話できるといいなぁ。

品川アジャイルの、ふろしきFMコーナーに呼んでもらって、お話をしてきた。お二人と一緒の席でお話してるー！って喜んでた。お世話になります！

ばやしさん、とみーさんとも、直接お話するのは初めましてだった。いつも聴いてる笑い声だー！ってなった。とみーさんとその後少し話しをしたけど、この人、やっぱりなんていい人なんだって気持ちになった。

いわおさんに、撮影・音響機材のこと教えてもらって、すごー！ってなった。機材沼に招待されたけどなんとか回避！

たかはしさんの、おもちゃのお話。無限プチプチ欲しい。自分の「好き」って大切だなーって思った。

いなのさんとお話できた。ずーっと一方的に知ってたので嬉しい。わいわい。

Day2

クリエーションラインのブースでビンゴがあって「安田さんと話す」ってのがど真ん中にあったから「えー！話したいー！」って半分冗談で言ってたら、本当に連絡くださって話をした。自分の近況と次に何をやりたいのかの壁うちをしてもらったのと、クリエーションラインについて興味があったことを質問して教えてもらったりして、嬉しい時間だった。

Lyssaさんのキーノート。スケール大きくて、ほへーって聞いてた。それに比べると、僕の考えてる範囲のことなんて、なんとかなりそうだなって気持ちになった。あと、対話をしなきゃなぁ、って今書きながら、そういえば今回のRSGTは、僕にとって「対話」がテーマになってる気がした。やっとむさんか、あきさんにお話聞いてもらえたら嬉しいかもと思ってコーチズクリニック見てみたら、おふたりとも全部埋まってて、そりゃそうだｗってなった。今度機会見つけてお話聞いてもらおっと。

川口さんのセッション。昼休みからずっと喋り続けてたのすごいｗ面白くて分かりやすくて知識と経験に裏付けされてて、尊敬しかなかった。

nagaさんのペアプロのすすめ。モブプロよりもペアプロの方が安心って話。たしかに、教えてもらうときには1対1の方がいいよなわかる。ってなった。打ち合わせなしで観客の一人とライブペアプロしてて、nagaさんも、手を上げて参加された方もすごー！ってなった。いいペアプロをみせてもらった。学生だと、仕事で取り組むのとは観点が違うのが新鮮でよかった。

ひあささんのGOの組織づくりのお話。職能別組織の課題と、職能横断チームへの挑戦と、そこで見えてきた次の課題。面白いなー。って、それはそうと、ひあささんに「妻がよろしくって言ってました！」って言われて「え？なんで？知ってる人？」って言ったら、めちゃくちゃ一緒に仕事したことある尊敬してる人だったのでびっくりした。仕事してるときに教えてほしかったわｗ今回のRSGTでいちばんびっくりしたことだな。

かっぱさん（塩谷さん）にご挨拶。組織開発のことを教えてもらった！わいわい。

遠藤さんとお話。LAPRASから10人以上？参加されてるってすごー。キーノートで2日とも質問してペアプロで手を上げてた人、同僚なんだよーって言ってた。あの方、今回の中心感ある！

及部さんの安定したチームのお話。なんとなく、声を聞くだけで元気もらえるかなーって思って参加。安定したチームって、不安定なチームだよなぁって、キローさんがドヤ顔してそうなのを頭に思い浮かべながら聞いてた。元気もらった。

ぼっちしてたら、いっしーさんが、下の中華に行きましょう、って声かけてくれて行ったら、色んな人がいて面白かった。混ぜてくれてありがとうありがとう。

いくおさん＆いくおさんとお話できて喜んだ。負債の話とかGit Blameすると自分の名前が出てくる話とか。

中村洋が色んな人をつないでくれるのすごい。DevLOVE関西また遊びに行こっと。

えみさんが声をかけてくださったり、りょかさん・ぶれいすさんにご挨拶できたり、みつかわさんに会えたり、他にもたくさんの方とご挨拶できたりと、オフラインの懐かしい感じが嬉しかったのと、ハイブリッド開催なのでオンラインでもセッションの内容についてお話できたりして楽しかった。

Day3

今日はOSTだなー。僕はOSTはふらふら歩き回るのが好きなので、そんな感じで楽しもうと思う。そしてクロージングキーノートの、いわしさん楽しみ。生でふかぼりFMの声がきけるー！

2022年はとても面白い一年だった！

雑記

2022年はCircleCIでシニアフルスタックエンジニアとして開発に携わりました。これまで自分が経験してきた開発との違いに戸惑いながらも、たくさんのことを学ぶことができて、とても良かった。正直いうと、もう数年続けて、より良いCI/CDプラットフォームづくりに取り組んで、ユーザーさんたちの喜ぶ顔を見たかったなという気持ちはあるんですけど、このようなご時世では、レイオフもしょうがないですね。これからは、いちユーザーとしてCircleCIを応援してます！

短い期間とはいえ、この1年は本当に自分の中でとても大切な時間になったなと思います。技術的な部分はもちろん、それ以外でも、完全に英語の環境、多様性に富んだチーム、タイムゾーンが異なるチームとの協業、年齢や性別やポジションや社歴に関わらずお互いに敬意を持ったフラットな関係性など、たくさん勉強になりました。おかげで、CircleCIの前の楽天での11年間の経験を一旦手放して客観的に捉えることができたんじゃないかなと思います。

そんなわけで、ひとまわり成長もしたことだし、2023年は新たな気持で頑張っていこうと思います！誰かの喜ぶ顔が見たいー

以下は、思い出話

1-3月

試用期間も終わって、本格的に開発に参加。ClojureとReactを勉強しながら仕事をしてた

散歩用にFitbitを買ってPixelaで歩数を見えるようにした。Pixela便利！

小粋fmに呼んでいただいた。楽しかったなー

からまないブラシの掃除機を買ってとても良かった。購入してからいちどもブラシの分解をしてない。すごい。あと、やっぱり紙パックのやつが吸引力が強くて好きだなと再確認

4-6月

トランクベース開発で毎日デプロイを何回もやってることについて考えてた

ゆめみのフロントエンドコーディング試験でフロントエンドの勉強をしてた

ふろしきfmに呼んでいただいた。お世話になりますー。いつも楽しくきいてる

コーヒーのミルを買って、とても気に入ってる

TIMEMOREタイムモア 栗子C2 Max コーヒーミル 容量30g

7-9月

CUE言語で遊んでた

Go の勉強をしてた（ブログにまとめたのは10月だけど）

オーディオテクニカのヘッドホンを買ってとても気に入ってる

10-12月

Findy Engineer Lab わたしの選択に記事を掲載していただいた

このツイートがきっかけでメンタリストを見始めた。英語の勉強にもなって良かった

アジャイルリーダーシップを楽しく読んでた

見積もりについて考えてた

無職になった

とてもありがたいことに77社からカジュアル面談のお声がけをいただいた。全ては難しそうなので事業ドメインを絞って40社とお話をさせていただいて、結局仕事してたときより忙しくしてた。ほんとにどこも魅力的でいいなぁって思った。年明けにもう数社お話をして、自分が次に何をしたいかをしっかり考えて、応募する先を決めたいと思っている

ずっと緊張してたからか2日間寝込んでたのだけど、だいぶ元気になってきたので、明日から年明けまでは、転職活動のことは一旦忘れて、本を書く作業に集中しようと思う。そしたらRSGTだー

2022年はとても面白い一年だった！

アジャイルと通過点とベクトル

雑記

昨日と比べて今日一歩前進してる？

もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある

それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり（幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった）

そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない

計画駆動で頑張る

最初は何も変えずに、その当時のやり方に従いながら、結果を出せるようにがんばった。プロデューサーがタスクを個別のエンジニアにアサインして、ガントチャートをひくようなやり方

  • スナップショットで見ると、計画駆動の開発をしているだけ。なので、全然自分のやりたい開発ではない
  • ベクトルで見ると、「この人に任せておけば最終的にはなんとかする」という信頼を周囲から得ることができたので一歩前進

チームの外からだけじゃなくて、チーム内でも信頼を得ることができたので、中心的なエンジニアとして動けるようになった

イテレーションを導入

周囲からの信頼を得たことで、わりと自由に動けるようになったので、イテレーションを導入した。これで、開発フェーズの中ではイテレーティブな開発ができるようになった

  • スナップショット：ウォータースクラムフォールまたはスクラマーフォールと呼ばれるような状況。理想的ではない
  • ベクトル：完全な計画駆動に比べて、開発フェーズでリスクを早めに発見することができたり、変更すべき仕様の発見に対して柔軟になったりした

あんまり覚えてないけど、イテレーションと同時かそれより前に、ふりかえりを導入していた。それもあって、開発プロセスを改善するリズムができた。それによってチーム内のやり方をちょっとずつ改善していくことができた。例えば

タスクを小さく分割

  • スナップショット：デモができるような単位で切ってるわけじゃない
  • ベクトル：大きなタスクを小さく分割することで何をやっているかが見えやすくなった

プランニングポーカーの導入

  • スナップショット：ポーカーをしたところでデッドラインは変わらない
  • ベクトル：お互いの認識のズレが見えるようになったので、早い段階で認識齟齬に気づいたり手を打ったりできるようになった

その後も色々と試したり改善したり。このあたりで、僕個人ではなくチームが周囲から信頼を得ることができてきたのかな。何をやっているのかが外から見えるようになってたり、あぶない兆候を早い段階で伝えられるようになったりしていたので

プロデューサーを巻き込んだ取り組み

チームが安定してきたので、プロデューサーを巻き込むことができた。プロデューサーは今で言うと、プロダクトマネージャーとプロジェクトマネージャーを合わせたような役割かな。プロデューサーを巻き込むことで、工数に影響がでる部分にも手を出せるようになった

  • 自動テストの導入（開発フェーズでやることが増える）
  • ペアプロの導入（２倍の工数がかかるように見える）

などを少しずつ取り入れて、結果を見ながら調整していった。色んな難しい局面もあったけど「この人・チームに任せておけば最終的にはなんとかする」というところは守るようにしていた

  • スナップショット：開発チームに閉じている
  • ベクトル：工数影響がでる部分の改善にも取り組むことができた

ビジネスチームを巻き込む

プロデューサーも巻き込んで開発チームとして動けるようになったので、ビジネスチームも巻き込むことができるようになった。リーンキャンバスやユーザーストーリーマッピングなどで、なぜつくるのか、今何を最優先にするべきか、などビジネスチームからの意見をより深く聞くことができるようになり、重要な部分に集中できるようになった

このあたりで、開発チームとして、本当に向き合いたかった課題に向き合えるようになってきたように思う

他の組織を巻き込む

組織の中で信頼を得ることで、他の組織を巻き込んだ改善を考えることができるようになった

  • デザイナー組織を巻き込んで、デザイナーさんがもっと意見を言ったり、結果を見てすぐに次の手を打ったりできるようにしたり
  • QA組織を巻き込むことで、シフトレフトな取り組みを始めたり、テストの観点をエンジニアたちに教えてもらって開発の段階で品質を上げていったり

そんな感じで

スナップショットではなくて、ベクトルを大切にして、一歩ずつ前進していった感じ

今から取り組む人たちに、このやり方をおすすめするわけではない。今だと、アジャイルな開発は以前よりも普通のことになってると思うから、トップダウンとボトムアップの両方で全体として取り組むのが良いなぁって思う。コーチを呼んだり、研修に参加したりして

ずっと通過点

スクラムはカスタマイズしない方が良い、というのはそうだなって思うのだけど

  • カスタマイズしたスナップショットをもって「ここが最終地点だ」って言うのが僕は好きじゃなくて
  • ベクトルを意識して「ここは通過点だ」って言ってるんだったらいいんじゃないかな

と思っているのでぼーっと書いてみた。やりたいことに向かって今日も前進できてるかな？って考えて、前進してるなら、それはとても良いなって思う

Metaが作ったソースコントロールシステムのSaplingを触ってみた

雑記

日曜日の午後の気分転換にちょっとSaplingを触ってみる

Sapling?

https://sapling-scm.com/

  • Meta（旧Facebook）が作ったソースコントロールシステム。Meta社内で使われてる
  • ユーザビリティとスケーラビリティに重点を置いてる
  • 仮想ファイルシステム（まだ公開されてない）と合わせて使うと巨大なリポジトリも扱える
  • GitHubと連携して使うことも可能

へー。コマンドが色々ユーザーフレンドリーみたい。モノレポに対して使いやすい感じなのかな？個人的にはコードレビューの仕組みが気になる。じゃ、見てみよう

Getting Started

Macなのでbrewでインストールして

❯ brew install sapling

Getting Startedを見ながらやってみる

ユーザー設定をして

❯ sl config --user ui.username "名前 <メールアドレス>"

GitHub連携のためにGitHub CLI（gh）のログインを設定しておく

❯ gh auth login --git-protocol https

Clone

適当に作ったGitHubリポジトリをクローンしてきて

❯ sl clone https://github.com/bufferings/try-sapling.git
❯ cd try-sapling

Gitのコマンド使えるのかな？と思ったら .git ディレクトリがなかった。代わりに .sl がある。へー。

❯ ls -al
total 8
drwxr-xr-x   4 bufferings  staff  128 Dec 18 16:47 .
drwxr-xr-x   3 bufferings  staff   96 Dec 18 16:46 ..
drwxr-xr-x  16 bufferings  staff  512 Dec 18 16:46 .sl
-rw-r--r--   1 bufferings  staff   13 Dec 18 16:46 README.md

sl コマンドをオプションなしで実行するとコミットグラフが見える（作ったばっかりだから今は何もないけど）

❯ sl
@  57f903ea2  6 minutes ago  bufferings+github  remote/main
   Initial commit

Add

変更を加えてみる

ファイルを作って

❯ touch hello.txt
❯ touch hello2.txt

確認してみて

❯ sl status
? hello.txt
? hello2.txt

一個だけ追加してみる？

❯ sl add hello.txt

ふむふむ。A が追加されたもので ? がまだ追加されてないものってことなんだろうな

❯ sl status
A hello.txt
? hello2.txt

変更を加えてみる

❯ echo 'Hello, World!' > hello.txt

特に変わってない

❯ sl status
A hello.txt
? hello2.txt

Gitと違ってインデックスがないとのこと。もう Hello, World! の変更は適用されてる

Commit

じゃ、コミットしてみよう

❯ sl commit -m 'my first commit with Sapling'

コミットグラフ

❯ sl
@  cc9195646  21 seconds ago  bufferings
│  my first commit with Sapling
│
o  57f903ea2  22 minutes ago  remote/main

ステータス

❯ sl status
? hello2.txt

Stack

スタックって複数のコミットの積み重ねのことを指すみたいだけどSaplingのドキュメントによく出てくるから特有の概念として覚えておいたらいいのかな？

Getting Startedに従って適当にコミットを追加してスタックを作る

❯ echo foo > foo.txt ; sl add foo.txt ; sl ci -m 'adding foo'
❯ echo bar > bar.txt ; sl add bar.txt ; sl ci -m 'adding bar'
❯ echo baz > baz.txt ; sl add baz.txt ; sl ci -m 'adding baz'

❯ sl
@  64c381a9f  3 seconds ago  bufferings
│  adding baz
│
o  4220bb64a  8 seconds ago  bufferings
│  adding bar
│
o  65280397f  14 seconds ago  bufferings
│  adding foo
│
o  cc9195646  3 minutes ago  bufferings
│  my first commit with Sapling
│
o  57f903ea2  25 minutes ago  remote/main

この @ が今いるコミット。これを sl go bottom や sl go top sl next sl prevで移動できる

❯ sl go bottom
0 files updated, 0 files merged, 3 files removed, 0 files unresolved

❯ sl
o  64c381a9f  2 minutes ago  bufferings
│  adding baz
│
o  4220bb64a  2 minutes ago  bufferings
│  adding bar
│
o  65280397f  2 minutes ago  bufferings
│  adding foo
│
@  cc9195646  5 minutes ago  bufferings
│  my first commit with Sapling
│
o  57f903ea2  27 minutes ago  remote/main

そのコミットの状態になってる

❯ ls -al
total 16
drwxr-xr-x   6 bufferings  staff  192 Dec 18 17:10 .
drwxr-xr-x   3 bufferings  staff   96 Dec 18 16:46 ..
drwxr-xr-x  23 bufferings  staff  736 Dec 18 17:10 .sl
-rw-r--r--   1 bufferings  staff   13 Dec 18 16:46 README.md
-rw-r--r--   1 bufferings  staff   14 Dec 18 16:58 hello.txt
-rw-r--r--   1 bufferings  staff    0 Dec 18 16:55 hello2.txt

top に戻っておこう

❯ sl go top
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

❯ sl
@  64c381a9f  12 minutes ago  bufferings
│  adding baz
│
o  4220bb64a  12 minutes ago  bufferings
│  adding bar
│
o  65280397f  13 minutes ago  bufferings
│  adding foo
│
o  cc9195646  16 minutes ago  bufferings
│  my first commit with Sapling
│
o  57f903ea2  38 minutes ago  remote/main

GUIで操作

GUI で操作することもできる

❯ sl web
started a new server

ってするとブラウザで画面が開く。便利そう

ん？どうやってWebサーバーを止めるんだろう？と思ってヘルプを見てみたら --kill オプションでいいみたい

❯ sl web --kill
killed Sapling Web server process 26955

VS Code extension もあるとのこと

プルリクエスト

いちばん興味あるところ。いくつか方法がある中で一番シンプルなのは sl pr ということなのでやってみる

❯ sl pr
pushing 4 to https://github.com/bufferings/try-sapling.git
created new pull request: https://github.com/bufferings/try-sapling/pull/1
created new pull request: https://github.com/bufferings/try-sapling/pull/2
created new pull request: https://github.com/bufferings/try-sapling/pull/3
created new pull request: https://github.com/bufferings/try-sapling/pull/4
updated body for https://github.com/bufferings/try-sapling/pull/1
updated body for https://github.com/bufferings/try-sapling/pull/4
updated body for https://github.com/bufferings/try-sapling/pull/2
updated body for https://github.com/bufferings/try-sapling/pull/3

おー。pushして、コミットごとにプルリクエストを作ったな？全部mainブランチがdestinationだな

コミットのところにプルリクエストの番号が表示されるようになった

❯ sl
@  64c381a9f  27 minutes ago  bufferings  #4
│  adding baz
│
o  4220bb64a  27 minutes ago  bufferings  #3
│  adding bar
│
o  65280397f  27 minutes ago  bufferings  #2
│  adding foo
│
o  cc9195646  31 minutes ago  bufferings  #1
│  my first commit with Sapling
│
o  57f903ea2  53 minutes ago  remote/main

sl ssl でプルリクエストのステータスも表示される

❯ sl ssl
@  64c381a9f  34 minutes ago  bufferings  #4 Unreviewed
│  adding baz
│
o  4220bb64a  34 minutes ago  bufferings  #3 Unreviewed
│  adding bar
│
o  65280397f  34 minutes ago  bufferings  #2 Unreviewed
│  adding foo
│
o  cc9195646  38 minutes ago  bufferings  #1 Unreviewed
│  my first commit with Sapling
│
o  57f903ea2  60 minutes ago  remote/main

ReviewStack

コミットごとのプルリクエストのレビューのためにReviewStackが用意されてる

リポジトリのドメインの github.com を reviewstack.dev にしてあげれば見える。ReviewStackからGitHubに対するアクセス許可が必要

↑で作ったプルリクエストに対して、コミットごとの差分をレビューできるみたい

まだ機能は足りてなさそうだし、今いろいろやろうとしてるところなのかな

面白かった

ひとまずGetting Startedをやってみた感じだと、これから色々と公開されて充実していくのかなと思った

Gitのコマンドをシンプルにしてるみたいなので、その辺りも慣れると分かりやすいのかな？Gitに慣れてるからまだあんまりよくわかんない

正直なところ、まだコミットごとのプルリクエストの狙っているところも、よく理解できてないんだけど、プルリクエストを出した後にコミットに対して変更を加えるとそれがプルリクエストに反映されるみたいなことが書いてあるので、しばらくしたらまたもうちょっと深く触ってみようかな

ちょうどいい気分転換になったやー。今日はカレーつくろう

ウェブアプリケーションエンジニアとして転職活動をしますー！

突然ですが CircleCI を辞めることになりました。そのことについてあまり話すつもりはないのですが、今の気持ちだけ書いておくと、びっくりはしたけど特にネガティブな感情はなく、面白い経験だなぁという気持ちです。

この一年間、色々とあまりできない体験をしてきた締めくくりにピッタリです。この状況を受け入れて、流れに身をまかせて楽しもうと思います。

ということで、こんな機会はあまりないので、次をどうするか、折角だから色々な会社のお話を聞いてから考えたいなぁと思ってつぶやいたら、たくさんのご連絡をいただき、とても嬉しく思っています。ひとつひとつのお誘いや励ましが、とてもありがたいです。

当初は、年内ぼーっと過ごして1月からお話を聞いて（お話をして）いきたいなと思っていたのですが、お話をいただいているのにそのままにしているのが、自分的に気持ちが落ち着かないことに気づいたので、考えを変えて来週から少しずつお会い（オンライン）していこうと思います。

そこで、自分のスキルや考え、お伺いしたいことについて、頭の中の整理のために、まとめておくことにしました。お会いする方に、これを事前に読んでおいてほしいということではなく、自分が当日にこういう話を伝えたい・聞きたいだろうなということを自分のために書いておく、というものです。

「こういうことも聞いておくといいよ」や「こういうことも伝えたほうがいいよ（面談する側は知りたいよ）」ということがあればツイッターで教えて下さい！

また、この記事を読んで興味を持ってくださった方も、まだまだ声をかけてくれると嬉しいです！

方向性

CircleCI に転職したときは「挑戦」を中心にしたいなと思っていたのですが、今の気持ちは「挑戦したい」と「今持っているチカラで、役に立ちたい」の両方が同じくらいです。

希望するポジション

まずは、希望するポジションから。こういうポジションで仕事をしたいなと思っています。

  • シニアウェブアプリケーションエンジニアとして、自社ウェブサービスの開発に携わりたい
    • バックエンド、フロントエンド、フルスタック、どれでも大丈夫です（自分の持っているスキルについては後述します）
    • 自社のウェブサービス開発を希望します
  • マネージメントではなくIndividual Contributorとして、コードを書くことを仕事の中心にしたい
    • 今後もコードを書き続けていきたいと考えているので、自分の仕事の中心はコーディングにしたいと思っています。将来的にも、Individual Contributorとしてステップアップしていくことを希望します
    • この「コーディング」は「設計などがすべて終わった状態で、設計の通りにコードを書く」ということではなく「要件定義や概要設計も含めて設計とコードをいったりきたりしながらコードを書く」ということを指しています
    • コーディングで自分の価値が発揮できている状態であれば、テックリードとしてチームを取りまとめたり、チーム作りや組織づくりについて考えたりと、その場で求められることに取り組むことは全く問題ありません

英語で仕事をできると嬉しいなとは思いますが、必須ではありません！

自分のスキル

自分の強みは、チーム作りをしながら広い視野でアプリケーション開発を進めることができること、です。

  • 要件定義から設計、コーディング、テスト、運用まで含めた開発
  • 開発者としての視点だけでなく、マネージメントの視点を含めた開発
  • フロントエンドからバックエンド、Kubernetes上でのアプリケーションの運用を含めた開発

以下に自分ができることを書いていきます。粒度がバラバラですが・・・。

プログラミング言語

  • Java
    • 一番慣れている
    • SpringBoot を使って開発できる
    • この1年は使ってないので、もし触るなら最新情報はキャッチアップしておきたい
  • Clojure
    • この1年間使ってた
  • JavaScript/TypeScript
    • この1年間フロントエンドの開発で使用
    • React/Next.jsを使用
    • サーバーサイドのNode.jsアプリケーション開発は、経験はあるがかなり昔なので思い出す/最新情報をインプットしなおす必要がある
  • PHP
    • 以前に勉強して書いたことはあるけど、最近使ってないから使うならもう一度復習が必要
  • Golang
    • 最近勉強したところ。実践経験はないので、参照にできるプロジェクトがあれば開発できる、くらい
  • Ruby
    • 数年前にRailsチュートリアルをやって、コードを読める、くらい

特にプログラミング言語の好き嫌いはありません。

フロントエンド・バックエンド

  • フロントエンドは、Reactを使った開発経験あり
    • Hooks、Testing Library、Next.js、Emotion、Storybook、Chromaticなど
  • バックエンドは、サーバーサイドレンダリングのアプリケーションから、APIまで開発経験あり

フロントエンドもバックエンドも、どちらも好きです。

アプリの周り

  • Git
    • 日常使い
  • DB
    • MySQLは慣れてる。Oracle、PostgreSQLも使用した経験は少しある。どれも基本的な使い方は可能だが「詳しいか？」と聞かれると、そうではないと思う
    • スキーマやインデックスなどの基本的な設計は可能
    • DBの構築やチューニング、運用は経験なし。DBAに相談してた
  • Docker、Kubernetes
    • Docker、Kubernetesを使用したアプリケーションの開発・運用は可能
    • Kubernetes自体を構築・運用した経験はない。インフラエンジニアに相談してた
  • GCP/AWS
    • GKEでKuberenetes+Istioのクラスタを構築した経験はあり
    • AWSはインフラエンジニアに相談しながら雰囲気で使っていたくらい
  • Terraform
    • 調べながらなら使うことができる
  • CI/CD
    • CircleCIはちょっと詳しいです！

アプリケーションの開発について

  • 要件を元にヒアリングをしながら、アーキテクチャや仕様を考えて、実装することが可能
    • プロダクトマネージャーやデザイナーと相談しながら、技術視点での話をすることができる
  • 自動テストや手動テストなどを含めて、アプリケーションに求められるテストを考えて実装・実行することができる
    • QAエンジニアがいる場合は、早い段階から相談しながらテストのことを考えたい
  • 運用を見越した設計をすることができる
    • 開発して終わりではなく、ログやアラートなど、運用を考慮した設計・開発をすることができる
  • 既存のシステムの改善をすることができる
    • これまで、既存のシステムの改善をすることも多かったので、ドキュメントやコードを読んでシステムを理解し、改善を加えることができる

チーム開発について

  • アジャイルな開発や、スクラムを採用した開発経験あり
  • また、そのようなチームづくりの経験あり
  • 特にこの一年間は、多様性のある組織で開発に取り組んできたので、そのような環境で、信頼を土台にして、違いに敬意を払って、チーム開発に取り組むことが可能
  • マネージメントの経験もあるので、マネージメントの目線とチームの目線と両方の目線で事象を理解したうえで、意思決定や情報共有を進めることができる

その他

新しいことを学ぶことは好きなので、これまでに経験のないことでも対応可能です。

以上が自分のスキルセットです。

カジュアル面談に求めるもの

カジュアル面談は、自分が一方的に会社のことを知るための場ではなく、両者がお互いのことを知る場だと考えています。

自分はその会社やそこで仕事をしている方々のことを知りたいなと思っていますが、それと同時に、会社側も自分がどのようなスキルや考えを持っているのかということを見る場だと思っています。

ですので、お声がけをしていただいてはいますが、お話をした結果、自分のスキルや考えが結局その会社の求める人物像とは異なることが分かった、ということは当然あると思います。その場合は、気にせずにその旨を教えていただけると嬉しいです。

お互いの求めているものを情報交換して、合う・合わないを早い段階で知ることができる場であるといいなと思います。

その後の流れ

まだあまり深くは考えていないのですが、お声がけをしてくださった会社の方々とお話をしたあとは、自分が働いてみたいなと思う（そして相手側が自分と働いてみたいなと思ってくれる）3,4社くらいに応募できたら嬉しいなと考えています。

カジュアル面談でお話するのは概要だけだと思いますので、採用選考で落ちてしまうことは普通だと思っています（書類選考で落ちたら少し悲しいですけど）。そこで最終的にオファーをいただくことができたなら、とても嬉しいですし、すべての選考に落ちてしまったら、また考えます。

これもあまり深く考えていないのですが、仕事を始めるのは、2月か3月からかなぁとぼんやり思っています。

自分が最初にお聞きしたいこと

まずは以下の3点をお伺いしたいです

  1. ビジョン
  2. 技術スタックやチームの様子
  3. 自分に期待する役割

ビジョン

自分が仕事をする上で一番大切にしたいことは、その会社の目指しているものに共感できることです。ですので、会社のビジョンを聞きたいなと思います。

プロダクトの面では

  • 会社として何を良くしたいと思っているか、そのためにどのようなプロダクトを開発しているか、そのプロダクトをどのように成長させていこうと考えているか

をお伺いしたいです。それから組織面では

  • そのプロダクトを開発する従業員のことをどう大切にしているか、どのような組織づくりをしていきたいか

も知りたいです。

プロダクトも組織も、現状が目指す姿に追いついていなくても全く問題ありません。それが普通だと思います。でも、会社のリーダーがプロダクトと組織の両方で目指す姿を持っていることはとても自分の中で大切です。そのビジョンを明確に打ち出していて、メンバーを信頼して任せていて、みんなが共感してそれを目指して取り組んでいる会社が良いなと思います。

技術スタックやチームの様子

これはエンジニアとして普通のトピックです。

そのプロダクトの開発に、どんな技術を使っているのか、アーキテクチャはどうなっているか、課題や困っていること、それから、チームはどのような構成なのか、どんな風に仕事をしているのか、などです。

自分に期待する役割

そういったビジョンやチームに対して、自分にどのような役割を期待するか、をお伺いしたいです。これも普通のトピックですね。

次にお聞きしたいこと

ビジョンに共感できることが第一ですが、その次に、以下の2点も自分の中で大切なので、お伺いしたいです。

  • 働き方
  • 待遇

働き方

リモート勤務を希望します。共働きで、子供の送り迎えがあるのと、できるだけ子供と触れ合う時間を大切にしたいという気持ちがあるので、リモートワーク中心でフレキシブルに仕事ができると嬉しいです。

とはいえ、顔を合わせて仕事をすることの大切さも感じてはいますので、出社推奨日があったりするのは、良いなと思います。大阪に住んでいますが、東京に出張として行くのも問題ありません。

待遇

給料やストックオプションなど、できるだけ、今の待遇と同じレベルのものを希望します（もちろん、今以上だと、とても嬉しいです）。

まとめ

以上です。来週の頭に、いったん頂いた情報を整理して、その後少しずつご連絡させていただこうかなぁと思っています。

約束は開発を遅らせる

雑記

観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい

自分の頭の中

この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか

という感じ。6割ぐらいの自信

チームの中

チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う

聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは1ヶ月で終わるものもあれば、4ヶ月くらいかかるときもあるかな。それぐらいラフ

チームの外に対する約束

さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある

だから、可能性があったとしても、少なくとも「1ヶ月でできるかも」とは言わないし、6割程度の自信だと「2ヶ月でできるかも」も言えないかな。色々な可能性を考えながら調査をすることになる

その調査で分かるのは、一番運が悪いと6ヶ月くらいかかりそうだということ。さすがに6ヶ月あれば何かあっても大丈夫かなという線。自信9割。これで計画を立ててみることになる

「遅すぎる」

そうするとだいたい「遅すぎる」ってなる。だから自信8割くらいのところまで削って4ヶ月くらいで計画を立てて、それに沿って進めることになる

これで、もう2ヶ月では終わらなくなる。4ヶ月の計画で進んで、3ヶ月半くらいで終わるんだろう。計画内でできた！やった！

約束すると遅くなる

こう・・・何も考えずにふつうに開発を進めてたら2ヶ月くらいで終わってたんだろうなぁと思う。遅くても3ヶ月くらい。約束をしたことで開発は遅くなってしまったということなのかな

さらに、この色んな可能性を考慮した調査と計画づくりとその説明のために2,3週間かかるので、その分もプラスされる。その間に開発を進めることもできたね

約束してはいけないということではない

約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発するのが一番早いんだなぁ。と思ったので、雑に書き残しておいた