っていうか、システム開発ってプロジェクトなのか?

プロジェクトとは何か?PMBOKによると

Project
A project has five features specified as follows; (1) A sequence of tasks has a beginning and an end. (2) Resources such as manpower, time, money and facility are used.(3) A final goal is clearly defined. (4) The goal is achieved under a planned and schematic approach.(5) The tasks are executed by a team.
A project is unique and there does not exist the same one. A daily work repeated everyday or regularly is not called a project.
A construction project has four components traditionally consisting of schedule, cost, quality and safety. Recently concept on scope, risk, communication, organization, project integration etc. is included.

太字のところに違和感がある。システムってライフサイクルがあって初期開発のSは通過点に過ぎない。イチロー2000本安打ぐらい通過点だ。大阪行くときに新横浜でビールを飲みきってしまうぐらいの勘違いだ。いつそのシステムが必要となくなるのか、そして普遍的なシステムの存在目的は明確に定義できるのか。できないと思う。
 システムは進化する。前言っていたように、Lehman先生ソフトウェア進化の法則(元は1970年あたりに体系化された法則)を抜粋しておこう。

Lehman先生のE-Typeソフトウェア進化に関する肝に銘じとけの8つの法則を(日本語は解釈が混じってます)
1. Continuing Change

    • An E-type program that is used must be continually adapted else it becomes progressively less satisfactory.
    • 仕様が確定できないプラグラム(E-Type:環境依存のE?)は、常に環境に合わせて変化を続けなければ満足性が下がる一方なんだよ。

2. Increasing Complexity

    • As a program is evolved its complexity increases unless work is done to maintain or reduce it.
    • さっきも言ったけど、プログラムは変化するんだから、何か手を打たないと複雑性は増すがり。そうしたい?

3. Self Regulation

    • The program evolution process is self regulating with close to normal distribution of measures of product and process attributes.
    • ソフトウェアが進化をする過程は、普通のプログラム開発と同じぐらいきっちりと決めてせなだめ。特にビジネスからの要求変更管理には気をつけたほうがいい。

4. Conservation of Organisational Stability

    • The average effective global activity rate on an evolving system is invariant over the product life time.
    • システムの試用期間にかかわらず、ソフトウェアの進化にかける実施作業の比率は一手に確保しておけ

5. Conservation of Familiarity

    • During the active life of an evolving program, the content of successive releases is statistically invariant.
    • ユーザが真に実現したかったシステムは結局作って反応を見て継続的にリリースしていくアプローチしかない

6. Continuing Growth

    • Functional content of a program must be continually ncreased to maintain user satisfaction over its lifetime.
    • ユーザの満足が駆動減となってシステムの機能は変更を要求されプログラムはずーっと変更され続けなければならない。

7. Declining Quality

    • E-type programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment.
    • E-Typeのシステムはどう進化するのか、環境によってまったく読めない。しかしそれに対してちゃんとプログラムを進化させ、保守*1をきっちりやらないと、品質は目に見えて下がっていく

8. Feedback System

    • E-type Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved
    • E-typeシステムの進化のプロセスは、複雑なサイクリックな開発スタイル、内容に応じて様々なレベルでの変更の混在、そして五月雨式かつ複数のステークホルダからのフィードバックなどのおかげで大変すぎる。

E-Typeつまり、問題すらはっきりしないシステムが多くなってきた*2ことで、「ソフトウェア進化」の世界は注目をあびつつあるのだ。SaaSもひとつはその流れのソリューションだと思うのだけどね。

*1:ここでいう保守は、いわゆる日本語で言う「維持メンテ」と呼ばれるものではなく、是正、適応、完全化、予防のための保守を指す:Ref ISO/IEC 14764

*2:S-Typeは問題がはっきりして、仕様もはっきりしているが、最適なある解決を設計することが困難であるシステム「将棋プログラムとか」、もう一個は、問題も仕様も解決のアルゴリズムも確定しているプログラム「今日の曜日を計算するプログラムとか」