個人的にプロセス改善に関して有益（後から見返したい）と思った論文・資料等を列挙しておく。
随時、追加・更新していく。
論文・資料
清水吉男，「硬派のホームページ」
清水吉男，「Index of "Software Process について"」，2006
https://affordd.jp/koha_hp/process/Proc.Index.html
清水さんがSoftware ProcessとCMMについて語られている。
清水吉男，「これまでの「標準化」の間違い」，2003
https://affordd.jp/koha_hp/process/Proc.WhyStd.html
「プロセスを設計する能力」の必要性について述べられている。
清水吉男，「ＰＦＤ（Process Flow Diagram）の書き方」，2009
https://affordd.jp/koha_hp/process/PFDform3.pdf
清水さんが提唱されているPFDの書き方が解説されている。
Kouichi Akiyama，「35号：PFDの使い方」，2019
https://note.com/akiyama924/n/n033ae30a0cf2
秋山さんが清水さんとPFDについてお話されたことが示されている。貴重な記事。”シミュレーション”が大切なキーワード。
安達賢二，猪股宏史，「問題構造分析とPFDの併用による現実的・段階的な改善実践方法の提案～PFDを使いこなす能力を確実に身に着けるために」，派生開発カンファレンス2013，2013
https://affordd.jp/conference2013/xddp2013_p8.pdf
安達さんの提案。問題構造図は確かに有益だと感じる。
安達賢二，「「プロセス改善2.0」入門編 これから求められるプロセス改善のあり方」，ソフトウェア品質シンポジウム2019 チュートリアル1，2019
https://www.software-quasol.com/sapid3-0/
SQiP2019併設チュート_プロセス改善2.0入門.pdf
プロセス改善において、「まずは当事者の困り事の解消から始める」という一見当たり前に思える言葉が重要。
takashi4233，「ハードウェア設計とソフトウェア設計の違い」，2008
https://takashi4233.hatenadiary.org/entry/20080426/1209164094
https://takashi4233.hatenadiary.org/entry/20080506/1210042025
https://takashi4233.hatenadiary.org/entry/20080511/1210513408
ハードウェア設計とソフトウェア設計の違いが考察されている。興味深い。
試作の回数をこなすにつれてハードウェアは精度を上げていきます．
試作の回数をこなすにつれてソフトウェアは機能を追加していきます．
上記の違いは面白いです。
ハードウェアの設計の進め方は、ソフトウェアの設計の進め方を考えるときに参考になることがあるかも。ハードウェアの設計の進め方に、興味を持っておくとよさそう。
昔、清水吉男さんに、「ものごとを理解するときには、比較をしなさい」と教えていただいたことを思い出します。
石山康介，後藤孝一，「なぜなぜ分析について考えよう～楽な楽しい原因分析へ～」，SWEST19，2019
https://swest.toppers.jp/SWEST19/program/pdfs/s1c_proceeding.pdf
原因分析の参考資料。以下の資料の最終ページに参考文献があり、それも参考になる可能性大。
金子龍三，「原因分析「プロセスネットワーク分析法（PNA）」の勘所 品質マネジメントシステムの原則に基づく原因分析法」，Quality One Vol.8 2009年11月号，2009
http://www.juse-sqip.jp/archives/vol8/qualityone_01.html
金子さんとお話するのは本当に楽しい・刺激的。原因分析をするときにPNAっぽいものを作るのは確かに有効。
@kaizen_nagoya，「仮説・検証(12)プログラマが能力を発揮できる１６の条件」，2019
https://qiita.com/kaizen_nagoya/items/94538999a4edfe1332ef
エンジニアに能力を最大限発揮してもらうためのプロセス改善（工夫）をしたい。
@kaizen_nagoya，「仮説・検証(10)「共有」と言って良い時」，2019
https://qiita.com/kaizen_nagoya/items/b554d24193f38740ce6a
「共有」って響きよい言葉としてよく使うが、普段の業務でも注意して使いたい。共有と言いながら、編集することを許していない（権限がない）ことがある。
「共有しているのであれば、誰でも変更できる。変更できないのに、共有という言葉を使うべきではない。」と考える。
情報共有の仕組み、資産共有の仕組み、リソース共有の仕組みを、これから組織として、再構築していくと思いますが、そこでも注意したい。
藤原啓一，「要求・要件仕様を効率的、高品質に作成する方法 －経験的設計ルールを継続反映させながら使うモデルベース要件定義フレームワーク－ 」，MSS技報 Vol.29
https://www.mss.co.jp/technology/report/pdf/29_03.pdf
この論文すばらい。
- 開発の進め方を、しっかり言語化している。
- 使用している用語が定義されている。
- 作業と成果物の関連が示されている。
- 一般化されている技法を使ってる。
- 例が示されいる。
- アンチパターンが示されている。
- 参考文献が示されている。
自分のプロジェクトの開発の進め方を、この論文と同じような粒度で、言語化し、共有したい。言語化するということは難しいが、言語化することを通して理解が深まる。言語化できないということは、十分に理解しきれていないということ。
方法論は進化し続けるし、完成しないし、知ったらできるものではなく、意識して訓練して習得するものと考えると、文書化して伝えることが目的ではなく、文書化して議論することを目的にするとよいのかも。
対象工程の経験者全員が、自分の知識を文書化し、共有し、新たな知見を得るというサイクルを回し続ける仕掛けがあるとよいのかも。
結局、SECIモデルのようになるのかも。
波田野裕一，「運用自動化、不都合な真実」，ssmjp 201712 はたのさん祭，2017
https://speakerdeck.com/opelab/20171212-automation?slide=35
自動化に関して重要なポイントが述べられている。
野中誠，「今さら聞けないソフトウェア品質データ分析の基本」，ソフトウェアエンジニアリングシンポジウム2014(SES2014)，2014
http://www.se.mng.toyo.ac.jp/wordpress/wp-content/uploads/2014/09/SES2014-tutorial-nonaka.pdf
SQiP研究会で野中さんからご指導いただき、"不具合"、"欠陥"、"誤り"等の用語を使いわけるようになった。機能性欠陥と発展性欠陥という分け方は好き。
Kouichi Akiyama，「48号：エラー・欠陥・故障」，2019
https://note.com/akiyama924/n/n3177be19c3b4
エラー・欠陥・故障の違い・関係が説明されている。
ジャバ・ザ・ハットリ，「イーロン・マスクのロケット製造５つのステップがサイコーだった」，2021
製造工程を極めるための５つのステップ
ステップ１ 要件定義にあるバカさ加減を少なくする
ステップ２ プロセスをできるだけ削る
ステップ３ 最適化
ステップ４ 高速化
ステップ５ 自動化
@kyon_mmさんも、同じようなこと（「面倒なことを見つけたときに、すぐに自動化するな」）を言ってた記憶・記録あり。
外務省経済協力局民間援助支援室，「どう終えた？どう終える？プロジェクト撤退のポイント」，2004
https://www.mofa.go.jp/mofaj/gaiko/oda/shimin/oda_ngo/shien/pdfs/04_kyoiku.pdf?fbclid=IwAR2brYULS5bzJ5v72_VMxwD7mNNzGoeKk0RNOP9gFbTQcYjSMToj0yThH3Y
プロジェクトの終わらせ方については、学んだり・考えたことがなかった。
maccos，「スケールドメテオフォール開発」，2019
https://hogepiyohoo.hatenablog.com/entry/2019/07/07/003625
面白い(笑)
関連記事
プロセスアセスメント
Vモデル
PFD（プロセスを設計する）
USDM
アーキテクチャ設計
プロダクトライン開発
HAYST法
コードメトリクス
チェクシート・チェックリスト
知識共有
アジャイル・スクラム