概要
人材を活用する
トラブルの要因は技術よりも人間が大多数
書籍
技術的な問題がプロジェクトの失敗の主要因となることは少なく、
人間的な問題の方が主要因となる。
にも関わらず失敗の要因を技術のせいにしがちである。
現実
過去参加してきたプロジェクトで失敗要因として最も多いのは
・受注段階での無理な納期設定
受注担当や、スケジュールを決めるPMが技術自体に疎かったり
プロジェクトで利用する主要技術分野に疎かったり。
ある程度無理を承知で、受注するために安売り＋短納期で仕事をとったものの
後は徹夜で何とかしてね、的なことも。人の問題か。
・お客様-元請け間、元請-下請け間のコミュニケーションミス
要件、設計内容の大幅な齟齬。
お客様が立場的に強すぎるがゆえに無理な要求も飲まざるを
得なくなって最終的に炎上、など。
これも技術自体とは関係ない。
・技術者の技術力不足
一見、技術の問題に思えるが根本は採用と教育の問題＝人の問題。
未知の新規採用者と協力会社が大半のプロジェクトなど博打ですね。
システム開発はマニュアル作業ではない
書籍
ファーストフードのバイトや工場の単純作業のように
プログラマーを扱う開発現場が多いが、システム開発は知的作業のため逆効果。
ものを扱うように開発者を扱うのは生産性を下げる。
開発者が心地よく能力を発揮できるように配慮するのが正しいマネジメント。
現実
下請け大量採用で詳細設計、製造分業の烏合の衆体制。
更に「誰でもいい」レベルでテスターを採用して一斉手動テスト。
プロジェクトが終わったらノウハウは消える。
実際そのような火事場プロジェクトを裏で支えるのは、真に技術力のある技術者。
アルバイト10人を雇うより、職人プログラマーを1人雇ったほうが遥かに生産性が高い。
あるプロジェクトでは平均20人体制で開発を行っていたが、終わってみれば
プログラム設計・製造・自動テストの5割以上を一人の優秀な技術者が作っていた。
それほど生産性には差がある。残りもほぼ3・4名の主要メンバーが作成したようなものだった。
特に技術を知らない上に業務も詳しいわけではない設計専門の自称「SE」の
作成した詳細設計書はひどいものでほとんど使い物にならなかった。
触媒
書籍
さほど技術に詳しいわけではなくても、チーム間・内のコミュニケーションを円滑にする
「触媒」となる人材は貴重。
現実
なかなか数値的な成果が見えにくい話題だが、確かに。
ある開発で、スキル的には未熟なAチーム。スキル的には成熟しているはずのBチームがあった。
AチームはムードメーカーMさんを中心に和気あいあいと助けあいつつ、モチベーションを保って開発。
Bチームは特に連携がなく、各自がプロジェクト全体の状況すら把握していない状態で開発。
結果、Aの方が品質・生産性が高くなった。Bは特に認識齟齬による根本的なバグや連携ミスが多々あった。
ただ、この話もコンテキスト次第かなと。
小規模な開発だと、実力は無いがコミュ力が高いような人がいても仕事を回しきれないだろうし。
余力の重要さ
書籍
余力がないと、効率化・工夫・学習などがなくなるため人材が育たず、
結果として品質・生産性が上がらない。
現実
常時火事場のプロジェクトにおいて、各自の問題解決能力が不足している場合
学習する余力・モチベーションも無いため事態は改善しない。
学習マニアの自分ですら、相当学習量が落ちた。
定時勤務で余力の出た最近から見ると、前職でこれを試しておけばもっと改善できたのに
という手法が多々発生。火事場の状況では体力的な事情も含め発想力が狭まる。
余力のあるプロジェクトでは、よりよい工夫をしたり、学習をしたり、別の新たな手法を
調査検証する余力があるため長期的に見ると品質・生産性が向上する。
ここで特徴的なのが通常自己学習しない開発者は技術力が極めて低いことが多いのだが
余力のあるプロジェクトでは業務自体が学習効果を持つ内容になっているため、
一般的な無学習開発者よりも技術水準の高い技術者が多かった。
生産性のコストに退職・退場コストも含めるべき
書籍
短期的に開発者を酷使して使い捨てる手法は、優秀な技術者を手元から
逃すこととなり、計り知れない損失がある。
同レベルの開発者を採用することは困難であったり、他の開発者を
同レベルまで育成するのには多大なコストがかかる。
現実
この人は仕事が出来る、と思った技術者が技術力重視ではないプロジェクト
に参加した場合ほとんど例外なくプロジェクトの区切りで退場していく。
ここで面白いのは出来る技術者はプライドが高いのか、プロジェクトのリリースまでは
残ってくれることが多いことか。ひどい状況に悪態をつきつつも、リリースまで
最善を尽くしてくれる。
そして、コアメンバーとしてほとんどのノウハウを蓄積した上でいなくなる。
前にプロジェクトの振り返り資料に、プロジェクトの良かった点として
「ある技術者Aさんの技術力」と記載して提出したのですが、管理者層に大笑いされました。
そのぐらい、技術力なんてとるに足らないものと考える管理者が多いようです。
※ある技術者Aさんはほとんどバグも出さずに、保守性・可読性の高いコードを他担当の
10倍ほどの生産性で作り、システムのパフォーマンスも場所によって何10倍・何100倍に上げ、
誰も解決出来ない難しいバグをいくつも解決した。
目標達成と対応方法の取捨選択
書籍
ダメな開発の場合は、コスト増（良人材の採用や増員）、開発のスコープの縮小（リリース対象を減らしてもらう）
などの対応をせずに品質を犠牲にする。
品質の犠牲は主に既存メンバー酷使による品質の低下、テスト等必要な作業の省略による品質の低下。
開発者の酷使＝＞大きく分けてサボるタイプか、辞めるタイプに別れる。
前者は残業代の分だけコストが上がっただけで成果物の価値はさして変わらない。
後者は大きな損失となる。
またテストの省略等品質を下げることはやる気のある開発者のモチベーションを下げる。
現実
まさに書籍の記載通り。
恒常的に長時間の残業がある開発現場では
A・効率良くサボるタイプ（遅刻や欠勤を意図的に増やすタイプ）
B・職場でサボって給料だけもらうタイプ
C・優秀で真面目に働くがプロジェクトの区切りや途中でやめていくタイプ
のようになっていた。
気づくと対して働いてもいないのにコストばかりかかるBのような人ばかりの
現場になっていきます。
また普段は非常に技術力が高くバグを出さない開発者も、無茶なスケジュールで作業を依頼されると
作業の質を落として期日を守って対応したりします。
