「わかる」と「できる」を超えて〜スキルは身につけ、センスは磨く、熟達のメカニズム

これまで、仕事を技芸と捉える視点から、熟達を測る三つの尺度として「練度」「広さ」「セルフマネジメント」について書いてきました。

これらの尺度を伸ばしていくために、私たちは何を積み重ねればよいのでしょうか。知識なのか、経験なのか、それともセンスのようなものなのか。今回は、ソフトウェア開発における「できる」の正体と、その身につけ方について整理します。

「わかる」と「できる」のあいだにあるもの

まず明確にしておきたいのは、知識としてわかっていることと、実際にできることの間には大きな隔たりがあるということです。

プログラミング言語の仕様を理解したからといって、良いソフトウェアが作れるわけではありません。これは、日本語の文法に詳しくても、面白い小説や心に響く文章が書けるとは限らないのと同じです。

ソフトウェア開発は、多分に身体性を伴うものです。たとえば自転車の乗り方を本で読んで理解しても、すぐには乗れません。車の運転も同様で、練習を重ねて乗れるようになると、車体が自分の身体の拡張であるかのように扱えるようになります。

ソフトウェア開発もこれと同じです。頭で理解するだけでなく、身体に馴染むまで練習を繰り返す必要があります。研修で知識を得ただけで一生できるようになることはありません。イメージした通りに手を動かせるようになるまで、鍛錬を積むしかないのです。

宮本武蔵の『五輪書』に、「千日の稽古をもって鍛となし、万日の稽古をもって錬となす」という言葉があります。「鍛錬」という言葉は、ここから来ています。千日（約3年）の稽古で基礎を固め、万日（約30年）の稽古を経てようやく自分のものとして練り上げられるとされています。

私は、ソフトウェア開発には宮本武蔵が目指した道と同じくらいの技芸としての奥行きや面白さがあると感じています。

試行錯誤が生む「面白い」という感覚

私が初めてプログラミングに触れたのは、小学生の頃なので40年ほども前の話になりますが、最初は知識もなく、説明書に書いてあるゲームのコードをそのまま打ち込んで、それが動くことから始まりました。そのときは「わかる」も「できる」もありません。

そこから、少し変えてみて動かしてみたり、似たようなゲームを作るためにを自分で打ち込んでみたり、動かなくなったら、なぜ動かないか考えて直してみたり、そんなことを繰り返していくうちに、動くことが快感になって、のめり込んでいきました。あれが面白いと感じた瞬間でした。

ソフトウェア開発に限らず、身体性を伴うことは技芸の特徴であり、その「できる」には繰り返しの体験が必要なのです。

プログラミングの良いところは、失敗しても修正が楽なので、何度も試行錯誤ができることや、できた結果がすぐに反応として返ってくるところです。ただ、現代だとスマホやウェブのアプリを作ろうとすると、前提知識が膨大になっていて「できる」を体験するまでの知識が多くなりすぎています。

もっと、初心者がプログラミングの素朴な面白さを体験したり、教わったりする機会を作っていきたいと考えています。

経験という名の「引き出し」

「できる」ようになった先には、「うまくできる」への道があります。ここで必要になるのが経験です。

私たちは、経験から得られた知見を「引き出し」と呼んでいます。引き出しとは、何かを作ろうとするときに、その作り方と完成形が具体的にイメージできることです。一度作った経験があれば、次に同じようなものを作ることは容易になります。

プロフェッショナルとして大事なことは、見積もり通りに仕事を完遂することです。試行錯誤は面白いものですが、仕事においては時間を溶かす要因にもなります。経験に基づいた設計ができれば、実装段階での試行錯誤や手戻りを最小限に抑えられます。

ベテランと初心者の決定的な差は、この「引き出し」の数と、それに基づいた設計能力にあります。

ベテランは、実際にコードを書く時間が驚くほど短いものです。それは手を動かす前に、頭の中で設計が終わっているからです。設計が固まっていれば、コーディングは単なる出力作業になり、手戻りは起きません。

この段階に達していると、生成AIは強力な武器になります。単なる出力作業をAIに任せることで、ベテランはさらに生産性を高められます。一方で初心者は、完成形のイメージが持てないまま手を動かそうとします。AIを使っても、結局は試行錯誤を繰り返すことになるため、ベテランとの差はなかなか埋まりません。

仮にベテランであっても、もし経験のない技術を扱う場合は、まず小さく試せる範囲のものを作ったり、あるいはその技術だけを試してみるという「スパイクを打つ」という手法をとります。そして、現代ではAIがその大きな助けになります。

「スキル」は身につけ、「センス」は磨く

熟達を考えるうえで、避けて通れないのが「センス」という言葉です。開発現場では「ひらめきが必要か」という問いをよく受けますが、私は不要だと考えています。

ソフトウェアは論理を積み上げて作るものです。思いつきで開発することはありません。もし「ひらめき」と呼べるものがあるとするなら、それは考え抜いた先に見つかるものであり、それもやはり経験に基づいています。

熟達に必要なのは、スキルとセンスの使い分けです。

スキルは、答えがある知識や技術です。本人が持っていないものを学習し、鍛錬によって身につけるものです。

対してセンスは、正解がないなかで「良し悪し」を判断する感覚です。これを私たちは審美眼と呼ぶこともあります。

「美しいコードとは何か」「良い設計とは何か」がわかること。コストや時間といった状況下で、適切なトレードオフの決断ができること。これらはスキルというより、磨き上げるべきセンスの領域です。AIは選択肢を提示してくれますが、最後に決めるのは自分自身であり、その判断にはセンスが求められます。

フィードバックと客観視でセンスを磨く

では、正解のないセンスをどうやって磨けばよいのでしょうか。

そこで重要になるのが、熟練者からのフィードバックです。自分が作ったものに対してレビューで「良い」「悪い」という判断をもらう。なぜ悪いのか、どうすれば良くなるのかという判断基準を、自分の中に少しずつインストールしていくのです。これには、作ったものにフィードバックをもらうループを回すのが一番の近道です。

加えて、センスを磨くためには「良いものを見ること」も欠かせません。自分の目が肥えていなければ、自分が作ったものに対しても妥当な良し悪しの判断が下せないからです。美しいものを見なければ、美しさを会得することはできません。ベテランが作る作品としてのコードを見ることは、自らの目を肥やすことにつながります。

さらに、後進のコードをレビューすることも重要な経験になります。今度は自分がフィードバックする立場になることで、より客観的な観点が得られるようになるからです。また、相手に良し悪しを説明するプロセスを通じて、自分の中にある感覚を理論化していくことにもなります。

鍛錬をつなげる仕組みとしての徒弟制度

知識を得て、経験を積み、センスを磨く。これは一朝一夕でできることではありません。特に、たった一人だけで熟練のソフトウェア開発者になるのは非常に困難で、相当な時間と才能が必要です。

そこで私たちソニックガーデンでは、あえて「徒弟制度」という形の育成の仕組みを導入しています。これは、昔の職人のように師匠の身の回りの世話をするといった類のものではなく、プロの技術を間近で見て学び、自ら実践し、フィードバックを受けるための合理的な育成の仕組みです。

私たちの徒弟制度では、経験豊富なベテランプログラマーが師匠である「親方」となり、数名の「弟子」を直接指導します。親方と弟子は、最初は同じオフィスで働いて、セルフマネジメントの基礎を身につけることから始まります。親方は、仕事の中で良いソフトウェアを作るための機会を与えます。

弟子は、ただ教わるだけでなく自ら実践しなければ身につきません。しかし、実践するだけでは正しいフォームは身につきません。だからこそ、親方がフィードバックを行うのです。できることを増やして、段階的に成長していくことをガイドします。

この徒弟制度という環境で成長を促進することはできますが、最終的に伸びるかどうかは本人次第です。面白さを原動力に、地道な練習とフィードバックを積み重ねること。それが、仕事を技芸とするための唯一の道だと言えるでしょう。