現在、AI-Opsエンジニアとしてインターンをしており、来春から新卒として正式に入社予定の筆者である。本記事では、CEO直下のタスクやAI-Opsチームでの業務を通じて体感した、ログラス流の「究極の権限委譲」と「信頼のカルチャー」について、等身大の視点でまとめた。
イントロ：自分の常識を覆した「情報の空白」
自分は、仕事の細部にはかなりこだわる方だと思う。 だからこそ、漠然とこう思っていた。「もし自分が会社を作ったら、社員の仕事は全部把握せざるを得ないだろうな」と。そうでなければ、自分の理想通りの成果が出ないと考えていたからだ。
もちろん、「スタートアップは自律性を重んじる」「仕事を任せる」という言葉は知っていたし、頭では理解していたつもりだった。 しかし、ログラスに入って直面した現実は、自分の想像を超えていた。
マネージャーや上の人に新プロジェクトの進捗や成果を報告する際、相手にとって「初耳」となる内容が意外に多いのだ。 「え、そんなツール使って解決したの？」 「そういうアプローチで検証してたんだ」
彼らは途中のプロセスを、報告を受けるその瞬間まで知らなかった。 しかし、それは決して無関心だからではない。「知らない状態」をあえて許容し、自分を信じて任せているからだと気づいた。
自分が持っていた「管理」のイメージ（上司は文脈を把握しており、部下はそれを前提に報告する）は、ここでは通用しなかった。 そこに存在していたのは、「任務（What/Why）」だけを共有し、「実行（How）」の空白を完全に個人に委ねる、究極の信頼関係だったのだ。
余談だが、この環境は自分に思わぬ成長をもたらした。「相手は文脈を一切知らない」という前提で話す必要があるため、複雑な背景やコンテキストを効率よく、かつ誤解なく伝えるスキルが叩き込まれてきた。
任務の正体：「実装」ではなく「意思決定」を託される
具体的に、どのような形で仕事（任務）が渡されるのか。それは「決まった仕様をコードにする」という作業依頼とは程遠いものだった。
例えば、「AIを使ってこの業務を自動化できないかな？」といった、ふわっとした相談から始まる。 そして渡される時の言葉はこうだ。 「これ実現したいんだけど、今は他の優先すべき課題があるから頼む」
ここには「How（どうやるか）」の指示が一切ない。「どのツールを使うか」「どうアーキテクチャを組むか」は完全に空白だ（もちろん、会社規則とセキュリティガイドラインの遵守は大前提である）。
渡されるのは「欲しい結果」と「Why（なぜやるか）」だけ。 そもそも「解決可能かどうかも不明」なボールが、信頼とともに飛んでくるのだ。
ここで求められているのは、単なる実装力ではない。「技術検証」と「判断」だ。 技術的に可能か？ コストは見合うか？ 運用に乗るか？ 調査の結果、もし精度が出なかったりコストが高すぎたりするならば、「やらない（廃止する）」という判断を下すことすら任されている。
詳細な指示がないということは、裏を返せば「正解がない」ということだ。 だからこそ、任されている自分が専門家として調べ、考え、決めるしかない。 「実装」ではなく「意思決定」を託されること。これこそが、本当の意味で「仕事を任される」ということなのだと、肌で理解した。
ただし、この自由には重い責任が伴う。 プロセスを任される代わりに、「なぜそうしたのか（説明責任）」と「結果はどうだったか（成果）」については、一人のエンジニアとしてプロの水準が求められる。もちろん、果敢に挑戦した結果の失敗は「次への学習」として称賛されるが、思考停止や妥協による失敗には厳しい。自由だからこそ、その選択にオーナーシップを持つことが求められるのだ。
なぜ「詳細を見ない」で組織が回るのか？
最初は正直、「本当に見てなくて大丈夫なのか？」と不安になることもあった。
しかし、冷静に考えるとこれには合理的な理由がある。
そもそも、CEOや役員が全社員の仕事の「How」まで把握しようとしたら、物理的に頭がパンクしてしまう。何より、逐一確認が入ることで意思決定が遅れ、会社の成長スピードが落ちてしまうだろう。
だからこそ、「任務を果たす人」即ち優秀な人材を採用し、採用した以上は信じて託す。
「厳格な選考を通った＝信頼できる仲間」。だから逐一確認しない。このシンプルだが強力なロジックが、組織の根底にある。
その実例を、自分自身も体験した。
インターン開始当初、自分はCEO、共同創業者とCBDO直下のチームで、AI活用の特命任務にあたっていた。
しかしフェーズが進み、会社は専任の「AI-Opsマネージャー」を採用した。するとCEOは、その領域を彼らと自分たちチームに完全に託し、自身は次の経営課題や別の新しい課題へ向かったのだ。
自分も現在は、その新しいマネージャーのもとでAI-Opsエンジニアとして働いている。
「採用して、任せて、次の仕事へ行く」。
このサイクルが回っているからこそ、役員は経営に専念でき、現場は自分の専門領域に専念できる。詳細を見ないことは、組織をスケールさせるための必須条件だったのだ。
「放置」ではなく「信頼の連鎖」
ここまで読むと「リリースまで完全な放置（丸投げ）ではないか」と思うかもしれないが、そうではない。 実装の「How」は任されるが、設計レビューやコードレビュー、テストといった品質を担保する仕組みは徹底されている。 また、このセーフティネットは入社初日（Day0）から機能している。
直属のマネージャーやチームは進捗を見まもり、困ったことがあればSlackで投げれば即座に返信が来る。同じチームだけでなく、クラウド基盤チームやCorpIT、そしてビジネスサイドの他部署のメンバーも、驚くほど速く助けてくれる。
そこにあるのは「監視」ではなく、ゴールに向かうための「支援」のネットワークだ。そして、信頼はモチベーションの伝播を生む。互いにリスペクトし合っているからこそ、全社イベント「Win Session」やSlackでの成果報告はいつもお祭り騒ぎのように盛り上がる。
「あ、みんな凄いことやってる。自分も最高の成果で応えなきゃ」
そんな健全な責任感とやる気が、自然と湧いてくるのだ。
まとめ：信頼が生む「プロ」の自覚
「詳細を知らない」と言われること。
それは最初は不安だったが、今では「プロとして認められた」という勲章のように感じている。
「信頼しているから、やり方も任せる」。
その無言のメッセージに応えるために、今日も自分は（自分で決めた方法で）コードを書いて何かを実装する。
もしあなたが「裁量」という言葉に飢えているなら、ぜひログラスの扉を叩いてみてほしい。ここには、想像以上の「余白」と、それを支える最高の仲間たちが待っているはずだ。
Discussion