tl;tr

マジで！！マネジメントとか適当な言葉に逃げて、
「エンジニアの仕事したいからマネージャーの仕事したくない」じゃねーよ。

それって、エンジニアじゃねーから
マジで！！駆逐してやる。１００倍返しだ！！

とか過激な発言、行動は控えつつ「何かよくして生きたい」ための、準備のやつですね。はい・・・

やりたいこと

開発プロセスについて議論したくないので、大体落ち着くところを決定するフローチャート的なのを作りたい
開発プロセスの選択よって、必要なメンバー役割とスキルセットを決定したい
取り組む課題、問題のスコープを合わせるツールとしたい

特記事項

フローチャートにはまらない場合は、それ自体が重要な課題として認識できればいいはず（と信じたい）
小規模システム（関係者が片手間で終わるみたいな範囲のこと）ならどうでもいい事なのだろう

概要

フローチャート作成に向けて、３点について記載しています。
内容は下記の内容です。合致しない条件の方は本ページは参照してもプロセスに決定にたどり着けないと思います。

「誰が考える？」⇒ 対象の人はこの人
「大枠の考え方」⇒ ポイントはこれです
「プロセス再考」⇒ カバー範囲はこれです

結論はこちら（フローチャート）となります

考える人って誰だっけ？

エンジニアリングとは

Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations.

ソフトウェアエンジニアリングとは

Software engineering is the application of engineering to the design, development, implementation, testing and maintenance of software in a systematic method.

マネジャーの仕事とは

計画を作り、組織を作り、動機付けを与え、指示を与え、そして統制を行う。さらに、先見性、秩序、目的、努力の一本化、及び有効性などを他社による貢献を加味する

上記を下記に要約します。

エンジニアリングは、知識を応用して改善すること
ソフトウェアエンジニアは、設計-実装-テスト-保守までをエンジニアリングする人
ソフトウェアにおけるマネージャーの仕事 ≒ ソフトウェアエンジニアの内容

これ等から、後の説明での便宜上分類をします

「初級エンジニア」設計、コーディング、テストくらいの職務範囲と考えている人または、それらまでを実行できる人
「シニアエンジニア」ソフトウェアエンジニアリングを職務範囲と考えている人
「上級シニアエンジニア」ソフトウェアエンジニアリングを職務範囲と考え、実行できる人

分類から考える人は「シニアエンジニア」以上の方を対象としています。
「初級エンジニア」の方は、厳密にはプロセスの議論をしてはいけなくて、観察対象としての存在になります。ここでの観察対象とは「発言内容」自体も関心事になり機能構築を行えないと言う意味となります。

大枠の考え方

要素：ビジネス要件（ビジネスモデルとか含む）、組織構成(コンテキスト)、開発プロセス、メンバー役割、文化

の要素で考えます。それぞれの関係は下図になります。

これだけだと以下のような状態を生み出すと思います。

制約的な意味で「文化」の要素を追加して開発プロセスを検討したいと思います。

開発プロセス

ウォーターフォール / Agile開発 / Scrum / DevOps の４つのプロセスを範囲として、各プロセスについて「ビジネス要件」「組織構成」「文化」の３つの視点で理解したいと思います。

ウォーターフォール、Aglie開発、Scrumまで以下にまとめました。

ウォーターフォール/Agile開発
- チームレベル：初級エンジニア
- 備考
  - PM的な人とPGがいればなんとか回る
  - Agileマニフェストとか原則無視しても大丈夫
Scrum
- チームレベル：シニアエンジニア（初級レベルを脱していれば良い）
- 備考
  - 改善の仕組みが組込まれているので、シニアエンジニアの素養がチームに備わっていないといけいない

DevOpsについては、Scrumと対比して以下にまとめました。
DevOps関連の書物では、要素については文化的な記載があると思いますが、やるかやらないの判定はビジネス的要因が強いと判断して、ビジネス要件の領域にしてあります。

DevOps
- チームレベル：上級シニアエンジニア
- 備考

フローチャート

あとがき

議論を回避できないのだろうという結論に至るのであった。

参考リンク