はてさて。
プライベートに忙殺されていて、なかなか思うように書けなくなりつつありますが、始めた当時の勢いでがりがりと書いていられたのもここまでなので、これからは勢いより内容を考えて書かねばなりません。
一段落ついでに、システム開発のプロジェクトで必要になると思うものを考えます。


自分は、プロジェクトを遂行していくにあたり、オブジェクト指向の概念が活用できると思っています。それはつまるところ、要員それぞれに明確な役割を与え、その役割を達成していく事でプロジェクトの完遂を目指す、いわば「ミッション駆動」とも言うべきものになるでしょう。(多分)

オブジェクト指向がデータモデリング手法だというのも、オブジェクトという概念の中心にデータ構造があるというのは、実は初心者に陥りがちな罠だと言えます。もともとオブジェクト指向とはシミュレータから生まれた概念で、自分はそれを現実世界を「存在」とか「役割」といった側面で抽象化しよう、というのがオブジェクト指向の真髄だと考えます。なので、オブジェクトは「もの」などではなく「存在」とか「役割」とした方がより確実な気がします。


ここで自分は「役割」という側面に注目して、それをプロジェクト運用に当てはめてみています。

マネージャならマネージャの役割と振る舞いが、エンジニアならエンジニアの役割と振る舞いがあります。この時点でオブジェクトの抽出が出来ていますから、モデルとして書き起こす事も出来るでしょう。振る舞いも、例えば「要員を調達する」とか「設計書を作成する」等の、それぞれの役割に沿ったものを定める事が出来ます。唯一、「実は出来ない」とか「達成できなかった」というプログラムにはあり得ない事があり得る、というのが現実の人間ならではな部分です。


役割と振る舞いがモデル化できれば、メンバーは自分のやるべき事が明確になりますし、何をして良いか質問したり指示を待ったりする事もなくなります。責任領域もより明確になりますし、実際これをUMLなどで書き起こせば、成果物の状態遷移や管理方法がもっと的確に把握できるでしょう。

しかし、やはりこの考え方は実際にプロジェクト運用をしていく上で、単なるエッセンスとしかならない事も、十分意識しておく必要があります。なんせ人間なので、役割と振る舞いを定義してもその通り動く保証はありません。役割を与えたのにその通りの働きをしてくれなかった、なんて愚痴はどこででも聞きます。更に風邪をひいたり、寝不足でパフォーマンスが落ちる事まで想定しては、モデル化なんて無理です。


その為、プロジェクトを進める上で、メンバーそれぞれのミッションを明確にする程度の効果が得られればこの考え方はそれで十分だと、自分は思います。