2025-02-26 共有記事ログ

概要

現職の開発部のメンバーに共有した記事のログ

マネジメント系

技術者のキャリアを考える

技術者のキャリアには3つのパターンが存在するという記事です
自分はスペシャリスト希望の2軸目はリーダーかなと考えております！
皆様はいかがでしょうか？
それぞれのキャリアの考え方の一助になるかと思い共有いたします！

その他

言葉のズレが生むすれ違い―どう埋めていくべきか？

同じ言葉でも認識が異なる場合に、どう向き合っていくかを示した記事です
言葉の認識に違いが出たときはその意図を確認して、深堀りしながら理解するように気をつけると良さそうですね！
そして相違する場合の共通点を探すという視点は抜け落ちがちなので意識してみると良さそうです！

SLI/SLO 完全ガイド

SLIとSLOについての導入に関して解説している記事です
SLIやSLOというものは言葉としてはよく聞くかと思いますが、実態としてどういうものなのか知らない人も多いかと思い共有いたします！
当社ではまずアラートを整えることからですが、外部に約束するためにもしっかり数値化して監視する必要がありますね！

To プロダクトチーム

新規機能開発におけるユビキタス言語のパワー

ユビキタス言語がどのように管理・運用せれているかの実例記事です
自分たちはこれの運用に失敗してしまいましたが、うまく活用できると認識の違いが生まれることを未然に防ぐことができ、コミュニケーションが円滑に進むと同時に、業務効率も上がるものだと思いましたので、再考する余地があるのではと思いましたので、共有いたします！

伝えたことを意図通りにやってもらえない原因は私にあった

相手に正しく意図を伝えるための考え方の記事です！
自分の認識通りに意図を伝えることは難しいですが、文章で残す・口頭で補足・目的を共有など、相手によらずできる努力がある内容だと思い、共有いたします！
自分自身とても気を付けなければと思いました。。

不確実性の高いフィーチャー開発においてやってよかったこと3選

大きなスコープの開発で、本当にユーザに価値を届けられるかわからない内容の開発時の取り組みの紹介記事です
自分が共有する目的としては「ユーザの価値」という部分ではございませんが、ここに記載されている「概算見積」について開発以外も含め部内で検討しても良いのではと思い共有いたします！
具体的には、「チーム全員での見積もり」と「ストーリーポイント」という点です

チーム全員での見積もり

開発業務とサポート業務などで理解の差があるため、「チーム」は部内で分ける必要があるとは思いますが、一人だけの認識では抜け漏れが発生したり、今の状態を正しく把握できていないことでの過剰な見積もりが発生することもあると思います
そういったことを補い合うために、どれくらいの時間がかかるのかというものを複数人で認識を合わせながら行うのが良いのではと思いました

ストーリーポイント

これは主に開発に影響する話ではありますが、どれくらい時間がかかるをある程度の精度を持って出すためには、かなり深く仕様書を見る必要があります
しかしそれでは見積もりだけでもかなりの時間を要することとなり、たとえすぐに着手しない、もしくは永遠に着手しないものでも見積もりに時間がかかり、業務を圧迫していくことになります
そのため基準値となる課題を設けて、それに対してフィボナッチ数を用いてどれくらいかかるかを表現していくような見積もりの方が良いのではと思いました！

具体的には下記のような運用となります！

1. 各課題のストーリーポイントを見積もる
2. そのポイントと課題の価値を参考に優先度を決める
3. 開発期間中に優先度が高いものから時間レベルでの見積もりを行う
4. 時間的にそのタームで開発が完了しない可能性が高い場合に優先度の入れ替えを相談する
5. そのタームで行う努力目標が決定する（約束ではない）
6. 開発も原則優先度が高いものから順に行う

To Intern

フィードバックの受け止め方で成長が決まる！就活と社会で求められる「素直さ」

フィードバックの受け止め方に関する記事です！
フィードバックを得られることは新人だけでなく中堅以降にとっても成長の機会というのは間違いないと思います！
なんならそのうち求めてもなかなかもらえなくなってくることも…
素直に相手の意見を受け入れた上で、納得できていない部分は深掘りして理解を深めると、より身になると思いますので、どんどんフィードバックをもらえるようにコミュニケーションを取っていきましょう！！

共有するほどではないけど興味があったもので読んだもの

• 「就活の面接は嘘つき大会？」—半分本当で半分嘘の理由
  • 背伸びをした姿を見せる。これは大事そうだと思った
  • 逆に面接する側は成長した姿として捉えた方が良さそう
• インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
  • スライドにするには字が細かすぎないか？字が小さすぎて見辛い
  • 組織全体の技術力と生産性の向上に寄与することを経営者に知ってもらえると、より動きやすくなり、良い環境を作り上げれそう
• 面接はマッチングの場。目的を知って対策しよう
  • 言葉足らずな面接官にも問題はありそうだけど、何を知りたいのかを汲み取って話せる能力がある人は面接という場では強そう
  • 直接会話する面接ではなくて、文章で提出してもらう方が本当に知りたいことをしっかり考えて回答してもらいそうだと思った。代理回答の判別が難しいかもしれないがw
• 【2025年版】モダンな開発用ターミナル環境のためのツール紹介
  • 参考にする
• Githubのプルリクエスト単位で動作確認用のURLを発行する
  • せっかくDocker環境で開発しているのだからECSとかつかってこういう環境を構築できると良さそう
• スクラム入門 - ROXX開発者ブログ
  • アジャイル開発を開発以外が含まれるプロダクトチームで取り入れるのは、なかなか初期のハードルが高そう
• メールアドレス以外の識別子でログイン！ログインIDユーザー機能の開発舞台裏を紹介します
  • 当社のプロダクトでも役立ちそうな考え方かも
• 社会人と学生の違いは「能力」ではなく「成果の出し方」と「学び方」
  • 学生時代の成果を言語化するのはなかなか難しいけど、今の時代はAIが良い感じに言語化してくれそうで難易度は下がってそう
• 自分ばっかり大変と思ってるときは気をつけたほうがいい
  • 確かに生んだ価値という点を客観視するのは大事
• 言葉遣いからわかる人間関係とポテンシャル
  • いままであまり意識してこなかったけど、そういう視点で見られているのかと反省
• Findyの爆速成長を支えるエンジニア教育メソッド ~ 育成ノウハウの一部を初公開 ~
  • 新人エンジニアが増えると、こういった先人の知恵を借りながら教育していく必要がありそう
• エンジニアのカジュアル面談でよくある質問 ~ 技術や組織、開発について
  • MVV に共感できる人にとっては楽しいという言葉があるように、やはり定めたほうが良さそうに思うが…
• エンジニアのカジュアル面談でよくある質問 ~ 働き方や福利厚生について
  • 個人開発費にも補助が出るのは嬉しい
• 就職活動で考えるべき好き・得意・お金・やりがいのバランス
  • バランスは大事だよなと思う。ただ好きと得意がお互いに影響し合うように、お金によって得意が延びるなどあると思うので、ある程度の妥協もあっても良いのかもしれない
• DBマイグレーションの安全性を高めるガードレールの実践
  • Index を触るときなんかは気をつけないと長時間ロックされてしまうことがあるから、こういう取り組みを取り入れるのもありかも
• 「年収を決めるのはスキルじゃない？」無視できない『成果のレバレッジ』という視点
  • 日本企業は結局マネジメント職が影響力が大きく利益を出しているという考え方をするから、スペシャリストが海外に流れていくんだろうなと思った（あくまで想像でエビデンスがあるわけではない）
• え？本買ってるの？？もっと良い方法あります。
  • ChatGPTのこういった活用方法もあるのかと感動！
• 期限が遅延してしまう要因を分析してみた
  • 期限が遅延するという問題に対しても、それに対応するための時間は必要だろうなと思った
• KubernetesはOCI, CRI, CNI, SMI, CSI, CDI, NRIこれだけを理解すればいいから簡単に学習できます
  • k8sをただ使うだけでなく、使いこなすために必要な知識かも
• 先輩の無慈悲な「ドキュメント読んだらわかる」発言に物申したい
  • ピンポイントに特定の問題を解決したいときは公式ドキュメントは情報量が多すぎて困る
  • 逆に網羅的に知りたい時やチュートリアルが欲しい時は公式ドキュメントはとても役立つ
• コミットメッセージのルールついて
  • コミットルールは賛否両論ありすぎてどうするべきなのか難しい