黒川利明『ソフトウェア入門』
故きを温ねて新しきを知る。同書の初版は2004年。AIは無視して、自分の勉強を進める。
本ブログの内容とは、一切関係ないが、昨日、Netflixで映画『BlackBerry』を観賞した。Research In Motion社(BlackBerry製造・販売会社)には2名のCEOがいる。ビジネス部門を担当するジムと技術部門を担当するマイクだ。作中、ジムがマイクへ言った。「Mike, are you familiar with the saying that perfect is the enemy of good」。マイクは答える。「Not good enough is the enemy of humanity」。
両者の言い分はどちらも正しい。Facebook創設者のマーク・ザッカーバーグも「Done is better than perfect」と言っていた。我々は時折、もしくは頻繁に、理想を掲げて何もを事を成さないことがある。物事には全て正解があり、正解以外は全て間違いだという考え方。学生時代、そこそこ成果を上げていた人ほど、この理想を掲げて何もしない、理想を他人に押し付けるタイプが多い。
汝は画れり。
まずやってみる。だが、忘れてはならない。低品質なものは世に出してはいけない。
ハードなソフトウェア
別書『Clean Architecture』に以下のような3つの図が紹介されている。
ソフトウェアは物理的にこの世に存在していない。だからソフトウェアを「柔らかい」と肌で感じることは不可能だ。ソフトウェアの「ソフト」はハードウェアの「ハード」の対義語として採用された訳だが、意味としては「変更しやすい」である。
しかし、上記3つの図はソフトウェアがプログラムとしては変更し易くとも、現実的には如何に変更しづらいものかを物語っている。確かにソフトウェアはプログラムを書き換えるだけなので、作業としてはハードウェアよりも圧倒的に変更しやすい。
まず、ネジ、回路、基盤、チップなど部品を取り寄せる必要がない。取り寄せる際は全ての規格を全て把握して、必要な規格通りに注文しなければならない。注文する部品を間違える。注文した部品とは違った部品が配送されることはよく起きるだろう。
次に、修理をしようとすると、ハードウェア所有者は壊れたそれを修正してくれるところまで届けなくてはならない。それからエンジニアは、中を確認するためにドライバーを工具箱から取り出し、ネジを回してカバーを取り外し、配線を理解して、色々な配線方法を試して、どこに不具合があるかを確認する。不具合箇所があったら、パーツを取り替える。バージョンアップをしようと思ったら、新品を全てゼロから用意しなくてはならない。
ハードウェアの修正・更新は大変だ。
それに比べてソフトウェアの修正・更新はどうだろうか。基本的には全ての作業は、パソコン上で完結できる。不具合が発生したら、どこでそれが発生したかをソフトウェア自身が教えてくれる。更新作業も、少し前までは更新したプログラムをCDに焼いて、パッケージングしてという工程があったが、現在では、更新プログラムを自分のPCからベンダーへアップロードするだけで終わる。
何がソフトウェアをハードにしているのだろうか。
皮肉だが、変更への敷居の低さが頻繁且つ乱雑な変更を招き、ソフトウェアの複雑化・硬直化の原因になっている。
では、ソフトウェアを元から変更しづらくすれば、長期的には比較的変更しやすくなるのではという期待が生まれる。プログラミング言語レベルにおいては、型制御と形で80年代にはこの試みは行われている。多少の生産性向上には寄与しただろうが、エンジニアと一緒に働く非エンジニアの期待に応えるほどの成果には繋がらなかったのが現実だ。
個人的見解だが、ソフトウェアがハードになっている原因がもう1つ存在する。ソフトウェアエンジニアの能力低下である。
おそらく、昔のソフトウェアエンジニアは、今のソフトウェアエンジニアよりも優秀だった。正確に言うと、優秀でなければソフトウェアエンジニアが務まらなかった。ソフトウェアエンジニアリングの面白さの1つはその難しさにある。絶え間ない知的挑戦こそがプログラミングの醍醐味である。
だが、ソフトウェアエンジニアリングもビジネス。難しいことばかりやっていたのでは、消費者ニーズを追えない。生産速度を上げるためにソフトウェアエンジニアが出した答えがライブラリ化である。
ソフトウェア開発をしていると、同じようなプログラムを書くことが常だ。それだけではない。いまも知らないどこかで誰かが同じようなプログラムを書いている。だから、エンジニアはまず、個人レベルないしチームレベルであるプログラムを抽象化・共通化する。次にその出来上がった共通プログラムをオープンソースにして、世界へ無償で配布する。なんとも寛大な行いだ。
結果として、ソフトウェアエンジニアは他人が作ったライブラリを使えば、早く簡単にソフトウェアを作れるようになった。ソフトウェアエンジニアという名のソフトウェアライブラリーユーザーで、何もエンジニアリングしてない職業の誕生である。
もちろん、ライブラリを使うにはリスクがある。まず、自分のソフトウェアなのに、どうやって作られているのか分からない。作られ方が分からないから、問題発生や要求変更で、ソフトウェアを修正しようと思ってもできない。または時間がかかる。
現実問題として、要求には納期があるから、大抵のエンジニアは要求を満たすだけの仕事をする。医療に例えるなら、ソフトウェアに鎮痛剤を飲ませるかバンドエイドを貼るだけで終わらせるのである。バンドエイドを張り続けられた体が健康体な訳がない。最終的にソフトウェアは医者から見放される。
先にソフトウェアを元から変更しづらくすれば、長期的には比較的変更しやすくなるのではという仮説を述べた。これとは別にソフトウェアをソフトに保ち続ける方法があるかもしれない。
変更するのは諦めて、毎回作り直せば良いという発想である。
エンジニアであれば「これ作り直した方が早いな」と思うことは多々ある。早さとは関係なく「作り直したい」と思うこともだろう。理論上、早く作れるのだから、コストも削減でき、品質も向上し、この上なくうまい話しなのだが、現実的にそうならない。
「これ作り直した方が早いな」はあくまで希望的観測だ。「作り直した方が早い」と聞いた依頼主もしくはプロダクトマネージャーがそれを素直に聞き入れてくれることはまずない。新しいものへの不安、という人間的心理も弊害となっている。新しく作り直したものが、今まで通りに動作してくれるか? 今あるものはそのままに、修正箇所だけ直っている方が安全では? 短期的に安全なのは言うまでもなく問題部分だけを修正する方である。だが、上記の図も踏まえて作り直さないことが本当に安全だと言えるだろうか。
伊勢神宮の社殿は20年に1度、造り変えられる。流石にソフトウェアを20年に1度の頻度で作り変えていたのでは、作り直す前に寿命が絶つだろうが、2~4年に1度は作り直すべきではないだろうか。
2~4年に1度ソフトウェアを作り直せば、新規開発メンバーがソフトウェアの全貌を理解する良い機会となる。ジュニアエンジニアはゼロからソフトウェアを作る経験が得られる。作り方がわかっていたほうが、変更もしやすい。何より、普段はマイナーチェンジだったり、半年~1年ぐらいの期間をかけた新機能開発と比べて、圧倒的なコーディング量をこなすことができる。プログラミングはサイエンスではなく、アートだ。上達するには頭より手を動かす方が早い。作り直しはドキュメントよりも技術と知識の継承、人材育成の場となるだろう。
式年遷宮方式。ソフトウェアがソフトであり続ける鍵かもしれない。