随時追加します。
最高エンジニアの思考法
この本のエッセンスは上記リンク等に書いてあるが、それ以外の部分で
優先順位をつけて、「やらないこと」も作る
プログラムの解説を設計書ではなく、解説動画で残してシェアしている
個々で開発している場合、開発チーム内の業務内容のシェアを行う
何かを変えたい時は、「住むところ」「付き合う人」「時間配分」のいずれかを変えるべき
「生産性を上げるためには学習だよ。だから、僕は仕事を定時くらいで切り上げる。その後で、自分のやりたいトピックを勉強したり試したりする。」
朝方の生活にシフトして、朝起きてから就業前までの数時間を学習の時間に充てる
理想の事が書かれていた
ウォータフォールはやめて2024年の開発をやろう！
1. 開発プロセス
会社で共通の開発プロセスとかは定義されていません。各チームが自分たちなりに好きに決めてやります。標準もありません。
フェーズも見積も無い
筆者のアジャイル開発では、優先順位も変わるし難しさもやってみないと分からないという事実に向き合ってる
無理くり工数を出しても意味がないという経験に基づいている
開発の状況は現場によってすべて違うし、開発しているものによっても異なるので、自分たちで考えて、試して、フィードバックを得て少しづつ改善するしか手がありません。
もちろん他の会社がどんなやり方をしているだろう？と学ぶのはもちろん有効だと思います。
でもあくまで主体は自分たちのチームだと思います。
「このやり方でやれば一発解決」みたいな方法があると思っていたのは幻想で、
実際は現状を少しずつ（俯瞰して見たら効率が悪そうに見えるやり方でも）その時点そのチームで良いと思えるやり方を地道に試すしかない
一気通貫で変えないと意味無いのではなく、ベストだと思える方法から1つずつ実行して行くのは正しそう
2. チーム
Buddy 制にしていて、１つのコンポーネントに対して２人いる感じになっています。
これは、休暇を誰かがとてっても問題ないようにとか、PullRequestのレビューで、誰もレビューが出来なくて承認されないとかの問題を防ぐ効果があります。
個人開発というのは同じだが、
1つのサービスに対して1人の専任ではなく、主副の担当を用意するのはやはり良さそう
3. ドキュメント
自分の負荷を減らすためにも重要です。
自分が整理するため、他の人に渡すために、楽をするために、アーキテクチャのドキュメントを自ら書くことはあります。
ただ、強制とかプロセスで決まっているとかではありません。
誰が見てもわかる正確なドキュメントを作成、維持するのではなく、
自分たちの理解促進のための最小のドキュメントが良い（労力が効用を超えないレベル？）
現役シリコンバレーエンジニアが教えるアジャイル開発（Udemy講座）
チームワークを重視する分、チームワークを意識してくれない人が入ってしまうと上手くいかない
アジャイル以前の問題、マインドセットの問題は開発手法とは別の問題
人の性格を変えることはできないし、それぞれのワークライフバランスを崩す事はできないし、
結果、仕事へのコミット＝人の行動を変えることもできない
上記、『世界一流のエンジニアの思考法』でも圧倒的にアジャイル開発が推奨されている（ウォーターフォールはするな）という記載があったが、
上記の個人事業主やマネージャーの話も含めてすべて人中心の考え方で個々人のパワーに頼った話で、
良きプログララマー、開発者がメンバーだからこそ成り立つ話でもあるのかなと思える
まだ一人前ではない開発者の集団に対して、本書でおすすめされていた方法を取ると、
実際にはスキルややる気の問題でうまく行かない気がするので、ある程度マネージメントやWBSのような期限設定やタスク管理は必要なのかなと
（スキルはエキスパートに聞け、やる気はマネージャーが出させろという話だが、エキスパートやマネージャーの負担が大きくなりバランスが悪い）
リーダーの仮面
この本で定義されるリーダー像には共感できないポイントもあったが、
以下の1on1と朝礼は実践し有意義だった
■1on1
毎週メンバー内での情報共有の時間を設ける
・先週一週間で成長したと思うこと
・目的・目標への立ち返り
・大切にしてほしい価値観のメッセージ
忘れてはいけないのは「一人一人が目的・目標に立ち返り、行動・チャレンジしていくことを動機づけられること」
■朝礼を設定する
朝礼を行うことで、メンバーの中で今日一日の流れと最重要目標を考えておかなければならない気持ちが醸成される
自然と考えを巡らせるようになり、一人一人が目的・目標にフォーカスするような育成の機会になる
・各メンバーの進捗共有
・アクションプラン（今週絶対にしてほしいこと）への落とし込み
・組織として取り組む課題を一斉にその場で実行する時間（書類提出など）
・チーム内での好事例の共有
部下をもったらいちばん最初に読む本
期待値を「相手のライン」に合わせる
チームメンバーを自分のレベルで仕事ができると考えてしまってはいけない、求めてはいけない
マネジメントは、メンバーを管理する仕事ではなく、メンバーを仲介して仕事＝成果を作ること
部下を自分の思い通りに動かそうとしてはいけない
JSTQB（テスト技法）の勉強から
テストは、技術的な活動だけではない。適切に計画、マネジメント、見積り、モニタリング、コントロールすることもまた必要となる（第 5 章参照）。
テストは技術的な活動に留まらず、マネジメント部分の活動も数多く存在する。
QCは、適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチ（開発者視点）
QAは、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチ（お客座視点）
シラバスの読解から話は逸れるが、第三者検証の企業は
発注側が自社でテストを行うリソースを確保できず、テスト設計〜実行の部分のみ外注する経緯もあり、QC寄りの業務が多い。
テスト分析（何をテストするか）とテスト設計（どのようにテストするか）
テスト分析の作業成果物には、（優先順位を付けた）テスト条件（例えば、受け入れ基準な ど、4.5.2 項参照）、およびテストベース内の欠陥についての（直接修正しない場合の）欠陥レ ポートが含まれる
テスト設計の作業成果物には、（優先順位を付けた）テストケース、テストチャーター、カバ レッジアイテム、テストデータ要件とテスト環境要件が含まれる。
アジャイル開発の手動テストのほとんどは、事前の大規模なテスト分析やテスト設計を必要としない経験ベースのテスト技法（4.4 節参照）を使用して行われる傾向がある。