内部から変革しようとしてます
日本でプログラマが少ない理由は戦う戦場を間違えているからです - 文系プログラマによるTIPSブログ
仰ってることはたぶん正しい。
この業界、そういう性質が多分にある。
年功序列とは切っても切り離せない性質。
いわば、会社をまたいで上司と部下の関係を貫いてるわけだから、ヒエラルキーの上層部に行くほど管理職が多くなるのは必然と言うか、水が流れ出る元には蛇口を調節してる人がいるよねと言うぐらい当然の話。
さて、僕はSIというSIかどうかはよくわからないが、とにかくユーザー系システム会社にいる。もちろん、多重下請け構造だ。無駄なことが多過ぎてうんざりするよね。
エクセルと向かい合うだけの仕事は個人的にお断りなので、いろんな仕組みを作って、世間ではほぼ枯れてても弊社では新しい技術を取り入れたり、好き勝手やってる。
記事でも言及されてるが、新しい何かを本気で浸透させるには、説得させる資料を用意したり、啓蒙したり、とてもじゃないが成果に見会わない労力がかかる。
だから、僕は正面作戦はやめた。アホらしい。
与えられているリソースを活用してひっそりとjenkinsを稼働させて、実運用にまでフェーズインさせたり、redmimeでの情報管理を徹底するよう、自分が指示できる範囲で指示して、気がついたら上司以外はredmimeを使ってるような、外堀を埋める作戦をしてみたり。
jenkinsやらredmimeなんか今更すぎるけど、それって悲しいけどSIの現実なのよね。それほどまでに、技術的には頼りない。エクセルベースの進捗管理、課題管理表が横行してて、改善しようとする人がいない。やり方を変えられそうになると反発を食らう。
よく言われることだけれど、
事前に許可を得るより、事後で許しを得るほうが容易い
なのだ。
もちろん、やればいいってもんじゃない。結局混乱を招いたりしたら、それこそ目をつけられる。自分の努力が水の泡になるだけでなく、未来がなくなる。
失敗しても、次に繋がるよう、立ち回らねばならない。
例えば、こういうプロセスだ。
- 上司と雑談しているとき、問題点を共有しておく。「なんか、もっと効率よくやりたいですよね～」
- こっそり新しい仕組みを導入してみる
- 部下や、管轄下にある派遣さんに試験的に使ってもらって、意見を聞いてまとめる。
- 他のチームにも状況を聞いてみる。「あー、やっぱりそういう悩みあるよね。うちではこんな取り組みをしようとしててさ…」
- 他のチームから「あいつのチームではなんかこんなことやってるらしいぞ、うちもやってみるか」
- 上司に報告。「効率化のために、こういう取り組みをしてるんですけど、こういうところがまだうまくいってなくて…他のチームもやり始めてるんですけど、一緒に改善活動してます」
- 「みんなで協力したら、生産性向上活動の実績にもなりますしね。うちのチームの。」←成果が欲しい上司への殺し文句
とりあえずここまで持ってくれば、もう反故にされることはない。
重要なのは
- 外堀を埋めること
- 関係する人の共感を得ておくこと
- 取り組みにはフワッとしてる段階からいろんな人を巻き込んでおくこと
これだと思う。
コミュニケーション力というより、政治力に近い。
自分の企てが露呈しても、潰されないよう手を打っておくこと。
もちろん、上司の性格や、部署の性質なんかによって話のもっていきかたは違うと思う。
けれど、共通してる作戦がある。
それは、
敵対しそうな人を当事者にしてしまうこと
である。
と、なんだか権謀術数ばかり考えてる人みたいだけど、とにかく、僕は技術的に弱いSIってのを嫌ってるから、こうして新しい仕組みを導入しようと日夜企んでいる。
僕？僕は技術的なことは好きだけれど、適正はあまりないと思う。
でも、こうして僕が取り組んだ結果、技術者が働きやすい、チャレンジしやすい環境が出来ればな、と思ってる。
下請けに対しても、立場的には、「情報共有はslack使って行うからね」とか強制させやすい。
それが、業界全体の底上げに一石を投じることになるなら、なんだってしよう。
なんてったって、僕も技術者軽視の日本の風潮をなんとかしたい一人なんだから。
