システム開発を行う中で、外的要因によりソフトウェア開発部門がしわ寄せを受けることがある。
一般的には、以下のようなものがある。
- 要件定義決定、仕様決定の遅れによるもの。
- 顧客、企画部門、営業部門による無理な要求によるもの。
- 大元の企画からの方針転換によるもの。
- 本来ハードウェアで解決すべき問題をソフトウェアで解決しようとするもの。
- 開発途中の仕様追加。
実際のシステム開発プロジェクトを例に挙げて、どのような外的要因によるしわ寄せを受け、どのような対応を取ったか、またソフトウェア開発部門以外の部門を含めて、あるべき姿について語りたいと思う。
1.ソフトウェア開発部門が上流工程に積極的に関与するプロジェクトの序盤
既に市場に流通している製品のマイナーチェンジ品の開発が企画されている。マイナーチェンジ品なので、主にソフトウェアのみの変更で、価値を提供する製品を開発したいというもの。この開発へのリソースアサインも少ないものだった。
企画における本製品のコンセプトは、当初「ソフトウェアで価値を提供する」としていた。しかし、近い将来本製品を含む製品群の大幅なラインナップの見直しを行うこととなった。この影響により、本製品に関しては、できるだけ追加機能を必要最小限とし、開発費用を最低限に抑えるよう方針転換があった。
費用を最小限に抑え、追加機能を最小限にするため、一部のモジュールについては現行製品から変更なしで進める計画である。「最小限」「変更なし」と言えば、開発のボリュームが少なく、難度が簡単であるかのような印象を受ける。しかし、費用を抑えること、特定のモジュールの変更をせずに開発することは、制約事項が膨らみ、その制約事項を満足するために、その他のモジュールにおける設計の工夫が必要であるため、かえって難度が高くなることがあるのである。今回の開発がこれに該当している。
このプロジェクトでは、ソフトウェアエンジニアがシステム仕様決定を待ち、決定した要求仕様に従ってソフトウェア設計を行う従来のスタイルから一変し、開始当初からソフトウェアエンジニアが仕様調整等前工程に積極的に参画し、複数の仕向先の仕様、ソフトウェアの共通化に向けて進めることで、品質の確保、開発工数の削減といった開発効率の向上に寄与した。（・・・【開発効率向上１】）
また、仕様決定に時間がかかるようなケースにおいては、ソフトウェアエンジニアがデモ用ソフトを作成し、実際にシステムの振る舞いを、仕様設計部門や製品企画部門に確認してもらいながら、具体的なイメージを掴んでもらい、円滑な仕様決定へと導くよう試みた。（・・・【開発効率向上２】）
2.ソフトウェアエンジニアに次々と追い打ちをかけるプロジェクト中盤
上述の【開発効率向上２】のようなこれまでにはない取り組みにもかかわらず、それでも仕様決定が難航し、少しずつスケジュールが予定より遅延していった。対応仕様項目ごとに仕様確定期限を設けていたが、いずれも２週間から１カ月程度遅れての確定であった。
その原因の１つは、本プロジェクトで開発している一部のモジュールを、以降の別製品との共通化を見据えた議論であった。長期的な視点では良い取り組みである一方、本プロジェクトで開発している製品とは別の製品の都合により、直近の製品開発スケジュールに徐々に影響が出ている状況であった。（・・・【外的要因１】）
また、別のモジュールでは、開発費用を最小限にするため、ステークホルダ間での調整が長期化した。具体的には、一方が開発の見積費用を提示したことに対し、他方が機能削減と値下げ交渉を行い、最適な落としどころを見い出すといったやりとりの往復であった。（・・・【外的要因２】）
このような状況の中、仕様追加が発生した。開発中のマイナーチェンジ品のベースとなる現行品において、発生数は少ないが市場品質問題の報告が品質保証部門に寄せられ、本来製品のハードウェアで対応すべき問題であるにも関わらず、対応が困難であることから、ソフトウェアによる対策を行うこととなった。本件の依頼元部門においても、本来ハードウェアで対応すべきことや、ソフトウェアでの対応が極めて難度が高いことを理解していた。（・・・【外的要因３】）
更に追い打ちをかけるように、製品・ハードウェアの耐久試験の結果、規定を満たさない箇所があることが判明し、その対策用ソフトウェアの作成に、ソフトウェアエンジニアが度々協力した。結果、このハードウェアの耐久試験において規定を満たさない内容とは、試験方法や試験環境によるものと判明した。（・・・【外的要因４】）
更にハードウェアの設計において、開発当初に予定していた設計に問題が見つかり、開発終盤でハードウェア設計を見直した。これに伴いソフトウェアの変更が必要となった。（・・・【外的要因５】）
その他諸々、細かい内容も含めてこれらの【外的要因】が、全てソフトウェア開発部門がしわ寄せを受けることとなり、開発難度が一気に増してしまった。
3.ソフトウェア開発部門が受けたしわ寄せの吸収に尽力するもやっぱり残業対応にならざるを得ないプロジェクト終盤
これらのしわ寄せを受けたソフトウェア開発部門は、鋭意対応を進めソフトウェアの完成に近づけていった。ソフトウェアで対応する内容が開発当初よりも増加していることをステークホルダにも伝えたが、納期を遅らせることなく、ソフトウェア開発部門内の調整のみで対応した。
一部の項目については、ソフトウェアエンジニアから仕様検討部門へ対応を免除するよう申し出た。しかし、受け入れられなかった。
また、しわ寄せを受けたソフトウェア開発部門では、一部開発中のソフトウェアにバグが検出されたが、迅速に対応し、以降大きな問題にはならなかった。
【外的要因】のしわ寄せの解消に貢献した【解消要因】がいくつかあるので、ここで挙げておく。
一つは、前述の【開発効率向上１】に記載した、複数の仕向先の仕様、ソフトウェアの共通化に向けて進めることで、品質の確保、開発工数の削減に前倒しで取り組んだことが救いとなった。（・・・【解消要因１】）
次は、ソフトウェアエンジニアの１人が以前からテストを自動化する構想を持っており、この対応には数日を要したものの、その工数を回収することができ、大幅なテスト効率向上と、品質への貢献を実現した。（・・・【解消要因２】）
更に、ソフトウェア開発部門の管理職の協力を仰ぎ、開発終盤に期間限定で応援要員を２名追加し、対応した。幸い２名ともこの開発中製品に対する類似製品の開発経験者である。しかし、応援要員２名が元々アサインされていたプロジェクトへの影響が出ている。（・・・【解消要因３】）
更に、一部のソフトウェアエンジニアが一時期間、深夜までの残業対応で遅れを挽回した（・・・【解消要因４】）
そしてこの開発は紆余曲折あったが、無事納期までに完了した。また、幸い労働トラブル、メンタルトラブルの発生等もなかった。
4.ソフトウェアエンジニアが前工程のしわ寄せを吸収する開発は当たり前ではない、異常だ！
ここまでを読むと、ソフトウェア開発のエピソードとしてよくある話であり、情報処理技術者試験の高度区分の１つである「プロジェクトマネージャ試験」の題材にもなりそうだ。
「いかなる外的要因や変化にも対応できることがプロジェクトマネージャには求められる」
とか、いかにももっともらしいことが解説に書かれていることがある。
o08usyu7231.hatenablog.com
ハードウェア、ソフトウェア問わず部品の共通化や業務効率化等短時間で完成させるための工夫は、どの開発現場でも当たり前に言われる。応援要員追加も珍しくない。長時間労働も職場によってはよくあることだ。
しかし、ここからが重要だ。これが「当たり前」「よくあること」「業界の常識」と考えてしまうと、その時点で思考停止である。
前工程の遅れや仕様追加等の外的要因にも関わらず、最終的な納期を当初の予定から変更しないとなると、ソフトウェア開発部門にしわ寄せがきて、最悪ソフトウェアエンジニアの犠牲によって開発全体が成り立つなど、普通に考えれば理不尽極まりないことである。
とはいえ、現実にはプロジェクトの進行中に状況が変わることがある。想定外のことも起きるし、開発当初に全ての問題やトラブルを予測するのは現実不可能である。そのような時は以下の考え方を持っておくと良いだろう。
- プロジェクト進行中の「方針転換」や「仕様追加」は、「ある」よりは「ない」方が良い。しかし、「ある」場合でも発生すること自体は致し方ないと考えている。設計当初の時点ではすべてのケースを想定しておくことは難しい。誰にでも、どの部門にでも、開発である以上想定しないトラブルはある。発生すること自体を否定してしまうと何もできなくなる。
- 次にこのような要因による、ソフトウェア開発部門へのしわ寄せを、ソフトウェア開発部門の頑張りで賄うことが考えられる。ソフトウェア部門のリソースに対して許容範囲内であれば、対応可能であると考えられる。対応不可能である場合は、対応内容の絞り込み、優先度の再検討、後回しにできる作業の洗い出しなど、ステークホルダ間で調整すれば良い。
- 次にこのような要因による、ソフトウェア開発部門へのしわ寄せを、ソフトウェア部門で吸収することが当たり前になると、問題意識を持つべきだ。部門間やステークホルダ間でこのような力関係があると、健全な開発を行うことが困難になり、無理か祟り、Ｑ（品質）、Ｃ（コスト）、Ｄ（納期）のいずれかに歪みが発生する。ソフトウェア開発部門も、ソフトウェアエンジニアも正常に機能しなくなることを理解しておくべきなのである。
- 次にこのような要因による、ソフトウェア開発部門へのしわ寄せを、ソフトウェア部門で吸収することが「業界の常識」として洗脳するような社畜が存在すれば、ブラックの底辺と断言できる。このような組織や人とは関わらないことがベストである。
ソフトウェア開発部門が、前工程のしわ寄せを受けたとき、
が大きな二択となるケースが多い。良し悪しは別として。。。
ソフトウェアエンジニアでさえ、良心なのか、使命感なのか、社畜魂なのか、自分達を犠牲にして全体に尽くそうとする。新しいソフトウェアのリリース日、新システムの稼働開始日、新製品の発売日、これらを死守しようとする。顧客目線を考えれば当たり前と教える人が多いのだが、問題なのはスケジュールを守ることが絶対的な正義と勘違いし、エンジニアの犠牲の上にプロジェクトを成り立たせるという、コンプライアンス面での問題が大きすぎることだ。その結果、ソフトウェア品質やソフトウェアエンジニアの労務管理という形で表面化する。特に労務管理に影響が出て、心身不調者や離職者が出て、ブラックとの噂が広まれば、ソフトウェア開発部門を抱える企業にとって、大きな損害だ。
また、外的要因によるしわ寄せを受けたエンジニアの労働実態の問題点と、このような問題点に対してステークホルダ全体で改善が必要な旨について、社会的に高い視座でもって声を挙げたエンジニアに対して、組織にとって都合が悪いという理由で、人事評価で低評価するような残念な管理職も存在している。このようなことをすれば、声を挙げにくくなりますます労働問題の解決から遠ざかる一方である。
o08usyu7231.hatenablog.com
一方、少数派ではあると思われるが、納期を遅らせるという選択肢もある。ソフトウェアエンジニアもその他のステークホルダも、無理なく健全な状態でWin-Winになり、これで業務が回るような労働環境と経営を実現することこそが、経営陣や管理職の本来の仕事だ。ソフトウェアエンジニアの犠牲をもって全体を成り立たせるなど、ソフトウェア・ファーストの考え方と真逆であり、経営としては恥ずかしいことと心得るべきである。
ソフトウェアエンジニアは前工程のしわ寄せを、自分達で吸収することを当たり前と考えてはいけない。しわ寄せを受けている現実、ソフトウェアが提供する価値、ソフトウェアエンジニアが犠牲になることの弊害の大きさ、これらをソフトウェア開発部門以外が知っておかないと、ソフトウェア開発は成り立たなくなる。管理職、経営陣は尚更だ。
一方、開発の前工程を司る部門、製品評価部門、製品企画部門、品質保証部門等、ソフトウェア開発部門以外のステークホルダもまた、何か外的要因によるしわ寄せを受け、それがソフトウェア開発部門に連鎖しているのかもしれない。IT業界でいうところの「多重下請構造」の問題のように、業界・職種・業種の構造上の問題を抱えているかもしれない。まずは、お互いの困りごとを全部掃き出し、他部門の現状を『知る』ということから始めるべきではないだろうか？ 困りごとを解決できる／できないに関わらずである。
o08usyu7231.hatenablog.com
「他部門だから」「他社だから」という理由で「言いづらい」「言えない」「言ってはいけない」等と、管理職やベテラン社員が黙らせているのならその姿勢を改めるべきだ。このような風通しの悪さこそが問題であり、部門内だけで文句を言っても始まらない。医療機関のスタッフの大変さ、運輸業界の過酷さ、教員の長時間労働問題、国会・官僚の非効率な働き方、公に報道されるから我々はその実態を知ることになるのである。ソフトウェア開発も同じである。
o08usyu7231.hatenablog.com
経営陣や管理職は、一般の従業員よりも高い視座を持っている。しかし、それは組織内での視座である。本来必要なのは社会的に高い視座である。上述したように、コンプライアンスを差し置いてビジネスを進めるなどあり得ないと考えるべきだ！
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
