Yahoo! JAPAN

与えられた時間の中で、最大のパフォーマンスを発揮するのがプロ。しかし、経験の浅い若手にとっては決して容易なことではない。

失敗をするたび、つい「もう少し時間があれば……」「質を高めるには時間が足りなかった」という言い訳が口をついて出そうになるが、果たして、それは本当に“時間”の問題なのだろうか。

今回、そんな疑問に答えてくれたのは、長年エンジニア組織づくりに尽力してきたソニックガーデンの代表・倉貫義人さんと執行役員・野上誠司さん。仕事とクオリティーの関係性や若手が「量より質」を考え始めてもいい時期について、詳しい事例をもとに教えてもらった。

株式会社ソニックガーデン
代表取締役　倉貫義人さん（@kuranuki）

大手SIerにて経験を積んだのち、社内ベンチャーを立ち上げる。2011年にMBOを行い、株式会社ソニックガーデンを設立。月額定額＆成果契約で顧問サービスを提供する「納品のない受託開発」を展開。全社員リモートワーク、オフィスの撤廃、管理のない会社経営など新しい取り組みも行っている。著書に『人が増えても速くならない』（技術評論社）『ザッソウ 結果を出すチームの習慣』（日本能率協会マネジメントセンター）『「納品」をなくせばうまくいく』（日本実業出版社 ）など

執行役員　
野上誠司さん（@LuckOfWise）

1982年生まれ。大学卒業後、地元のSI企業にてシステム開発に約5年間従事。その後、パッケージソフトウエアの企画・開発販売に携わる。2014年ソニックガーデンに参画。「納品のない受託開発」の開発責任者として多くの企業の支援を行っている。21年から執行役員として経営にも携わる。22年にはソニックガーデンの徒弟制度の立ち上げに関わり、親方として若手プログラマーの育成に取り組んでいる

「時間がない」からパフォーマンスが上がらないは本当か？

——本題に入る前に伺います。倉貫さんはプログラマにとって「パフォーマンスが発揮できている状態」ってどのような状態だとお考えですか？

倉貫：僕らの会社、ソニックガーデンでは、シンプルに「事業にどれだけ貢献できてるか」でパフォーマンスを判断します。例えば若手だとプログラムを書くことが仕事であれば「どれだけ早く優れたコードを書くか」ですね。

こう言うと、スピードと品質がパフォーマンスの重要な構成要素だと思われるでしょうが、他にも加味すべき要素はあります。

——と、言いますと？

倉貫：コストです。パフォーマンスを発揮するためには、それなりのコストがかかります。先ほどのプログラミングの例えでいえば、マネジャーが若手のコードをレビューしたり、品質チェックしたりする教育コストがかかります。書かれたコードが良くなければ修正コストも必要です。

目に見える成果からコストを差し引いたものが、本当の意味での「パフォーマンス」なので、一見、パフォーマンスが優れているように見えても、実はそれほど成果が出ていないこともあるわけです。

——野上さんは「エンジニアのパフォーマンス」についてどう思われますか？

野上：まず、ジュニアクラスのプログラマーの場合、時間をかけたからといって必ずしも品質の高いものができるわけはないという認識です。とりわけ若い時分って「期待に応えるためには、とにかく与えられた仕事は自分で何とかしなきゃいけない」と思いがちですよね。

でも仕事って、従業員個人のものというより会社のもの。一人で抱え込んで質の低いコードが生まれたり、教育コストがかさんでしまったりするくらいなら、問題が小さいうちに手を挙げてもらった方が結果的に速くいいものができます。

業務量が手に余るなら、他の人に割り振ればいいだけのこと。「時間があればできるのに」って考え方は、一人で仕事をやり遂げることが前提になっているのかもしれませんね。会社という組織で開発する上では馴染まない考え方だと思います。

——とはいえ「もっと時間があれば、あれもこれもできたのに」と考えてしまうこともありそうです。そうした人たちが生まれる要因はなぜだと思いますか？

倉貫：1日24時間は誰に対しても平等に与えられているわけなので、大事なのは使い方。エンジニア本人も上長であるマネジャーも、時間を割くべき取り組みに優先順位が付けられていないのではないでしょうか。

仕事で事業責任者の方と話していると、時折「お金も人も時間も足りない」という話を聞きます。リソースが潤沢に無いのは確かだとは思うものの、無ければ無いなりにやるのが仕事というもの。有り体に言えば、手持ちのリソースを精査し優先順位を決めて順にやっていくしかありません。

それは個人の成長やスキルアップについても同じで、「時間がない」というのは、目の前の業務に追われて何をすべきか分かっていない状態なのだと思います。そもそも仕事である以上、やらなくていいものなんてないですからね。

野上：「やらなくていい仕事はない」というのは、僕も同感です。ただ、やらなくていい「作業」はあると思います。

——「仕事」と「作業」、その違いは？

野上：僕らが携わっているソフトウエア開発は、「昨日書いたコードと同じものを今日も書く」といった定型業務とはほど遠いクリエーティブな取り組みです。プログラマーはプログラミングの質を左右するプロセスを端折るべきではありませんし、コードを書くことに時間を割いた方がいい。その上で、駆逐すべきものがあるとしたらExcelで作成したフォーマットの体裁を整えるような、クリエーティブとは無縁な作業です。

空き時間にやるぶんには構いませんが、本来であればソフトウエア開発の本質にかかわらないものに時間を割くべきとは思えません。商習慣としてExcelのフォーマットがどうしても必要なら、自動化するなりして徹底的に効率化すべきです。

倉貫：会社によるでしょうが「なぜだか分からないけど昔からあるからやっている業務」はどんな組織にも多かれ少なかれあるものです。例えば、誰が読んでいるのか分からない報告書のような定型業務が典型です。やること自体が目的化している業務、現場のマネジャーもエンジニアも「無駄だな」と思いながらやっている業務を「作業」だとすると、価値を生むための営みが「仕事」。野上が言うように、価値を生まない作業はやめてしまうなり、効率化してしまうなりすべきです。

野上：もちろん、やりたいことがあり過ぎて時間が足りないという気持ちはよく分かります。それは僕だって一緒。作りたいものは山ほどありますから。だから優先順位を決めたり、効率化したりすることが大事なんです。

——そう考えると、メンバーの仕事配分を差配するマネジャーの責任は重そうです。

倉貫：そうですね。ただ、全ての責任をマネジャーに帰するのはちょっと違うと思いますね。

——どういうことでしょう？

倉貫：メンバーのタスク管理が上手なマネジャーに当たったら成長し、そうでなかったら成長できないという状態があるとしたら、それはマネジャー個人の責任である以上に、そうした状況を放置してしまっている経営の責任があると思うからです。

野上：ソニックガーデンの場合、ソフトウエアを開発する手順として、マネジャーとメンバーが仕事を細かく分解し、どこから手を付けるべきかを決める「タスクばらし」というプロセスがあります。おそらく、パフォーマンスが発揮できない理由を「時間のなさ」に求めるのは、タスクばらしに準じるプロセスを踏んでいないからではないでしょうか。

優先順位が低いタスクに固執していたら、当然時間は足りなくなりますし、よく考えず手当たり次第に手を付けていたら二度手間になることも珍しくありません。

倉貫：「タスクばらし」のように、どんなマネジャーの下についても当たりはずれがないような環境を整えるのは経営の務めだと思っています。直属のマネジャーだけに責任を押し付けるのは間違いだというのはそういうことです。

いずれ質重視に転換すべきタイミングがくる

——優先順位を決めて上から順に仕事をこなしていくことが、限られた時間を有効に使うために必要なのは分かりました。ただ、愚直に仕事と向き合うだけでパフォーマンスは上がっていくのでしょうか？ どこかで質に転換すべきタイミングがありそうです。

倉貫：おっしゃる通り、単に仕事をこなしているだけではいずれパフォーマンスは伸び悩みます。ソニックガーデンでは、量から質への転換を促すために若手の成長を5段階に分けて言語化し、育成の目安にしています（下図参照）。

大雑把にいうと「第1段階」は新卒が身に付けるべきレベル、「第2段階」が仕事を任せられるレベル。ここまででおおよそ3年のイメージです。開発の責任者としてプロジェクトをリードできるレベルが第3段階で、10年程度の経験が必要でしょう。

「セルフマネジメントで自由に働くまでの5段階ロードマップ」より

——こうした段階をつくる必要性を感じたからこそ、明文化されたわけですよね。過去には失敗も？

倉貫：新卒採用を始めたばかりの2020年頃は、若手育成のノウハウが全く無い状態でした。技術力が高く経験もあり、セルフマネジメントできる方しか採用してこなかったので、育成方針を指標にして明文化する必要性がなかったからです。

その結果、ベテランの中にルーキーを放り込むような形で育成することになってしまいました。例えるなら、メジャーリーグ球団にリトルリーグの選手が入ってきたようなもの。キャッチボールするにしてもベテランは手加減して投げなければなりませんし、ルーキーは投げられた球を受け止めることすらままならない。そんな状態では、価値を生み出すことはできません。

この状況を改めるために導入したのが、ルーキーを「弟子」、ベテランを「親方」と見立てた徒弟制度と、今紹介した技術の「熟達」とエンジニアとしての「自立」「成熟」を軸とした5段階ロードマップです。

——この段階を上ることによって、質重視への転換を促すわけですね。

倉貫：そうですね。入社から1、2年は、ある程度量をこなして土台をつくる時期です。この時期に質を問うような仕事や難易度の高い仕事をさせたところで、弟子自身に受け止めるだけの準備ができていなければ負担になるだけ。まだ自転車に乗ったことがない子に乗り方を教えるなら、まず体にバランス感覚を覚えさせるために練習を重ねさせますよね。仕事の量がパフォーマンスを養うのはまさにこの段階です。

量から質に転換するのは、自転車に乗れるようになり、それだけでは飽き足らなくなって、オートバイやクルマに乗りたいと意欲が高まっている段階に例えられます。親方は弟子のそうした変化を見逃さず、頃合いを見計らって仕事の質を上げる手助けをする、そういう役割なんです。

同じ努力をするなら、希望が持てる場所で最善を尽くせ

——親方的な人が身近にいない場合はどうしたらいいでしょう？

野上：もちろん独学でもスキルは磨けますが、さらに上を目指すなら、自分より経験が豊富な人からのフィードバックを受ける機会を作った方がいいでしょうね。そうでないと、どうしても成長の頭打ちが早めにきてしまいますから。

身近に技術的に尊敬できる先輩なり上司なりがいなければ、興味のある技術コミュニティーを探して参加してみてはいかがでしょう。ロールモデルになりそうな人に相談を持ちかけたら、きっといいアドバイスがもらえるはずです。

もし会社の中だけで思う存分働けないことが自分の成長を阻害していると感じているなら、自分でアプリやサービスを作って公開してみるといいですよ。必ずいい経験になりますし仕事にも役立つはずです。

倉貫：よく「石の上に三年」って言いますよね。でも、ただの石の上にいくら座り続けても得られるものは限られるでしょうし、何も得られない可能性だってあります。もし、3年も座り続けられるだけの我慢強さがあるなら、若手を育成する意志と仕組みを持つ会社に転職して鍛えられた方がはるかに有意義でしょう。

野上：そうですね。さっきプログラミングはクリエーティブな仕事と言いましたが、思考力が要求されない作業に追われ、かつその状況が一向に改善される見込みがないなら、早々に見切って違う会社にいくべきだと思います。

倉貫：エンジニアをただの労働力としてしか見ていない会社にいていいわけがありませんからね。中世イタリアの哲学者トマス・アクィナスによると「希望」とは「実現が困難だけど、実現可能性があり、実現すると善い未来のこと」なのだそうです。だからぜひ希望が持てる場所で頑張ってください。それがパフォーマンスを出し続けるためにもっともシンプルかつ的確なアドバイスになると思いますよ。

取材・文／武田敏則（グレタケ）