ソフトウェア開発に関わる者として実感・共感できる話

ソフトウェアの仕様書は料理のレシピに似ている

昨今、個人的におぼろげながら感じていたことが明確な文章になって目の前に現れたという感じで、非常に共感できます。

私の身近では、ソースコードを記述することは「製造」と呼ばれています。

個人的にはソフトウェアにおける「製造」とは「コンパイル」のことだと勝手に思っています。つまり、ソースコードを記述している間、そこから得られるフィードバックを元に「設計」をし続けているということです。

普通、「設計」の通りに「製造」したら毎回同じものができあがるはずであり、ソフトウェア開発でそれが発生するのは「コンパイル」の時だけです。*1

と思っていたこともあるため、

　実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。（ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。）

ソフトウェアの仕様書は料理のレシピに似ている

という点について、同感することしきりです。

また、

ほどんど自らソフトウェアの開発をしたことの無い人達が詳細資料書を書き、それを外注に発注してプログラムを書かせる、というソフトウェアの作り方をしていた。

ソフトウェアの仕様書は料理のレシピに似ている

というようなことも身近であったりするわけなんですが、やっている側も次のような状態になり、困ったことになるのではないかと思っています。(今、自分がそうなりそうで怖いというのもあるのですが)

• 「一部分だけでも自分で作ってみて設計を検証する」もしくは「基盤部分は作りその上に載る物について依頼する」といったことをせず、全てを丸投げしてしまう場合、最終的にできあがったものの詳細な内容が理解できず、できあがった物の正当な評価も行えなくなる。
  • 外部入出力は外見から検証できますが、内部の構造が「良い状態」かどうかは評価できない可能性が高いと思います。
• 最初は全て理解できていたかもしれないが、「自分で手を出さない」ことにより、理解できないことが少しづつ蓄積していき、最終的には「実現できること」の「予想」すらできなくなってしまう。

テクノロジーの修得は、「差分アップデート」の段階に入ると、ついていくのが比較的楽になると感じています。

つまり、

• 以前の知識を踏み台にしつつ「この欠点」を克服した新しい技術が出たから、それについて学ぶ

という感じでちょっとづつ知識を増やしていける状態です。

20年前の人に突然、「携帯電話をみんなが持ってていつでもどこでも連絡がつき、さらにインターネットとよばれるもので世界中の人と瞬時にコミュニケーションができる」と言えば「そんなことは信じられない」かもしれませんが、現在の我々は、ここに至るまでに「差分アップデート」してきたために、なんら違和感を感じない….というのと似ています。

この逆で、ちょっとつづちょっとづつわからなくなって、最後にはまったくついていけなくなる。つまり「差分ダウングレード」が発生してしまうかもしれないということが怖いです。「差分アップグレード」が変化に気づきにくいように「差分ダウングレード」も変化に気づきにくいと思います。

とはいえ、やはり若い時の学習能力・集中力を年を取っても維持するのは難しいわけで、この劇的なまでに変化の激しい業界でどういうスタンスをとっていけばいいのかは思案のしどころではあります。

100年前の知識ですら踏み台にして新しいことを生み出すことが可能なシェフとは、ここが違うところなんではないかと…..。