DevOpsに興味が出た
DevOpsに興味が出た。というか、DevOpsエンジニアとして舵を切っていこうかなと思っている。理由は以下。
- 機能の変更や、機能の追加のリードタイムを減らしたい。
現在、受託開発をしているが、機能の変更や追加の相談を受けて、見積もりを出した時に、工数の兼ね合いで、発注に至らないケースが多い。
会社としても損失だし、エンジニアとしてより良いものを作りたいと思っているので、システムを良くしていくようにできないのは歯がゆい。
機能の変更や追加を容易にできるようにすることで、三方よしになるのではないか？
・自社：発注を受けて売上アップ
・取引先：システムが良くなることで、サービスの質が上がり、顧客の増加、定着
・ユーザー：システムが良くなることで、満足度の増加
- 個人的には、実際に動くものを作れる実装が好き。パズルを解いている感覚に近く、論理的な推測をしつつ、意図した通りのものを作れた時の達成感がやりがい。また、変更しやすく、意図の分かりやすいコードや、パフォーマンスのいいコードをかけた時も同様。
ではあるが、キャリアアップを考えると、どうも実装に比重を置くのは難しそう。
日本のIT業界では、キャリアアップ = マネジメントというモデルが多い。
確かに、レバレッジをかけるという意味では、作業スキルを極めるより、マネージメントスキルを極める方がいいとはおもう。一人より多人数の方が出力は高いので、理には適っている。
ただ、人の調整、スケジュール管理、顧客折衝などを主にするよりは、開発に携わっていたいので、開発だけではなく、運用面のスキルも磨けば、開発側でポジションを見つけれるのではないか？
DevOpsの勉強を始めた
・手始めに、AWS Certified DevOps Engineer - Professionalを勉強しようかなと思っている
・第一歩として、AWS Certified Cloud Practitionerを勉強中
・あとオライリーの以下の本を買って読む予定
・O'Reilly Japan - オブザーバビリティ・エンジニアリング
・O'Reilly Japan - SLO サービスレベル目標
・O'Reilly Japan - ソフトウェアアーキテクチャメトリクス
・O'Reilly Japan - システム運用アンチパターン
＜以下はできれば読みたい＞
・O'Reilly Japan - ソフトウェアアーキテクチャの基礎
・O'Reilly Japan - ソフトウェア設計のトレードオフと誤り
・O'Reilly Japan - オブジェクト設計スタイルガイド
マインドの変化
モデルがありそれを真似る、先導者がいて導いてもらうという思考より、自ら学びつつ、自分で考えてどうすればいいか、自分が主体となって決める。受身的な仕事ではなく、主体的な仕事。言われたからやるではなく、こちらが言って周りを巻き込む。
こんな感じに変化した。
Next.jsの勉強
参考書を購入
・Nextのルーティングを学んだ（AppRouter、useRouterを使う）
・Nextのレンダリングを学んだ（Server側とクライアント側でレンダリングする）
・NextのAPIの実装方法
・NextでAPIを実装できるなら、Expressは必要ない？
Nextでフロントとバックを一つにして開発することと、
Nextでフロント、バックをNextかExpressで分けて開発することの違いを知りたい
参考記事が下記にあった。
Youtubeで見たプロゲーマーの話がかなりいい話だった
暗記型と法則型として語られているが別の言葉の方が良いのでは？と思ったので、以下として定義する。
暗記型：模倣型
法則型：追求型
それぞれの特徴
模倣型：サンプルや参考書を見て、要点を掴み、すぐに実行できる
追求型：いろんな疑問を持ち、深く追求することで技術が身につく
エンジニアで例える
模倣型：How to系の記事や、チュートリル型の記事、エラーに対する解決方法だけの記事で、とりあえず動かせる状態に持っていく
追求型：公式ドキュメントなどを読み、仕組みから理解していくのが追求型
動画でも語られているが、どちらも一長一短。
模倣型のメリット ：実行して結果が得られるまでが早い
模倣型のデメリット：深い理解はないので、関連した問題の対処や応用ができない
追求型のメリット ：深い理解があるので、関連した問題の対処や応用が効く
追求型のデメリット：理解に時間をかける（かかる）ので、実行して結果が得られるまでが遅い
エンジニアとしては、なるべく追求型のスタンスでいた方が良いと思う。
マイクロソフトに勤める優秀なエンジニアが難しいことを理解していて、著者が「難しいことを理解してすごいなー。頭がいいんだろうな」と思っていたところ、その優秀なエンジニアはそれを理解するために、何回も繰り返し時間をかけたという話があった。
優秀な一流のエンジニアでさえ、理解するには時間をかける。
理解に時間をかけず、表面上の理解だけで仕事をしていると、作業スピードは確かにはやいし、評価もされるかもしれない。
でも、何も身についてないので、次同じことをするときにまた調べ直したり、ちょっとしたトラブルや、よくドキュメントを読んでいたら回避できたことにつまづくこともある。
なので、時間の許す限りは時間をかけて、基礎から理解していくようにした方がいい。
新しい技術や、エラーの解決など調べるときは、人に説明できるくらい、場合によっては記事を書いたりしながら深く理解することを習慣にした方が最終的にはよさそう。
