私たちがアーキテクトを置かない理由〜全部を担える人を育てる、という選択

先日、モダンなアーキテクチャとは何か、をテーマに対談する機会がありました。一般的に、アーキテクトとは、機能を提供し続けられる基盤を設計する専門職のこと。仕組みを作る人と、その仕組みの上でアプリケーションを作る人を分けて、前者を指す言葉とされています。

私たちソニックガーデンには、その役割がありません。全員をプログラマと呼び、設計から実装まで全部を担っています。なぜアーキテクトを置かないのか。今回、その理由を改めて言語化してみました。

アーキテクトを名乗っていた頃に、足りなかった視点

20代の頃は、私もアーキテクトを名乗っていました。自作のフレームワークを作って、社内に広めたりもしていました。

当時は、難しい問題を、スマートに解けるほうが優秀だと思っていました。どんな要件が来ても受け止められるように、先回りして拡張の仕組みを用意し、例外にも備えて、共通の基盤として整えておく。考え抜いて立派に作れば、評価されるし、喜ばれる。

経営する側に回ってみると、見え方が変わりました。先回りして備えた例外や拡張のほとんどは、実際には使われません。その例外は起きないから、作らなくていい。そう判断して捨てた瞬間に、難しさの8割が消えることがあります。難しい問題を、難しいまま解く必要などなかったのです。

当時の自分に足りなかったのは、設計の力ではありませんでした。事業の役に立つ、という視点です。立派な仕組みを作ること自体が目的になっていて、それが事業の役に立つのかどうかまでは、見ていなかったのです。

役割を切り出すと、そこに「納品」が生まれる

アーキテクチャを設計することは、いまでも大事な工程だと考えています。引っかかっているのは、そこだけを担う役割にすることのほうです。

役割として切り出すと、基盤を作って渡す、という区切りが生まれます。その区切りは、もう納品です。事業は続いていくのに、ソフトウェアだけがどこかで止まる理由はありません。実際、フレームワークごと入れ替えることもありますし、インフラでも、言語でも、必要なら変えます。冒頭の、モダンなアーキテクチャとは何か。私の答えは、変化に対応しやすい状態が保たれていることです。その状態は、渡して終わりにしない人がいて、はじめて保てます。

アーキテクチャをずっと改善し続ける役割、としてのアーキテクトなら、いてもいいのかもしれません。それでも、それだけをする人を置くのは、オーバーヘッドが大きい。だったら、全部やるほうがシンプルです。

事業からコードまで、すべてはソフトウェア開発の「工程」である

事業の戦略を考えることも、要件を整理することも、アーキテクチャを設計することも、コードを書くことも、すべてソフトウェア開発の工程です。役割ではなく、工程。ものづくりの側には、分けなければいけない理由はありません。

一人が全部を担うほど、事業とソフトウェアはぴったり合います。間に人が入るほど、伝言ゲームでズレていく。理屈でいえば、社長が一人で事業もソフトウェアも作れるのが、いちばんズレません。現代の事業において、ソフトウェアがなくていい会社はほとんどないのですから、経営とソフトウェアが一体になっているほど強い。

そして、事業まで理解して作るなら、求められたものを作るだけでは足りません。それはやめましょう、こちらのほうがいい、と提案できることまでを含めて、開発の仕事だと考えています。

できない前提で仕組みを作るか、できる前提で人を育てるか

こう書くと、それは難しい、と言われます。たしかに難しい。事業まで理解して、提案までできる人は、そう多くいません。

だから世の中は、別の形を選んできました。できる人が少ないなら、できない人のままでも仕事になるように、腕のいい人が土台を作る。アーキテクトが基盤を用意し、その上でたくさんの人に作ってもらう。効率よく人が動ける工場を作って、たくさん作る、という製造業の発想です。SIerにいた頃は、私もそう説明していました。

ただ、いま振り返ると、その考えは、作る人たちの可能性を信じていなかったのだと思います。いつまでもできないままであることを、前提にしているからです。

難しい仕事を担える人は、育てられる

私たちが立っているのは、逆の前提です。できる人が少ないなら、できるように育てればいい。

実際、私たちはお客様の会社にCTOのような立場で入り、事業計画やロードマップの検討から、作るところまでを一人で担ってきました。その全部を、プログラマの仕事と呼んでいます。

そして、5年ほど前から徒弟制度を始めました。まず、いいコードを書けるところを徹底する。いまなら、AIを使っていいコードを作れるところ、になります。そこから内部設計、データモデルの設計、要件の整理、事業戦略の検討、そして経営者の相談相手へと、担う範囲を少しずつ広げていきます。範囲が広がっても、仕事は取り替えません。役員も親方も、いまだにコードを書いています。できることが増えて、仕事の縁が広がっていく。

簡単ではありません。5年かけて、ようやく育つ階段が見えてきたところです。

それでも、本当にできないのだろうか、とは思うのです。明治のはじめに、国民のほとんどが文字を読めるようにしようと言ったら、難しいと言われたはずです。90年代に、全員がパソコンを使えるようになる、と言っても同じでしょう。いまは、ほとんどの人が文字を読み、パソコンを使っています。難しさの多くは、いまこの瞬間を見て、難しいと言っているだけなのかもしれません。もっと人間の可能性を信じていい、と考えています。

分けずに全部を担う仕事は、「技芸」になる

アーキテクトという役割を否定したいのではありません。アーキテクチャを考え、改善し続けることは、これからも欠かせない工程です。ただ、できないままを前提にした土台を作ることより、できる人を育てて増やしていくことのほうを、私たちは選びたいのです。

それに、これは効率だけの話でもありません。切り分けられた仕事は、どうしても他人事になっていきます。自分の作ったものが、誰の役に立ったのか。事業はうまくいったのか。それが見えないまま、頼まれたものを作り続けるのは、つまらないものです。

事業から作るところまで、分けずに担う仕事は、大変ですが、最後まで自分の手応えが残ります。作ったものが役に立てば、それが直接わかる。うまくいかなければ、作り替えればいい。そんな働き方を「技芸」と呼んで一冊にまとめたのが、9月に出る新刊『仕事技芸論』です。