TL;DR
プログラミング、ソフトウェアエンジニアリングって本当はとてもとても楽しいです。
……のはずですが、過去、その楽しいはずのこの道を踏み外してしまった、大きな過ちがあったと思っているので、誰かが同じ過ちを繰り返さないためにも、過去に書かれた文献を見て真に受けてしまわないように。
なにが言いたかというと、いまだに一部のソフトウェアエンジニアは黒歴史から抜け出すことが出来ていない気がします。 あと、プログラミング教育とかも、同じ過ちを踏まないか大分気になってます。 ということで、誰かのお役に立てるのであれば、誰か共感してくれる人が一人でもいないか、とまとめてみました。
黒歴史を巻き起こした2大事件
ということでわたしが考えるソフトウェアの黒歴史を迎えることになった「２大事件」です。
1. "コーディング"を"製造"に置き換えてしまった
一般的に、システムでも製品でも建築でもなんであってもモノを作る場合には次のような工程をとります。
- 要件定義（なにを作るかを決める - What）
- 設計（どうやって作るかを決める - How）
- 製造（実際に作る）
ソフトウェアという新たな分野が出てきたときにも、同じように、昔の偉人たちは、次のように考えました。
- 要件定義
- 設計
- 製造 ← コーディング
コーディングの位置がとても重要です。
ひょっとしたら今でもこういう考えを持ってる人がいるかもしれませんが、これは致命的な間違いです。
コーディング以前に、そもそも"製造"とは？
与えらえた設計図や原材料にたいして、ものを作るのが製造。
原材料を加工して製品にすることです。 イメージとしては大量生産の工場ラインです。
誰が作っても同じものができあがるのが製造です。
"プログラミング" は "製造" ではない？
ないです。
まったく違います。
設計工程のインプットを受けて、それを実際にソースコードにするためには、プログラマの様々な独創的なアイディアが入ります。 コーディングは、100人いたら100通りのソースコードが出てくる工程です。
以前に実験で、とても簡単な要件でプログラマ5名くらいに同じコーディングを依頼したことがあります。
結果としては、単純にコード量で比較しても5倍くらいの差はありました。 もちろんロジックも人それぞれ。 つまり、それくらいには独創的な世界です。
では... コーディングって何？ 製造って何？
答えは明快で、"コーディング" は "設計" の一部です。 より厳密で詳細な設計です。 プロダクトの世界で言えば、CADを使った電気回路や金型の設計とかに近いものです。
では、ソフトウェアの世界における "製造" は何かといえば何かというと、例えばコンパイル、例えばリリースパッケージの作成です。これは基本的に誰がやっても同じものできるようになっていてる工程です。
決して、"コーディング" は "製造" ではありません。
なにが黒歴史？
"コーディング" を "製造" としてしまったせいで、"製造" → "誰がやっても一緒" → "人件費が安いところでやった方がいい" という構図ができあがってきたのだと思います。
その結果、ソフトウェアエンジニアは、誰がやっても一緒の結果になる簡単な作業をしているという理解が進み、だから設計をする人より格下、安く買いたたかれたり、そのための子請け孫請けの商売の乱立、という、黒歴史にまっしぐらです。
2. "建築"のメタファーを採用してしまった
これが2つの目の大きな問題です。
ソフトウェアというとても複雑な分野が出てきて、何か歴史上の今までの分野で似ているものを探そう、としました。 その分野のベストプラクティスを流用することでソフトウェアの世界もより良いものにしようという考え方です。
そこで "建築" というメタファーが選ばれました。
建築のメタファー
決して全て悪いとは言いませんし、このメタファー(比喩)のおかげで様々な発展を遂げたのも事実です。
参考までに、建築のメタファーの結果生まれた言葉としては「アーキテクチャー（アーキテクト）」「デザインパターン」等、今のソフトウェア開発を決定づけた単語は建築のメタファーのおかげだと思います。
建築のメタファーの弊害
ただ "建築" という概念に近づきすぎたせいで弊害が出てきます。
開発プロセスが、上流工程 → 下流工程 と別れること。 あわせて組織的な構造も クライアント → SI と流れ、実際の製造作業（建築作業）は下請けへ流すという、上流偏重の構造。 指揮系統もお金も。
建物を作るところまでを一つの仕事として、作った後にはメンテナンス会社への受け渡すという構造。
最初にほぼ完璧な最終形を設計してから、工程にしたがっての計画的に作業していくという工程重視の作業手法。
メタファー（比喩）は、とても優れた思考ツールですが、その反面、大きな欠点があります。
あるメタファーを採用することで気づけなかった色々なことに気づくことが出来ますが、同時に、他の側面が見えづらくなってしまうのです。
「何かを見えるようにすることは、なにかを見えなくしている」ということです。
上にあげたような建築的な手法は、どれも、今のソフトウェア開発では似つかわしくないことです。
上流・下流なんて分ける必要はなく、考えた人がそのままプログラミングした方がよいです。 プログラミングしながら何か気づきを得たらそれを自分自身にFeedbackした方がいい。
ソフトウェアは、建築やハードウェアと違って、作った後もどんどんアップデートが可能なものです。
最初から、最終形なんてわかるわけがないし、そもそも最終形を最初に決める必要がない。建築物みたいに最初に決めておかないと手戻りが大変なものや、大量生産が必要なものであれば、最初に最終形態を作らないといけないですが、ソフトウェアはどんどん形が変わっていいもののはずです。
組み込みソフトとか、パッケージリリースするソフトウェアは、ちょっと話は別です。
それは、ソフトウェアという文脈ではなく「プロダクト」という文脈での制約のためにソフトウェアの利点が使えなくなっている例です。
では、何のメタファーが良かったのか？
結果論ですが、何のメタファーも採用しないのがよかったと思います。 または、もっと早くに建築のメタファーから抜け出せばよかったと思います。
プログラミング、ソフトウェア開発というのは、他の何にも似ていない、特殊な分野だと思います。
さいごに
なにが言いたかったかというと、いまだに一部のソフトウェアエンジニアは黒歴史から抜け出すことが出来ていないです。 あと、プログラミング教育とかも、大分気になってます。 単なる安い労働力として製造工程を担うだけのプログラマが増えてしまったらとても悲しいことです。
せっかく楽しい世界に身を置いているのであれば、楽しくいきましょう。
そのためのきっかけか、誰かを説得するときの何かの材料になればいいかな、くらいの気持ちで書いておきました。
なにかお役に立てたり、１つでも共感できることあったら、いいね でも コメント でも足跡残していってくださいませ m__m