学生にプログラミングの課題を出すと、友人が作ったものをコピーしたり本に載っていたコードを引き写したりして提出してきます。 教育者としては、「そんなことじゃいかん。自分の脳みそで考えろ！」と叱るべきかもしれません。そんなことをしてもプログラミングの能力は養われませんから。
でも、ソフトウェア開発の方法論としては、それはそれで一つの立派な問題解決方法です。実際のソフトウェア開発では、要は、実際に動くシステムを作れればいいのです。問題解決にはどんな手もありです。 ひとぎきの悪い言い方ですが、オブジェクト指向開発というのは、いかにして効率よく他人のプログラムを盗んで使えるようにするかという方法論だということもできます。
本格的なソフトウェア開発で、全くの無の状態からプログラミングをはじめるということはほとんど無いといっていいでしょう。できるだけ既存のコードをみつけ、それを問題にあうように改良して開発をするというのが普通だと思います。 実際に、既存のコードの簡単な改造だけでシステムを作れるようにした「ミドルウェア」という手法や、既存のコードだけでなく、将来に作られるであろうコードまで取り込んで利用してしまおうという「フレームワーク」というどん欲な手法まであります。
一般的に言って、創作という活動は無から何かを生み出すことではなく、入力と出力があるものです。 参考文献の無い論文は、よほどの天才のものでもない限りおおかたつまらないものでしょう。 優れた創作物は、沢山の人々の英知とアイデアの集積だと言ってほぼ間違いないでしょう。 ソフトウェアのコードの独占的支配で最も利益をあげているビル・ゲイツでさえ、ソフトウェアに関する特許はこの分野の進歩に有害であると言っています。 コードは盗んでも無くなったり減ったりしません。むしろ遺伝子のように、沢山の複製を生み出すコードはある種の優位な環境をつくることさえあります。 コードは盗むものです。そう。どんどん盗みましょう！
問題解決方法を見つける最良の方法は、人にきくことです。 ペア・プログラミングといってチームを作っても、自分と同じような人とだけしか組めないというのでは、あまり価値はありません。 とっつきにくいけど優秀な人に教えてもらうのは、それはそれでかなり難しい技術を要します。 何でも見境なしに聞くというやりかただと、疎まれてあしらわれるのがおちでしょう。まず自分でよく調べて、聞きたいことをよく整理して質問するのが礼儀です。でも、きちんとした質問の内容であれば、優秀は技術者は教えたがりであることが珍しくありません。丁寧に教えてもらえる可能性は高いと思います。 ソフトウェア開発における問題解決の力のかなり大きな部分が、実はこの人に聞く力つまりコミュニケーション能力だったりします。
要求分析をして、仕様を作成し、その仕様に基づいてコードをつくり、テストを行う。
いまどき、こんな方法でソフト開発をやることはほとんどないでしょう。 こういう方法は、コンピュータのハードで言うなら、自分で回路の設計から全部やるということに近いのではないでしょうか。
いまの現実のソフト開発は、ちょうどパソコンのパーツを買ってきて自分の好みのパソコンを組み立てるような感じで、既存のツールを探して、自分の目的のものを組み立てるという感じが普通だと思います。 いわば、既存のものから「近似解」を求める力こそが、現実的なソフト開発に要求される重要な能力なのです。 そして、その近似解が、正確に必要条件を満たしていることを検証することは、新しい重要なそして面白いテーマとして浮かび上がってきます。そのあたりの話は桧山にまかせることにしますけど。
土地の値段は、駅や道路から近いとか公園や公共施設に近いといったことで変わってきます。 もし前の道路が突然私有地になってしまったら、その土地の価値はひどく落ち込むことになるでしょう。 こんな感じで、私有財と公共財は、互いにうまくバランスすることで価値を高めていくことができます。 ソフトウェアの世界も、これと似た一種の生態系のようなものができようとしています。 言語処理系やミドルウェアやプラットフォームやフレームワークといったものが道路のような公共財にあたるとすると、ソフトウェアの価値は、そういった公共財との関係のもとで測定されることになります。 また、そのようにして開発されたソフトの集合体が都市に似た文化圏や経済圏を作っていきます。
いま、新しくソフトウェアを開発するとき、僕達ソフトウェア技術者は、この都市のような文化圏／経済圏の住民として、礼儀正しくかつクレバーに振舞うことが要求されるのです。