我々の暮らしを支えているシステムを制御するソフトウェアは、我々の目に見えないものだが、非常に重要な役割を担っている。
同様にシステム開発におけるソフトウェアエンジニアも、高いスキルを必要とし、システムの構築に多大に貢献している。
システム開発の受注側企業におけるソフトウェアエンジニアとしての心得は、企業内の教育等において、上司から部下へ、先輩から後輩へ、よく叩き込まれる。お客様の要望に応え、「良い品質」のソフトウェアを「早く」「安く」、といった具合にである。
しかし、システム開発の発注側企業の心得をあまり聞いたことが無い。私が専ら受注側の立場で業務を行ってきたため、そのように感じるだけかもしれない。
世間一般を見ると、日本においてはIT・システム開発に関してまだまだ闇が多く、ソフトウェア開発はソフトウェア企業に丸投げになり、業務の負担が多い割には賃金があまり高くないという悩みに直面しているソフトウェアエンジニアは少なくない。
つまり、業界としてまだまだ健全とは言えない。この点は海外と比べても遅れをとっており、先進国としては恥ずかしい限りである。
この記事では、システム開発の中でも、ソフトウェア開発の発注側企業が心得ておくべきことの中でも代表的な内容について書こうと思う。
1.ソフトウェア開発の費用・納期と発注範囲・内容を適切なバランスとする
まず、ソフトウェア開発の費用と発注範囲について、発注側が心得ておかなければならないのは次の二点である。
- ソフトウェア開発をベンダーに丸投げし、ベンダーによる手厚いサポートを要求するならば、高額な開発費を支払うこと。
- ソフトウェア開発に関してベンダーに支払う費用を安く済ませたいなら、要求や仕様をしっかり確定し、ベンダーが作業しやすい前段を整え、ベンダーをしっかりコントロールすること。
一般社会では当たり前である。
鉄道なら早く目的地へ行きたい場合、通常の運賃に加えて特急料金を払う、良い設備で良いサービスを受けたいならグリーン料金を払う。郵便物なら速達にしたい場合、速達料金を払う。
しかし、ソフトウェア開発となれば、要求が増えても納期が変わらない、しかも安い費用なんてことはよくある。
- 「業務内容の割には賃金が安い」
- 「想定以上の手厚い対応を求められる」
納期に関しても同じことが言える。
- 「開発内容の割にはスケジュールが短すぎる」
- 「そもそもプロジェクト計画自体が破綻している」
- 「開発途中に機能追加があるが、納期が変わらずベンダー側で吸収している」
このような背景から、受注側企業のソフトウェアエンジニアが低賃金や過重労働を理由に退職するケースが発生している。受注側企業の労働環境が劣悪になることは、発注側企業にとってもリスクであり、他人事と捉えてはいけない。当たり前なのだが、できていない企業が少なくない。
2.ソフトウェア開発の大変さを理解する
ソフトウェア開発の発注側企業の社員は、ソフトウェア開発の大変さを理解するべきである。
この件に関しての取り組み事例を紹介する。
あるメーカーでは「交流会」と称して、ソフトウェア開発の発注先企業を訪問し、ソフトウェア開発現場、ソフトウェア開発工程、ソフトウェアデバッグ環境を視察し、発注側と受注側の交流の場が設けられた。
二度に渡って行われ、一回は両社の若手社員同士をメインとしたもの、もう一回は両社の中堅・管理職をメインとしたものであった。
お互いの社員同士が、相手方の企業の内部を知り、以降の業務のありかたを考え直す良い機会でもあるし、お互い刺激しあえるものであった。
ソフトウェア開発における設計資料や有識者によるレビュー資料は、普段は社外秘であるものの、この「交流会」の場では、その一部が公開された。その資料にはソフトウェア開発担当者が設計・検証した内容、ソフトウェア開発部門の上位者が照査した結果、担当者に対する指摘事項一覧とその対応内容・確認結果の詳細が示されており、ソフトウェア変更が地道な作業で成り立っていることがわかるものだった。
これを受けてソフトウェア開発発注側企業のマネージャが、発注側企業の担当者全員に向けて発した言葉が、以下のものだった。
- 「『ソフトウェアを変更する』作業は、変更に対して、（受注側企業の担当者による）多くの検証、資料作成、その他様々な作業で成り立っている。」
- 「『ソフトウェアを変更する』ことは、我々が想定しているのと比べると大変な作業であることを認識すべきである。」
- 「できるだけ無駄な『ソフトウェア変更』を避けるように、（受注側企業に対して）配慮しなければならない。」
- 「それでも『ソフトウェア変更』を依頼する必要がある場合、できるだけ早めに依頼し、（受注側企業の担当者が）余裕を持って取り組めるようにしなければならない。」
私も同感である。
このソフトウェア開発発注側企業のマネージャーは、システム開発を円滑に進めるために、ソフトウェア開発の発注側として念頭に置いておかなければいけないことを、発注側メンバに周知し、教育している。
ソフトウェア開発者の負担をできるだけ減らし、ソフトウェア開発者がシステム・ソフトウェアの品質担保に最大限注力できるようにするための配慮は、ソフトウェア発注側企業に必要なマインドだ。
ソフトウェア開発は簡単なことではない。ソフトウェア開発を簡単と捉え、軽視することの問題点については、下記リンクの記事を参照していただきたい。
o08usyu7231.hatenablog.com
3.ソフトウェア開発行程へのしわ寄せを軽減する
- システム開発は想定外のことが起きる。
- プロジェクト途中での機能追加、機能変更が発生する。
- 事前に十分な想定ができておらず、作業を進めていく中でトラブルが発生する
これらのことは発生するよりはしない方が良い。できる限り最善を尽くし、未然防止に努めなければいけない。
しかし現実のところ、開発である以上発生する可能性が高いため、発生することを想定しておくべきである。想定外の事態が発生することで、工数が増大すること自体は致し方ない。
一方、このような原因により、ソフトウェア設計・実装・検証等、後工程にしわ寄せが行き、それを後工程の長時間労働等力技で回復することがあればグレーゾーンである。
労務管理に厳しい企業なら、工数増加要因の発生に対して残業で賄うことは、何も知恵を絞らない「サルでもできる愚策」であると考えている。
しかし、大半の企業では一時的に残業で賄うことは致し方ないと考えているようだ。それが管理職が育たない理由でもある。
本当に問題なのは、ソフトウェア設計・実装・検証等の工程を長時間労働等力技で回復することが当たり前になっているケースである。これは、ソフトウェア部門の管理者によるマネジメントが行き届いていない他、発注側の甘えであると言ってよい。
ソフトウェア開発部門が力技で回復するということは、その部門の人に多大な負担をかけることにより、十分な設計・検証ができず、ソフトウェア品質に影響する。つまり、発注側もリスクを負うことになるのである。ソフトウェア開発部門に責任を押し付けたところでこのリスクは無くならないし、発注側の立場を利用した圧力は社会的に冷ややかな視線を浴び、発注側にとって不利益になるだけである。このような状況にならないよう配慮しなければならない。
o08usyu7231.hatenablog.com
更に問題なのは、世間一般の感覚や社会的にはあり得ないことだが、ソフトウェア設計・実装・検証等の工程を長時間労働等力技で回復することが当たり前になっている状況を、
- 「業界の常識」
- 「会社の厳しさ」
- 「それでも対応してこそ本当のプロ」
などと正当化して、美徳であるかのようなマインドコントロールにより、洗脳するケースである。これは完全にブラックであると言って良い。
o08usyu7231.hatenablog.com
4.ソフトウェア開発発注側が心得ておくべきこと、まとめ
ソフトウエア開発の発注側企業は、ソフトウェア開発は大変なことであると心得、ソフトウェアエンジニアに負担を強いて完成するソフトウェアは品質面のリスクを負うと考えるべきだ。
- 「自分たちは発注側だから関係ない」
- 「受注側企業さえしっかりしていれば良い」
- 「受注側に責任を押し付ければ良い」
このような考え方は危険である。
ソフトウエア開発の発注側企業は、前工程の遅れをソフトウェア開発で賄うことが当たり前と考えてはいけない。発注先に納期短縮を理由に過重な労働を強いることの他、力関係を利用した過剰な要求により発注先を脅かすことは、人権侵害を助長する行為であると心得るべきである。自社・他社問わず、発注元先問わず、働く人すべての人権を守ることは、人間として、社会としての基本である。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
また受注側企業は、発注側企業がソフトウェア開発に関してどれほど理解があるか、発注側企業の社会的モラルがどのようなものであるかを見抜く必要がある。顧客の要請に応えることばかりに注力しすぎて、ソフトウェアエンジニアの負担を軽視することがあってはならないのだが、残念ながらこれが非常に多いのである。そのような企業は長期的に総崩れになるどころか、既に世界標準から取り残されている。ソフトウェアの重要性はますます増してきている。
o08usyu7231.hatenablog.com
