技術的負債より文化的負債を返済できる人材が圧倒的に足りない件

死海文書と五十年後の君へ

「パンがなければお菓子を食べればいいじゃない」とマリー・アントワネットは“言ってない”そうですね。

そんな事からも、自分の言葉でこのようにブログなど で文章をしたためるのは大事なのかもしれません。

Photo by Youjeen Cho on Unsplash

いやね、

「必要な人材が足りなければ、育てればいいじゃない」

なんてフレーズを思いつきまして。なんとなくマリー・アントワネット思い出しちゃった。レッテルって良くないですね。

去る、2021年4月15日 DevOpsDays Tokyo 2021 で発表をさせて頂きました。

話しの風呂敷を広げすぎて、なんだか「上澄み」の発表になっちゃいました。でも、楽しんで頂けたようでなによりです。

そのうち YouTube や記事化が予定されているので、今回観れなかった方は気長にお待ち下さい。

14ケースにわたる文化的負債のお話しをさせて頂いたのですが、ひとつひとつ深堀りすると本を1冊書けてしまうボリュームなので、機会があれば今後もどこかで発表できればと思っています。

そもそも「ぼやき」コーナーはケース毎に付ける予定だったしな…

さて、発表後にエゴサーチしてみたところ(するんかい!)ちょっと説明したほうがいいのかな?と思った件が。

はてブにこんなコメントがありました。

おもしろかった / なにを「負債」と呼ぼうとしているのかはよくわからなかった」

そっかー……「負債」が通じてなかったかー(汗

確かに、発表の中では明確に「これが負債よ」という言い方はしてなかったけど、我々としては各ケースのタイトルが負債そのもののつもりでした。

文化的負債とは、そのソフトウェア開発組織にて歴史の積み重ねにより不健全になっていく事柄全般を指しています。

たとえば、

  • ソフトウェアで不具合を出すと期末に「落ち穂拾い」という名の役員総出の吊し上げ会議に招かれる。その準備にかなりの時間がとられるし、発表会ではメンタルも削られる。そして、その後の開発に活かされるかというと、そうでもない。
  • QCサークル活動という改善運動で「クリエイト提案」を必ず半期に1件は出すというノルマがある。ノルマなのでネタに困ったときは、ぜんぜん業務とは関係ない「コピー機に印刷失敗した紙のウラを再利用することで用紙を削減した」みたいな提案を無理やりひねり出し提出する。でもなぜか報奨金500円がもらえた。

これ自分の体験談なんですけどね……これらは、別の言い方だと形骸化と呼びます本来の目的から外れた活動に、まじめに取り組んでしまうのも文化的負債と呼んで良いかと。

また、最近だと、

  • そこしか予定が空いてないからと昼休みにミーティングが設定され、それが常習化してくる。会議メンバーに役員が入ってたりするので誰もそれを咎められない。そして週の何回かは昼食を食べそこね、その日は血糖値もさがり頭の回転も悪く、結局、生産性が落ちている。
  • コロナ禍なのでZoomで会議を行っているがネットの帯域が保たないので発表者以外はビデオをオフにするルールの徹底を指示される。発表者は相手の様子がよくわからないので、発表中だんだん不安になり、言いたいことが8割も言えず会議が終る。ディスカッションも盛り上がらず。

……みたいなのも文化的負債と、その弊害だと思います。

組織の健全性が損なわれているとき、それを文化的負債と呼びます。そして、「文化的負債との戦い」とは簡単にいえば「これおかしくね?」が言える雰囲気をどう醸成するか?に

四苦八苦しながら自分たちで考え解決策を探ること

かなと思っています。銀の弾丸ねーしな。

先日、この本を読ませて頂きました。

VOYAGE GROUPさんの「技術的負債との戦い」の歴史がインタビュー形式でこれでもかってくらい語られていて、痺れました。

こんなにオープンにしていいの?と心配になるぐらいですが、それを良しとする文化なんでしょうね。積極的に情報をオープンにすることで得られるメリットに価値を置くのは素晴らしいですね。

経験上、技術的負債と文化的負債の解消って表裏一体です。

我々エンジニアは技術的負債については良く気がつくし(見て見ないふりしてる可能性も高い)、それに対する対策を取れる優秀なエンジニアもたくさん居ると思います(本当はやれば出来る子たち)。

一方、文化的負債を解消できるエンジニアがなかなか見つからない。作るの大好き!なエンジニアはいるけれど、カイゼンとか文化形成には興味すら示そうとしない……これはなぜか?

「ピープルウェア」などのトム・デマルコ本の翻訳で有名な松原友夫さんの「日本のソフトウエア産業、衰退の真因」という2007年に書かれた記事があります。

私は、これを勝手に日本ソフトウェア業界の「死海文書」と呼んでいます。

私はこの記事が大好きで、何かに付けて読み返しています。何故なら、松原さんがここで書いた予言や「ぼやき」の中で、いくつ解消・カイゼンできるか?について密かに人生の目標にしているからです。

たとえば、

米国は、小学校での基礎教育からITを教えている。日本はどうであろう。ソフトウエアエンジニアリングを教えている大学の数はいまだに少ないし、仮に教えてもらったとしても、学生が就職する企業側でそれを生かしていない。情報学科を卒業して大企業に入った技術者は、開発ではなく下請けへの発注業務に忙殺されている。また、IT政策を統括する省庁もない。

やっとこさ小学校でもプログラミング学習が始まったし(ITとはいえないかもだけど)大学も専門的に教えてるところは増えたでしょう。デジタル庁が新設されることになり14年後にやっと動きがありました。

ところがところが。未だ変わらないのが上記の太字部分や下記引用部分です。

派遣ビジネスは、ソフトウエア開発作業を成果で請け負うのではなく、一カ月いくらというように、技術者の時間を売る。派遣指向のソフトウエア会社にとって最大の関心事は、人月単価(技術者一人が一カ月働くときの単価)と、人の稼働率であって、稼ぎが減る開発プロセスの改善や、余計な金を使う技術教育は、できればやりたくない。特に品質は、技術者だけの問題と見なされ、経営者は関心を持たない。極端な話、派遣プログラマーが自分で埋め込んだバグ(ソフトウエアの瑕疵)の摘出に時間を掛ければ、会社の実入りは増える

この問題が、文化面に取り組むエンジニアが少ないことに繋がっていると思うのです。

それは、事業会社に属するエンジニアよりも、圧倒的に派遣的エンジニア(派遣に限らず、請負だけど客先常駐するタイプも含む)が日本では多いという点です。

松原さんの記事に書かれているとおり、カイゼンなどの所業は稼ぎが減る行為です。また派遣的エンジニアこそ、組織文化から程遠いと思います。

なぜなら、従うべき文化は、自分が所属している組織か、派遣させられている組織なのか、派遣的エンジニアは常に混乱しているからです。この状態で、何が文化的負債か分かるはずもありません。最近は、品質保証会社も派遣ビジネス化しており、年々その規模を拡大しています。これで品質にどうコミット出来るのか……

また、派遣的エンジニアは顧客の言うことを素直に聞いていればラクです。私はこれを「受託脳」と呼んでおり、文化的負債の筆頭に挙げています。

たとえば事業会社のエンジニアも、転職前のキャリアはSIerなことが多いと思います。その場合オンボーディングでは「自分で考える大切さ」「自律的な行動とは」といったストレッチに凄く時間をかけるようにしています。

私自信、社会人キャリアは「派遣ビジネス」会社からスタートしました。そしてその会社は倒産してしまい、幸運にも、倒産時点の派遣先で仕事を続けさせてもらえました。

ところが、すぐに驚愕した事実がありました。それは仕事の対価としての報酬である。倒産した会社に払っていた金額を、個人として受け取ることとなったのですが、それはなんといままで貰っていた給与の3.5倍だったのです。どんだけ搾取されていたのか、そのとき初めて気付きました。

私は、残りの人生を掛けてこの派遣ビジネスにまつわる問題部分をどうにかしたいと思っています。ぜひ、アナタにも仲間になってほしいです。

--

--

Hiroyuki TAKAHASHI
Hiroyuki TAKAHASHI

Written by Hiroyuki TAKAHASHI

ファインディ(Findy) Software Engineer, SPI Coach, Agile Coach, Certified Scrum Professional® — Product Owner, Certified Scrum Professional® — ScrumMaster

No responses yet