大企業の基幹システム開発における開発方法論（は関係ない？）

カンバン方式を勉強して、数百人から数千人及ぶ大企業の基幹システム開発に最新の方法論と言われるやり方が（部分的にでも）導入して、失敗しがちなプロジェクトの成功率を上げることはできないかと考えた。

しかし問題は方法論ではなく以下の点にあるのでは？と考えた。ウォーターフォールよりアジャイルがより良いかとかそういう問題ではないと考えた。

大規模プロジェクトの特性

1. ミッションクリティカル（業務を止められない、止めるとしても時間を最小にすることが求められる。）
2. 基幹システムなので、関連（連携している）システムが非常に多い。（数十〜）
3. 関連システムが密結合で連携している。
4. システムが多いので利害関係者が多い。
5. 利害関係者は、システム部門間だけではなく、ユーザー部門も巻き込んで複雑な関係になる。
6. （日本人の特性なのか？）失敗したくない。（評価方法が減点方式なのか？）

1.は方法論に関係なく、移行の仕方の難しさの話。

2,3.は密結合から近年の考え方である疎結合への移行の難しさの話。アーキテクチャをどう考えるかという技術の話ではあるが、プロジェクトの進め方の方法論とは直接関係ない。

※ここまで書いて考えたのが、作る対象のシステムが密結合から疎結合に変わっていくように方法論やプロジェクトマネジメントツールも密結合から疎結合へという流れになるのかな。依存関係は少ない方がもちろん難易度は低くなる。

4,5.は、アーキテクチャや方法論を超えて、もはや政治の世界になる。全員がハッピーになる方向などありえない。（PMにはその企業１番の実力者、といわれるのはそのためであろう。）

6.は（個人は、あるいは自チームは）失敗したくないのに、（全体としては）結果的には失敗する流れになってしまうという相反する結果を生み出してしまう。これも方法論とは関係ない。個人が成功するため（失敗しないため）には、他の人は知ったこっちゃないという考え方が生まれがちと考える。

よって方法論の良し悪しに関わらず大規模プロジェクトは失敗の確率が高いのでは？