概要
現職の開発部のメンバーに共有した記事のログ
技術系
汎用テーブルがもたらす副作用とその対処
汎用テーブル/APIによる問題についての記事です
当社プロダクトでも、この記事で出てくるようなスケジュールの問題を抱えています。
自分の当時の設計としても問題が大きい部分がありますが、その問題を改善すること無く新たなデータを付け足していった結果が今の状態だと思います。
今後はこのような状態にならないようなテーブル設計をしたり、テーブル自体を改善したりと様々な対策が必要だと思い共有いたします!
マネジメント系
コードの内部品質を高める動きをチームに浸透させたい
内部品質向上にむけての具体的な行動記録の記事です
特にリファクタリングのタスクを起票することや、コード全体のLinterのエラー数などが増えていないことを検証することは、自分たちの運用にも適したやり方なように感じました
こういった目に見え辛い取り組みもしっかり行うことで、中長期で見ると効果が出てくるものだと思います!
今後話し合いながら、しっかりと目標を定めて取り組めるようにしていきましょう!
全社向けのValueをエンジニア向けに再定義した話
エンジニア向けのValueを定義した記事です
現在当社では全社向けに周知されたmission/vision/valueが存在しない状態ではありますが、役員間で持つvalueをエンジニア向けに具体性を持たせたvalueとして定義して周知、浸透させれば、今後向かうべき方向が明らかとなり、評価や舵取りがしやすくなると同時に、各エンジニアが当社にプラスとなる成長を遂げやすくなるのではと思います!
その他
新規事業開発を加速させるために重要なエンジニアの4つの価値観
どのようにユーザに価値を提供するまでも開発を行うかと言う記事になります
どこを丁寧に作り、どこを捨てやすく作るかという部分が特に開発をメインで行うエンジニアにとって重要な部分だと思いました
丁寧に作ることを大事なことではありますが、捨てやすく作るために疎結合を意識した実装をすることもまた、大事なことです
またそういった設計と同時に、捨てやすく作る、丁寧に作るの判断をしっかり行うことも大事になってくるので、やはりビジネル目線というのは大事だと思いました!
コードレビューをラウンドロビン方式に
コードレビューを機能面の動作保証を行わないラウンドロビン方式にしてみたという記事です
当社でもレビュー負荷が集中したり、レビュー待ちでブロックが発生したり、PRがいつまでも残り続ける状態になりがちです。
そのため村を横断する形でコードレビューを取り入れることで全社で品質向上を目指せるのではと思い、提案の意図も含め共有いたします!
To プロダクトチーム
ユーザー価値提供につながる開発とは?
ユーザーに価値を提供するための考え方の参考記事です
この記事で挙げられている内容は、自分たちに足りていないものが多く紹介されていたので共有いたします
主に自分が気になった点としては下記があります
- ユーザーに価値を提供するためのマクロ視点での分析
現在個社対応というN=1の限られた極小さな価値しか提供できない内容が多いため、個社ではなく利用者全体に価値を提供できるものとして開発優先度を考えなければならないと思います - 価値の検証
本当に使われている機能なのか、価値を提供できているのかということを検証して、その機能を拡張するのか、捨てるのかという判断が行われずに作りっぱなしになっている事が多いのではと思います - MVPでの提供
ビックバンリリースが多く、開発にもコストがかかり、価値提供まで非常に時間がかかるとともに、テストの時間も少ない事で甘くなり、バグも多くなるという負のスパイラルになっていると思いますので、もっとMVPを意識して仕様を定めるべきだと思います - 技術的負債の返済
数年間機能開発優先で行ってきた事で非常に認知負荷が高いシステムとなってしまっていますが、返済計画が一切無いので開発速度がとても鈍化しているのが現状です
最近は個々のタスクの開発レビューという形で少しずつ返済するようにしていますが、それ自体が負荷となって開発工数を圧迫しているので、ある程度のマイルストーンを区切って返済していかなければならないと感じています
To Intern
なんやかんやの検索に役立つ基本コマンド・テクニック
検索に利用するコマンドの紹介記事です
自分もよく利用する便利コマンドが記載されていますので、参考までにどうぞ!
共有するほどではないけど興味があったもので読んだもの
-
「いつ終わる?」から「何パーセントで終わる?」でコミュニケーションするアジャイルプロジェクトマネジメント
- 見積もりを予測、コミットメントを努力目標、ターゲットがビジネスで必要な時期という考え方をPdMやそれよりもビジネス側の人間が認識できると、全員のストレスが軽減されそう
- また達成確率を求める考え方は不確実性が残り、考える要素が多くなるのでマネジメントする側は負担になるが、いつまでと言う考え方は作業者を無理に働かせれば達成できると考えると考えるとマネジメントは楽にはなると思う。その分人は消えていきそうだが…
-
ロードバランサーを設置してネットワークをまるごと吹っ飛ばした
- 確かにL2以前になった瞬間知識がフワッとするので気をつけないととは思った
-
【2024年版】エンジニア必見!!おすすめYouTubeチャンネルまとめ
- 最近どこかで見たような記事だった
-
セキュリティエンジニアって200職あんねん(分類とキャリアの話)
- まずは資格取得を目指そうかな
-
JavaScriptの便利な構文に潜む罠
- 可読性は意識するべきだけど、想定データ量も意識したコーディングは必要
-
エンジニアの成長に技術力は必要条件であって十分条件ではない - 文系新卒エンジニアが大規模開発から得た技術以外の3つの成長
- チーム全体での最適解を目指すために、認識を合わせるコミュニケーションが大切だと感じた
-
OpenFeature で実現するベンダーフリーな機能フラグ管理
- OpenFeatureに則った実装でFeatureflagを管理するようにすると良さそうかも
-
テスト管理ツールCATが開発された背景とは?
- テスト進捗の管理はPMだけでなく、開発エンジニアにとっても何か問題がある時に気づく事ができるので役立つツールかと思った
-
CAT・TD開発者によるCAT活用体験記
- 自由度というのは慣れて使いこなせる人にはありがたいが、不慣れな人にとっては障害となる。それをどう汲み取って開発するかが難しいと思う
-
今、リモートワークについて思うこと
- リモートワークの難しさは確かにあるが、拠点を跨ぐ人がいる時点でオフィスワークも在宅ワークも変わらないなと思う
- ただオンラインミーティングの難しさは、ファシリテータをやると特に感じる部分ではある
-
開発者向けドキュメントの改善のその後
- 開発者向けのドキュメントは必要だと思うが、ドキュメントの作成には手間がかかり、その時間を捻出できていない問題がある
-
統括マネージャー(EM of EM)の仕事7選
- 今後こう言ったことを考えながら立ち回る必要もあるかも
-
キャリアの大半は偶然によってできている - Fenrir Engineers
- キャリア形成は偶然の積み重ねだとは思うが、言葉にする事である程度誘導はできる類のものだとも思う
-
ドメイン駆動設計をはじめようを読んでみた
- 一冊紹介系の記事は冗長になりがちだが、この記事は良い感じにまとまっていて、実際の本を読んでみたいと思った
-
今から始める NeoVim 生活 (序章)
- Vimは慣れると色々便利
-
NeovimでGitHub Copilot for Businessを有効活用しよう
- CopilotChatが使えるようになっていたのは知らなかった
-
VPoEを引き継ぐ技術
- VPoEに限らず引き継げる状態を普段から作っておくのは大事かもしれないと思った
-
良いシステムを設計するには
- メリット・デメリットの洗い出しはまず大前提として、とりあえず少し触ってみる、使ってみる、というのも大事そう
-
「改訂新版 良いコード/悪いコードで学ぶ設計入門」を使ったリファクタリングの事例
- 自分たちの勉強会も一通り読み終えたら実践方式で改善することを取り入れるのも良さそうかも
-
セキュリティチームの日々の取り組みの紹介 (10X アドベントカレンダー 2024)
- 外部セキュリティアドバイザーとの相談会ができる環境はとても良いと思った
-
エンジニアとして大きな変化があった1年、でも変わらなかったこともある。
- 他人を頼るということはとても難しいことだと常々思う。信頼関係を築き、心の壁をうまく壊していく必要があるなと改めて思った
-
エンジニアの能力・給与・尊厳
- 給与は運の要素が大きく影響していると自分は思う
-
Makefileの基礎的な活用方法
- たまに使う。結構便利
-
教え上手の第一歩: 相手の心に響く教え方
- 自分にとっては特に理由の部分が大事だったりする。「一般的に」「普通は」で片付けられるとモヤっとするが、自分も使いがちなので気をつけたい
-
ペアプロが嫌すぎて会社を退職した話
- コミュニケーションが負担になる人がいるというのはどうしようもない部分ではあるけど、コミュニケーション次第でこのデメリットは解決できるように思った