プロジェクトが問題だらけな理由

エンジニアを続けていると感覚が麻痺するのかもしれない。プロジェクトが立ち上がるとどこからともなくメンバと称するエンジニアが集められ、具体的なプロジェクトの内容も知らないまま納期までに作業をするように指示される。

システムエンジニアリングだという人がいる。エンジニアリングなら開発手法もプロジェクトマネジメントも、様々な手法や方法論が確立され、技術的にはある程度決まったやり方で、システム開発ができることを期待しても良いだろうが、現実はそうではない。

ウォーターフォール開発にしろアジャイル開発にしろ、概念や思想があるが、これがテンプレートだという開発手法が存在しない。エンジニアの読み手や解釈、それまでに経験してきたノウハウが互いに影響し合い、読み手の解釈に基づくプロジェクト運営が行われる。

プロジェクトチームが編成され、メンバが召集され、そのメンバに示されるプロジェクトのやり方は過去に誰も経験したことがないやり方をプロジェクトに参画してから提示される。いきなり初見でこのやり方に合わせてやれとアドリブに完璧を求められるのだ。

メンバはメンバで、誰一人同じ経験をしていないから、示されたプロジェクトのやり方の解釈は必然と違うものになるし、解釈されたことは似ているかもしれないが根本の意思決定では違う判断をなされているのだ。

ではと、プロジェクトのやり方のテンプレートを作ったとする。そのテンプレートを素直に使ってくれるかと言えば、そんなようには受け入れられない。今まで経験してきたやり方と違うから使えない、このプロジェクトには合わない、などと使わない理由をいくらでも述べるのだ。

もちろん、テンプレートに問題もあって、テンプレートを作るタイミングでたまたま成功した事例を雛形にテンプレート化するから個別事情が色濃く反映される。それをやってきたらプロジェクトが成功したのだと言われるとモデルを抽出することに長けた才能を持つ人がテンプレート化しないとそうなってしまうのだ。

複数の事例からテンプレート化することを進めると原理主義がまかり通り、個別事情を徹底的に排除する勢力が台頭するため、テンプレート化されるのは概念モデルだけで、実務で必要なプラクティスが根刮ぎ削られてしまう。

プロジェクトの問題は得てして以下のことから起きている。

  • 誰一人同じ経験を持っているエンジニアはいないことを認識していない。
  • プロジェクトチームでやるやり方なのに当事者のエンジニアにそのやり方でやれるかを問われることがない。
  • テンプレートは使わない理由をつけられ使われない。

プロジェクトの問題を減らしたいなら、逆のことをすればいい。

  • 異なる経験を持ち寄り、違いを理解する。
  • チームのやり方は全員で小さく試し、出来ることを確かめる。
  • テンプレートをチームのやり方にカスタマイズする。

テンプレートが無いなら、これからやる作業を書き残すか写真に撮り、残しておくこと。

 

 
amazon kindle『50%OFF以上』 IT・専門書フェアから選り抜き書籍

ピープルウエア 第3版

ピープルウエア 第3版

 
パーフェクトソフトウエア

パーフェクトソフトウエア