読書感想「TeamGeek」
TeamGeek
第一印象
- Googleのソフトウェアエンジニアリングと被っている部分が多かった
- Googleのソフトウェアエンジニアリングを辞書とすると、TeamGeekはまさに「チーム」に関連する事項に絞ってある読み物
- TeamGeekは挿絵もあって読みやすさがある
- メーリングリスト等はちょっと現代だと古いかなぁと思いつつSlackで置き換えて考えている
- TeamGeekの目的としては、「プログラマがソフトウェア開発を効率的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させること」とあるので、「人」にフォーカスしている
- もちろん、Googleのソフトウェアエンジニアリングに載っていない事項もあったので集中的にその部分を読み進めた
目次をいくつかピックアップしながら印象に残った部分をあげる。
ミーティング効率
まとめると
- 進捗報告だけのスタンディングミーティングは無意味
ルール
- 絶対に必要な人だけ呼ぶ
- アジェンダを作ってミーティング開始前に配布する
- ミーティングのゴールを達成したら時間前でも終了する
- ミーティングを順調に進める
- ミーティングの開始時間を強制的に中断される時間（お昼休みや就業時間前）に設定する
という話だった。進捗報告だけのミーティングはオンラインミーティングでもやりがちになってしまっているので、「この会議必要ですか？」と言う積極性が必要だと強く感じる章だった。
有害な人に対処する
少し話がズレるが、世間にはブリリアントジャークと呼ばれる人が存在しており、この本では有害な人と称している。
最近ではテクハラと呼ばれることもあり、おじさんに限らずデジタルネイティブの世代がおじさんにテクハラをしてしまうケースも少なくないようだ。
参考記事
しかし、技術的指導をマウントと感じるのは個人の裁量に任され、Aさんはマウントに感じなかったが、Bさんはマウントと感じてしまうケースなども往々としてある。難しい。
ただ、そういった場合でもこの状況を避けるためには尊敬の精神を持っていれば十分回避可能だと感じる。
尊敬の精神を持っていれば言葉遣いや態度に不快要素が現れる可能性は低い。「えぇ！？知らないの？」のように驚いた素振りを見せると質問者は萎縮し、心理的安全性は失われてしまう。質問には「知らなくて当然」の精神で答えるくらいがちょうどよいのではないかと最近は思う。（ちなみにここらへんの話はGoogleのソフトウェアエンジニアリングのほうが深堀りされていた）
本書にもどると、有害な人はチームの直接的な脅威になると言われており、生産性だけではなく、チームの文化まで悪化する傾向にある。と述べられている。
そのために対策としては、「文化を強固なもの」にするのが有効であると述べられている。やはりチーム文化はしっかりと土壌から作っていく必要があると感じた。
余談だが、2013年の本なのに笑うを「草」と表現していて驚いた。こんな前から「草」なんてあったっけ？
ユーザーも人間
アプリを開発する側として、絶対に忘れてはいけないユーザーの存在について述べられている。
個人開発で開発することだけに焦点を当てていると、ユーザーのことを全く考えていないアプリが出来上がることがある。
その問題を避けるために、この章を一読すると良いと思う。また、ユーザーに対しても尊敬の気持ちは大切で、「ユーザーはバカ」と思っては絶対にいけない
本書のたとえ話として
ユーザーのことをバカと思うのは、トランスミッションの修理や問題の診断ができない君のことを自動車工がバカだと思うのと一緒だ
という一文があった。ごもっともである。
- マーケティング
- ソフトウェアがどのように見られるか気を配る必要がある
- ユーザビリティ
- ソフトウェアが簡単に使用できなかったら、遅かったら、使いにくかったら、アクセスできなかったら、ユーザーはいなくなってしまう
- カスタマーサービス
- ユーザーと長期的な関係構築が、ソフトウェアの進化やユーザーの定着に影響を与える
というのが重大なコンセプトであり、私達のプログラムを書く理由である。
ソフトウェアはユーザーの生活を豊かにするために作られるのだ。
感想
- 本書の最後にて「本書のアドバイスは必ずしもソフトウェア開発に限ったものではない」と言われており、そのとおりだなと感じた
- 今までの自分は技術を追い求めることに躍起になっており、人間的に重要な部分が少し欠如していたように感じられ、本書の要素を胸に刻む必要がありそうだった
- エンジニアリングは簡単。人間は難しいという言葉があるように、人間に対する理解の時間を増やすべきだと感じた
- 組織で働く上で「人間関係」は切っても切り離せないものであり、重要視する必要がある。
- そしてその「人間関係」を円滑に行うには「尊敬」の気持ちを忘れずに持っておくことが一番の鍵なのだと再実感した
尊敬については過去記事で重要性を再実感している。
一番大事にしているものは何かを考える
自分と向き合って自己理解を深め、意見を堅牢なものにしていくためのプロセス。
一番大事にしているものは何か
- 学習
- なぜ？
- 今後の人生において役立ち、物事を多方面から考えられるようにし、豊かにする
- キャリアの形成に役立つ
- 人間が普通に生きていたら何十年も悟るのに時間がかかるものを短期的に得られる
- 知的好奇心を満たすことはたのしい
- それで？
- 人生を豊かにするために必要で、人生という道のショートカットにもなる
- なぜ？
- 最高効率で学習を行える環境
- なぜ？
- 学習環境が不適切だと学習効率が異なる
- 学習を快適におこなうため
- それで？
- 一番大事なのは学習ではないか？
- なぜ？
- 自分の時間
- なぜ？
- 自分会議を行うことで客観的に自分を内省できる
- 内省を行うことで自分の不足している部分・得意な部分を見通すことができる
- 自分の時間は学習に充てることができる
- 他人に合わせないで自由にする時間は必要
- それで？
- 自分を見つめ直すための時間があることで、人間的な成長が望める
- なぜ？
- 他人へのリスペクト
- なぜ？
- リスペクトを忘れると傲慢になる
- 相手から学べることは必ずあるはず
- 自分が相手より上など定量的に判断するのは不可能だから
- 良質な人間関係を構築していく上で必要不可欠
- 相手を悪い扱いをして良い扱いがされるわけがない
- リスペクトができないのであれば、視野が狭まっている
- それで？
- 「相手から何か学べる」の精神を失うと、人間的に傲慢になり、人間関係も悪化していき、不幸せな結果に行き着く
- なぜ？
- 他の人が不幸せな選択をなるべくしてほしくない
- なぜ？
- 不幸せなのはつらい
- 本当に？
- 自分の人生ではないのでエゴかも
- なぜ？
- 自主性（自己の未来実現の為に動いていくこと）
- なぜ？
- 自分の人生を生きるために
- 他人に操作された人生は面白くない
- 他人の甘い言葉に誘惑されやすくなってしまう
- 自律的に行わないと学習効率が大幅に落ちる
- 人間は自分の意思で決定したものでないと後悔する
- それで？
- 自分の人生を生きたいのであれば、自分から変えていくマインドで考える必要がある
- なぜ？
- 信頼のおける友達
- なぜ？
- 友人は自分が困った時に助け舟を出す相手になりうる
- 友達がいることで精神の安寧が担保される
- 友達がいない人生は自己に寄りすぎてしまい、偏見の塊になってしまう
- 友達というのは利益を度外視して関わっていける尊い存在
- ドメインが異なる友達から得る知識がたくさんある
- それで？
- 自分の人生を豊かにする・成長する機会を与えてくれる友人は尊いもの
- なぜ？
- 謙虚さ
- なぜ？
- 謙虚さを失ってしまうと傲慢になり、学ぶ機会が減ってしまう
- 謙虚でないと、一度振り上げた拳を下ろすことができずに振り下ろしてしまう
- 謙虚でない＝尊敬が足りていないので態度に出てきやすい
- それで？
- 謙虚でないということは尊敬が出来ないということになり、成長の機会を失ったり、他人を傷つけてしまう
- なぜ？
- 素直さ
- なぜ？
- 素直であるということは謙虚で他人の意見を聞けるということ
- 素直に言葉を受け取ることで、変な勘ぐりを行わない
- 間違っていても素直に受け取れば恥の上塗りは避けられる
- それで？
- 素直さは頑固にならないための要素であり、物事をややこしくしない性質
- なぜ？
- 健康
- なぜ？
- 体が機能しないと学習が行えない
- 心が健康でないと効率の良い学習が行えないし、分析もできない
- 寿命が長くなるということは生涯学習時間が増える
- 医療費にお金を割く必要がある
- 他の人に心配をかけてしまう
- 学習時間が減り、効率が落ちてしまう
- それで？
- 人間的活動を行う前提条件として「心身の健康」は必須となる。これがない状態では全てが始まらない。スタートである。
- なぜ？
一次結論
これから変わる可能性があるため
前提で一番大事なもの＜健康＞
- 人間的活動を行う前提条件として必須（すべての土台となる）
- 自分が大事にしている概念を健全に行うためには健康が必須
- 健康を捨てて何かに時間を注力するのは、長い目で視ると損
- 健康を適切に維持することが、最終的なコストパフォーマンスが良くなる
概念的に一番大事なもの＜リスペクト＞
- 「相手から何か学べる」の精神を失うと、人間的に傲慢になり、人間関係も悪化していき、不幸せな結果に行き着く
- 素直さ・謙虚さの原点。ここから全てが始まる
- リスペクトしあえる人間同士なら無限に成長していける
行動的に一番大事なもの＜学習＞
- 今後の人生において役立ち、物事を多方面から考えられるようにし、考えを豊かにする
- キャリアの形成に役立ち・幸せな家庭を作っていくための稼ぎの柱となる
- 人間が普通に生きていたら何十年も悟るのに時間がかかるものを短期的に得られる（重要）
- 知的好奇心を満たすことはたのしいので、人生の充実度が向上する
- ->心の健康が保たれる
欠点の認識
欠点の再認識
近況
最近諸事情で様々な人と会話していく上で、自分の論理的思考力・説明力の低さに対して能力の低さを実感した。
言語化と言われることもあるが、自分の中にある考えが抽象的・ふわふわと実体がないものであるために、説明が芳しくない。つまり、WhyWhyと聞かれてしまうと困ってしまうということ。
Why
なぜ、「なぜ？」と聞かれてしまうと言葉が詰まってしまうのか、自分には複数の要素が起因していると考えている。
- なぜ？と思う前に直感的に答えとして出してしまっている
- なぜそうなのか、なぜなのかという点で物事を深く考えることが少ない
- 自信がないために、自分の意見として主張が弱く、逃げてしまう（折れてしまう）
- 楽観的な見方をしてしまう（なんとかなる）
- 自分の考えについて理解が足りていない・分析が不十分である
上記の点で言葉が詰まってしまうのだと考えた。1つ1つのケースに着目して考えていく。
なぜ？と思う前に直感的に答えを出してしまっている
私はコミュニケーションが得意ではないし、人を不快にさせないようにコミュニケーションを取るように心がけている。
つまるところ、「人の顔を伺っている」のであり、思慮が浅いままレスポンス重視で返答している傾向にある。
長い目で見てしまうと信頼を失い兼ねない行為であり、人を不快にさせる悪い行動になりうる危険な行動なため避けたい。
社会的な経験が浅いという点もあり、社会に慣れてきてしまえば多少こなれた返答ができるようになるのだろうが、本当にそれで良いのだろうか？
本質的な原因の解決には至っていない上に、隠してしまっている。経験が浅い今が一番の変える契機である。
なぜそうなのか、なぜなのかという点で物事を深く考えることが少ない
エンジニアとして「なぜなのか」という点については日頃から考えているつもりである。
同時に「こういうものだから」と押さえつけられる事も多々あり、「なぜ？」を探求する心の芽を摘まれる経験もあった。
仕様の「なぜ」を聞いても答えにたどり着けないケースも往々にしてあるが、その制限の中でも「なぜ」を追求していく力が必要なんだと思う。
自信がないため、主張が弱い
大前提として、自分の考えは「間違っている」という認識をもったまま話を進めることがある。
「間違っている」前提で話を聞いているがために、他人の意見に影響を受けやすく納得してしまうこともある。
もし自分が十分な知識を得て、自分なりの考えを持つようにした時に強く、自信を持って主張することが重要なのだと思う。
楽観的な見方をしてしまう
基本的に楽観主義で生きているため、「なんとかなる」で生きている節は幾分かある。その場しのぎのキリギリス的な生き方で過ごしている。
自分を理解出来ていない
自己分析など一番最初にやるべきものだろうが、自分以外の考えを見てしまい「自分はこっちかもな」と感じ、ありのままの自分が見られていない可能性がある。
何がありのままの自分なのかを視ることがファーストステップなのかと思う。
それでもテストは好き
なぜ、ユニットテストが好きなのだろうか？
- ユニットテストは霧がかかった森の中で道を照らしてくれる妖精のようなもの・・・。つまり、曖昧なソフトウェア開発の中で信頼を提供してくれるから好きだ
- なぜ信頼を提供してくれるのだろうか？
- テストが失敗すれば少なくともコードに欠陥があり、成功すればテストケースの動作は担保されるから
- リファクタリングも心理的安全性が確保された状態で実行することができるから
- テストを見るだけでおおよその動作を把握でき、コードを動かすこともできるから
- リグレッションからの保護をしてくれるから
- それでもって良いテストと悪いテストが存在するが、それについて普及度が低く情報の発信しがいがある
- なぜ信頼を提供してくれるのだろうか？
- テストによって保護されたソフトウェア開発は生産性の低いバグ調査やバグ修正から開放され、快適に開発が行える
- テストによってテスタブルなコードの意識が強まり、本番環境のコードの品質も高めることができる
好きなものについては「なぜ？」が定まっているあたり、軸が定まっていないだけなのかもしれない。
これから
アウトプットを増やす
常日頃からアウトプットを行い、自分が「なぜ」そう考えているのか、「なぜ」行ったのか、「なぜ・・・なぜ・・・」を文を各過程で自分に投げつけることによってトレーニングを行おうと思う。
自分のNotionを再構築した話
歴史
2020/5/24に初めての有料利用となり、意外と前から利用しているNotionですが、最近まで放置しぎみだったので一念発起し再構築しようと感じました。
自分はアーリーアダプターくらいのマインドを持っていて、好奇心旺盛に色々試すタイプの人間です。
自分のNotionの使い方ですが、勉強メモに使っていたり、ブログとして使っていたり、お買物リストに使っていたり、結構幅広く利用していた感じでした。
nextjs-notion-starter-kitやSuperを使ったりWraptas(旧Anotion)を使ってブログを作るなどもしていましたが、Managementとしてちゃんと使用した経歴はなかったように感じます。
詳しくはこっちの記事で
方針と実施
前にNotionを使っていた時は何時間も考え、試行錯誤したページを作った挙げ句、1~3日ほどで管理をやめてしまうケースが多々ありました。マネジメントルールを厳しくしすぎたり、工程を複雑にしてしまうと結局使用されなくなり、腐ってしまうケースが多い為、今回はやらないことから先に決めることにしました。
やらないこと
学習メモのStack
学習メモはNotionに溜めていくと管理が辛くなった記憶があるので今回はNotionでは一切扱わないことに決めました。（管理手法が悪いのかもしれませんが・・・）
以下が自分の感じた点です。
- 学習メモをStackしていく
- タグ分類で疲れる
- メモが大きくなりすぎるとメンテナンスがされなくなる
- メモが大きくなりすぎると見通しが悪く、読まなくなる
- Notionの情報へのアクセス性がちょっと悪い
- できればO(1)で決まって欲しい（わがまま）
- 見返さないメモは意味ないのでは？と感じてきてしまった
- 細かい粒度でメモを作るとしてもページが境界があるので面倒
- 階層が深くなりすぎると分からなくなりやすい
- これはAll in One でデータベースに全部入れてフィルターとビューで調整すればなんとかなるかも
- vim操作ができない
なので、今回は学習メモは全てObsidianに委任することにしました。
細かい管理
ざっくり言い過ぎですが、細かい管理は行わないことにしました。
- ReadingList
- Obsidianで管理するため、Notionでは扱わない
- 収支管理
- Money Forwardで管理し、Notionでは入力も手間なため扱わない
- 雑費管理という大まかな区切りでの支出管理は行う（無駄遣いの可視化のため）
- ブログ記事管理
- Obsidianで管理する（Markdownで保存するのでGit管理が楽）
- 欲しい物リスト
- 欲しい物が多すぎる上に、AmazonのWish Listで事足りている感じがするので
- Linked Databaseを用いた複雑なデータ管理
- 構築済みテンプレートを使うならまだしも、1から構築するのはコストが高いので見送り
- 既に構築されているテンプレートを購入するとかなら全然OK
- Notion アンバサダーのYuji TsuburayaさんのNoteとか購入して構築するなどが一番コスパ良さそう
- 凝ったダッシュボード作成
- ダッシュボードはサクッと通り過ぎる事が多いので「かわいい」「かっこいい」などは考えずに作ります
- 資産管理
- 管理するほど資産がありません
例としてはこのような感じになります。逆にするものはなんだよ？と思う方もいらっしゃると思いますが、基本的に自分に対してマイナスになることの可視化ができるように管理していきます。一種の自戒ツールです。
やること
マイナスになることの管理
自分にとってマイナス影響を与えるものの管理をします。
雑費出費管理
コンビニや近くのパン屋での出費を記録していきます。いわゆるラテマネーというもので、ちりも積も出費を管理します
管理方法としてはデータベースにテンプレートとして(100円, 300円, 500円, 1000円)と入力されたものを用意しておき、消費時に近い金額のものを選んでpageを作成します。近い金額がない場合は複数組み合わせて作成します。columnとしてplaceという消費場所を予め選択肢として作成してはありますが、最悪選択しないでも問題ないようにしています。
あくまでも目的はラテマネー発生による出費の概算値の確認なので、そこから外れないように障壁を限りなく減らします。（こういうリッチな管理ツールだとリッチにしたくなってしまいますが、リッチにすればするほど入力コストが増え、使われなくなってしまいます）
後はビューとして週毎・月毎・年毎でグループ分けをしたビューを作成して終わりです。簡単ですね。
お買い物リスト
自分は業務スーパーのヘビーユーザーなのですが、毎度買うものをリストに作成するのは面倒なためNotionでお買い物リストを管理しています。
管理方法ですが、データベースを作成しカレンダービューも作ります。
次にテンプレートで内側に以前買ったことのあるもの・恒常的に買うもの・Todoリストを作ります。
テンプレート内部のリストではよく行く店舗で商品が置かれている順番・買う量・買うチェックボックス・買ったチェックボックス（カゴに入れた）を作成しています。
もう1つビューも作成し、フィルターで買うチェックボックスにチェックが入っているものだけを抽出して実際にお店で使えるようにしています。
Todo Listはテンプレート内部のデータベースに登録されていない、突発的に必要になったもの用です。
SubScription管理
ありがちなやつですが、現代ではSubScriptionを何でもかんでもしてしまうので管理しています。ちなみにテンプレートはここから引っ張ってきました。
WebClip管理
NotionでのWebClip管理は個人的にかなり使い心地が良く重宝しています。Chrome拡張のSave To Notionが優秀で、ワンクリックで保存できるのが便利でよく使っています。
Clip用のデータベースもそんなに凝ったものではなく、inbox（最初は全部ここに入るがCategory分けすると消える）とallビューくらいしか作っていません。
All In Oneタイプのデーターベースにしておけば後々参照したい時もデーターベース参照とフィルターでタグ分類毎に出せるので個人的にはよく利用しています。
タスク管理
タスク管理をしないとすぐに忘れてしまうため、Notionで扱うことにしました。ただ無秩序にデータがストックされていっても嫌ですし、キレイに流れていって欲しいということでテンプレート選びに苦労しました。
選んだテンプレートとしてはUltimate Tasks and Projects Template for Notionです。
リンクを見てもらえれば分かると思いますが、かなりリッチで使い勝手も良いです。（しかも無料）
ところどころのcalloutは英語なのでDeepLに翻訳をかけてから入れ直してます。とっても便利で満足しています。
その他
後は大したことはしていないためSummaryだけ書いておきます。
- Memos
- All In One型のメモデータベース。アイデア系も生活メモ系もここに入れて、カテゴリで管理
- Habit Tracker
- ゴミ捨ての日確認だったり、何曜日にここお掃除する！程度の簡易的なものです
- Minimalist Habit Tracker Template for Notionこれ使っています
- Stack Knowledge
- 過去に使っていて溜まっている学習メモです。一旦ここに置いてはありますが、そのうち消す予定です
- キャリア関連
- 就活的なものはここにまとめてあります
- ただResumeみたいのはMarkdownで管理したいのでGithubで別に管理しています。あくまでも業界研究や企業調査等のデータを置いてある感じです
簡易的ダッシュボード
ダッシュボードはあまり凝らずにバランスが良くなるように作成しました。ウィジェットはIndifyで作成したものを利用しています。
ダッシュボードには各ページへのリンクとTaskリストのDaily Taskだけデータベース参照して表示させています。
余談
cover画像
ところどころ統一させているcover画像ですが、全てMarpでサクッと作りました。
一応テンプレートとして置いておきます。（2/23のアップデートでダークモードのカラーが変わっていたので地味に探すのに苦労しました）
フォントはにくまるフォントなので、以下から利用してください。
/* @theme notion */ @import 'default'; section { font-family: "NotoSansJP-Regular", "NotoSans"; background-color: #191919; width: 1500px; height: 600px; } section.title { text-align: center; } section.title h1 { color: #FFFFFF; font-family: "07にくまるフォント", "NotoSans"; font-size: 90px; padding-top: 24px; }
Icon
アイコンは全てNotion Iconsを利用しています。シンプルで事足ります。
まとめ
- 学習メモはObsidian
- Notionで管理しすぎない・リッチにしすぎない
- テンプレートを流用して構築コストを抑える
エンジニア1年目の思考ログと気づいた大切なこと
エンジニアとして働く前
専門学校生としての4年間
2017年からエンジニアを目指して専門学校に入学し、やっと4年の時を経てエンジニアになることが出来ました。
専門学校としては資格取得をメインとする、よくあるIT専門学校であり、プログラミングの授業はほとんどなかったので独学で4年間プログラミングを学び続けてきたことになります。
当初は2年制のコースに入っていて、19卒になる予定でしたが就活をした際にTeamLabさんを受けさせていただいたところ1次面接で落とされました。当時自分は情報収集力もありませんでしたし、プログラミング経験もほとんどありませんでした。資格だけで評価されると勘違いしていたのです。
自分が面接官であったとしても選考から落としていたと思います。そのおかげで市場価値を意識するようになり、今があると思っています。
そこから2年間色々なことに触れてきました。学校の方で強制される資格試験もそれなりにやってきました。
- AtCoder
- 今は参加者が多くて勝てそうにないですが、緑くらいまではやりました
- ロジック考える力はここで養われたので、やってよかったと思っています
- 技術書典
- 初参戦は4で、「これがエンジニアの人たちか・・・」と胸を踊らせていました
- Qiitaアウトプット
- 初投稿が2018年で、無教養で内気な私がアウトプットをする為にしたこと、自信のなさが表れています
- Flutter
- 触ったのは2020年頭頃、最初期でリソースが全くなかったので英語リソースやGithubのissueを読む力がここで培われました
- 触れたUdemyのコースはこれで、リファクタリングの楽しさ等もここで知りました
- Unityゲーム開発
- チュートリアルレベル。かんたんなコイン落としなど作って「ゲームプログラマーの人は大変だ・・・」と思っていました
- Ruby On Rails
- Rails チュートリアル全盛期ですね。この頃にTwitterで「Railsチュートリアルでポートフォリオを作って転職！」みたいなトレンドがありましたね。懐かしい。
- Bot作り
- Discord Bot, LINE Botが手軽に作れたのでHerokuの勉強がてら作ってました
- Flask
- 当初はDjangoに触れていたのですが、フルスタックすぎて、わけが分からなくなってしまったため、最小構成のFlaskが好きで触ってました
- React
- フロントエンドも触りたいと思っていて、TypeScriptを学びつつ、Reactも触っていました。
- 技術書典の場のノリで買ってしまった りあクト！がすごく優秀でわかりやすかったので場のノリって意外と重要なんだなぁと実感しました
資格はIPAのやつです。エンベデッドとネスペは2点くらい足りなくて落ちました。
- 基本情報
- 応用情報
- デスペ
- セキスペ
技術書マニアだったので色々買い漁っては目を通してました。ただ、「人間一番必要だと思ったときが一番学習効率が良い」ので習熟度としては微妙だと思います。頭の片隅に置いてある感じですね。
21卒としてエンジニア人生スタート
4 ~ 6月 新人研修期間
エンジニア1年生としての最初の期間は例に漏れず研修を行ってました。
研修内容は基本的なものとLarave, Vueでしたが、研修期間は自分の手元でLaracastを見つつ、独自に情報をキャッチアップしてました。独学の時間が長くなってしまうと自分で学びがちになります。
この時期はDB設計なども空き時間に勉強してました。データベーススペシャリストを取ったとしても実戦とは乖離しすぎているので、現場に近い知識を習得したかったのが動機になります。
ここらへんで読んだ書籍は以下です。
6 ~ 7月 Docker環境構築
M1 Macが出てすぐだったため、VirtualBoxが使えませんでした（これは今も？）
なのでDockerを用いて会社の自社サービス開発環境を整えるという仕事が最初の仕事（？）になりました。
Docker自体は触れるつもりもあり、知識を積める良い期間になったのですが、0から構築するのは結構骨が折れた思い出です。
以下の本を参考にしました。
7月 ~ 8月 テストコードにハマる
インフラを学んだ後に実案件のテストコードを担当しました。ここが自分の人生の中でも転換期になると思っています。
カバレッジ率90%を目指すというアンチパターン テストをたくさん書くということで慣れないPHPやPHPUnitで悪戦苦闘をしていました。
「テストコードとは何」から始まり、飽くなき探究心・好奇心で学びまくりました。
- テストコードは何を担保すべきなのか？
- テストコードをキレイに書く方法は？
- テストコードの目指すものは何なのか？
- テスト容易性とは何なのか？
- ユニットテストはどこまでカバーするのが正しいのか？
- テストコードのベストプラクティスは何なのか？
上記のようなWhat?が溢れんばかり出てきてしまい、日夜テストコードのことしか考えることが出来ませんでした。
ソフトウェアテストからテスト容易性に繋がり、テスト容易性から設計に繋がり、設計からDDDに繋がってきています。
また、これはソフトウェアテスト技法ドリルの受け売りですが、実生活でテスト駆動を意識することで相手に理解しやすい話し方や例示ができるということを知りました。
自分の今の目標としては、
- リグレッションからの保護
- リファクタリング耐性の高い
- 迅速なフィードバック
- 保守性が高い
という4つの柱を適切な分配で両立させたテストコードを普及させ開発者を幸せにする。というのが目標になっています。
- テストで迅速なフィードバックを得ながら開発
- テストハーネスによる安全なリファクタリング
- テストによる心理的安全性の確保された新規機能の開発
- 仕様変更時のテストメンテナンスコストの低減
- 上記が担保された開発者が幸せに開発が行える環境
を提供することができれば、もっと開発者が幸せになり、幸せな開発者はエンドユーザーに高品質を届けられ、ユーザーの幸せを生産することができるのではないでしょうか。
自分はそれを信じて、今を生きています。
熱くなりすぎました。この期間で読んだ書籍が以下になります。
9 ~ 10月 バックエンドAPI開発
ある案件のバックエンドAPI開発に携わりました。OJT期間ということもあり、工数が0で自分の責任範囲は大きくなく、要件定義書から実装に落とし込むような練習みたいなものでした。
自分の中でテストコードのベストプラクティスがまだこの段階では模索中であったため、酷いテストコードを書いてしまった思い出もあります。
幸い影響範囲が大きくなく、修正も容易だったことが救いですが勉強の必要さを感じられました。リポジトリパターンなどに触れつつ案件開発を進めることが出来ましたが、今となってはこのリポジトリパターンに細やかな疑問を感じています。
自分の知識量が上がったのもそうですが、コードの良し悪しが見分けられるようになってきたので大きな成長を感じます。
以下を読みました。
11月 ~ 現在 バックエンドAPI開発
世間的にも話題になるようなアプリのバックエンドAPI開発に携わることになりました。
納期も厳しく、様々な人の手が加わったコードで、要件も難しい案件でメンタルをすり減らしながらコーディングしていた思い出です。
アルゴリズムの重要性を体で実感しましたし、パフォーマンスの良いEloquentの書き方も意識するようになりました。ここでもテストコードのメンテナンスコストが大きくなりつつあり、一番テストに対して真摯に向き合っています。
PHPUnitとLaravelで上手くテストをするために試行錯誤を繰り返しながら見つけた個人的ベストプラクティスもありますが、なんとか今はそれをガイドラインとして落とし込もうとしている最中になります。
ただDDDを学んできて、このテストガイドラインの存在がちょっと揺らぎつつあります。
例えば、「リクエストデータはリクエストデータでImmutable Classを作る」という方針が自分の中で答えだと思っていたのですが、（あとから知ったのですが）これまんまData Transfer Objectの考え方なんですよね・・・。
なのでテストガイドラインも現時点の考えのスナップショットを撮る気持ちで書くつもりですが、DDDの知見を深めた時にさらなるベストプラクティスを見つけられて改善できると思っています。
Spatieの教材信者になっていたり、Eloquentでパフォーマンスを出すためにはSQLをちゃんと学んでインデックスを意識しながらクエリを作らなきゃいけないという事実に気づいて、次はSQLをもっと勉強すべきかな？と感じています。
ただDTOの概念を知ってからリスコフの置換原則や依存性逆転の原則などの概念がやっと理解できましたし、Facadeがもたらす秩序の破壊も理解できました。オブジェクト指向（もしくはプロセス指向）も深く掘り下げていきたいと考えています。
以下の教材で学びました。
職務経歴書みたいな進め方をしてしまいましたが、1年の反省と言ったらこのような形になりました。
エンジニアとしての気づき
Eloquentはインデックスを意識しながら書く
前述でも述べましたが、LaravelのEloquentは簡単に書けるが、インデックスを意識するとしないとでは雲泥の差でパフォーマンスが変わってしまうということを実感しました。derived tableを意識しながらサブクエリを書くと有効にインデックスを使えるなどの小技を知り、突き詰めるためにはSQLを再度奥深くまで学ぶ必要があると感じました。 書籍はお家にあるので、時間があるときにぜひ読み進めようと思っています。
アルゴリズム力はあればあるほど良い
競プロは実務では役に立たない、という層が一定数いますが自分はそうは思いません。競プロのアルゴリズム力は普段の実装でも大いに貢献してくれますし、論理的に物事を考えられる力は大きな力になります。
また競プロはテスト駆動開発を素で行っていることになるので品質の高いコードを書く意識が強くなります(保守性は別)
コーナーケースを考えられる力も培う事ができますし、時間がある時は積極的に競プロをしていこうと思っています。
少しずつ読み進めています。
独学が1番だが、仲間は居たほうが良い
エンジニアは基本的にみんな独学になります。ただ、共に方向性は違えど学ぶ志が同じ人達と時間を共にする、ということはかけがえのないことだと思います。
モチベーションの維持にも繋がりますし、自分のウォッチしている範囲外から情報が入ってくる可能性があるため視野が広がりやすくなります。
今の会社では全体的に独りで学ぶ、といった傾向のが強く、情報共有が行えているのは一部の同僚くらいですが、ゆくゆくは会社全体で一体感を持って切磋琢磨できる環境に身を置くことが出来たら・・・と強く思っています。
コードの先は人
おそらく109回くらい言われていることでしょうが、「コードの先は人」 ということを強く実感しました。
コードだけ書いていればいい、という人も時にはいますがチームとして開発を行っていく上で一番大切なのは、和気あいあいと会話をする能力だと感じました。
会話が少なく、険悪なムードのチームではどんどん閉鎖的になってしまい、情報の共有自体行われる事が少なくなってしまいます。 心理的安全性も良くないので、モチベーションにも影響が大きく出ますし、ミスを恐れる・自分のタスクだけを淡々とこなす方針に寄っていってしまうため、チームでの協力という文化が失われます。
そうなってしまうと品質の面でも影響が出てきますし、テストも雑だったり、更にバグを生み出しやすい環境に近づいていき、最終的に待つものは死となります。
人と協力してチーム開発を行っている以上、尊重すべきなのは「コード」ではなく、「人間」ということを肝に命じながら末永いエンジニア人生を歩んでいこうと心に誓った一年になりました。
自分はリモートワークの中で、いかに心理的安全性を確保するため絵文字を多用するように推進した記事を書いたり、なるべく人とコミュニケーションを取るように話しかけていました。また、Slackだとリアクション絵文字をたくさんつけることによって「認識している」という実感を与えてコミュニティを活性化させる取り組みも意識的に行いました。
これからも良いチームビルドとは何なのか？を学びつつ、開発者が幸せな環境を作り出す努力を続けて行きたいと思っています。
技術ブログを何で書こうか迷いに迷った結果はてなだった。
アウトプット全盛期かつ、ツールに溢れたこの世界でどのように技術ブログを書こうか迷ったことはありませんか。
自分がどのサービスを使うか迷った挙げ句に、結局はてなに戻ってきた話の紆余曲折になります。
続きを読む