【奇人】会社ウラミーマンの対応にめちゃくちゃ苦労した話【すなわち奇跡の人】

またPLをやることになった(私派遣だけども)

派遣でしたが前回の実績からPL業務を再度やることになってしまいました。
さすが鉄工所。
組織が決めたらそこは鉄のごとく曲げられぬ。

メンバーは前回と異なります。
会社に対して恨みを持っている人の対応に苦慮しました。
会社ウラミーマン編ということで進めます。

前回

ブログにしようと思った理由

PL案件としてうまくいったこと・学んだことはいつかブログにします。それほどに時流にそったマネジメントが必要と強く思ったため。

— カワッター:.)鉄工所IT(なぜか生産技術) (@kawattawatta_B) August 6, 2022

会社ウラミーマンの対応に苦慮する

前章で話しましたが、今回のプロジェクトには問題児と言われる方がいました。
もう命名してますが会社ウラミーマンです。

なぜウラミーマンというと、以下です。

• 過去に会社に受けたぞんざいな扱いに対して相当の不満を持ってる
• 本来やらねばならぬ業務内容であっても頑なに業務を行わない(やる気がない)

まとめると「俺は今までにこんなにひどい扱いをうけたんだ、これ以上仕事できるか！！」でした。

相当に頭を抱えました。

なぜなら前回の方法だけでは彼は仕事をしようとしなかったからです(前回の方法はさっき出したリンクからみてね！(宣伝))。そのためリスケしようにも進捗が遅れまくりです。

あと、クビにできませんからね。しかも自ら窓際を望んでいる感じ。
アメリカとかだったら「you are fired.」とか言えちゃうんでしょうけど。

当時の状況。

どうしたか(回想)

傾聴、傾聴、傾聴。

とにかく粘り強く最後まで話を聞きました。

そうすると、次第にウラミーマンの本音が見えてきました。

相当に長い会話をしたため、内容はかなりはしょっています。

会社ウラミーマンも組織の将来を案じていた

蓋を開ければ、このプロジェクトに入る前、ウラミーマンはC#→VB.netプログラマーだったそうです。ITエンジニアとしてのウラミーマンを知るために、私はPL権限を使ってウラミーマンの作ったコードを彼が前いた部署に見せてもらいました。

とても見やすい、わかりやすい。メンテナンス性に長けたコードでした。少なくとも私では同じレベルのコードはかけないレベルでした。ドキュメントも申し分ない。

そうです、会社ウラミーマンは優秀だったのです。窓際の人材ではなかったのです。

彼は使う言語が異なるプロジェクトを転々することは望みませんでした。

これは彼が新しい言語を始めるのが辛い、ということではなく、ゆくゆくはどのような仕様がきても対応が容易で、さらにメンテナンスができるような「変化に対応した設計思想・実装の双方におけるコードのフレームワーク」を作っていきたいがための、一つの言語のエキスパートになるキャリアを考えていたためだったのです。

これは今後、人が減ることがあっても増えることがないことを懸念した彼なりの対策でした。私はウラミーマンのコードを何度かみて「作業(コーディング)は短く、しかしブラックボックス化は防ぐ」といった意図を容易に読み取ることができました。彼には彼なりに筋の通った考えがありました。

ウラミーマンがC#→VB.netで言語の変更を容認したのは、おおまかな傾向が似ていたこともあったため、しぶしぶ承諾をしたのでした。

しかしその後も会社は彼の本来の考えを受け入れませんでした。コストがかかりすぎるからです。そんなことしてるなら次の案件をやれとなったのです。

それでもウラミーマンはコードの標準化に向けた取り組みをするために自分が扱う言語がコロコロ変わるプロジェクト配置はやめてくれといったのですが、会社からすれば、人がいない中で多能工な人材が求められる中、何を言っているんだと一蹴されました。

結局彼の主張は会社から見ればただのワガママとしてしか見られなかったのです。

次第に彼は口を開かなくなっていき、ただ会社のいいなりになっていきました。

それだけならまだマシでしたが、抑圧され続けたうっぷんがたまったからか、仕事のやる気そのものがなくなってしまったのでした。

会社ウラミーマンは同情でも報いでもなく公平を望んでいた

そんな彼が私と会った時には文句ばかり言って仕事を全くしないモンスター社員に変身していました。

私ははじめ、ウラミーマンをなだめるために同情の念を示しました。一見してクレイジーに見えるウラミーマンも、確かに主張は筋が通っていたためです。

しかし、ウラミーマンは私の態度が不服でした。嘘っぽい態度が気に入らない、うわべだけの同情ならいらない、あっちいけと。私はその気はなかったのですが、彼から見れば「こいつも他のやつと同じ」だったのでしょう。

なら何が望みなのか。もちろんウラミーマンは答えません。言うわけがありません。

次に私はウラミーマンの望むものは報いと考えました(良い意味の方です)。今までぞんざいな扱いを受けたウラミーマンに何かしらの見返りが必要なのでは、と考えたからです。私は彼に組み込みCの任を解かし、設計思想・実装の双方でコードのフレームワークを作っていきたいがための、一つの言語のエキスパートになるキャリアを提案しました。

これには私の思惑もありました。プロジェクト的にもウラミーマンは仕事をしないことから予算の人件費を浮かすことができ他にあてがうことができる、そして彼は望み通りのポジションに就ける。双方にWIN-WINだと考えました。

しかし、これも違いました。会社ウラミーマンの逆鱗にふれてしまい「今さら何ができる」と怒鳴られました。

一体何なんだろうか。

答えは公平であること、でした。ただウラミーマンを目の上のたんこぶ扱いせず、ひたすらに他の人と同じように接しました。
(私PLでしたが派遣なので目の上のたんこぶと言う表現はあってると思ってます)

私自身、なんでこの発想が浮かんだかが分かりません。
要は勘です。大事なところなのに。
いままで大学の頃にアホ程読みあさっていた心理学の本の内容が今さらになって結びついたから？だから私の心がそうしろと言った？よくわからないスピリチュアルワードが今この記事を書いている時点のせいぜいな答えです。

なんにせよ、これがうまくいきました。

次第に私は会社ウラミーマンと業務の話ができるようになっていきます。私ももともとは組み込みCをしていたことから、ウラミーマンとは機能仕様～実装の話まですることができました。

他のメンバーは元々優秀だったのでそこの辺は問題なし、DR合格、そしてプロジェクトは着地・完了をしたのでした。

考察および結論

上記の通り、プロジェクトは着地・完了しました。
しかし、一方で疑問や課題も多いものとなりました。
考察および結論の形で締めます(各節のタイトルは結論です)。

どのような形であれ、自分の歩んだキャリアに無駄など1つもない

これについては、なぜ会社ウラミーマンは私と普通にやりとりをしてくれたのかを考えたとき浮かびました。ウラミーマンは文句以外は口を開かなかったからです。そんな彼が自分の過去を話すこと自体、相当なことであると私は考えています。

これは私の特殊な立場なんじゃないかと(自分で言うか？ですが)。

当時の私は派遣にも関わらずPL・生産技術・盤屋といった分野関係なしの3足わらじの役割をもっていました。
これはウラミーマンからみれば自身が言語を転々とすることと、私が分野を転々とすることに何かしら共感するものがあったのではと考えています。

これも自分で言うか？ですが、辛いにしろ色々な分野の仕事ができることがある種充実していたのも事実で、それがオーラ的な何かになり、ウラミーマン的にも何かを感じ取ってくれたのかもしれません。いやいや、もしかしたら会社ウラミーマンも何かしら私に対して哀れみの感情があったのかもしれません。

実際派遣でここまでやる人いないし。給料あげろや(ボーナスはPL分上がってたけど)。

もはや予想の域を出ませんが、きっとそうなのだろうと思い(込んで)ます。

そう考えると、私の分野がごった煮のキャリアも無駄じゃなかったのかな、と。少しだけ自信になったのでした。

会社はジョブマッチングについて本気で考えるべき

もし、会社ウラミーマンはしかるべき場所に配属されていればきっと窓際ではなくレジェンドクラスになって、後継者を育成、会社の発展に貢献していたのではないかと考えています。

私は今後、会社がジョブマッチングに本腰をいれる時だと思いました。
具体的には、人を採用するときを例にすれば以下の通りです。

1. 初めの段階では高専や大学で学んだ内容がそのまま会社で使える分野に配属させること
2. その後で、本人の得意不得意を見定めたうえで関連分野に異動させること

クソでか主語をつかいますが、この国の大半の会社は人材育成の順番が上記と完全に逆だと思うのです。
例えばこの話。

これ、私の経験でいえば、本来の設計業務をするまえにあらゆる雑務(図面コピーとか)をさせる手順に似ています。もちろん雑務が大事なことはわかっています。ただ、2週間以上(酷いときは2ヶ月とかもっと)ず～～っとさせることが駄目ってことです。つまるやらせる業務の中心ではなく、外堀から埋めるような非常にまわりっくどいことをしていることが駄目ってことです。
図面を眺めても都度来る図面の相違が分かるくらいで、先輩の技術テクとかは盗めないよ。新入社員さんはもともとの図面の書き方といった社内ルールを知らないのだから。

これからは質の時代

ハイライトです。

私は扱う側がかなり大変なことを前提で、これからは会社ウラミーマンのような人が組織にとって本当に必要なんだと思います。これからは本格的に量の時代から質の時代にくると考えているからです。

量の時代、質の時代は造語です。定義は次の通りです。

• 量の時代
  製品の中身の重みよりもとにかく製品を大量に作ることが最優先となる時代。
  (人口増加が顕著なバブル世代)
• 質の時代
  製品の中身の重みが大きく個人の細かな要求に応えられるものを作ることが最優先になる時代

質の時代は量の時代の時代の上位となる時代です。顧客の潜在的なニーズと製造側の価格が完全にマッチさせた後で量産にうつす必要があるからです(質の完成後に量産にうつる)。まず製品の中身の重みづけが手順の一番はじめにきます。

質の時代では会社ウラミーマンのような人材が必要不可欠です。なぜなら短期的・長期的に関わらず、常に変化する顧客ニーズに追従するように製品を開発しなければならないからです。

そのために必要な要素は「標準化された製品の構成要素」となります。会社ウラミーマンがやろうとした「変化に対応した設計思想・実装の双方におけるコードのフレームワーク」がまさにそれだったと考えています。

標準化といっても時代が進めば結局内容が陳腐化すれば意味がないじゃないか、という意見があるかと思いますが「変化に対応した」と言う観点で違います。分かりやすい例としてトヨタ自動車を例とした"市場適合重視のアプローチ"があります。かなり長い内容のため、腰を据えて読む必要があります。始めは”要旨”→末尾の”おわりに”と読み進めてください。大まかにですが要点をおさえて全体が把握できます。

【参考リンク(https接続ではありません)】

VWグループ、トヨタの標準化アプローチに関する比較分析 ： 1990年代後半から2000年代におけるプラットフォームの統一性比較を中心に,
宇山, 通, 2017年1月30日, 九州産業大学経営学会, 第27巻第3号

この中で注目したい内容を引用します。

モデル、地域、時間を超えて一括でPFやその他の部品を設計し、2000年代までの複雑性、手間、コストを削減する。この側面のみを見ればコスト抑制重視に見える。しかし同社は自動車部品インターフェースを標準化、その中でも重要なPFの統一を、先進国と新興国とで使用するPFを分けた上で実施していた。このように新たな標準化アプローチには市場適合重視の側面も同時に見られた。

引用：P37, VWグループ、トヨタの標準化アプローチに関する比較分析 ： 1990年代後半から2000年代におけるプラットフォームの統一性比較を中心に, 宇山, 通, 2017年1月30日, 九州産業大学経営学会, 第27巻第3号

※PF:プラットフォームの略、詳しくは引用元P2参照

上記引用より、会社ウラミーマンはトヨタ自動車の思想をソフトウェアのクラス(関数)を自動車の部品にみたて、標準化に適用しようとしたのではないかと考えます。具体的にはクラス(関数)を顧客ニーズごとに分けながら行ったのではないかと。トヨタ自動車がPFの用途を先進国・新興国で分けたように。

おそらくですが、自動車部品の標準化の思想をソフトウェアに当てはめようとする考えはネットで検索すれば大体の方がたどり着けるはずです。しかしまさか本当に実行に移すとは。その姿勢はまさに奇人として見られると思います。一般的には理解しがたい人の代名詞ですが、私にとっては奇人＝奇跡の人です。

質の時代の形を垣間見れたのではないかと思います。

優秀な社員が腐ってしまう会社は滅んでしまえばいいと思っている

私は会社ウラミーマンをモンスター社員を生んでしまった弊社(派遣先)はいったん滅んでしまえいいと思いました。組織の思想にあわない人材をひたすらに排除する動きが今回のモンスターを生み出してしまったと強く感じます。いわゆる闇堕ち。笑えない。

昨今、多様性多様性といっているならまず会社が扱いづらいと思っている人材こそ上手く扱えるようにしろと言いたいです。いつまでも臭いものに蓋をするような組織の在り方はまさに思想が完全に固着しロボットのような同じ作業を良しする量の時代を象徴していると考えます。

どうやって会社が扱いづらいと思っている人材を上手く扱えるか私の考えについてはこの記事が超長くなったので別の記事にて(いつかなﾊﾅﾎｼﾞ)。

え、そもそも会社が滅んだらそんなことしたら私の仕事先もなくなる？きっと大丈夫また転職すればｲｲﾖ(白目)。

変更履歴