開発者としてのプロダクト開発のフォーム、開発の仕事

継続的にプロダクトを開発するという前提で、開発者がどのようなメンタルモデルを持つとよいか、ということを整理します。守破離の守のフェーズにあっては、一旦受け止めてもらったうえで、破離のフェーズでは自分としてどうするかを考えていくのがよいと思います。
主に私の記事へのリンク集になっています。上から順に読み進めていく想定ですが、特に足りないことや気になることがあれば、まずそこから見ていくのもよいと思います。

学習・習熟の必要性、メンタルモデルの概念の獲得

まず、開発の業務を円滑に行うには、開発の業務を学習・習熟する必要があります。この学習という行為をメタ的に整理し、「メンタルモデル」という概念を持つことで、「物事を理解すること」についての話がしやすくなります。

★必須
プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ(amazon)
「プログラマー脳」の本の感想と賛辞 〜 意味波と具象と抽象と
※メンタルモデルの概念を獲得できれば概ねなんでもよいのですが、学習・習熟という観点でもプログラミングに関わることで具体的に言及されている本書は有効です。
仕組みか個人か、という不毛な論争の答

特に学習に興味がある場合はおすすめ
学力喪失──認知科学による回復への道筋（今井むつみ著）
学ぶ力の正体と、その影響 - 学力喪失を読んで

開発の仕事についての基礎となるメンタルモデル

開発の仕事とはなにか？ということについての、基礎となるメンタルモデルを構築します。これは、スポット的に開発に関わる人や、「指示された実装作業をする」という人の持つメンタルモデルとは根本的に大きく異なります。 長期的にプロダクトを開発する、あるいは将来的にプロダクトオーナーに近い立場で、自主的に対象について考えながら開発をするという前提で、長期的な効率を維持するために必要な考え方をまとめています。

★必須
システムをつくるということ
合意とはなにか - プロジェクトの合意形成、プロダクトの合意形成
価値を創出する、ということ
技術的資産としての良いコード - 蓄財のメンタルモデル
エンジニアとビジネスと、の手前の話 - あなたの給与はどこから？
事業についての継続的な学習や、システムが作り出す世界についての継続的な学習が必要となる話（そのうち書く）

チームによる開発についてのメンタルモデル

開発をチームで行うということはどういうことなのか？というメンタルモデルを構築します。ざっくり、認知が合わないと全く成果を挙げられない構造があるので、まずは認知を合わせようということと、それによってチームとして個人のできることの幅を広げられるようなあり方を目指したい、ということがあります。

★必須
知的な仕事の量と深さ - 10倍の成果とIQ、執念、知識、認知
学習・認識合わせ・失敗・作業量あたりのメンタルモデル
個人の向き合いを支えられるチーム - 混乱期の先にあるもの
「差し戻しをするとうまく承認できない問題」とどう向き合うか
チーム開発で成果を出す - 作業指示道からの卒業

学習についてのメンタルモデル

これまでに示したメンタルモデルや考え方によって、学習をするということが極めて重要なことがわかります。学習することについても、メンタルモデルを構築する必要があります。

★必須
システム開発と教育におけるアンラーンの重要性
成功と失敗、学習と混乱 - 混乱を乗り越えるには
その勉強、いつまでするの？ - 学習完了の定義
進む学習と進まない学習 - 学習を完了させるには
「質問しろ」「自分で考えろ」のダブルバインドのメカニズムと解消法
叱ることと褒めること。いつワークして、いつワークしないか。

コードについてのメンタルモデル

開発者の具体的な仕事であるコードを書くということについてのメンタルモデルです。蓄財のメンタルモデルもこれに該当しますが、冒頭で挙げているので省略しました。実際には、さらに深い具体的なコードの書き方について、レビューを相互に実施しながら練習することが重要であると思います。

★必須
汚いコードの害を伝えたいだとか
汚いコードと対処法 - 君はコードなんか汚いと思いながら
消耗せずに「良いコード」とはなにかを考える

発展
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
致命的な障害を減らすための可用な設計入門 - 設計と算盤
ラーメンの構造に学ぶ、コード設計 - そこに汎用性はあるんか （≠Rahmen編）

問題解決・プロジェクト推進のメンタルモデル

プロダクトの開発をしていると、時に問題解決やプロジェクト推進の技術が必要となります。一般的な仕事の仕方のようなことも含むメンタルモデルを構築します。

★必須
新卒の頃に思っていたこと、気づいたこと
問題解決ブルドーザーと認知の構造 - 便利なアンラーン
0→1とか1→10で知っていると得すること - 執念と知とMP
目指せ高付加価値！アジャイルにおけるフロー効率・リソース効率とは？徹底解説。

発展
「毎回自分の意見が通ってしまう」時に起こることと対策
ピーターの法則を避けるいくつかの方法、あるいは「ビジネスのわかるエンジニア」として望まれていること