どうも、しんざきです。
実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。
デスマ程健康に悪いものはこの世に存在しないと思います。
失敗した時の話をします。
十年近く前の話ですが、システム開発の会社に勤めていたことがあります。
それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。
私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。
ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。
某大きな銀行の三つのシステム合体不思議案件なんかにも関わったことがありますが、金輪際システム統合案件はやりたくないです。
その部署で、ある時「チームリーダーに、もうちょっと技術的な業務に集中出来る時間を作ってあげよう」というような動きが持ち上がったことがありました。
システムエンジニアをやっている方ならよくお分かりかと思いますが、一般的なエンジニアのキャリアパスは、コーディングや外部設計などの下流寄りの業務から始まり、上流寄りの工程、ないしマネジメント寄りの仕事に進む、というものが一つの典型です。
最近は当てはまらない例も増えているとは思いますが、まあ「プログラマー→システムエンジニア→チームリーダー→プロジェクトマネージャー」なんてのが「よくある」キャリアパスの一例であって、大雑把に後ろにいけばいくほど管理系の仕事が増えていく、と考えてよいでしょう。
タスクの具体化・細分化、タスクの割振り、スケジュールの管理・調整、他部署との調整なんかの仕事配分が、技術的な業務を押しのけて増えていくのは、まあどこの世界でも割とよくある話です。
勿論これはざっくりした話であって、人によってはいつまでも技術的な仕事と縁が切れない人も、管理職をしながらもきっちりコーディングの仕事を確保している人なんかもいましたし、フルスタックエンジニアや特定分野のスペシャリストもいない訳ではありませんでした。
ただ、少なくともその会社では、大雑把に「キャリアが長くて出世した人ほど、管理の仕事だけに時間がとられるようになっていく」という傾向が間違いなくありました。
当然のことながら、マネジメントの仕事をする際に技術的な知識が必要でないかというと全くそんなことはなく、技術トレンドを追いかけられていないマネージャーはあっという間に見当外れな采配しか振るえなくなりますし、転職をした際の潰しも効きにくくなります。
勿論各自勉強をしてそれについていこうとしているのですが、「職位が高い人間ほど技術的な実務に携われなくなるのは問題ではないか」という声は、割と昔からあったのです。
そこでその部署では、「職位とロールを分離しよう」という実験的な試みが行われるようになりました。
つまり、「エライ人 = 管理職」という、役割と職位の紐づきをどうにかしよう、という話です。
いわゆるPMOと言えるほどちゃんとしたチームではないのですが、「タスク割振り・スケジュール管理・部署間調整を専門でやる人たち」というような役割が設定され、そこに人が集められました。
その中にはまだ入社1,2年の新人や、新規配属の派遣さんも含まれており、当然のことながらスケジュール管理をしようにも右も左も分からなかったら意味がないのであって、そのフォローに当時チームのサブリーダーだった私もちょこちょこ入ることになりました。
一方プロジェクトの方では、今まで管理業務に忙殺されていた人たちに工数の空きが割り振られ、色んな技術的な実務が入っていきました。
この試み自体は、決して悪いチャレンジではなかったと、当時も思いましたし、今でも思っています。
いわゆるピーターの法則打破の為にも、「マネジメント以外で偉くなる道」というのは存在して然るべきですし、その為の道筋としても悪くない試みだと感じました。
新人でもマネジメント業務に触れることが出来る、というのもメリットのように思えました。
なにより、管理職の人たちの中には、「こんな面倒くさいマネジメント業務よりコード書きたい」と日常ぶつくさ言っている人たちが山のように存在したのです。
タイトルで先に書いてしまっていますが、この試みは失敗しました。
もうちょっと正確に言うと、有象無象の抵抗がなんとなく発生して、最終的には有耶無耶のままチーム自体が解散の憂き目に遭いました。
そのチームの仕事は、まず「各プロジェクトから、タスク管理・スケジュール管理・調整の仕事を切り出す」というところから始まりました。
以前はマネージャー職が引いていたWBSを引き継いで、メンバーに進捗状況をヒアリングしに行って、チケットの進捗状況を集積して、進捗率を計算してプロジェクト会議で報告して、進捗が悪いところには改善策を相談しにいきました。
最初は、「なんとなくやりにくい」という程度の、ふわっとした不満が出るところから始まったと思います。
実際のスケジュールの切り方は、私から見ても別段問題があるように思えなかったのですが、重箱の隅をつつくような、普段ならだれも指摘しなさそうな指摘がちょこちょこ出てきました。
ヒアリングの際もなーんとなく嫌な顔をする人が結構な数出始め、引き継いだだけのWBSに対して何故かタスク切り方の文句が出る、というようなことも散発していました。
「誰が切ったのこのWBS？」
「いや、あなたですけど」みたいな面白会話も発生しました。
「進捗ヒアリングが上手くいきません…」
「タスク調整が全然進みません…」みたいな話がしょっちゅう私のところに来ることになって、本来チームメンバーではない私が何故かフォローに奔走する羽目になる、みたいな状況まで起こるに至って、「なんでこうなってるんだ？」ということを調べてみたんです。
アンケートを作って無記名で集めたり、喫煙所で世間話ついでにあれこれヒアリングしてみたりしました。
勿論細かい不満は色々とあったんですが、突き詰めてみると
「コーディングが出来るのはいいんだけど、ぶっちゃけ職位が下のヤツにあれこれ管理されるのはなんか嫌」
という、言ってしまえば極めて感情的な問題がその状況の根本原因でした。
要は、「仕事をする上で、職位や身分の意識を完全に消すことは難しい」ということと、「チケットの遅れを職位が下の物に指摘されるのは腹が立つ」という、そこに問題があったのです。
勿論これは全体の話ではなく、なかにはすんなりとこの制度に順応出来た人もいました。
本当に単純に「面倒な管理業務がなくなってめちゃ嬉しい」という人もいましたし、喜々としてコーディングに取り組めて幸せ、という人もいたんです。
ただ、元々が実験的な試みだったこともあり、色々な抵抗から「まあやめようか」ということになってしまい、この動きは立ち消えになってしまいました。残念例です。
今から振り返ると、この失敗の根本原因は、「エンジニアにおける、職位についての意識というものを甘く見積もっていた」ということにあったのではないか、と思います。
大筋、エンジニアには「部長-課長-係長」というような「旧来型の組織構造」に親和性が低い人の方が多いであろうことは恐らく間違いなく、組織に属するというよりはプロジェクトに属して働く場合が多いことから、職位についてもある程度ゆるい人の方が多いんだろう、と、私も思ってはいたのです。
ところがそれが甘い考えというヤツで、実際には「職位・上下関係」というものに強い意識をもっている人もたくさんいたし、そういう人の中には「職位が低い者からあれこれ指示が来る」ということ自体に拒絶感を持つ人もたくさん含まれていたのです。
「下のもんに全体的なスケジュール管理なんて出来るか」という意識の人も複数いました。
やっていることや仕事の形態が進歩的であったとして、意識まで進歩的であるとは限らない。
当たり前の話なんですが、当時の推進側には、まさにこの認識が欠けていたと考えていいでしょう。
私が考えたこの問題の解決策は、
・「実験的な試み」というような中途半端な立ち位置だから職位の問題が解決出来ないのでは？
・いわゆるPMOのように、きちんとした管理チームを会社側が定義して、かつそのチームリーダーにはきちんとした職位の人を据えれば、管理される側の抵抗感も薄れるのでは？
・管理される抵抗感は人にもよるので、チームによって管理チームのサポートを受けるかどうかを任意に選べるようにすればいいのでは？
というくらいであって、その提案もしてみたんですが、結局そこは受け入れられないまま、その暫く後に私その会社辞めちゃったんで、今どうなってるかは知らないんですが。
この話で私が学習したことはいくつかありまして、
・「職位」とか「身分」というものは、エンジニアには気にしない人が多いようでいて案外無視出来ないし重要である
・職位とロールを分離する際には慎重に進めないと失敗する
・「ぺーぺーに管理されたくない」という抵抗意識の強さは馬鹿にならない
というようなことであって、以降「管理する・される」という問題にはだいぶセンシティブに接するようになりました。
お蔭で現在はだいぶ柔軟な運用が出来るようになりましたが、当時はまあ泥臭い対応しか出来なかったなあ、と思ったりもするわけなんです。
まあ、古臭い日本的企業のように思えることであっても、その取扱いは案外難しいものである、という話でした。
今日書きたいことはそれくらいです。
【安達が東京都主催のイベントに登壇します】
ティネクト代表・安達裕哉が、“成長企業がなぜ投資を避けないのか”をテーマに東京都中小企業サイバーセキュリティ啓発事業のイベントに登壇します。借金＝仕入れという視点、そしてセキュリティやDXを“利益を生む投資”とする考え方が学べます。
こんな方におすすめ
・無借金経営を続けているが、事業成長が鈍化している
・DXやサイバーセキュリティに本腰を入れたい経営者
・「投資」が経営にどう役立つかを体系的に学びたい
＜2025年7月14日実施予定＞
投資と会社の成長を考えよう｜成長企業が“投資”を避けない理由とは
借金はコストではなく、未来への仕入れ—— 「直接利益を生まない」とされがちな分野にも、真の成長要素が潜んでいます。【セミナー内容】
1. 投資しなければ成長できない
・借金(金利)は無意味なコストではなく、仕入れである
2. 無借金経営は安全ではなく危険 機会損失と同義
・商売の基本は、「見返りのある経営資源に投資」すること
・1%の金利でお金を仕入れ、5%の利益を上げるのが成長戦略の基本
・金利を無意味なコストと考えるのは「直接利益を生まない」と誤解されているため
・同様の理由で、DXやサイバーセキュリティは後回しにされる
3. サイバーセキュリティは「利益を生む投資」である
・直接利益を生まないと誤解されがちだが、売上に貢献する要素は多数（例：広告、ブランディング）
・大企業・行政との取引には「セキュリティ対策」が必須
・リスク管理の観点からも、「保険」よりも遥かにコストパフォーマンスが良い
・経営者のマインドセットとして、投資=成長のための手段
・サイバーセキュリティ対策は攻守ともに利益を生む手段と考えよう
【登壇者紹介】
安達 裕哉（あだち・ゆうや）
ティネクト株式会社 代表取締役／ワークワンダース株式会社 代表取締役CEO
Deloitteにてコンサルティング業務に従事後、監査法人トーマツの中小企業向けコンサル部門立ち上げに参画。大阪・東京支社長を経て、2013年にティネクト株式会社を設立。
ビジネスメディア「Books&Apps」運営。2023年には生成AIコンサルティングの「ワークワンダース株式会社」も設立。
著書『頭のいい人が話す前に考えていること』（ダイヤモンド社）は累計82万部突破。2023年・2024年と2年連続で“日本一売れたビジネス書”に（トーハン／日販調べ）。
日時：
2025/7/14（月） 16:30-18:00
参加費：無料
Zoomビデオ会議（ログイン不要）を介してストリーミング配信となります。
お申込み・詳細
お申し込みはこちら東京都令和7年度中小企業サイバーセキュリティ啓発事業「経営者向け特別セミナー兼事業説明会フォーム」よりお申込みください
(2025/6/2更新）
【著者プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
（Photo:NelC）
