システム開発が遅れた時の対処法

2019年2月19日火曜日

システム開発 システム業界問題

t f B! P L

ここで話すのはウォーターフォール開発の話だ。
アジャイル開発の場合は遅れた時は実装機能を減らし、実装を次のイテレーションに先送りにするのがルールだ。
従ってアジャイルに複雑な対処法は必要無い。
生産性が上がらないのであればスクラムマスターが対処するはずでありそれが叶わないのであればスクラムマスターを交代すべきだろう。

システム開発遅延対策とマネジメントの現状

システム受託開発ではウォーターフォール開発が主流であり建前上は要件と納期は厳密に守られる。
但しこれは建前であり実際は発注者や業務担当者は要件をシステム開発前に凍結することができない為、納期も厳密に守れないのが現実だ。
発注元に要件凍結という発注者責任が守れないのなら受注者が納期を守れるわけがないのだ。
そして多くの場合発注者にはその自覚がない。
このままならシステム開発遅延は無くならないだろう。

受託者側にも問題があり適切なアサインやマネジメントが出来なくなっている。
アーキテクトの居ない開発チーム。
プログラミングの出来ないマネージャーやSEをアサインすること。
開発だけ下請けに丸投げにする。
適切なスケジュールを初めから計画できない。
各モジュールや工程の依存関係を把握できない。つまりPERT図などを用いた計画を立てられない。
など、要するに計画や管理の基礎的な知識が無いのだ。
もう一つの問題として法律の知識が無く労働法や民法請負契約や準委任契約、下請法などを守ろうとしない。
遵法精神がなければ残業を無限にやらせようとする。
結果として労働者の労働時間というのは「限られた資源」だという認識が育たない。
これでは計画や管理の知識は必要ないということになってしまう。
日本企業は計画や管理の技術レベルが低いと私は思う。
その原因は残業時間の制限が弱いからではないかと思う。
残業の単価も25%増しでは安い。
欧州なら国にもよるが50%増しだと聞く。
裁量労働制や見込み残業などにより残業代を支払わずにごまかすことも当たり前のように行われている。
見込み残業などは超過分の残業代は支払わなければならないのだが、踏み倒すのが慣習になっている。

これでは時間のマネジメント能力が育つはずがない。
マネジメントの失敗を全て労働者の長時間労働でごまかしてしまうからだ。
マネジメントの本質は「限られた資源」を有効活用することにある。
「労働者の労働時間は無限に消費できる」という認識の中では「限られた資源」が存在しないことになる。
「マネジメントが重要だ」という認識がそもそもないのである。

間違った対処を繰り返す開発遅延

過去の経験や人から聞いた開発遅延の間違った対処法について紹介する。

人手を増やす

遅れたときに遅れを取り戻す為に人員を増やすという対処をとるプロジェクトチームは本当に多いが、予備知識の無い派遣など外部人材を投入すると確実に失敗する。
遅れているのに外部人材に説明教育する仕事が増えて主要メンバーが益々本来の仕事にリソースを回せなくなるからだ。
人員増加で遅れを取り戻せるケースは複数のサブシステムからなるシステム開発で一つだけ送れたときに他のサブシステムの人員を投入する場合である。
サブシステム全体で規格や開発手法、ミドルウェア、設計図などを共有しているから、ある程度システムの知識を持つメンバーが加勢するから成功するのだ。
予備知識の無い外部人材を納期間近の炎上案件に投入しても戦力にはならない。

長時間労働で頑張る

通常、理由もなく遅れることは無いのだが、遅延の原因を明らかにしないリーダーは、何も考えずに長時間労働で頑張ることで乗り切ろうとする。
予算があれば外部人材を投入して炎上する。
予算が無ければ既存人材に長時間労働をさせて乗り切ろうとする。
この場合も普通は失敗する。

安易に長時間労働で対処するリーダーは遅延の原因を除去しないで長時間労働させる為、ボトルネックが解消されることなく拡大して、いくら長時間労働しても遅れが解消されない。

また、マトモに残業手当や休日出勤手当を払えば、通常残業で25%増し、深夜残業で50%増し、休日出勤で35%増しの賃金を分単位で支払わなければならない。
簡単に赤字会計になってしまう。
安易に長時間労働で対処しようとするリーダーや会社は通常は色々な屁理屈を並べて残業手当を払わない会社だ。
偽装請負も横行している。
そうでなければ採算に乗るとは思わない。
システム開発の半分は失敗するのだから。

長時間労働のもう一つの問題は生産性が落ちることにある。



疲労や睡眠負債の蓄積が労働者の集中力を低下させミスを増やすことは既に明らかになっている。
少し検索すれば分かる話だ。

さらに長時間労働は労働者の健康を破壊する。
毎日4時間残業でうつ病リスクは倍増する。
毎日6時間以下の睡眠時間で認知症リスクが発生する。
7時間以上睡眠を取っていれば認知症リスクは殆ど無い。

「うつ病は怠け者がなる病気」という印象操作を企業がしつこく繰り返すのは、「うつ病はマネジメントの失敗である」という事実から世間の目を背けようとしているからだ。
「過労死も死んだ本人が悪い!」という印象操作をしつこく繰り返していることから彼らの倫理観を信用しないほうが良い。

次いでに言えば「認知症も怠け者」という印象操作が行われているが、これも働き過ぎによる睡眠負債の蓄積の結果だと思う。

つまり企業は過労死で国民を殺すだけではなく、長時間労働でうつ病や認知症などの障害者を量産し、社会保障費を不必要に増大させているのだ。

社会保障費の増大に文句を言う経営者は多いが医療費の歳出を減らす努力をしている会社の話はあまり聞かない。
残業を制限するだけでかなりの社会保障費の歳出削減に繋がり、企業の社会保障費負担の軽減に繋がると思うが、彼らは「社会保障財源確保のために消費税増税が必要だ」と叫ぶ。
本当にバカだと思う。
消費税増税で消費が減り売り上げが減って経営が苦しくなることが解らないのだろうか?
通貨発行益が使えるので財源に問題はない。
根本的にマクロで考える能力が無いのだろう。

原因(ボトルネック)を調査して排除しない

開発遅延には必ず原因(ボトルネック)がある。
遅れたときに人手を増やしたり残業増やしたりといったマンパワーと根性で対処するリーダーは通常、遅延の原因を調査して明らかにする意思も能力もないことが多い。

良く有る遅延の原因は、
発注元の業務担当者が非協力的。
要件が凍結出来ていない。
設計が曖昧。
依存関係を把握できていない状態で計画を立てている。
アーキテクト不在。
10人を超えるチームを一人のマネージャーがマネジメントしている。
初めから見積もりが間違ってる。
見積もりに基づいて計画を立てずに、発注元の一方的都合を押しつけられて開発計画を立てる。
それぞれの遅延の原因はそれ自体を除去しなければ解決しない。
ボトルネックは拡大を続けて遅れは深刻になる。
しかし多くの場合、リーダーはボトルネックに解消しないでマンパワーを投入して根性で対処する。
「根性で頑張る」という言葉は思考怠慢以外の何物でも無い。
繰り返すがボトルネックを解消しなければ遅れは取り戻せない。

開発遅延時の正しい対処法

最初に誤解の無いように言っておくが「開発遅延時の正しい対処法」を実施したからといって遅れを取り戻せるわけではない。
今以上に遅らせない為の方法論でしかないことは肝に銘じておいて欲しい。
もっとも正しい対処法は「遅れない」ことである。
「開発遅延時の正しい対処法」を実施している時点で「手遅れ」であることは自覚すべきだ。
これらは赤字を最小減に食い止めるの方法にすぎない。

原因(ボトルネック)を明らかにする

大多数のシステム開発プロジェクトが遅れた原因(ボトルネック)を調査確認しないで、開発の遅れに対処しようとする。
開発が遅れたらまず第一に取り組むべきは「原因(ボトルネック)の調査」であり第二に「原因(ボトルネック)の解消」である。
世のリーダー達には開発が遅れたら、原因(ボトルネック)も究明しないで「頑張れ」と発破かけるだけで何もしないバカが多すぎる。

原因(ボトルネック)を解消する

開発チームでは原因(ボトルネック)が分かっても解消しないことが意外に多い。
「解消できない」のではない「解消しない」のだ。
信じられないかも知れないが、次のようなケースが非常に多い。
現在のシステム開発チームは「人的レバレッジ」で開発人員を揃えるケースが多い。

「人的レバレッジ」は受託案件のあるときだけ派遣や偽装請負の形で外部から情技師(ITエンジニア)を調達し自社の社員は1割から2割ぐらいで開発チームを編成するSIer企業の経営方法である。
案件の無いときまで情技師を雇用するのは経営の負担になる為、必要なときだけ情技師を雇用する体制が根付いている。
個人的には「人的レバレッジ」という体制は嫌いなのだが、今はその話をしたいわけでは無い。

この「人的レバレッジ」体制で編成されたチームは正社員が少数になる。
原因(ボトルネック)が分かっても解消しないケースはこの正社員が原因(ボトルネック)になっている場合である。
会社によってかなり違うのだが正社員が原因の場合、一部の「絶対謝らない」タイプの会社のとき、自社の社員が原因で遅れていることを認めないことが多い。
よって自社の社員に関連する原因(ボトルネック)を解消しないで、遅延に対処する。
当然、遅れは解消しないのだが、こんな馬鹿馬鹿しいことを繰り返している会社は多い。

例えば「設計書のミスや曖昧さ」が遅れの原因になっている場合、設計者が正社員なら間違いを認めないケースが多い。
「設計書のミス」を治さないのだから、品質が満たされるわけがない。
遅れを取り戻せるわけがないのだ。

原因解消法(1)発注元の業務担当者が非協力的

これは発注元の上位管理者に相談して業務担当者に協力させるように要求すべきだ。
それができないタイプの顧客なら仕事を引き受けない方が良い。
システム開発というのは業務手順に影響を与える。
システムによっては業務手順が大きく変わってしまうこともある。
だからシステム開発は業務担当者と情技師(ITエンジニア)の共同作業で取り組むべきなのだ。
情技師に丸投げでは失敗しやすい。
だから業務部門を統括できる人物にシステム開発の監督を行って貰う必要がある。
これはマネージャーより上位の存在という意味だ。
通常は大企業でなければ業務部門の上位は経営部門である。
つまり経営部門がシステム開発の監督役を引き受けなければならない。
それができない顧客の依頼は受注しない方が良い。

要するに「顧客を選ぶ」ことができなければこの原因(ボトルネック)は解消しない。

原因解消法(2)要件が凍結出来ていない

要件定義書は本来、発注者が書くものである。
要件定義書に不備があれば依頼を受けた時点で要件定義書の修正を求めるべきであり、不備の無い要件定義書が提供されるまで、受注契約を交わさなければ良い。
要件定義書は見積もりを出す手段でもあるので、要件定義書が提供された時点ではまだ受託開発契約は交わしていないはずだ。

現実には要件定義書を書けない顧客というのが居て、これに対して顧客の代りに受託社が要件定義書を書いてやるケースが多い。
「要件が凍結出来ていない」のは殆どこのケースである。
営業の都合もあると思うのでハッキリ断言できないが、「顧客の代りに要件定義書を書いてやる」のが初めから間違っていると思う。
正しいやり方は顧客と「ITコンサル」契約と「受託開発」契約の二つの契約を交わし、「ITコンサル」契約のサービスとして「システムの提案」と「要件定義書の書き方の指導」を提供し、正しい要件定義書を保証してから「受託開発」契約を交わすのが正攻法だと思う。
「現実はそんなに甘くない」という人もいるだろうが、それをやらなければこのボトルネックは解消できない。
営業の都合で難しくても、「ITコンサル」サービスを安く提供する方向で対処すべきだ。
「顧客の代りに要件定義書を書いてやる」時点で間違いなく「ITコンサル」サービスを提供しているのだ。
そのサービスの存在を顧客が認識しているか否かの違いでしか無い。
認識させましょう。
最悪「無料」でも良いので「無料でITコンサルサービスを受けている」ことを顧客に認識させましょう。
これをやるかやらないかだけで大きく違うと思います。
(敬語になってしまったので元に戻す)
だ!

原因解消法(3)設計が曖昧

これは顧客と関係無く受託社側の問題だ。
(多重請負を除く)
ハッキリ言って「設計が曖昧」になる原因は設計者と開発者を別の人間に担当させるからだ。
設計と開発を同じ人間が担当すれば「設計が曖昧」であれば自分が困るのだから自分の責任で正しい設計書を意地でも書くはずだ。
いい加減な設計書を書いていたら、自分の仕事が完成しないのだから。
この問題は「設計者の能力」の問題と認識されることが大半だが、明らかに計画・管理・アサイン・役割分担の方針、などプロジェクト計画レベルの失敗である。
問題を矮小化して誤魔化すのが当たり前になっているが、「設計が曖昧」の問題が起きたらリーダーやアサイン担当者は自分の問題として捉えるべきだ。
(それができるような人間ならこんな問題起きないと思うが)

原因解消法(4)依存関係を把握できていない状態で計画を立てている

依存関係を把握することが何故必要なのか分からないのなら問題だ。
システム開発には必ず依存関係がある。
大きな枠組みで言えば、
データ構造→バックエンドシステム(サーバー)→フロントエンドシステム(クライアント)
という依存関係がある。
左が依存される側だ。
依存される側(左)が仕様を変更したら、依存する側(右)もそれに合わせて仕様を変更しなければならない。
だから開発工程を計画するときに依存関係が逆行していないか注意する必要がある。
データ構造が確定していない段階でバックエンドシステム(サーバー)やフロントエンドシステム(クライアント)を開発することはできない。
わりとこういう基本的なことができていないマネージャーは多い。
設計工程が完了する前に開発工程を始める計画を立てるバカはとても多い。

この問題を解消する手法は大昔から既にありPERT図を書くことで解消できる。
昔はPERT図を書くのは大変な作業だったのでPERT図を書かないで開発を進めることが慣習になったが、本来は書くべきなのだ。
今はフリーソフトでもPERT図を書くツールがリリースされているので難しくないはずだ。

PERT図を書いてください。

原因解消法(5)アーキテクト不在

アーキテクトというのはシステムの全体の構造の整合性に責任を持つ一級情技師のことだ。
建築家とは別の者だ。

システム開発のリーダーにアーキテクトの重要性に理解の無い人間が少なからず存在する。

(以下棒読み)
アーキテクトを一人決めてください。
それだけです。
それだけでシステムの整合性が取れないという問題が解消します。
そしてアーキテクトを置かなければ必ずシステムの整合性が取れません。

原因解消法(6)10人を超えるチームを一人のマネージャーがマネジメントしている

一人の人間が管理できる人数は10人が限度と言われている。
それを超える人数を管理するならばチームを二つに分けてそれぞれにサブマネージャーを配置しチーフマネージャーが全体を管理すべきだ。
システム開発の場合はアーキテクトとマネージャーを一人の人間が兼任することも多いが、この場合は5人を管理するのが限界だと思う。
一人の人間が理解できる「複雑さ」には限度があるのだ。
アーキテクトを兼任していたら10人も管理できないだろう。
「10人を超えるチーム」を一人に管理させている会社は人間の能力の限界に無頓着で非現実的計画を頻繁に立てている可能性が高いと思う。

さっさと転職をお勧めする。

ちなみにアーキテクトにも複雑さの限界があり、ある程度以上複雑になったら、システムをサブシステムに分割してそれざれにサブアーキテクトを付けて全体をチーフアーキテクトが監督する。

原因解消法(7)初めから見積もりが間違ってる

これも本当に多いのだが「計画を楽観的にしか考えられない」病気というのがあって、この性質は治すことができない。
こういう人間に見積もりを担当させたのが間違いだ。
「見積もり」は慎重な性格の人間に担当させるべきだ。
営業の都合に忖度して非現実的な楽観的見積もりを「出す」あるいは「出させる」人間は多いがそんなことしても会社の損害にしかならない。
会社の信用も失われる。

また、システムやソフトウェアの開発は必ず予想外の問題が発生するもので、見積もりに対して最低でも3割の余剰期間を足すべきだ。
昔「マイクロソフトシークレット」という本を読んだが、マイクロソフトのような自社製品開発している大企業でもソフトウェア開発計画は見積もりの3割増しで計画を立てるそうだ。
20年前のことなので今はよく知らない。
現実には顧客の仕様変更などの外的要因で遅れることも多いので5割増しぐらいが妥当だ。
ギリギリの見積もりは必ず遅れる。

原因解消法(8)見積もりに基づいて計画を立てずに、発注元の一方的都合を押しつけられて開発計画を立てる

そのような奴隷のような発注者との関係は解消した方が良いです。
情技師個人なら転職すべきです。

機能を減らす

システム設計する時は予め個々の機能に(顧客にとっての)優先順位を付けておくべきだ。
A・B・C のように三段階ぐらいでいい。
開発が遅れた時は優先度Cの機能の実装を諦める。
また、最初の契約段階で万が一遅れた時は優先度Cの機能を捨てることを明言しておくべきだろう。
顧客が喜ぶ話しかできないようでは、顧客と現実的協力関係など形成できないと思う。

計画を遅らせる(計画自体を見直す)

計画自体が最初から間違っているならば、まず計画立案者を担当から外し、既に着手してしまった部分を除いて、後の計画を作り直すべきだ。
その再計画中は情技師の稼働を減らして問題の拡大を遅らせる必要がある。
計画の中で問題の無い部分というのがあるのならその部分にリソースを配分して、誤計画部分の再計画をすることもできる。

マネージャーを交代する

開発が遅れた原因がマネージャーにあるのならば引き継ぎコストをケチらずにマネージャーを交代すべきだ。
多くの場合、「替わりの人材がいない」「引き継ぎコストがもったいない」「マネージャーの体面を壊したくない」といった理由でマネージャーを交代しない。
遅延の原因を作ったマネージャーに続投させるなら、問題は解消されず悪化するだけだ。
問題は拡大する前に解消した方がダメージは少ない。

私は大昔に炎上プロジェクトがマネージャーの交代により見事に解消され、黒字になったケースをメンバーとして経験したことがある。
マネージャーの問題というよりも会社のアサインがいい加減で固定した責任者が事実上いない状態だったので炎上したのだが、納期前に優秀なマネージャーに交代して、設計から見直しコードは再利用してシステムを組み直し、見事に品質の良いシステムに仕上げてしまった。
納期は遅れてしまったが、その後追加案件が発生し、順調に終わらせて黒字会計で終わった。
魔法を見ている気分だった。
マネージャーの資質は大事なのだ。
アサインも同様だが。

遅れた時の対処法は決まっている

以上のことから、システム開発が遅れる理由は大体決まっており、その対処法も決まっていることが分かると思う。

当たり前のことを当たり前にやれば深刻な炎上は起きず、少し遅れる程度ですむ。

間違った対処をし、当たり前のことをやらないから、深刻な炎上に繋がるのだ。

この記事に書いた方法など、普通の情技師なら誰でも思いつく方法ばかりだ。
皆、分かっていながら当たり前のことができないのだ。

できない理由は「顧客と交渉できない」「上司に事実が言えない」「多重請負の上位の会社に逆らえない」といったくだらない理由でできないのだ。

こういう体制の不備や無駄な上下関係が本来の開発遅延の原因であることが多いと思う。

体制を改革すべきだろう。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ