「裁量がある環境です」

採用ページでよく見る言葉だ。

でも、この言葉ほど意味が曖昧なものもないと思っている。

私が考える裁量は、タスクの進め方や働く時間の自由ではない。 

何を作るか、なぜ作るか、どの順で作るか。 その判断に関われること。それが裁量だ。

仕様を受け取る前に、仕様を作る側にいる

受託開発でエンジニアに最も多い不満は、「仕様が降ってくる」ことだと思う。

顧客とPMが決めた仕様書が届いて、それを実装する。設計の意図が分からないまま、画面仕様書の通りにコードを書く。

「なぜこのAPIがこの形なのか」は聞いても答えが返ってこない。
あるいは「顧客がそう言ったから」で終わる。

うちでは、エンジニアがDiscoveryフェーズから参加する。

記事3で書いた通り、私たちは要件定義を独立した商品として提供している。

その中で、エンジニアは顧客のデータ構造を読み解き、意味構造への変換方針を設計し、何をどの順で作るかを議論する。

仕様を受け取るのではなく、仕様を作る。この違いは大きい。

裁量には根拠がいる

少人数の組織だから、技術的な意思決定は代表の私と直接議論できる。
中間層を通さないから、判断が速い。「このアーキテクチャでいくか、別の方針にするか」を、その場で決められる。

ただし、直接議論するということは、「なんとなくこれが良いと思います」では通らない。なぜその設計を選ぶのか、何を捨てているのか、リスクは何か。技術的な判断の根拠を自分の言葉で説明する必要がある。

裁量があるとは、判断を委ねられるということだ。 判断には根拠がいる。根拠には思考がいる。

裁量の範囲は、実装だけではない

記事4で書いた通り、私たちはエンジニアを「コードを書く人」ではなく「仕組みを作る人」として見ている。

案件で見つけた成功パターンをテンプレート化する。データパイプラインの構築手順を標準化する。Discovery成果物の生成を半自動化する。こうした「仕組みへの貢献」が、個人の評価に直結する。

つまり裁量は、案件の実装だけでなく、組織の仕組みそのものを設計する領域にまで及ぶ。自分が作った仕組みが、次の案件の品質を変える。自分が設計した構造が、そのまま本番で動く。一回きりの納品物ではなく、蓄積される仕事だ。

正直に言うと、全員に向いている環境ではない

仕様を受け取って、言われた通りに実装する方が楽だという人もいる。それは悪いことではない。ただ、うちには合わない。

だからこそ、うちに合うのはこういう人だ。

• 実装そのものより、何を作るべきかの判断に関わりたい人
• 顧客仕様をそのまま受け取るのではなく、仕様を設計する側に回りたい人
• 一案件ごとの納品ではなく、仕組みとして蓄積が残る仕事をしたい人
• 技術選定や設計判断を、根拠付きで議論することを面白いと思える人

裁量がある環境は、自由な環境とは限らない。 判断を求められ、根拠を問われ、結果に責任を持つ環境だ。

その手触りを面白いと思える人と、話がしたい。

株式会社アルバコネクト 代表取締役 作田マルコ聡