2020年のプロジェクトマネジメント、システムエンジニアの姿

2020年のプロジェクトマネジメントの姿
2020年のプロジェクトマネジメントの姿はどんなプロジェクトマネージメントと呼ばれているか、どんな手法で私たちシステムエンジニアはプロジェクトをキャリーしているのだろうか。そんなことをひょんと思い立ったので未来を予測してみよう。

before water-fall, after water-fall
現状は、乱暴に言えばプロジェクトマネージメントは、water-fallの前の世紀かwater-fallの後の世紀のどちらに属するか。それだけしかない。

PMBOKに代表されるコントロール駆動型のプロジェクトマネジメントと計画を立てて遂行する計画駆動型のシステム開発手法の組み合わせが客観的に理解しやすいため現状それに代わるものがない。

特に、プロジェクトをコントロールしたい管理サイドの視点であるプロジェクトマネジメントを代替するものは全くない。ここは委託元が委託内でのプロジェクトの進捗を管理・コントロールしたいというニーズが変わらない限りシステム開発をモニタリングする手法としてのプロジェクトマネジメントは委託元が変わらなければ世代交代することはないだろう。

システム開発手法
いま新興のプロジェクトマネージメントスタイルのアジャイル（のスクラムとか）のように、ウォーターフォールの時間軸の単位を２桁くらい短くすれば高速開発といえる。

ウォーターフォールでの開発速度がスクラムなどの開発速度に負けているかといえば、そうとも言えるし、ウォーターフォールをその特性を生かして高速で回せばそれはそれで機能することは明らかだから、そうとも言えない。

問題は人の介在をどれだけ減らすことができるかだ。

でも、要件は委託元しか知らないし、その委託元だって実装ベースでのアウトプットは発注時点でイメージしているわけではない。結局、人に聞き、人が作るのである。それは繰り返し作業をいかに見つけ、やりたいことだけを実現することで開発速度が速くなるのである。

もしかすると、2000年のころにバズった4GLとかが要件管理や自動設計の高度化により統合開発環境と今風に最適化され、HWリソースのますますの低廉化と高速化により復活するかもしれない。

現在だって、チープなリソースで消えてしまったPDAとかがスマホとして生き返っているのだから、過去に黒歴史として消えていった発想がゾンビのように復活する可能性だってある。

人的リソース
実際、ウォーターフォールをシステム開発手法として導入したプロジェクトでも、開発規模のスケールや投入人員の規模によりアジャイル開発で適当と言われる7人±2人のチームなんてザラだ。世の中、それより小さいチームのほうが多いくらいだ。

開発チームのスケールは、結局、チームを小さくすればメンバの負う期待が大きくなりプロジェクトの人的リソースに対するリスクが増える。それはスキルマッチにも当てはまる。

開発チームのスケールが大きくなれば今度は逆の現象が起きる。人的リソースのリスクは下がるがスキルに対するプレッシャーは目が届かなくなるために下がり要求スキルにフィットしないメンバの混入が起きる。結局は、システムエンジニアとしての技術レベルは１を下回る。

トレンドとしての高速開発は加速するだろうから、メンバへのスキルプレッシャは今よりは高くなることが想像されるが、委託元の要求がなければ依然として従来の技術レベルでのチーミングは絶滅しないから、結果的に高度なエンジニアの少人数チームと従来の規模に応じスキルレベルが下がるチームに二極化が加速するだろう。

プロジェクトコスト
従来のウォーターフォールでの大型の開発は絶滅しないだろうから、大規模のプロジェクトは大規模なりのコスト構造を取るが、プロジェクトチームサイドが内部からのコスト低減圧力により無理に低減かを進めることが続くだろう。同じように委託元からシステム更改のたびにランニングコストを含めたトータルコストの低減要請により、委託元からも価格低減のプレッシャーは断たないなだろう。

これを話をすり替えるのが機能追加であり、その特効薬はこれまで以上に常習されるだろうから使われない機能を作り続けることは無くならないだろう。つまり、委託元と委託先とのそれぞれの事情でプロジェクトコストはそれなりに維持し続けるということだ。

クラウドサービスのようにコンピューターリソースを外部化することを進め、浸透しながらも、脆弱な体力のクラウドサービス事業者が脱落し始めることを機にランニングコストが上昇するかもしれない。

コンペティタの現象は寡占を産むから結果的に価格上昇を招く。

リスク
高速開発に求められるより高いスキルへのプレッシャー、短納期としての圧力、コスト低減の壁はプロジェクトの不確実性をより高める。

システム開発はシステムエンジニアの思考と判断と体力に依存している。それもほとんどのリソースとして依存しているからその依存が減らなければリスクは深まるばかりだ。

単純に短納期のプロジェクトに最適化したスキルセットとレベルを持つメンバでチーミングしなければ勝負する前からデスマーチは決まったも当然になる。

システムエンジニアの2020年の姿
どれだけ人であるシステムエンジニアから仕事を機械が奪えるかによりその姿の進度は変化するだろう。あと5年で2020年であるからその5年でどのくらいファンクションとしての業務シフトが起きるかにかかる。

その業務シフトの量に関わらず、技術を作るシステムエンジニアは職を続けられるだろうし、技術を利用するだけのシステムエンジニアはITの業界から業務ドメインに中に内包されていくだろう。