「経営者目線で動いてくれ」――この言葉、どれだけのエンジニアをイラつかせてきただろう。
権限も情報もないのに目線だけ求められても、無理に決まっている。
じゃあ、なぜK.Platinumのエンジニア17人は本当に経営者目線で動けるのか。今日は仕掛けの話をする。
「経営者目線で動け」が空虚なスローガンになる構造的理由
僕は前職、スタートアップITコンサルでエンジニアをやっていた。20代半ばの頃の話だ。
その頃から「経営者目線で考えろ」「全員が経営者だ」みたいなフレーズは、いろんな会社で耳にしてきた。聞くたびに違和感があった。
なぜなら、そう言ってくる会社のほとんどで、エンジニアには次の3つが共有されていなかったからだ。
- 数字（PL・案件単価・採用コスト）
- 意思決定の権限（誰がどこまで決めていいのか）
- 採用や評価への関与（誰を仲間にするか）
数字を知らない、決めていいことがない、誰と働くかも選べない。それで「経営者目線」と言われても、できるわけがない。経営者目線とは、結局のところ「経営に関する情報・権限・責任を持っている人の目線」のことだ。情報も権限も渡さずに、目線だけ求めるのは精神論でしかない。
僕は24歳でK.Platinumを作った。3期目に入った今、従業員は17人。うち8人が高専出身。20代エンジニアが多い、平均年齢の若い会社だ。
それでも、ほぼ全員が「経営者目線」で動いている。少なくとも僕にはそう見える。なぜか。理由はシンプルで、経営者目線が成立するように、3つの仕掛けを作ってきたからだ。
仕掛け①：数字をすべて開示する――PL・単価・キャッシュまで全社員が見る
最初の仕掛けは、徹底的な情報開示だ。
K.Platinumでは、案件の単価・粗利・受注パイプラインの状態・採用にかかっているコスト・キャッシュの推移を、全社員が見られる状態にしてある。Slackと社内ダッシュボードで、月次の数字が淡々と流れていく。
「えっ、それって経営情報じゃないですか。普通隠すものでは？」とよく聞かれる。
確かに、多くの会社では数字は経営層と一部の幹部しか見れない。理由は2つある。1つは「不安にさせるから」、もう1つは「悪用されると怖いから」だ。
でも、僕はその2つとも、エンジニアを信用していない言い訳だと思っている。
数字を見せると、若手エンジニアでも自然に会話が変わる。「この案件、単価に対して工数かかりすぎてないですか？」「次の四半期、新規案件のパイプラインこれだと薄い気がするんですが」――こういう会話が、雑談レベルで出てくる。これは、数字を見ているからこそ出てくる。
逆に、数字を渡されないエンジニアは、自分の仕事と会社の経営が分断されたまま働く。それで「経営者目線で動け」と言われても、ピンとくるわけがない。
もちろん、開示にもラインはある。個人の評価情報や、特定顧客との交渉中の案件詳細は伏せている。でも「会社の体力」と「事業の構造」は全員が把握している。これが、僕らの一つ目の前提だ。
仕掛け②：意思決定の権限を「役職」ではなく「案件」に紐づける
2つ目の仕掛けは、権限設計だ。
普通の会社は、意思決定の権限を「役職」に紐づける。部長は部の予算を決められる、課長は人事評価をできる、平社員は何も決められない、みたいな。
K.Platinumでは、意思決定の権限を「案件」に紐づけている。
具体的には、ある案件のリードエンジニア（プロジェクトマネージャー的なポジション）になると、その案件に関する大半の意思決定権が渡される。クライアントとの交渉、メンバーアサイン、技術選定、見積もり、契約条件の調整、サブコントラクターの選定。これらを、リードエンジニアが主導する。
僕や経営陣が出てくるのは、「リードエンジニアが判断に迷ったとき」と「会社全体に影響する取引（数千万単位の契約や、与信に影響する話）」だけ。日常の意思決定は、現場で完結する。
これは「権限委譲」というより、「最初から意思決定はそこでやるもの」と設計してある。だから、入社2年目でも、リードを任されれば数千万円規模の案件の方向性を決めている。
もちろん、いきなり放り投げるわけじゃない。最初の数案件はサブとして入ってもらい、意思決定の現場を見せる。徐々にリードに上げていく。経営者目線は「見て覚える」ものだと思っているから、座学で教えるより、隣で意思決定している人の判断を見せた方が早い。
案件のアサイン自体も、エンジニア側が手を挙げて選べる仕組みにしてある。だから「やらされ仕事」になりにくく、自分の意思決定の延長として案件を取りにいく感覚が生まれる。
裁量・情報・採用権をフルオープンにする組織で働きたいエンジニアの方へ。
K.Platinumでは、リードを任されれば数千万円規模の案件を主導できる環境を用意しています。詳しい条件・募集ポジションは採用ページからどうぞ。
仕掛け③：採用と評価をエンジニア自身が回す
3つ目の仕掛けは、採用と評価へのエンジニアの関与だ。
K.Platinumでは、採用面接にエンジニアが必ず入る。書類スクリーニングから面談、内定の意思決定まで、現場のエンジニアが主導する。僕が最終面接に出ることはあっても、「現場が良いと言うなら採る、ダメと言うなら採らない」を原則にしている。
理由は2つ。
1つ目は、自分が一緒に働く人を、自分で選びたいから。これは僕自身がそうしたいと思うし、エンジニアもそうだろう。「上が決めた人と組まされる」ストレスは、想像以上にパフォーマンスを下げる。
2つ目は、採用が「経営行為」だから。会社は、人を採るたびに変わる。誰を採るか、どんな順序で採るか、どこに投資するか。これらは、経営の中核的な意思決定だ。これをエンジニアに渡さないままで、経営者目線を求めるのは無理がある。
評価も同じ思想で設計している。年に2回の評価サイクルで、ピアレビュー（同僚評価）を必ず入れる。「上司が部下を評価する」一方向ではなく、「同じ案件で組んだメンバーがお互いを評価する」構造にしている。
評価は給与に直結するから、ここに関与すると、当然「給与の仕組み」も理解する必要が出てくる。だから給与テーブルも全公開している。「あの人がこのレンジにいるのはなぜか」を、自分で解像度高く理解できる。
採用と評価。この2つを現場に渡している会社は、僕の知る限りそんなに多くない。でも、ここを渡さないと、本当の意味での経営者目線は育たないと思っている。
17人だからできるのか、17人で回るように設計したのか
ここまで読んで、「それは17人の小さな会社だから成立しているんでしょ」と思った人もいると思う。
半分正解で、半分違う。
確かに、17人だからこそ情報開示のコストが低いし、意思決定の現場も近い。100人になったら、同じやり方では回らない。
でも、僕の見方は逆だ。「17人で回るように設計したから、3期目で17人なのに案件が回せている」。
普通のITコンサルや受託開発で、17人で同じ案件規模を回そうとすると、たぶん回らない。意思決定が経営層にボトルネックして、現場が動けなくなる。だから、人を増やして役職を作って、「上に判断を上げる」構造を作る。
僕は逆をやった。最初から「経営層に判断が上がってこない」構造にした。だから、現場で意思決定が完結し、僕が雑務に追われない。その分、僕は新規案件の獲得や、組織全体の方向づけに時間を使える。
これは「権限委譲」という名前で語られることが多いけど、僕の感覚では権限"委譲"じゃない。最初から、意思決定はそこにあるべきだ、と設計している。
将来、会社が大きくなるとどうなるか。たぶん、現在のフラット構造のまま100人にはできない。どこかで「事業部」みたいな単位を切る必要が出てくる。でも、その時も「事業部長に権限を委譲する」のではなく、「事業部内で意思決定が完結する設計にする」つもりだ。
「経営者目線」は精神論ではなく、組織設計の問題だ。情報を渡し、権限を渡し、採用と評価を渡す。この3つができれば、エンジニアは勝手に経営者目線で動き出す。できないなら、何人いても同じだ。
まとめ：仕組みで作る、ということ
「経営者目線で動け」が嫌いな人は、たぶん僕と同じ感覚を持っている。
その言葉が嫌いなのは、エンジニアとしての姿勢の問題じゃない。情報も権限も渡さずに、目線だけ求めてくる構造が嫌いなんだ。
K.Platinumは、その構造を反転させた会社にしようと思って作ってきた。3期目の今、まだ完璧じゃないし、毎月新しい課題が出てくる。でも、エンジニア17人がそれぞれ「自分が会社を作っている」感覚で動いている、という手応えはある。
もし、あなたが「もっと裁量を持って働きたい」「自分の判断で動きたい」「会社の意思決定に関わりたい」と感じているなら、一度カジュアル面談で話しましょう。逆に、あなた自身がどんな構造で働きたいか、聞かせてください。
僕らが作っているのは、エンジニアが経営者目線で動ける構造です。
沼田 海斗（ぬまた かいと）
株式会社K.Platinum代表。沖縄高専卒、トヨタ自動車、スタートアップITコンサル勤務を経て、24歳でK.Platinumを設立。3期目・27歳。資本金は設立時10万円から現在2,000万円。「エンジニアの能力を可視化し、稼げるエンジニアを量産する」ことをテーマに、17人（うち高専出身者8名）のチームでITコンサル事業を展開中。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。