ある社内のミーティングで、次のような連絡があった。
「現在開発中の製品◯◯の、機能□□は、ソフトウェア開発工数不足のため、搭載見送りになった」
「限られたリソースの中、色々検討を重ねた結果であると考えられる」
「それでも、周囲からは『搭載すべきでだったのでは』との意見があった」
「優先順位には気を付けようという事例だ」
ソフトウェア開発工数不足で機能搭載見送りというのは、私自身あまり見たことがない事例だ。
関係者の間では賛否両論あったようで、立場によって異なるのは容易に想像がつく。上述の通り、優先順位に気を付けることは然りなのだが、ソフトウェアエンジニアへの負担軽減に向けたの第一歩となる優良事例と考えている。
この記事では、「ソフトウェア開発工数不足のため、一部機能におけるソフトウェアの搭載を見送る」ことについて、これまでの現実によくあることと、なぜこれが優良事例なのかその理由について語りたいと思う。
1.「一部機能におけるソフトウェアの搭載を見送る」ことが発生する一般的なケース
開発中にソフトウェアに搭載する機能が増え、これらを何とかスケジュールの中に押し込まれることはよくあるが、逆に「一部機能におけるソフトウェアの搭載を見送る」ことは珍しいのではないかと感じている。
まず、「ソフトウェア開発工数不足」に限らず、「一部機能におけるソフトウェアの搭載を見送る」ことについて、考えられる理由を洗い出していきたい。
一般的に、もしくは私が過去に遭遇したケースとして多いのは、以下のようなケースだ。
- 必要性が薄く、投資対効果が合わない。
- 製品やサービスの企画、要件定義が固まらない。
- 必要なハードウェアが固まらない、もしくは構築できない。
- 先行開発として性能を評価したが、期待する性能が得られず、対策もない。
- 事業計画に見直しに伴い、要件定義が白紙になった。
主に、開発対象となる製品、構築していくサービスの全容が決まらないことや、上流工程で行き詰まっていると言う理由で、全ステークホルダが合意の上で、搭載見送りとなることが多い。
上記の他、機能搭載見送りではないが、製品の性能評価部門による、定数決め（ソフトウェア制御ロジック自体は既に設計・構築されており、閾値や係数等パラメータの値を、実験による性能評価をしながら決めていくこと）が間に合わないという理由で、完成予定が延期になったことはある。関連するステークホルダとの調整はあってのことだと思うが。
新機能の搭載をむやみやたらに断るのは問題があるが、要否や効果、そしてそれの実現にかかるコストをしっかり見極め、実現すれば効果が高い要求を優先して受け入れることは必要だ。しかし、ソフトウェアエンジニアに限らずすべての労働者において、労働上の安全は全ての土台となるべきであり、ここを脅かしてプロジェクトを達成することは避けなければならないことだ。
「新機能の搭載など、ソフトウェアエンジニアが効率良くサクッとやればいいじゃないか！」
という綺麗事をいう人もいるだろう。言うのは簡単だ。しかし、ソフトウェアというものはそれほど簡単ではない。素人にはわからない、素人には見えない難しさがある。
「効率化」「改善」「時短」等、組織内の一定の努力は必要である。しかし、これらにも限度がある。行き過ぎるとこのような言葉のみが飛び交い、労働者には圧力にしかならないという「ジタハラ（時短ハラスメント）」を生み出すこともある。
2.「一部機能におけるソフトウェアの搭載を見送る」ことが許されないことでソフトウェアエンジニアの労働環境がブラックになる！
私は過去にある製品開発プロジェクトで、ソフトウェア機能の搭載見送り（もしくは先送り）を、要求元に申し入れたことがある。理由は工数不足だ。搭載見送りとする対象の機能を選定した理由は、その機能が無くても製品・サービスとして成り立ち、あまり売り上げに差が出ないと判断したことだ。
しかし、要求元からは
「申し入れのあった機能搭載の見送りはできない」
「それ以外にも削減できる機能はないと考えていだだきたい」
「搭載機能における（要求元にて実施する）評価のスケジュールを調整することで協力したい」
とのことであった。
スケジュール面で協力してもらえるのはまだ救いであるが、最終的なプロジェクト完了時期は変わらないまま、言葉悪いが無理やり押し込まれた形となった。生々しい言い方をすると、ソフトウェアエンジニアに工数を理由に機能の搭載を断る権限など一切無く、工数不足であろうと要求元には関係無く、ソフトウェアエンジニアの立場は無視され、ソフトウェアエンジニアの犠牲の上に製品開発プロジェクトが成り立たせたということになる。
「顧客目線」、「ユーザー目線」を大義名分として、ソフトウェアエンジニアを軽視する場面は、残念ながらよくあることだ。しかも、そのような組織に限って、このような問題点に関して声を挙げると、声を挙げた者の考え方が間違っているかのようにマインドコントロールされ、要求元の考えに従うことが筋であるかのように洗脳される。あるいは、声を挙げた者が不利益を被ることがある。いずれにしても、心理的安全性が担保されない。倫理観が失われ、力関係を背景としたビジネスから抜け出せない。
社会的には問題であるにも関わらず、組織内の管理職やエンジニア自身も、目先の利益を追及しようと、ある程度自分達を犠牲にしてでもステークホルダのために成し遂げることを美徳とする風潮があり、逆に
「断ることは許されない」
「組織の常識・業界の常識」
という風潮が浸透し、結果ブラックになってしまう。昭和で当たり前のことが、令和になってもまだまかり通るという組織体質だ。
3.最近の世の中は労働者への負担にも着目するようになった！ソフトウェア開発もその流れであるべきだ！
「ソフトウェアエンジニアの工数不足で機能搭載を見送る」
という、この記事の冒頭に示した事例は、前章に記載した事例とは逆に、ソフトウェアエンジニアの立場を考慮した優良事例である。
日本の企業では、前章の事例のように、「顧客第一」のもと、困難な状況でも要求を実現し、更に、製品・サービスを安く提供することが絶対的な正義とされる風潮が強い。それが労働環境の悪化に繋がるという弊害があるが、労働者の負担を軽減することを「甘い！」などと称して、なかなか受け入れらえない昭和的風潮が今でも残っている一面がある。
ただ、最近の世の中では「働き方改革」の流れもある。労働者側の立場が考慮されるようになってきた。労働者に無理を強いて、力関係でビジネスを成り立たせるなど、切り捨てるべき昭和的負の遺産である。
その一例が、2021年3月に、多くの鉄道会社において終電が30分程度早まり、夜間の線路点検の時間を確保し、点検作業員の労働環境を向上させたことだ。「働き方改革」以外に、ちょうどこの頃は「コロナ禍」で利用者が減少している鉄道において、利用者が少ない夜間の運行を早めに切り上げるという、多くの方々にとって合理的な施策だ。線路点検という利用者の命を支える安全に関わる作業を、夜間という過酷な労働環境の中で実施している作業員の方々に対して、我々利用者側はひとえに敬意を表するのみである。
o08usyu7231.hatenablog.com
これは、ソフトウェアエンジニアで言えば、搭載機能数を削減することで、残りの重要な搭載機能への対応工数を確保し、ソフトウェアエンジニアの労働環境を整え、製品・サービスの品質をしっかり確保するという考え方と全く同じなのである。特に、安全に関わる製品のソフトウェア開発に携わっているソフトウェアエンジニアは尚更である。
4.アジャイル開発の長所を活かすとともにコンプライアンスも意識すべきだ！
「ソフトウェアエンジニアの工数不足で機能搭載を見送る」
冒頭に記載した事例でも、搭載を見送る対象の機能の選定については、比較的重要度や優先度の低いものとしているはずである。
ソフトウェア開発の開発形態として、アジャイル開発はよく用いられる。搭載予定機能をストックし、その中から重要度や優先度の高い機能を、短いスパンで設計、実装、レビュー、テストを経て搭載する。この１サイクルのことを「スプリント」と呼ぶことがある。重要度や優先度の低いものは次の機会で良い。もしくはマーケットの動向や要求の変化次第では、搭載しないという選択肢もある。要求の変化に対応しやすい点は、ウォーターフォールモデル開発と比べて、アジャイル開発の利点だ。
アジャイル開発と言えば聞こえはいいが、開発手法だけですべての問題が解決するわけではない。
「重要度や優先度の低いものは次の機会に」と上述したが、同じ搭載機能でもステークホルダによって重要度や優先度が異なる場合、調整を怠り、「全部搭載せよ」というステークホルダからの圧力や、権限を持った人の鶴の一声によって、ソフトウェアエンジニアは簡単にブラック労働に巻き込まれてしまうことになる。
一部の人に圧力をかけて、ビジネスを成り立たせることが無いよう、コンプライアンスの意識向上やソフトウェア開発の難しさや重要性の認知も必要だ。
「ソフトウェアエンジニアの工数不足で機能搭載を見送る」
ことは、コンプライアンスの面でも優良だ。
o08usyu7231.hatenablog.com
日本は、「顧客第一」のもとサービス精神が行き過ぎており、要求する側の立場が上といった感覚に陥ることが多い。
日本は元々製造業が強いと言う歴史的な背景から、モノ・ハードウェアを中心とした製品開発が依然として多く残っており、IT・ソフトウェアは業務効率化のためのツール程度と軽視されてきた。
このような理由から、ソフトウェアエンジニアの労働環境は過酷なものとなり、安心して働けるか否かは、ソフトウェアエンジニア自身のスキルの問題よりも、プロジェクトをマネジメントする人のスキル、管理職のコンプライアンス意識、発注者側のモラルといった外的要因が少なくない。
o08usyu7231.hatenablog.com
ソフトウェアエンジニアがスキルを高めることはもちろん必要なのだが、これに加えて労働分野やコンプライアンスについての知識を深め、フィジカル面もメンタル面も安全性が担保された土台の上で、高いパフォーマンスを発揮し、製品・サービスの提供に貢献していただきたい。
また、ソフトウェアエンジニアはそのような労働環境を提供できる企業へ行くべきであり、そのための準備も普段から怠らないことが大切だ。
30代後半〜40代前半は、キャリアチェンジも容易ではなく、かつ家庭がある方が多く、自由度が低い、リスクが取りにくい、といったキャリアを築く上では、あまりに大きな課題を抱えています。RYOMEIのトレーナーも同じ世代であり、自身も子育てと仕事の両立に試行錯誤していたり、順風満帆にキャリアを築いているわけではないからこそ、受講者の痛みに共感しながら、一緒に考えていくことができます。
困難な状況にある方こそ、お勧めできるサービスです。是非、一歩踏み出し、人生を変えてみませんか？
