新しいチームでTypeScriptに素早くキャッチアップするためにやったこと - KAKEHASHI Tech Blog
カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回は、私が TypeScript をメイン言語として採用しているチームに参加した際、言語や周辺技術のキャッチアップを行った方法について紹介します。 この記事は秋の技術特集 2024の 3 記事目です。 この記事の想定読者 私が元々持っていたスキルセット 認知負荷の増加 TypeScript 学習のためにやったこと 学習の進め方 テックリードとの 1on1 の中で壁打ちや相談 ペアプログラミング 輪読会 もくもく会 学習コンテンツ O'Reilly Online Learning を使った学習 TypeScript Deep Dive プロを目指す人のための TypeScript 入門 安全なコードの書き方から高度な型の使い方まで type-challenges 公式ドキュメ
情報の見つけやすさを追求する - 社内ドキュメンテーションの階層整理術 - KAKEHASHI Tech Blog
カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回はチームに配属されて数ヶ月の私が、いかにして社内ドキュメンテーションの階層構造を整理し、情報の検索性を向上させたかについてお話します。 はじめに この記事の想定読者 課題意識 メンバーへの共有と相談 社外事例の調査 esa の階層整理 第 1・第 2 階層の整理 ストック情報とフロー情報を意識した階層の整理 esa の機能をフル活用する 効果や今後について はじめに カケハシでは全社的にドキュメンテーションツールとして esa - 自律的なチームのための情報共有サービス を利用しています。それぞれのチームやプロダクトごとに階層を切ってドキュメントを書いています。 プラットフォームチームでは認証基盤などの社内プラットフォームシステムを開発しているため、自チームが運用する各種
アーキテクチャの進化はドメインイベントが起点になる - KAKEHASHI Tech Blog
こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性
目標管理と評価制度の考え方 - KAKEHASHI Tech Blog
本エントリはカケハシ Advent Calendar 2023 の 11日目の記事です。 今年はPart2もあるのでぜひそちらもご覧ください！ カケハシのVP of Engineeringの湯前（@yunon_phys）です。皆さん、目標設定と評価は順調ですか？私はこれまで何年にも渡って、様々なメンバーの目標設定や評価をしてきました。残念ながら、こうすれば良い目標設定や評価が出来る！という銀の弾丸は無さそうです。でも、こう考えたら目標設定はやりやすいかも、こうすると評価はより納得感のあるものになるかも、というのはあります。 そこで今回は制度を施行・運用していく立場の人間として、目標管理と評価制度の考え方について、私の意見を述べていきます。 目標管理 目標はそもそも変わるものである みなさんこんなことありませんか？ やる気満々であんなことやこんなことを色々考えて、壮大な目標を期初にがんばって
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
