世間で言われる無意味な労働、生産性とIT業界内の実態について
こんな記事があったので敢えて書いてみようと思いました。
（１）誰かを偉そうに見せるための取り巻き（受付係、ドアマンなど）（２）雇用主のために他人を脅迫したり欺いたりする脅し屋（ロビイスト、顧問弁護士など）
（３）誰かの欠陥を取り繕う尻ぬぐい（バグだらけのコードを修復するプログラマーなど）
（４）誰も真剣に読まないドキュメントを延々と作る書類穴埋め人（パワーポイントを量産するコンサルタントなど）
（５）人に仕事を割り振るだけのタスクマスター（中間管理職など）
1と2はよくわからないですが、真偽はともかく3番以降はIT業界でも関わる話かと感じました。
■誰かの欠陥を取り繕う尻ぬぐい
そもそも、こんな状態になっている原因って殆どが大規模案件が対象で理由がないとこんな結果にならないです。
もし、これを改善しようとするなら利害関係から清算しなければならないかもしれません。
・システムリプレイスの時に現行システムの納品業者と良好関係を保っていること
・エンドユーザがリプレイスに掛かる費用の妥当性を理解して貰う
・設計段階でやりたい事が全てクリアされていること（後だしジャンケンや納品直前になって御代わりがないこと）
・システム連携に関するデータ連携などの仕様がしっかり連携されて内容が固まっていること
★筆者の経験からすると、結構難しい様に思えます。
只、一つ言える事は「やりたい事」と「やらないといけない事」をしっかり把握した上で参画者全員が意図を正確に理解している事は必要かと思います。
特に「やりたい事」の中には「できたらいいな」がマストになってしまっている事が普通にあります。
少しでも工期に問題が出る可能性が生じる場合、フェイズを分けて必要なものだけを先に早く納品してしまうのも一つの方法でしょう。
不要不急なものまでチャンポンして複雑にさせてしまうと確実にコミット出来るものが不確実でコミットされる温床になります。
多くの場合、製造ボリュームが少なければ比例してバグの発生率も下がります。
（システム全体に掛かる様な重要な場所を触ってしまうのは例外です。）
■誰も真剣に読まないドキュメントを延々と作る書類穴埋め人
小規模はともかく、炎上案件や大規模開発になると、大抵はドキュメントの意味を成していないパターンが多いです。
理由は開発途中で大きな仕様変更などが発生したり、カスタマイズした時に手が足りない時は設計書よりも納品する方が優先されてしまいます。
結果、ドキュメントは納品に含まれていても真面目に記載されていないケースが多いです。
★本来、ドキュメントはエンドユーザに対してアジェンダを定義し、開発を円滑に進める為に必要な作業です。
所が炎上してしまうと、ドキュメント作成や製造する時にレビューを省いたりしてしまう事が地方によっては実際にあります。
結果、整合性が取れていないものが出来上がって更に問題を難しくさせて人を増やしてとにかく品質よりも納品を優先してしまう。
仮に品質を優先したとしてもサーバー導入構築手順の内容に矛盾が無いか確認が出来ていないケース（バックアップやクラスタなどの既製ソフトにバグ改修のパッチが当たっていない、特定機器にファームを更新しないまま古いバグを持っているなど）も実際にあります。（ダブルチェックやトリプルチェックまで出来ない。）
わりかしよくあるのがJUnitを通すのが目的になっているパターンです。
JUnitは本来、想定されるデータに対して意図する網羅になるかのテストですが、修羅場になると想定データがそもそも不明とか実績を上げる為にデータはどうでも良くて網羅させる事が目的になってしまう事が普通にあります。（井上喜久子17歳です💛オイオイッ！）
それはもはやJUnitを通す意味がそもそも無いです・・・
しかし実際には上からの指示なのでエビデンスや担保として取るのが通例です。
（そしてJUnitに時間をかけて作った割に後に大きな仕様変更が入ってしまい、どうにも動かない扱いに困ったゴミになっていたりします。
修羅場プロジェクトは巨額負債者と同じ様な負のスパイラルロジックに浸っている事が多いです。）
アタタ、ワチョー！・・・もう、お前は既に死んでいる。
by ケンシロウ
指針の一つとしてドキュメントからソースに変換するフレームワークも実際に存在はしているのですが、結局フレームワークのメンテナンスに膨大な労力を割いてしまいます。（膨大な労力を割いた割にPG補完が必要になるのでドキュメントも修正、本来の理想からズレてしまっている。）
そういう訳で出来上がったソースコードから一定のフォーマットで日本語に変換するツールを作ってドキュメント作成を半自動化させるのも一つの方法ではないかと考えます。
昨今の事情を考えるとAIを利用する事で一定の精度は保たれる気がしています。
■人に仕事を割り振るだけのタスクマスター
恐らく、IT業界だけで言えば珍しいパターンかもしれません。
（ひと昔前は中抜き業者がこれに相当してはいましたが。）
多くの場合、中間管理職の立場は平社員に毛が生えたくらいで上からも下からも色々言われて責任を追及される立場にあります。
タスクが正常に進行できない場合、特に中小企業のプロパは責任持ってはみ出た製造などを自分で穴埋めする必要が出てくる事も普通にあります。
★大手に派遣出向した時に一部、該当する事例も経験していますが割と稀です。そういったプロジェクトはPMOがまともに機能していないです。
ＰＭＯは宛にせず、抗議して不味い所は対応を考えて貰うか、場合によっては引き取るくらいしかないです。
■まとめ
わりかし、これを書いてしまうと一般的に批判されそうな話になるのですが、そもそも論で折衝の時点で「無駄な時間が多い」というのが筆者の感想です。
これは筆者だけではなく、別の方でnoteを使っておられる方も記事に起こされていました。経歴はこんな方です。
・文系卒業（英文科？）
・上流経験（Sier企業）（なんとなく就職して給料が安かったので転職）
・外資系でPM（英語必須）経験（給料は良いが技術が無い事に気づいた）
・下流のPGを志望（給料が安かった）
・フリーに転身した（上から受けるだけで面白くなかった）
・起業して現在は30代で社長（CEO）
※筆者自身は2001年のＩＴ不況真っ盛りで就職し、紆余曲折してきた筆者からするとうらやましい限り。
この方の言い分にもあったのですが、「折衝時に無駄な時間が多い」と発言されています。
実際には機械的に話を進めてエンドユーザがついてきてくれるかどうかという話で、客層次第とは思います。
例えば新規顧客に仕事だけの会話を断続的に続けた所で面白くない話にユーザが興味を持ってついて来てくれるかと言えば、それは恐らく違うでしょう。せめて一つや二つの笑い種は必要に思います。
只、既にコミュニケーションが取れている顧客との間で、30分会話しても仕様が決まらないのに更に時間を使って、ああでもないこうでもないと解決方法を探した挙句、結果は話が纏まらないという話は結構あります。
これは発注側にも受注側にも負担にしかならないでしょう。
（ヒアリングに5～6時間とか普通に使われている。）
凡そ、10分程度会話して話が纏まらない場合は、掘り下げた要点や課題だけをヒアリングして次回に幾つか選択肢を作って提案できるならば、それが恐らくはベストな選択です。
その他で恐らく肝となるのは以下でしょう。
・いつまでも仕様を曖昧にしない事
・製造段階で参画者全員が設計意図をしっかり理解出来ている事
・基本設計までの時間を可能な限り正確かつ早く済ませる
・製造段階で発生した類似ロジックは情報共有して共通化に倒す（誰かに一任するのが望ましい）
・品質指標を作っても効果はそれ程でもない
・ブルックスの法則を頭に入れておく
★いつまでも仕様を曖昧にしない事
時間経過に比例して炎上リスクを高める結果にしかなりません。
調べもせず確認や質問するのもどうかとは思いますが、多くの場合は恰好つけて「完璧に把握しています」という鄭で発注側と会話して発注側が受注側のやろうとしている事が実際には見えていないケースが多い様に感じます。
★製造段階で参画者全員が設計意図をしっかり理解出来ている事
参画者が設計意図を理解していない場合、かつそのまま放置されてしまった日には悲惨です。
場合によっては大きな手戻りを起こしてしまうリスクを生みます。
これはプロジェクトの運用次第で、特に1言ったら10くらい理解を求めようとする体質の企業は確率的に意図しないものが出来上がってしまうリスクを高めます。
特に「それくらい聞かなくても理解しろ」と言われる様なプロジェクトになると、確認も簡単に出来ないので結果として本来の方向とは乖離したものが出来上がってしまいます。
★基本設計までの時間を可能な限り正確かつ早く済ませる
筆者が経験してきた限り、テストに時間を幾ら割いても無駄はありません。
よく、必要最小限で人を割り振りたい理由でギリギリになるまで人をアサインしなかったり、ギリギリになるまで基本設計が片付かないパターンは普通にあります。
筆者が経験してきた限り、多くは開発規模に比例してテストに割かれる時間は軽視されています。
海外では品質はテスト時間に比例すると言われており、実開発工数の約2倍以上のテスト期間が無ければ品質担保は出来ないそうです。
日本では「製造者≒仕様を把握している」のでテスト工数は半分～1/3以下で見積もられています。（この考え方だとブラックボックステストはほぼ確実に軽視される）
炎上案件になると単体テストをスキップして結合で吸収するパターンも普通によくありますが、結果的に品質の担保は厳しいです。
提起された「バグを生まない環境」を構築するには、予定工数から2倍の期間を担保した上で設計から製造までの期間を前倒しする必要が出てきます。
予定工数2倍はイレギュラーケースなどを踏まえています。
一般的に完了出来る想定の工期から2倍を取っていれば、確実に納品できるであろうという艇で概算している会社が多いです。
但し、実際にそれでも工期が収まらなくなる原因は色々あります。
更に言えば、発注者側の意向を踏まえて実際には提案する工期が認められない（現行保守契約期間の都合など）ケースも多くあります。
主なリスクとしては以下でしょうか。
・データ移行が予定通りに進まない（現行データを貰えない、データも資料も正しく貰えても想定にない不可解なデータが存在するなど）
・納期直前で仕様が変わってしまう
・単体製造が凡そ完了した後、テーブル設計が数日単位で大きく変更される（当初設計が破綻している）
この様なリスクを回避する為にも、設計に一定の時間をかけて理論的に精査する作業は必要なのですが、設計～製造までの期間をいかに短期間で楽して仕様上の範囲で確実なものを作るかが鍵なのではないかと筆者は考えます。
考えられる方法の一つとしては基本設計をした人が詳細設計に近い所まで仕様を落とし込む事でしょうか。（つまり沢山の文章を作ったりする手間よりも図を主体にしたアジェンダを重視し、製造者が詳細設計を行う場合は機能単体の概要や利用テーブルと後続処理のデータ連携を重視させた方がドキュメント修正の手間も軽減出来て無難な気がします。
例えば良し悪しがあれど例外が無い限り、画面項目名とテーブル項目名を規則的に一致させておけば保守の観点や規約作成の手間を考えても簡略化できる一つの案になるでしょう。
規約書のヘボン式などを参照して命名規約に従って第三者がチェックして・・・といった手間が削減されるでしょう。
チェックはマクロを作って機械的にチェックできる規約にすればそれこそ、数秒で正確にチェックできます。
最も、図を作ったり修正するのに時間が掛かる場合は本末転倒になってしまいますが。）
★製造段階で発生した類似ロジックは情報共有して共通化に倒す
類似ロジックを増やして嬉しい事は皆無です。
カスタマイズ都合などで纏めると都合の悪い場合は類似ロジックを敢えて作る事もありますが、多くの場合は非生産的です。
・バグの温床になる
・開発効率が下がる
・メンテナンス性が悪い
また、情報の共有化は未着手の人が同じ様なロジックをまた1から作り始める労力を減らす事に繋がります。
全くロジックが無いものについては仕方ないですが、複数の人が同じロジックを微妙なタイミングでパラパラ作っても労力と時間を消費して望まないリスクを増やすだけです。
★品質指標を作っても効果はそれ程でもない
こんな事を書いてしまうと、批判が起きてしまいそうなのですが。
例えば製造時に最低ラインのバグ発生率の指標を作り、バグ件数を一定数出せばその機能は品質担保が出来るという考え方です。
しかし、特段に言及するならば炎上案件で実際に現場で起きている事の多くは、品質を担保している訳ではなく「バグ発生率を担保する為」に指標に準じちゃっています。
そうでもしないとテストが完了しないからです。
例えば以下のケースであれば品質指標を作っても一定の成果を出せるでしょう。
・敢えて意図して仕様書を100％正する体制（客先に許可が必要）
・コーダー相当のスキルレベルが多い
（本当に問題がありそうなもの等も含めて一切確認しない人が多い）
・一般流通しない特殊言語ないし比較的新しい言語が導入された
・作りがオブジェクト指向ありきで継承を多用している様なもの
※オブジェクト指向ありきで継承使ってガッチリ固めている作りは品質指標があった方が良いです。想定から外れた動きをする可能性が出ます。
本来は製造者はロボットではないという意図があって品質を担保する為に「必ずイレギュラーを洗ってバグを出して潰せ」「結合以降で単体バグを出すと収拾がつかなくなるから潰せ」という意味で指標を作っているのですが場合によって、基準目標値を作ってもバグが出ないものは出ないのです。
理由は例えば開発者が先取りして製造周辺全体の仕様を把握して製造していると、本人が予測可能ないし知る以上のバグが出る筈がない訳です。（つまり製造者がドジっ子なら発生率が担保されて「品質保証」した事になるが、キリっとしている人には発生率は担保されない。
更に大規模になると上層から流れたデータがどんなデータになるか正確に認識出来ていなければテストケースと品質指標を設けて第三者が頑張ってレビューイとなって漏れてしまう。正確なデータが無い限り、誰にも正解がわからないから。）
ですから、バグが発生しなかった場合の事を考えて予め意図したバグを仕込んで作っておくような本末転倒な作り方をしなければならない人が普通に出てきます。
例えて言うならターゲットを予め殺しておいて東郷（ゴルゴ13）が恰好つけの為に演出で渋い顔でライフルを握るという・・・東郷もおったまげですね。意図がズレているので本来はやってはいけないのですが、特に炎上案件になると無理なスケジュールで物が出来ないと不味いので踏み倒してしまいます。
この品質指標は単体テストの段階で求められる事の方が多いのですが、実際には結合まで発生したバグ発生率を統計化し、結合以降で緩い目標として求めるのが正しい運用の様に思えます。
何故なら規模の増大に比例して結合より前の段階で正確なデータや完璧な仕様が固まっているケースは確率的に下がるからです。
大規模開発の場合、大半が移行案件相当が予測されますが、DB設計も同一になるとは限りません、多くの場合は何等かの形で変更が発生します。
DB設計やデータ内容に変更が限定的で明確化される前提であれば、正解が見えている訳ですから単体レベルで品質担保ないしレビューをしっかりやっておくべきものと思われます。
★ブルックスの法則を頭に入れておく
補足程度になりますが、炎上案件で人を増やす際に人を増やした方がメリットが出るかを予め計算しておく必要があります。
例えば2～3か月後に一次納品が決まっていて50％以下の進捗であれば、とにかく物を作ってしまわないと話にならないので品質は度返ししてダミーレベルだったとしても作り切ってしまう必要があります。
所が製造フェイズが終わった後に人が圧倒的に足りない状況になったとしても人を増やして補完できるかは参画者とプロジェクトの運用次第です。
大抵はプロジェクト運用が失敗しているので人を増やしても効果は望めない可能性の方が高いです。
何でそう言い切れるかと言えば、人を増やすと比例して認識誤解の確率が増えるので運用失敗なら経緯を知っている人を固めないと進まないです。
そして人を増やして失敗する最大の理由は技術供与や問題点などを洗いざらい共有しない事です、ぶっちゃげ本気で余裕がないという話です。
自分の範囲だけで一杯だったり全てを教えるキャパが無い所に作りこみがが不味いなど経緯や状況を知らない人を入れても余程、確認やコミュニケーション力を持っていない限りはおなざりになってしまいます。
※理由３：タスクの細分化には限界がある
この記述には若干、語弊があります。
タスクが割り振りできなくても、ダブルチェックやトリプルチェックないしテスト設計やテストデータの作成など、割り振ろうと思えば幾らでも割り振れます。しかし日本の開発は殆どの場合、縦割りなのでブラブラで非効率になっています、このような仕事のやり方は改善すべきでしょう。
結果、テスト設計などが不味いとテスト工数に時間を割いていないのでクソみたいなバグが発生しやすくなります。
・・・
とは言っても、実際には色んな問題が出て難しいというのが現実かとは思います。
おまけ：
蛇足的になりますが、この記事を読んで頂いた方に類似した記事をリンクしておきます。
どうか「パトラッシュ、僕もう疲れたよ」とか言わないで・・・（泣）