やらなかった後悔やばい…
やらなかった後悔やばい… 将来やりたいこととか色々今考えていることをやらずに人生が終わったら後悔する！ 自分の父親みたいに「何もチャレンジしないで可能性に夢見ている」のは嫌だ！！
という下書きを2020-04-30 15:37:38 に残していた笑
2年前だからコロナ流行にともない人生について思いを馳せていたのだろうか…
コードレビューで理由を書いているのに受け入れてもらえない
自分はコードレビューにおいて理由を書くようにしている。
「GoにおいてConstructorはMakeUser()よりもNewUser()の方が良いと思います」
これは良いと思う理由が書いていないのでNG。
「GoにおいてConstructorはMakeUser()よりもNewUser()を使用することが多いようです。(https://go.dev/doc/effective_go#composite_literals)」
であればGoらしいコードはNewUser()なんだなというのが伝わる。
このようにコードレビューでは指摘する内容には指摘するだけの理由が必要だと考えている。
(理由が説明できない指摘は好みの可能性があるので指摘しないようにしている。)
(自分でもどちらがよいか迷っているのですが、、、というコメントをすることもある。)
明確に理由を説明している場合、それに対する納得の行く反論があれば、指摘を取り込まないことはレビュイーの自由であると思う。
しかし、納得できる反論なしに取り込まないケースがあったので記しておく。
今までの自分の経験上、受け入れてもらえないパターンには2種類ある
- コードレビューを品質向上・学習の場ではなくてマウンティングの場と捉えている
- 格下だと認定した人からの指摘は何であっても受け入れられない人
- プロダクトに求められる内容よりも自分の好奇心を優先してしまう
- 思い付いたから実装したい
- 実装してしまったから取り込んで欲しい
- サンクコストバイアス
1のケースの場合、当事者同士で解決しようとすることはおすすめしない
仕事における目的を見誤っているのでそういうJerkな人*1に対して時間を割くことが無駄である。
Jerkな人のせいで仕事が円滑に進んでいないという証拠集めのためにSlackやGitHubに証拠が残る形でコミュニケーションを取り、上司や責任者に報告してJerkな人を排除しよう。
排除できない場合は自分がチームもしくは会社を去る法が良い。
職場の同僚と良好な人間関係を築き学びのサイクルを加速させることができないのであれば、よっぽど高待遇でない限りチームに残り続けることはおすすめできない。
チーム異動や転職などで一時的に苦労する可能性はあるが、中長期でキャリアを俯瞰してみたら早く離れる方が得なはずだ。
フリーランスの場合は契約更新時にJerk対応割増をしてもよいかもしれない。
2のケースの場合、対話をすることで解決できる可能性がある
好奇心を優先してしまう現状に対して本人もコントロールできない自覚はあるはずなので、認識を揃えるための時間を取り、丁寧にコミュニケーションしていくと上手く行く事が多い。
プロダクトの目的と中長期で目指す方向性の認識を揃えることができれば、好奇心よりもプロダクトの成長を優先して実装をしてくれるようになり、そのための指摘であればレビューを取り込んでくれるはずだ。
好奇心優先で実装してしまう人は難易度の高いタスクを一気に作り切る「突破力」が高い傾向にあるので、向き先を正すためのサポート的な役割になるとチームとして機能する。
自分がフォワードとしてGoalを決める以外にも試合に勝利する方法はあるのだ。
ただ、自身の成果がわかりやすく見えないようになるので、上司に対しては別途考えを述べる機会は作るようにしたい。
「納期が迫っているので」というのはレビューを受け入れない理由になるのか
スケジュールはレビューを受け入れない理由として適切なものだと思っている。
コードの品質よりもスケジュールを優先するチームやプロダクトのフェーズというのは存在するのでそれは理由になりうるし、スキル不足でスケジュールが遅れがちというのも立派な理由である。
このとき「改善の余地があることが見えているコードはメソッドに切り出してすぐに消せるようにする」くらいはやって欲しいなーと思ったりはする。
リリース前であれば30分で直せるものが一度リリースしてしまうとリファクタリングに1日かかったりする。
基本的にはシフトレフトの原則に則って気づいたタイミングで直すようにしたいし、それが優先されるチームであって欲しいと思う。
*1:あえてJerkな人という言葉を使う。Brilliant JerkってBrilliantだと本人が思っているだけでBrilliantだったことがないので。
【TIL/20200823】プロトタイプシティ 深センと世界的イノベーション
を読んでいる。
#プロトタイプシティ のこの辺の中国のエンジニアの実装速度の話本当ですか…単純にこれが理由で企業規模問わずうまく回っているんだとしたら、過去似た開発スタイルを経て中長期の開発がキツくなってた自分は敗北感がものすごいんですが… pic.twitter.com/AwQZP5HbJJ
— Seiji Takahashi - timakin / 社内管理画面なら「ベースマキナ」 (@__timakin__) 2020年8月19日
このツイートの内容を見て「中国のソフトウェア開発プロセスは日本とは全く異なるのか？」と気になって読み始めた。
- ソフトウェア開発に限らずプロトタイプを高速で作成して市場で試すことが競争優位につながるという話だった
- プロトタイプシティの条件は「安全な公園」が満たされていること
- 次なるプロトタイプシティがどこかは予想できない
- 人々が気づいたときにはすでにプロトタイプシティになっている
- ソフトウェア開発においてはテストコードをガチガチに書くことで開発効率を維持し続けることが正義だと思っていたけどそうではないのかもしれない
迷ったら両方！
Aという選択肢とBという選択肢、どちらを選ぶか迷っているなら両方選択した方がいいよね。
片方しか選べないなんて誰が決めたんだい？
という肥満まっしぐらな思考をしているから全然痩せないんだなー笑
仕様レベルの手戻りの振り返り
最近手掛けた機能で大きな手戻りを起こしてしまったので次回以降の開発に活かせるように言語化しておく。
手戻りの原因は2つ
- 課題の深堀りが足りていなかった
- 既存システムのデータ構造に対する理解が足りていなかった
課題の深堀りが足りていなかった
A機能を追加して欲しいという要望を満たすために、既存システムのデータ構造を壊さない範囲で「最小工数で実装できる方法」を選択した。 しかし、その方法ではA機能は追加できているが、業務上の課題が解決し切れていない片手落ちの対応になってしまっていた。 片手落ちの対応では結局ユーザに価値を届けられないので、仕切り直しになった。
既存システムのデータ構造に対する理解が足りていなかった
上記の「最小工数でできる方法」を選択したのは既存データ構造に対する理解が不十分なだったことも影響していた。 コードとテーブルを見てある程度理解はしていたけど、空で語れるレベルの理解ではなかった。 ちゃんと理解していれば、既存データ構造に適した拡張を加える判断ができたはずで、「最小工数でできる方法」は選択していなかったと思われる。
弊社開発フロー
before
after
対策
以下をドキュメントとして作成して、関係者に共有する
- 起票されたIssueに対して「Why?」「So what?」という問いを繰り返し、課題を深ぼる
- 業務とデータの関係を理解するために、既存システムのデータ構造を「図」にする
上記とキックオフMTGを踏まえた上で、ユーザーストーリーを作成する
- ロールごとに書く(管理者、営業、開発など)
- ストーリーを独立してリリース可能な順番に並び替える
- リリースを細かくするため
- スケジュールが把握しやすくなる
- 進捗が見えやすくなるので、メンタルに優しい
- リリースを細かくするため
- ユーザストーリー作成がスムーズにできない場合は、課題の深堀り・既存システム理解が不足している可能性が高い
メモ
開発フローが5段階あるうちの各フェーズでどうしたらより効率良く仕事を進められるかも言語化しておきたいな〜〜
ICL(眼内コンタクトレンズ)手術をして4ヶ月経った【1週間後検診 ~ 4ヶ月後まで】
1ヶ月後に記事を書くと宣言していましたが、完全に忘れていました。
ツイートやメモ書きを見て思い出しつつ経過を書きますが、結論としては、メガネ・コンタクトなしの生活は最高です！
経過
2週間後
- 寝起きに視界がぼやけていることに気がつく
- PCで細かい文字が見づらい感じ
- 文字を大きくすれば見える
- 午後になると気にならなくなる
- PCで細かい文字が見づらい感じ
3週間後
- 引き続き寝起きに視界がぼやけている
- 長時間ディスプレイを見ていたら、軽く痛みを感じた
- 翌日には収まっていたので、長時間ディスプレイを見ないようにすることに
- 軽めの運動を再開する
4週間後
- 1ヶ月後検診
- 問題なし
- 左眼: 2.0
- 右眼: 2.0
- PCを操作するときはブルーライトカットメガネを掛けるようにしていたが、この頃からメガネが煩わしく感じるようになり一切メガネを掛けなくなる
- 寝起きの視界のぼやけが収まってくる
2ヶ月後
- 寝起きの視界のぼやけはほぼ気にならなくなる
- 細かい文字もちゃんと見える
- 長時間ディスプレイを見ても痛みが出なくなる
- サウナに行く
- まったく問題なし
3ヶ月後
- 激しい運動をする
- まったく問題なし
- 海外旅行に行き、メガネ・コンタクトなしの快適さに感動する
4ヶ月後
- プールでゴーグルを着けて泳ぐ
- まったく問題なし
まとめ
お金も掛かるし、リスクもある(失敗する可能性は0ではない)、その後の生活にも影響がある*1のでICLは万人におすすめできる手術ではありませんが、僕にとっては掛かったコストやリスク以上のリターンがあったので非常に満足しています！
自分自身の耐障害性が高まり、万が一の際にメガネ・コンタクトがなくて生活に困ることもなくなりました！
余っていたコンタクトレンズと不要になったメガネを捨てたときは清々しい気持ちでしたｗ
もし興味がありましたら一度カウンセリングに行ってみることをおすすめします〜
カウンセリングは途中までは無料 & ICLについて専門家から詳しく説明してもらえるので、自分に合っているのか判断しやすくなると思います！
*1:ハロー・グレア、ボクシングなどの目を強く圧迫する可能性のある行為ができなくなる
試用期間が終わった
11月1日に入社した現職の試用期間が終わって一段落ついたので今の気持ちを書き留めておく。
入社して間もない頃は2015年にエンジニアになると決意して以来ずっと憧れていた「自社サービスのエンジニアとして働けること」にとてもわくわくしていた。 それと同時に、Webエンジニア未経験の前職や第二新卒として入社したSIerとは異なり、1人前のエンジニアとして採用してもらったので、「給料以上のアウトプットを出せるか」不安にも感じていた。
ちなみにその不安はすぐに解消された。 初PRがマージされたときくらいにチームのメンバーから「よくぞ入社してくれました！って感じで本当に入社してくれて嬉しい！今後一緒にプロダクトをさらに良くしていきましょう！」と言ってもらえたからだ。 SEとして身につけた要件把握スキル、前職で身につけたRailsのスキルの両方が活かされてかつ、チームの一員として認められた感覚があったのでとても嬉しかった。
※全社的に入社をとても歓迎してもらっていたことはここに記しておく。仕事で貢献しないとチームの一員として認められないのではないかと不安に感じていたのは、あくまで僕の主観である。
その後はチームとして半年近く掛けて取り組んでいたシステムリニューアルが佳境に入っていたこともあり、チーム全体として忙しい時期でもあったので、「自分がチームに加わったことで生産性がマイナスにならないようにしよう！」と思って働いた。 当初予定していたスケジュールよりは遅れてのリリースにはなってしまったが、自分が入社したことによる教育コスト、コミュニケーションコスト以上のアウトプットは出せていたと思う。
この頃から、自社サービス(スタートアップ)はインターバルトレーニングのようだなと思うようになった。 1週間のスプリントを走りきって、また翌週も全力で走り切る。スプリントのサイクルに終わりはない。 1本1本全力で走っているので、会社から帰る時間、週の終わりには疲れ切っているのだけど、気持ちの良い疲労感がある感じだ。 今まで所属してきた会社やチームでは食後はコーヒーを飲まないと必ず眠くなっていたのだが、現職では食後に眠気に襲われることはない。 やりたいことがたくさんあり、尊敬できるチームのメンバーとそれらの課題に取り組んでいること自体が楽しくて勤務時間は一瞬で過ぎ去っていく。
ただ、1月の半ばから身体に不調を感じるようになってきた。具体的には休日に起きるのが辛くて12時間程度寝てしまうのだ。 仕事が楽しくて頑張りすぎている自覚はあるので、その反動が休日に来ているのだと思う。(もしくは単純に寒いのが苦手で布団から出られない可能性はある。) もし、本格的に体調を崩して長期間離脱するようなことになったらそれこそチームに迷惑を掛けてしまってよくないので、労働時間には気をつけていこう。 今までの経験上、自分の肉体の強さ的には45時間残業が2ヶ月以上続くと不調が表れ始めるようなので、その辺を目安に。 けど、3月からまた大きめのプロジェクトが始まるし、それに向けて2月中にやりたいこともたくさんあるし、あるIssueで「これはエンジニアとして絶対に応えたい」というものがリソースの都合で応えられなさそうだったりで、労働時間を抑えるのが難しいのは事実ではある。何より、自分が頑張らなかったことが原因で会社が潰れたら嫌だしね。
悩ましい〜〜！！けど、弊社のValueに「不幸を生まない」というものがあるので、自分の健康はちゃんと管理する！Valueを体現するのも大事な仕事の一部である！
やっていきですよ！やっていき！！💪
