ロボット屋さんMisskeyサーバー立てたのでアカウント作って！ 
明るいデスマーチ研究会 Vol. 1で出て来た事例とコメント等
Fri Apr 18 16:30:59 JST 2014 (modified: Tue Sep 19 13:17:34 JST 2017)
views: 1478, keywords:事例が無限大,デス研,デスマーチ研究会 この記事は最終更新日が7年以上前のものです。
（2014/4/19追記: はまださん記事）
どうも上田です。
構想数ヶ月でやっとこさデスマーチ研究会の第1回をやりました。最初の会はどういう催しにするかを話し合うつもりで集まり、ミーティング形式で行いました。が、もう既に事例の嵐が吹き荒れる展開になりました。念のために言っておくと、第1回はちゃんと落ち着いて仕事をしているプロの方々を私の方で選んで集まっていただいたのですが、昔の惨事の話が出るわ出るわ・・・。みんな笑いながら話をしていたことは強く主張しておきます。
一方で課題もあり、本当はこの会は、TechLIONみたいに基調講演的なものと、実際に現場で頑張っている人の話をいくつか聞いて、みんなでデスマの起こる集団心理等を理解するエンターテイメント的な会にしたいのですが、やはりテーマがテーマだけに、ネタを持っていてもステージでしゃべってくれる方は少ないんじゃないかという話にもなっております。もうちょっとやり方を考えるのと、前に出て話してもらえる人が現れるのを待つために、次の会もミーティング形式にしようかなーと考えております。
それから、一つ一つの事例についてもうちょっと深く話をお聞きしたいなーと思いました。
第1回で出た話とコメント
さて、第1回の成果をフィードバックするために、その場でどんな話が出たかと、それに対して私の方でいろいろコメントしていきます。どの事例も断片的ですが、たくさん出たおかげで、だいたい何がテーマになるか、洗い出しができました。
そもそもデスマーチとは何なんだろ？
まず、デスマーチの定義から。この会限定の定義であっても構いませんが、共通認識が必要です。とあるコンサルタントが書いた怪しい本には「正常値の50%を超えた状態」という定義が書いてあったのですが、はっきり言ってわけわかりません。
話をしているうちに、過酷だと言われる業種は何だろうということで、次のように挙りました。
- 建設、出版、医療・看護・介護
- （上と重複するが）いわゆる「聖職」
ただ、デスマーチというのは（あくまでイメージですが）成果が長い期間の後に得られるものに対してしか言わないんじゃないかという話になりました。確かに単に激務だからデスマーチという話ではなくて、何か集団でものを作っていくときの膠着状態が発生している状況や、先が見えない感じがないとデスマーチとは言わないかと思います。だからまあ、上に挙げたものではデスマーチが起こるのは建設、出版となり、それに加えてソフトウェア開発ということになると考えます。
もう一つ私から申し添えると、ソフトウェア構築というものは出来上がるまで動くかどうか分からず、また、目に見えないという度合いが建設や出版よりも強いです。いや、プロなら進捗が分かるのですが、素人（上司とか営業とか）には全く分からんということで、いろいろ不幸が起こります。
一番、本質を付いた発言に「出口が見えないという感情」というのがありました。経験した人でないと実感が湧かないかもしれませんが、その通りかと。
デスマーチの死亡率は？
昔の銀行のプロジェクトの話。何千人規模のプロジェクトで何人死んで何人失踪したかという話題が出ました。たぶん3,4年間くらいの数だと思われます。特に大学生にはお伝えしておかなければなりませんが、大人の仕事は権力とかお金の存在が無視できず、利害の対立が起こるとどんな業種であろうが人が死んだり失脚したりします。これはSIerに限った話ではありません。それが嫌なら私みたいにアホな顔してフリーダム！とか叫んでいないといけません。
- 大手ベンダの偉い人3人: 自殺
- 大手ベンダの営業: 1人失踪。後日南の島で発見される。
- 大手ベンダのプログラマ（昔はそんな人たちもいたようです。今コード書く人いるのかという感じですが）: 3人くらい失踪
- 精神疾患: 数知れず
話を聞いていてまあ標準レベルだよなーと思いました。SIerの仕事というのは、建設業（というと建設業の人に叱られそうですが）と同じくらい危険ですので、特段驚く話でもないかと。ただ、こういうプロジェクトばっかりだと、私のような気の弱いタイプの人間はプロジェクトが始まったとたんに背筋が冷たくなって仕事が手につかないので、できることなら死亡率を下げたいものです。
また、ひどい目にあって業界を去る人がいるのは残念なことですが、少しトラウマを持って業界に残ってしまった人の性格が悪い方に変わってしまうことが心配です。ダメな徒弟制度で不幸せが連鎖します。
ここらへん、定量的に議論ができると有益かと。また、こういうことを扱った文献はおそらく山のようにあるはずなので、まずはこれを読めとかいうのがあれば教えていただきたく。
勤務時間で負荷を計測してはいけないのではないか？
休日と言っても誰しも死んだように寝ているわけではなく、体を動かしたり、プログラムを書いている訳ですが、勤務時間もそういう感じなら疲れないでしょう。勤務時間が長くなっても楽しく仕事ができれば疲れないという意見が出ました。逆に、勤務時間が短くても精神的に多大な負荷がかかることがありますし、だいたいデスマーチ状態だと、何にもしないで拘束されている時間がかえって増えることがあります。こういうときに、何にもしてなくてもストレスは感じます。
ストレスを感じている時間を計測して、体感勤務時間というものを提唱すると面白いかもしれません。
（体感）勤務時間関係で出た話としては、次のようなものがありました。
- 意見が尊重されず仕事だけ降ってくると疲れる
- 土日出勤で家族の理解が得られないと辛い
- インフラ系は仕事が無いのにいなきゃいけない時間があり、このときに他からやっかみが来るとしんどい
利害関係をちゃんと整理すればデスマーチが分析できそうだが？？
主に私からの話です。プロジェクトを正しく終わらせるという全体の目標と、健康を維持して家族との時間を持つなどの個人の正当なエゴや、あるいは邪悪なエゴの関係を整理しないとデスマーチの分析にならんということです。
特にこの分析を難しくしている要因に、「みんなでがんばろー」的な日本人的な考えがあります。経営側の要求と労働者側の権利という単純な図式に「経営側になぜか献身的に貢献したい労働者の感情」という項目を入れないと分析できないというややこしい状況で、話をまとめる役の私としては混乱しており・・・。
[caption id="attachment_2846" align="aligncenter" width="150"]
ホワイトボードに図を書いてデスマーチを解釈しようとしたが、難しすぎて撃沈。ていうかシャツ出てるし腹も出てる。[/caption]
私からは、労働者として頑張るのは善か悪かという問いかけを行いました。私はずっと「善」という教育を受けてきたのですが、どうもデスマーチという観点からは悪なんじゃないかなというのが、私のデスマーチに対する興味の本質にもなっています。少なくとも上役は甘え過ぎなんじゃないかと。
PMやPLとして指名されたが俺やったことない
上役の甘え過ぎと表裏一体ですが、本来プロがやるPMやPLを、デスマーチの被害者たる下っ端にやれというお達しが来る件についても話が出ました。だいたい、心優しい人はかなりよくない精神状態に陥ることうけあいです。
今日、http://www3.nhk.or.jp/news/html/20140417/k10013831161000.htmlという話が出ましたが、末端エンジニアであろうがリーダーであろうが、どうも人を確保すればうまくいくという安易な考えがはびこっており・・・。
デスマーチ症
- 眠い・寝れない・寝付けなくなる
- 勤務時間外も心が拘束されている
- 人に対する怒りが一日中頭を支配
- 足がしびれる
- 足がすーっと冷たくなる
- 食事30秒後に嘔吐
- 食事の味がしない
- 失踪
- 人に迷惑かけたくないと強く思ってしまう
COBOL→Javaの闇
技術の話は禁止していたのに自分から切り出した話です。もともとCOBOLを使っていたシステムというのはデータ指向でバッチ処理だったわけですが、なぜかSIerでオブジェクト指向のJavaが流行りだして現在に至る歴史があります。
これが人売り商売と相性がいいのではないかという意見がありました。結局、淘汰は技術ではなくて会社の存続で決まってくるので、儲かる仕組みのある方が生き残ります。
クラス単位で人を突っ込んで、全体を見渡すのが大変難しい状況でみんなクラスを作り、「いっせーのーで」で、くっつける。だめ。そして納期が伸びてベンダ儲かると。オブジェクト指向とRDBの相性の悪さも無視できません。これでまた延びる。
たぶんCOBOLだったらデータの種類で仕事量が決まるので、人のアサインも設計もシンプルになるはずです。COBOL使ってりゃいいのになと思います。あ、ユニケージもありますのでよろしくお願い致します。
ところでこの話が出たとき、残業代が青天井のときにはプログラマとかSEの月給が青天井で大変儲かったそうです。んなもん、誰が責任を持って仕事を終わらそうとするのか。
優秀なプログラマーにも責任があるんじゃないの？
従順なエセプログラマーが雇われて現場が悲惨になるのは凄腕プログラマーがわがままだからなんじゃないの、と私。例えば、自分の作っているものの意義が分からんでむなしいという話が出ましたが、資本主義なので9割がたは淘汰されるべきゴミかカストリアプリなのでそれは我慢しなければならんのじゃないかと。
その場では言わなかったのですが、プログラマには、野球に例えると
- オレは直球で勝負したいというピッチャー
- 直球で勝負しろやー！！！とピッチャーを脅すバッター
がいっぱいいますが、プロとしてどうなのかと。ちゃんとマー君みたいに数字で結果を残さないと・・・。
あとは、わりかし優秀なエンジニアが多い環境では、上層部の案で急に使う言語を切り替えたり、言語で派閥争いが起こることがあるそうです。そういう派閥争いは自分も嬉々として参加しそうなので、自省しました・・・。教育好きが多すぎると、このようなことが起こりがちだそうです。自省します・・・。
もう一つ、「お山の大将問題」が出ました。これも定番の話です。現場のお局プログラマが偉そうにオレオレアーキテクチャを作り、動かなくてリリース予定日から再開発が始まるあのパターンです。お客さんは堂々と繰り広げられる間違った説明を聞かされ半信半疑、周辺のプログラマもたぶん動かないだろうと思いながら言い出せず、撃沈するパターンです。ご存知の。
営業や上司対策
こういう話では定番です。特許庁の一件の話からもりあがりました。特に困ったという事例では、次のようなものがありました。
- エンジニアに「できるよな？できるよな？」としつこく聞いてできない仕事をできる仕事と思い込む
- エンジニアの条件付きOKをALL OKとする
- 上記のような事件がいくつか起こり、エビデンスをとられてうかつな話ができなくてエンジニアストレスmax
- Oracleちょっと触ったことある→エキスパート扱い
構造の話をしておくと、結局営業は取った案件数で評価されるので、それに現れないことについては正しくやっている人の方が損をして淘汰されると言える可能性があります。
かつてあった談合について
明らかにエンジニアが守られていた側面もある。
その他、Facebook上で後から出た話
論外ですが。
- ちょっとスクリプトの1本でも書けば解決することを「手作業の温かみガー」とか言い出す老害のせいで数人/日かかった
- スクリプトで さっさと仕事を終わらせて、 スクリプトのコピーを渡そうとしたら、さぼっている、とか、ほかの人はスクリプトがメンテできないから駄目だとか、楽しやがって... とか言われた
以上、とりとめもなく長く書いてしまいました・・・。それにしても、ここまで広がった話、どうやってまとめるんだろ？？？
まあいいか。面白いから。
ノート
Tweet
