どうも、しんざきです。

実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。

デスマ程健康に悪いものはこの世に存在しないと思います。

 

失敗した時の話をします。

十年近く前の話ですが、システム開発の会社に勤めていたことがあります。

それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。

 

私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。

ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。

某大きな銀行の三つのシステム合体不思議案件なんかにも関わったことがありますが、金輪際システム統合案件はやりたくないです。

 

その部署で、ある時「チームリーダーに、もうちょっと技術的な業務に集中出来る時間を作ってあげよう」というような動きが持ち上がったことがありました。

 

システムエンジニアをやっている方ならよくお分かりかと思いますが、一般的なエンジニアのキャリアパスは、コーディングや外部設計などの下流寄りの業務から始まり、上流寄りの工程、ないしマネジメント寄りの仕事に進む、というものが一つの典型です。

 

最近は当てはまらない例も増えているとは思いますが、まあ「プログラマー→システムエンジニア→チームリーダー→プロジェクトマネージャー」なんてのが「よくある」キャリアパスの一例であって、大雑把に後ろにいけばいくほど管理系の仕事が増えていく、と考えてよいでしょう。

タスクの具体化・細分化、タスクの割振り、スケジュールの管理・調整、他部署との調整なんかの仕事配分が、技術的な業務を押しのけて増えていくのは、まあどこの世界でも割とよくある話です。

 

勿論これはざっくりした話であって、人によってはいつまでも技術的な仕事と縁が切れない人も、管理職をしながらもきっちりコーディングの仕事を確保している人なんかもいましたし、フルスタックエンジニアや特定分野のスペシャリストもいない訳ではありませんでした。

ただ、少なくともその会社では、大雑把に「キャリアが長くて出世した人ほど、管理の仕事だけに時間がとられるようになっていく」という傾向が間違いなくありました。

 

当然のことながら、マネジメントの仕事をする際に技術的な知識が必要でないかというと全くそんなことはなく、技術トレンドを追いかけられていないマネージャーはあっという間に見当外れな采配しか振るえなくなりますし、転職をした際の潰しも効きにくくなります。

勿論各自勉強をしてそれについていこうとしているのですが、「職位が高い人間ほど技術的な実務に携われなくなるのは問題ではないか」という声は、割と昔からあったのです。

 

そこでその部署では、「職位とロールを分離しよう」という実験的な試みが行われるようになりました。

つまり、「エライ人 = 管理職」という、役割と職位の紐づきをどうにかしよう、という話です。

 

いわゆるPMOと言えるほどちゃんとしたチームではないのですが、「タスク割振り・スケジュール管理・部署間調整を専門でやる人たち」というような役割が設定され、そこに人が集められました。

その中にはまだ入社1,2年の新人や、新規配属の派遣さんも含まれており、当然のことながらスケジュール管理をしようにも右も左も分からなかったら意味がないのであって、そのフォローに当時チームのサブリーダーだった私もちょこちょこ入ることになりました。

 

一方プロジェクトの方では、今まで管理業務に忙殺されていた人たちに工数の空きが割り振られ、色んな技術的な実務が入っていきました。

この試み自体は、決して悪いチャレンジではなかったと、当時も思いましたし、今でも思っています。

 

いわゆるピーターの法則打破の為にも、「マネジメント以外で偉くなる道」というのは存在して然るべきですし、その為の道筋としても悪くない試みだと感じました。

新人でもマネジメント業務に触れることが出来る、というのもメリットのように思えました。

なにより、管理職の人たちの中には、「こんな面倒くさいマネジメント業務よりコード書きたい」と日常ぶつくさ言っている人たちが山のように存在したのです。

 

タイトルで先に書いてしまっていますが、この試みは失敗しました。

もうちょっと正確に言うと、有象無象の抵抗がなんとなく発生して、最終的には有耶無耶のままチーム自体が解散の憂き目に遭いました。

 

そのチームの仕事は、まず「各プロジェクトから、タスク管理・スケジュール管理・調整の仕事を切り出す」というところから始まりました。

以前はマネージャー職が引いていたWBSを引き継いで、メンバーに進捗状況をヒアリングしに行って、チケットの進捗状況を集積して、進捗率を計算してプロジェクト会議で報告して、進捗が悪いところには改善策を相談しにいきました。

 

最初は、「なんとなくやりにくい」という程度の、ふわっとした不満が出るところから始まったと思います。

実際のスケジュールの切り方は、私から見ても別段問題があるように思えなかったのですが、重箱の隅をつつくような、普段ならだれも指摘しなさそうな指摘がちょこちょこ出てきました。

 

ヒアリングの際もなーんとなく嫌な顔をする人が結構な数出始め、引き継いだだけのWBSに対して何故かタスク切り方の文句が出る、というようなことも散発していました。

「誰が切ったのこのWBS?」

「いや、あなたですけど」みたいな面白会話も発生しました。

 

「進捗ヒアリングが上手くいきません…」

「タスク調整が全然進みません…」みたいな話がしょっちゅう私のところに来ることになって、本来チームメンバーではない私が何故かフォローに奔走する羽目になる、みたいな状況まで起こるに至って、「なんでこうなってるんだ?」ということを調べてみたんです。

アンケートを作って無記名で集めたり、喫煙所で世間話ついでにあれこれヒアリングしてみたりしました。

 

勿論細かい不満は色々とあったんですが、突き詰めてみると

「コーディングが出来るのはいいんだけど、ぶっちゃけ職位が下のヤツにあれこれ管理されるのはなんか嫌」

という、言ってしまえば極めて感情的な問題がその状況の根本原因でした。

 

要は、「仕事をする上で、職位や身分の意識を完全に消すことは難しい」ということと、「チケットの遅れを職位が下の物に指摘されるのは腹が立つ」という、そこに問題があったのです。

 

勿論これは全体の話ではなく、なかにはすんなりとこの制度に順応出来た人もいました。

本当に単純に「面倒な管理業務がなくなってめちゃ嬉しい」という人もいましたし、喜々としてコーディングに取り組めて幸せ、という人もいたんです。

ただ、元々が実験的な試みだったこともあり、色々な抵抗から「まあやめようか」ということになってしまい、この動きは立ち消えになってしまいました。残念例です。

 

今から振り返ると、この失敗の根本原因は、「エンジニアにおける、職位についての意識というものを甘く見積もっていた」ということにあったのではないか、と思います。

 

大筋、エンジニアには「部長-課長-係長」というような「旧来型の組織構造」に親和性が低い人の方が多いであろうことは恐らく間違いなく、組織に属するというよりはプロジェクトに属して働く場合が多いことから、職位についてもある程度ゆるい人の方が多いんだろう、と、私も思ってはいたのです。

 

ところがそれが甘い考えというヤツで、実際には「職位・上下関係」というものに強い意識をもっている人もたくさんいたし、そういう人の中には「職位が低い者からあれこれ指示が来る」ということ自体に拒絶感を持つ人もたくさん含まれていたのです。

「下のもんに全体的なスケジュール管理なんて出来るか」という意識の人も複数いました。

 

やっていることや仕事の形態が進歩的であったとして、意識まで進歩的であるとは限らない。

当たり前の話なんですが、当時の推進側には、まさにこの認識が欠けていたと考えていいでしょう。

 

私が考えたこの問題の解決策は、

・「実験的な試み」というような中途半端な立ち位置だから職位の問題が解決出来ないのでは?

・いわゆるPMOのように、きちんとした管理チームを会社側が定義して、かつそのチームリーダーにはきちんとした職位の人を据えれば、管理される側の抵抗感も薄れるのでは?

・管理される抵抗感は人にもよるので、チームによって管理チームのサポートを受けるかどうかを任意に選べるようにすればいいのでは?

というくらいであって、その提案もしてみたんですが、結局そこは受け入れられないまま、その暫く後に私その会社辞めちゃったんで、今どうなってるかは知らないんですが。

 

この話で私が学習したことはいくつかありまして、

・「職位」とか「身分」というものは、エンジニアには気にしない人が多いようでいて案外無視出来ないし重要である

・職位とロールを分離する際には慎重に進めないと失敗する

・「ぺーぺーに管理されたくない」という抵抗意識の強さは馬鹿にならない

というようなことであって、以降「管理する・される」という問題にはだいぶセンシティブに接するようになりました。

 

お蔭で現在はだいぶ柔軟な運用が出来るようになりましたが、当時はまあ泥臭い対応しか出来なかったなあ、と思ったりもするわけなんです。

まあ、古臭い日本的企業のように思えることであっても、その取扱いは案外難しいものである、という話でした。

 

今日書きたいことはそれくらいです。

 

【お知らせ】
Books&Apps及び20社以上のオウンドメディア運用支援で得られた知見をもとに、実際我々ティネクト(Books&Apps運営企業)が実行している全48タスクを公開します。

「成果を出す」オウンドメディア運営  5つのスキルと全48タスク
プレゼント。


これからオウンドメディアをはじめる企業さま、現在運用中の企業さま全てにお役に立つ資料です。ぜひご活用ください。

資料ダウンロードページはこちら↓
https://tinect.jp/ebook/5skills48tasks/
メールアドレス宛てに資料が自動送信されます。

ティネクトの事業・サービス詳細はこちら

 

 

【著者プロフィール】

著者名:しんざき

SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。

レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。

ブログ:不倒城

(Photo:NelC