ソフトウェア技術者の職業性ストレス

書名：ソフトウェア技術者の職業性ストレス

著者：藤垣裕子

これはかなり昔の本だけど、その古書を読んだことがあるので簡単に書いておく

一般に言われている開発工程としては以下のような工程がある。

①要件定義

②基本設計

③詳細設計

④プログラミング（コーディング）

⑤テスト

⑥メンテナンス（保守）

これらの①～⑥で大きなストレス要因となるとすると、

どの工程もストレス要因となるのはもちろんのことだろう。

実際に考えてみれば、納期や要求品質、開発環境の状態やアプリケーション分野によって違うのは当然のことだと思う。

例えば、フロントエンド開発での操作面において、運用の流れに影響しないような操作のバグであれば、ストレスとしては小さい。

しかし、金融や販売系のシステムで数値を確実に合わせなければならないものであれば、不具合は許されないのでストレスは大きい。

とはいえ、ストレスを考えると抽象的な部分で話をまとめてしまうと、具体的な作業負荷と精神的負担がどこにあるかが見えて来ないので、

①～⑥の各工程での作業負荷（以下、負荷とする）と精神的負担（以下、負担とする）を考えてみることにする。

①要件定義と②基本設計

負荷としては小さいが、負担としては仕様が見えない、理解できているのか不安等、負担は高い傾向にある

②詳細設計

一つ一ついろいろなことを決めていかなければいけないので、負荷としては高い方になるが、ゲームを解くような面白さがあるということがあるので負担としては小さい。

③プログラミング（コーディング）

結構、大変な工程に見えるかもしれないが、詳細設計がしっかりしていれば、単調になりがちであるため、負担は小さいが単純作業を繰りかえしていくということでは負担は多少なりともあるだろう。

誰もが一番やりたくない工程。

問題解決に苦しんだり、納期に追われてしまうことが多々ある為、負荷も負担もかなり大きい。

⑤テスト

ほとんどが力作業に近いため、負荷としては大きいが、テストケースがはっきりしていれば単純作業になりやすい。

しかし、テストで不具合があればデバッグしなければいけないので、負担はある。

⑥メンテナンス（保守）

負荷と負担はトラブル内容によるが、システムダウンや法外な要求があると負荷も負担も非常に大きくなる。

さて、システム開発の最大目標としては、顧客満足になると思うが、

その顧客満足に到達するまでには、①～⑥の工程をしっかり突破しなければならない。

ただ、その中でその工程を突破していくのは、あくまでも「人」だということを忘れてはならない。

ストレスが溜まれば、モチベーションが落ち、生産性も落ちる。

その悪循環をどのように解決していくかを考える為に、リスクマネジメントをしっかり考慮したうえでプロジェクト計画を進めていく必要がある。

また、「ストレス要因になる」ということを、リスクの一つとして考える必要がある。

それにより、各工程でつまづいてしまえば、最後のメンテナンス（保守）の工程が全ての工程をけん引することになってしまい、長く続いて終わらないものになるだろう。