はてなブックマーク

IC (Individual Contributor) とは？ マネジメントの責務のない専門職 単に「管理職（マネージャ）」との対比として用いられることもある ICだからといって管理職に必要とされるスキルが全く不要というわけでもない キャリアパスとしてE1（下位）~E7（上位）のように求められるスキルにより職位が定義されることがある 職位が上がるにつれプロジェクトリードやマネジメントが求められる ICというのは、単に部下を持たないということ 日本ではICの定義が曖昧 上級エンジニアを連想する方も少なくない ICはチームや人のマネジメントをしない技術のスペシャリスト 自分の役割は制約しすぎない方が良い 開発するものに対して主体的に関わっていく必要がある（ただの作業者に陥ってしまう） ICとしてキャリアアップしても、テックリードになるわけではない テックリード的な役割を任されているエンジニアも

概要 2021/11/24に開催された下記勉強会のメモです セッション イミュータブルデータモデルの極意 データの種類 Event -> 日時属性を持つ Resource -> ライフサイクルで属性が変わる イベントの7W3Hがリソースと関連を持つ リソース同士では依存関係があるか？ライフサイクルを同じとするかで場合分け リソースのサブタイプは「区分」で分類 イベント同士の関係は時系列の並びで関係が変わる。時系列は変更してはいけない 例）注文に請求IDを保持、請求が決まった時に更新だと後から情報を変えてしまう事になる->中間テーブルを使う イベントが連なる場合はそれらを束ねたロングタームのイベントを作る リソースの関連とそれに関するイベントは別で識別する どのイベントを記録として残すか、が設計 お金を産むもの、記録がないとお金を失うリスクがあるものを取捨選択 記録すると決めたイベントは変更

概要 2021/10/29に開催された下記勉強会のメモです セッション RDRAはどう形作られたか？ RDRAの構造 4つのレイヤーと依存関係 WhatとWhyを表現->要件定義ではこの2つを明確に Howは表現しない->Howを考えると手が止まる ビジネスユースケースでボリュームがわかる 打ち合わせの回数、時間など計画が立てられる RDRA導入後の要件定義の変化 ※公開資料見つかりませんでした 課題 プロダクトの業務仕様管理 業務仕様の把握・管理の属人化が進行 変更差分で全体像が把握できない 要件定義プロセス そもそもよくわかっていない RDRA導入 RDRAモデルによるサービス仕様マスタの作成 RDRAの要素を要件定義書フォーマットへ反映 改善事例 ビジネスユースケース(BUC)の定義活用 BUCをプロダクトの業務として定義、プロジェクトごとに共通単位として利用 BUC視点で話すと伝わ