ここでは、お勉強のために読んだ論文を記録することにします。
自分の興味分野でわけて、このスキル・コンピテンシ編と、アジャイル開発編、それからキャリア編に分けることにしました。
なんだか増えていくなー。発散しないように気をつけよう。
スキル・コンピテンシ編はこちらへどうぞ。
キャリア編はこちらへどうぞ。

【001】アジャイル開発=コンカレントエンジニアリング×小集団活動+プログラムマネジメント（児玉（2015）、情報処理学会）

2021年8月8日
1980年代始めの米国のビジネス改革の目玉は以下の2つ。
　　・大量生産主義 ⇒ リーン生産主義
　　・シーケンシャルエンジニアリング
　　　　　　　　 ⇒ コンカレントエンジニアリング（CE）
コンカレントエンジニアリングとは製品の設計に関わる工程と生産準備に関わる工程を同時並行に進める、生産工程に配慮した設計を実現。
これが日本にわたって野中先生の「The New New Product Development　 Game」という論文になって、のちのちScrumになる。
アジャイル開発の本質は、CE。そのプロセスはISO/IEC15288のプロセスであり、その実行主体は小集団。でこの活動がプログラムマネジメント。
　* ここでなんで「プログラム」マネジメントなのか。筆者は対象を「大規　
　模情報システム」としているからではないかな。

【002】IoTプロジェクトにおけるアジャイル型手法に関するマネジメント方法論の一考察（今仁（2018）、日本情報経営学会誌）

2021年8月8日
プロジェクトマネジメントにおけるアジャイル型の選択方針（マネジメント方法論）を考察。分析結果は以下。
　　①アジャイル型の適用領域として要求または設計の手戻りの可能性が
　　　重要変数である。
　　②アジャイル型は手戻りの可能性による品質面のプロジェクト指標の
　　　悪化を抑制している。
課題は、①アジャイル型の技術面およびプロジェクトマネジメント面のスキルアップの必要性と、②プロジェクトの性質に応じたマネジメント上の目標の設定。
プロジェクトマネージャーは、アジャイル型の手戻りの抑制効果と調整工数の増加分を比較し、前者がより大きい場合にアジャイル型を適用すべき。
プロジェクトの性質、アーキテクチャ、ライフサイクルを含めた3つの検討軸を提案。
IoTプロジェクトでは、ハイブリッドアジャイルが有用。
　* 先に従来研究を読めばよかった。あとで読もう。

【003】企業等のIT部門におけるITIL実践のCSFから成果へ至るモデルの構築（角田（2018）、情報処理学会論文誌）

2021年8月11日
企業のIT部門20名にインタビューを行い、ITIL実践の成功モデルを構築した論文。キモは、半構造化インタビューを行い、M-GTAの分析ツールを用いてGTAの簡略版で分析を行ったこと。これで概念を抽出し、カテゴリー、カテゴリーグループの抽出、ストーリーラインの作成へとつづく。
やり方については、自分がしようと思っていることとほぼ同じなのでとても参考になる。
疑問は、「M-GTAの分析ツールを用いてGTAの簡略版で分析」というところ。M-GTAはGTAの修正版とは言え、（完全にかどうかはわからないが）社会構成主義を取り込んでいる。一方、GTAは客観主義、実証主義に基づいている。これは、コンフリクトしないのか？分析手法なのに良いのか？
これは、今後の課題。

【004】アジャイル開発のプロジェクトマネジメントと品質マネジメント（居駒（2021）、品質Vol.51,No.1）

2021年8月11日
アジャイル開発での品質保証（QA）は難しい。アジャイル開発でのソフトウェア開発は開発チームで行って、そのまま顧客にリリースしちゃうとなると、品質保証は開発チームに依存してしまう。開発チームに品質保証部門が入ることはまずないので、組織としての担保ができない。
この議論は、当然産業界のあちこちで議論されている話題だけど、この論文は、「そもそも品質マネジメントってなんだっけ？」をベースに、アジャイル開発での品質保証の参考になる気がする。
そもそも、ソフトウェアの品質は、開発途中では「見えない」。なので、設計不具合とか、設計レビュー時間とかの代用特性を使って品証部門が検証（Verification）している。ウォーターフォール型開発でのフェーズ移行審査とか。で、最終的に動くソフトウェアができると妥当性確認（Varidation）を行って、動くソフトウェアの品質を確認する。
一方、アジャイルの場合、スプリントごとに顧客に動くソフトウェアをリリースするので、毎回のスプリントで（限定された機能での）妥当性確認（Varidation）をしているようなものであるので、代用特性を使っての検証は不要となる（と、思うがここはQAの意見を聞きたいところ）。
実際に動くソフトウェアで妥当性確認をするので、ウォーターフォール型開発よりも早い時期にまずいところが見つかる、というメリットはありそう。
じゃあ、アジャイル開発と、ウォーターフォール型開発のインクリメンタルやイテレーティブとの違いは何か、というと、インクリメンタルやイテレーティブは、「設計を基にした実装の確認」であって、妥当性確認ではない。そもそも動くソフトウェアの形になっていないケースが多い。機能のフィージビリティならそれで充分だから。なので、イテレーティブやインクリメンタルで作成するソフトウェアは低品質でも、「後で品質向上しましょう」で十分OK。顧客にもリリースしないし。
アジャイル開発は、スプリントごとに顧客に（機能限定ながらも）ソフトウェアをリリースするので、それなりに高品質である必要がある。ここで中途半端な品質でリリースして、発生した不具合を次のスプリントに回す、というのは（多分できるけど）顧客のコストを無駄に消費することになるし、自組織の評判を落とすことにもなるのでやるべきではない。
なので、常に高品質のままインクリメントしていく。これを保証するために、スプリントバックログに品質確認用のアクションアイテムを入れておけばよい。高品質を維持するためには、自動テストの仕掛けが必要だと思うがそれは別の話。
改善、という観点で見ると、アジャイル開発は、スプリントごとに振り返りがあり、プロセスの補正が素早くできるのに比べ、ウォーターフォールはプロジェクト終了時に、次のプロジェクトに向けての1回のみ。組織のノウハウ蓄積として、アジャイル開発のプロセス改善を毎回、プロジェクト計画書に書くかどうかは検討が必要。メモでも良いとは思うが。JIRAとかBACKLOGを使うのはあり。
なかなか興味深い論文でした。本も購入したので、あとで読もう。

【005】アジャイル開発の特徴とその真の価値（柿田（2011）、PM学会2011秋季大会予稿集）

2021年8月12日
アジャイル開発宣言と12の原則についての概説。
「持続可能なペース」「自己組織化」がポイントとして、考察しているが、ちょっと浅いかも。「持続可能なペース」の成立をチームに動的な外部構造を与えるもの、「自己組織化」がチームに動的な内部構造を与えるもの、として、このセットが循環型開発という状態、としてこれを目指す、という。
わかるような、わからないような。

【006】アジャイル開発スクラムを実行する役割とリーダーシップの変化の考察（山北（2020）、国際P2M学会研究発表大会予稿集）

2021年8月12日
アジャイル開発のひとつ、スクラムは、「自己管理型のチーム」がポイントで、推進役であるプロジェクトマネージャーという役割が存在せず、チームメンバーがそれぞれ分担して進める、というのが「スクラムガイド」の記述。で、この論文では、リーダーシップの見地から、PearceのShared Leadershipという考え方を導入し、そのリーダーシップの特徴を説明している。これに従えば、チームメンバー全員がリーダー、とか、雅楽型プロジェクト、とかいうのも理解できそう。なるほど、なるほど。
確かにそうなんだけど、実態としてはそうなっていない、というのが、私自身の仮説で、質的研究により、そこを掘り下げたいと思っています。

【007】アジャイル開発スクラム実践時におけるコミュニティマネジメントとしてのプログラムの変化（山北（2019）、国際P2M学会誌）

2021年8月13日
スクラムでの開発は、従来のウォーターフォール開発と異なり、プロジェクトを推進するプロジェクトマネージャーが存在しません。その代わりに開発メンバー全員が「自己管理型」チームとして、プロジェクトを推進していきます。すなわち、「チームを構成するメンバー同士が必要なスキルを相互補完し、チーム全体として必要とされるパフォーマンスを実現」します。
先行研究を受け、この論文でのリサーチクエスチョンとその仮説は以下の2つになっています。
RQ1)　スクラムの現場では、ヒューマンスキルの分野で見たときに、どのようなエンジニアが活躍しているのか。
仮説1)　従来から言われているコミュニケーションやリーダーシップなどのスキル以外にも、他者を思いやるようなスキルが高いエンジニアが活躍している。
RQ2)　プログラムマネジメントは、スクラムの現場ではどのようにあるべきか。
仮説2)　プログラムマネージャーが存在せず、チームメンバーがその役割を担うべきである。
RQ2)はスクラムの定義からいくと、当たり前といえば当たり前ですね。
あ、国際P2M学会での論文なので、プログラムマネジメント、と言っていますが、プロジェクトマネジメント、としても十分によろしい。
で、定量的研究としてアンケートをとっています。
アンケート結果として、RQ1については、「向上心・熱意・積極性」については、ウォーターフォール開発よりもスクラムの方が高い。また、RQ2については、ウォーターフォールではプログラムマネージャー一人の決断となり、スクラムでは集団の合意に変化していることがわかる。つまり、「上意下達として命令伝達され、実行に移していく方法から、自らが考え、率先して行動していく方法へ変化している」。
論文は、惜しいですが、きちんと考察をされていない気がします。まずRQ1については、「向上心・熱意・積極性」が「他者を思いやるようなスキル」かどうかは議論の分かれるところです。また、RQ2については、単に机上調査での結果からの結論であり、ちょっと調査不足の気がします。

【008】アジャイル型開発手法の適用領域とプロジェクトの成功度の関係（今仁（2017）、日本情報経営学会誌2017Vol.37. No.1）

2021年8月13日
この論文の目的（リサーチクエスチョン）は、「アジャイル型開発手法は、プロジェクトの成功とどのような関係にあるのか」と「アジャイル型開発手法はどのような性質のプロジェクトで使用されているのか」を、質問票調査により分析したもの。
プロジェクトのモデルとしては、Boehmらによるアジャイルホームグランドの5つの検討軸とShenharらのNTCPモデルの双方を採用している。
結論として、
① アジャイル型開発手法の適用領域として要求および設計の手戻りの可能性が重要変数。アジャイル型は手戻り可能性が高い状況で採用されている。
② プロジェクトの成功への影響を分析したところ、アジャイル型開発は手戻りの可能性による品質面のプロジェクト指標の悪化を抑制している。
一方、課題としては、
① アジャイル型開発の技術面、およびプロジェクトマネジメント面のスキルアップの必要性
② プロジェクトの性質に応じたマネジメント上の目標を設定し、アジャイル型開発を適用する
参考になります。