正解を書くのが、仕事だった

株式会社Codence代表の西野です。エンジニアとして働いていた頃、仕事のほとんどは「正解を書くこと」だったように思います。仕様があり、期待される挙動があり、その通りに動くコードを書けば評価された。テストが通ればOK。レビューで指摘された箇所を直せばOK。手が止まるのは、自分の知識不足か調査不足かのどちらかで、ほぼ必ず「正解」が先にありました。

その前提で働いてきて、経営者になった途端、急にそれが通用しなくなった。今日はその話を書きます。

正解のない場所で、毎日決めている

Codenceを立ち上げてから一年と少しが経ちました。この期間で痛感したのは、経営の仕事のほとんどは「正解がわからない中で、何かを決めること」だということです。

採用面談に来てくれた人に、どのくらいの条件を提示するか。今月の営業先をどこに絞るか。受託開発の立ち上げを急ぐか、SESの基盤をもう少し固めるか。メンバーが現場で違和感を抱えているとき、すぐ動くのか、もう少し様子を見るのか。新しい協業相手と組むかどうか。開発環境にどこまで投資するか。

どの判断にも、ネットで検索すれば出てくるような一問一答の答えはありません。正確に言うと、答えに見えるものはたくさん転がっているのに、自分たちの状況に当てはめた瞬間、どれも少しずつズレて見える。他社の事例は前提が違うし、本に書いてあるフレームワークは、当てはめる手間のほうが重く感じることもある。

エンジニア時代の私は、こういう場面でも「答えがどこかにあるはずだ」と探し続けていたと思います。もっと本を読めば。もっと経験者に話を聞けば。もっと情報が集まれば。そうすれば迷わずに済む、と信じていました。

だから、創業して最初の半年くらいは、かなり苦しかったです。インプットは止まらないのに、判断の質が上がっている実感がない。誰かに相談しても「最後は自分で決めるしかないですよ」と言われて、確かにそうだけど、そうじゃなくて、と思っていました。

特に苦しかったのは、決めていないことが積み重なっていく感覚です。月曜に判断できなかったことが、水曜に別の判断とくっついて、金曜には全体像が見えなくなる。先延ばしにした分、課題はひとつずつ重くなっていって、来週の自分に押し付けている自覚だけが残る。あの時期の土日は、ほとんど仕事のことを考えていました。

考えている、というと聞こえはいいのですが、実際は「頭の中で同じ材料を何度も並べ直している」だけのことが多かった。判断の根拠は先週と変わっていないのに、自分だけがぐるぐるしている。エンジニア時代の私なら、こんな状態でコードを書いていたら絶対に手を止めてリファクタリングしていたはずです。それなのに、経営の判断については、同じ姿勢で向き合えていませんでした。

問いを立てる方が、答えを探すより先だった

あるとき、自分が「答え探し」に夢中になっていた一週間があって、結局何も決まらずに月末を迎えたことがありました。そのときに、ふと思ったんです。「そもそも、自分は何を決めようとしていたんだっけ」と。

決める対象がぼやけたまま、情報だけを集めていた。答えのサイズも出したい精度も自分で設計できていないのに、市場調査や他社事例だけを眺めていた。そりゃ、決まらない。

そこからは、意識的に「問いを立てる」ことから始めるようになりました。

今、自分が本当に迷っているのは何か。それは「やるか・やらないか」の問題なのか、「いつやるか」の問題なのか、「誰とやるか」の問題なのか。自分の中で問いの輪郭がはっきりすると、情報の必要量は一気に減ります。集めるべき材料もシンプルになる。そして、そこまでくると、驚くほどあっさり決まることが多い。

たとえば「受託開発を本格化させるか」という問いがあったとします。これを「やる・やらない」で考えると、情報は無限に必要です。市場規模、競合、人材、営業ルート、資金。どれから手をつけても終わりません。

けれど、問いを分解して「受託開発に半年で一人投下するか、しないか」にすると、必要な情報は急に減ります。半年分の人件費をSES売上から捻出できるか。担当させたい人の現在の現場をいつ抜けられるか。抜けた穴は別の案件で埋められるか。この三つが答えられれば、だいたい決められる。

経営の意思決定は、「正解を見つける力」よりも「何を決めるのか、正確に自分に問う力」のほうが先に効いてくる。そう実感してからは、会議でも面談でも、最初の数分を「問いの確認」に使うようになりました。メンバーから相談を受けたときも、いきなり答えを返すのではなく、「その判断って、どのレベルの判断ですか」と逆に聞き返すことが増えました。

問いを立てる力は、エンジニアの現場でも効く

面白いのは、これはエンジニアの仕事にも全く同じことが言えるという発見でした。

私たちはSESを主軸にしていて、メンバーはさまざまな現場で働いています。現場に入って最初の数週間、一番差がつくのは「技術力」ではありません。正確に言うと、技術の差はあるけれど、それは数週間でひっくり返るような差ではない。それより、もっと手前の部分で差がつく。

それが「問いを立てる力」です。

新しい現場に入ったとき、仕様書を渡されて「これ実装してください」と言われる。その時、何も聞かずに手を動かし始める人と、一呼吸おいて「ここ、こういう意図で合っていますか」と確認する人がいます。後者のほうが、ほぼ確実に早く信頼を得ていく。理由はシンプルで、そのひと言が「自分がズレた方向に走り出さない安全装置」になるからです。

さらに一段上の人は、仕様書を読み込んだ上で「このユースケースって、どう扱う想定ですか」と、仕様に書かれていない穴を見つけてきます。こうなると、もうその人は「作業者」ではなく「相談相手」になる。現場の信頼度が一段跳ね上がる瞬間です。

うちのメンバーで、入社してまだ数ヶ月のエンジニアがいます。現場に入って最初の一週間で、仕様書の矛盾を三箇所指摘してきた、とプロジェクトマネージャーから連絡をもらいました。指摘の仕方も丁寧で、「こう読めるのですが、こういう意図でしょうか」という確認ベースの聞き方。その後、彼はその現場で一番相談される側の人になっていきました。

彼が特別に優秀だったかと言えば、技術だけ切り出せば、もっと経験年数の長い人はたくさんいます。彼が早く信頼を得られたのは、間違いなく「問いを立てる習慣」があったからです。

そしてこの筋肉は、一度身についたらどの現場でも持ち運べます。言語が変わっても、プロジェクトのフェーズが変わっても、チームの文化が変わっても使える。私はSESのキャリアを「現場を転々とする」とネガティブに捉える言い方を聞くことがあるのですが、問いを立てる習慣を磨く場としては、むしろ条件は良いと思っています。違う前提の現場に入るたびに、新しい問いの立て方を試せるわけですから。

正解を手放したら、動けるようになった

話を経営の側に戻すと、私は「正解を書くこと」を仕事の中心から外してから、明らかに動きが軽くなりました。

以前は、決断のたびに「これで合っているか」を自分の中で検証していました。不安が消えるまで情報を集めて、情報が集まっても不安が消えないことが多くて、結果的に決めるのが遅れる。遅れた分だけ、メンバーや取引先を待たせていた。今思えば、あれは誠実ではなく臆病だったと思います。

今は、完全な正解ではないとわかっていても、「今の時点の最善」を決めて動かすようにしています。決めた後に違うとわかれば、そのとき修正する。そっちのほうが、最初から百点を狙って手が止まる人よりも、ずっと速く前に進める。

実際、この半年で「間違ったな」と思って修正した判断もいくつかあります。営業先の優先順位付けがうまくいかなくて、途中で組み替え直したこともあるし、面談のフローを変えたら応募者の満足度が下がってしまって、元に戻したこともあります。以前の私なら、そういう小さな失敗の気配が見えただけで、次の判断がまた遅くなっていたと思います。

今は、失敗を「次の問いのヒント」として拾えるようになってきました。なぜ想定と違ったのか。何を見落としていたのか。次に同じような判断をするとき、何を事前に確かめれば違う結果になるのか。これを数回繰り返すだけで、判断の質は体感として上がっていきます。

ひとつ例を書いておくと、SES案件の受け方について迷っていた時期がありました。単価で選ぶのか、技術内容で選ぶのか、チームの雰囲気で選ぶのか。最初は「単価が高いほうが会社のためだろう」と単純に考えていたのですが、実際にそれで案件を受けたら、メンバーが合わずに半年で抜けることになった現場がありました。売上は上がっても、メンバーが疲弊すれば次が続かない。その失敗の後、「初回の案件で、この人の三年後の景色が変わるか」という問いを自分の判断軸に足しました。結果として、単価の選び方自体は変わっていないのですが、選んだ後のフォローの仕方が変わりました。

もちろん、それができるようになったのは、一緒に働いてくれる人たちのおかげでもあります。こちらが「今はこう決めた。理由はこうです」と説明すれば、ちゃんと聞いて、必要なら意見を返してくれる人たち。彼らの存在があるから、不完全でも決められる。ひとりで完璧を目指す経営より、不完全を共有する経営のほうが、現場は回る。

創業期の会社で、一緒に問いを立てたい

Codenceはまだ一年目の、小さな会社です。SESを主軸にしながら、並行して受託開発の立ち上げを進めています。制度も仕組みも整っているとは言いがたいし、正直、毎週のように「どうしようか」という場面が出てきます。

そういう環境なので、求めている人もはっきりしていて、正解を求めてくる人ではなく、一緒に問いを立ててくれる人と働きたいと思っています。

具体的に言うと、こういう姿勢を持っている人です。技術の細部にこだわりながらも、「それは今、優先してやる価値があるのか」を自分に問える人。仕様や依頼を受け取ったときに、そのまま飲み込まず、「なぜこれが必要なのか」を一度考える癖がある人。困ったときに「どうすればいいですか」と丸投げせず、「自分はこう考えたのですが、どう思いますか」と持ってこられる人。

技術スタックで言えば、Javaが中心になりますが、C#の経験でも構いません。正直に言うと、言語そのものよりも、いま書いた姿勢の部分を大事にしています。経験年数は3年以上を目安にしていますが、これも杓子定規ではなく、「問いを立てる習慣」がどのくらい染みついているかを見ています。

面談では、経歴書に書いてあることを読み上げるような時間にはしたくないと思っています。むしろ、「前職で一番迷ったときに、どう判断しましたか」とか「直近の現場で、仕様がぼやけていた場面ってありましたか」という問いを投げて、そこからの返しを聞かせてもらうことが多いです。その返し方に、その人の「問いを立てる筋肉」が出ます。

面談で逆にこちらに質問をたくさん投げてくれる人も、私は強く印象に残ります。会社の方針、今後の事業、案件の選び方、評価の仕方。聞かれて答えながら、「この人は入ってからも自分で問いを立てて動ける人だ」と感じることが多いです。逆に、こちらからの説明を受け取るだけで終わる面談は、どこか不安が残ります。会社に入ってからも、指示されたことをそのまま処理するだけの関係になってしまう気がするからです。

もしこの記事を読んでいて、「自分は答えを探すタイプだな」と少しでも引っかかった人がいたら、それは悪いことではありません。私もそうでした。むしろ、気づいた時点でかなり有利で、そこから問いを立てる習慣を身につけていけば、自分の見える景色は確実に変わります。そういう変化を、Codenceの現場で一緒に積み上げたい。

正解は、書くものから、立てに行くものへ

エンジニアとしての10年、正解を書くことを仕事にしてきて、経営者として正解を手放すことを覚えた。結果としてわかったのは、正解は書くものではなく、自分で問いを立てて取りに行くものだ、ということでした。

問いを立てる力は、経営でもエンジニアリングでも効く、汎用的な筋肉です。そしてこの筋肉は、整った環境より、少し揺れている環境のほうが育ちやすい。創業期のCodenceは、その意味ではかなり良い練習場だと思っています。

誤解を恐れずに言えば、答えが用意された場所で働き続けると、問いを立てる筋肉は少しずつ弱っていきます。仕様書通りに書けばOK、前例通りにやればOK、という環境が悪いとは言いません。そこで得られるものもたくさんあります。ただ、その期間が長くなると、判断を求められたときに手が止まるようになる。これは本人が悪いのではなく、使っていない筋肉が落ちるのと同じです。

私たちの現場にも、答えのない問いは山ほど転がっています。それを一緒に拾いに行ってくれる人を、待っています。記事を読んで少しでも気になった方は、気軽に話だけでもぜひ聞きに来てください。合うか合わないかは、話してみないとわからないので、肩の力を 抜いて来てもらえたら嬉しいです。