「銀の弾丸などない」を考え
る
2013/09/14 by kitoku_magic
自己紹介
●
IT 業界歴 5 年強のフリーのエンジニア
●
自分では至って普通の人だと思っている
が・・・以下略(苦笑
●
物凄くシンプルなゲームか、物凄く奥が深い
ゲームが好き
●
知人によると、好きな音楽のジャンルが幅広い
らしい
本題
「銀の弾丸などない」
フレデリック・ブルックスが 1986 年 (27 年前 )
に著した論文で、書籍「人月の神話」にも書か
れている内容
しかし、書籍の内容は今となっては古い技術の名
前も多く、現在の状況に合わせて、置き換える
必要があると感じる。
ということで・・・
置き換えてみる
●
発言その1
「技術においても管理手法においても、それだけ
で十年間に生産性や信頼性と容易性での飛躍的
な改善を一つでも約束できるような開発は一つ
としてない」
意訳その1
要は、「ソフトウェア開発に万能薬なんて無い
よ」と。
また、「管理手法」というのは、ガントチャート
辺りのことを言っていると感じた。
一方で・・・
置き換えてみる
●
発言その2
「全てのソフトウェア構築には、本質的作業として抽象的なソフ
トウェア実体を構成する複雑な概念構造体を作り上げること、
および、偶有的作業としてそうした抽象的実在をプログラミン
グ言語で表現し、それを写像することが含まれている。過去の
ソフトウェア生産性における大きな収穫のほとんどは、偶有的
作業をはなはだ困難にする人為的障害を除去することによって
得られた。ソフトウェアエンジニアが現在行なっている作業の
うちどのくらいのものが、依然として本質的ではなく偶有的な
ものに割かれているのだろうか。偶有的なものがあらゆる作業
の十分の九以上でなければ、これにあてる時間をもしゼロにし
ても飛躍的な改善は得られない」
意訳その2
「ソフトウェア開発には本質的作業と偶有的作業
があって、偶有的作業の方は比較的改善しやす
いけど、本質的作業の改善が難しく、それがソ
フトウェア開発を難しくしている」
じゃあ、本質的作業にはどんなものがあって、偶
有的作業にはどんなものがあるのか・・・
作業の分類
●
本質的作業
1.どんなソフトウェアを作りたいのかという要
件の整理(いわゆる仕様)
2.作りたいソフトウェアに合わせた、デザイン
(いわゆる設計)
●
偶有的作業
1.高級言語や FW や TDD などによる、実装や
テスト
2. Cloud 技術による、インフラの構築・・・
etc
現在における偶有的作業
●
偶有的作業を行なうにあたって、使われる技術
オブジェクト指向・デザインパターン・アジャイ
ル・ TDD ・ IDE ・ ioDrive ・ AWS ・
NoSQL ・ FW ・言語・バージョン管理・
Jenkins ・テンプレートエンジン・ UML ・・・
etc
やや余談
どうも、本当は一つだと思うが、話が二つあるん
じゃないか?
一つ目:先程列挙したような技術に対する「取り
扱い方」
二つ目:それらの技術を扱った事による、ソフト
ウェア開発全体に対する影響
ということで・・・
技術の取り扱い方
●
ダメな例
1.その技術の適切な使い方を知らない。論外だ
けど・・・時々見る(苦笑
2.その技術が、どういう背景から出来た技術な
のか知らない
今回は、2番を取り上げる
まず、他の書籍から引用を一つ
「プロになるための Web 技術入門」 ――なぜ、あなたは
Web システムを開発できないのか より
「ポイントを押さえて技術を理解するには、その歴史や背景
を押さえることが効率的なのではないでしょうか。技術は
すべて私たち人間が生み出したものですから、それが必要
になった背景があります。ある背景から問題意識が生ま
れ、それを解決するために新たな技術が生み出される。さ
らにその技術を利用する上で別の問題が生じ、それを解決
するために新たな技術が生まれる・・・その繰り返しの上
に成り立っているのが、いま私たちが利用している技術だ
といえます」
今回のターゲット(やり玉ともい
う)
●
テンプレートエンジン(というか Smarty と
も・・・)
デザイナー「ねぇねぇ、 HTML に for とか if って
書いてあるけど、これ何?意味わかんなーい」
プログラマ「そっか、分かんないよな。よし!
” ”じゃあ、 覚えやすい書式で書ける仕組み を作
るよ!」
→ こんな「背景」から、テンプレートエンジンが
動的な HTML に組み込む機能
1.単一値を表示する
→ 例:名称( id によって変わる)を画面に表示する
2.選択した項目を表示する
→ 例:セレクトボックス・ラジオボタンなど
3.表示したりしなかったりする
→ 例:エラーメッセージを表示したりしなかったり
4.繰り返して表示する
→ 例:表形式で、名称を繰り返して表示する時
→ これ以外は無いと思うのだが・・・
Smarty が提供している機能
URI : http://www.smarty.net/docsv2/ja/
例えば、 {php} は、 PHP のコードを書かない様
にするという理念を考えると、どうか。
また、 {$articleTitle|lower} の「 lower 」の様な修
飾子が行なう処理は、サーバー側で行なってお
けば良いのではないか。
「必要最小限」という考え方
・テンプレートエンジンに限らず、その技術にお
いて必要な機能は何なのか?というのが本質か
と思う。
・本質からずれた機能を用意しても、使用する側
が混乱するだけでは無いだろうか?それなら、
用意しない方が良いと思う。
・また、一応使う側も、さっきの Smarty の様な
例もあるので、上記の点を頭に入れつつ使うの
が大切かと思う。
話を戻します
・じゃあ、以下の様な技術の、生まれた背景と適切な使
い方を知って、上手に扱えたとします。
オブジェクト指向・デザインパターン・アジャイル・
TDD ・ IDE ・ ioDrive ・ AWS ・ NoSQL ・ FW ・言
語・バージョン管理・ Jenkins ・テンプレートエンジ
ン・ UML ・・・ etc
・そして、出来たとして、ソフトウェア開発は上手くい
くのか?
技術で改善出来ること
・オブジェクト指向を用いることで、仕様変更が
発生しても対応しやすいメンテナンス性が高い
ソフトウェアになった。
・ Cloud(AWS や CloudStack) 技術を用いたこと
で、サーバの増減に対応しやすくなった。
改善出来る事があるのは確かだと思うので、今後
も更なる発展を期待したい。でも・・・
ソフトウェア開発の本質
・自動生成ツールだったり入力補完だったりサー
バの増減に対応しやすくしたりと、開発(実
装)を「支援」する手法は数多く存在するが、
「何を作りたいのか」や「どんな動きをしてほ
しいのか」を支援する手法は存在しない。
・ロボットを作って AI 的な事が出来ればとも思
うが、仮に出来たら「人間不要」になる。人間
が自分で自分の首を絞めるのでは。
どうすれば良いのか?
・顧客 ( 技術を知らないビジネスサイドという意
味 ) と継続的に「対話」しなければいけない。
「何を作りたいのか」や「どんな動きをしてほ
しいのか」を知る為に。
・前述の通り、技術による改善には限界があるの
で、実は顧客側にも、「銀の弾丸などない」と
いう認識が必要。
・なので、開発サイドは勿論の事、顧客側にも
「人月の神話」は読んで欲しかったり・・・
最後に
今回の資料は、早い内に SlideShare にアップし
ておきたいと思います。 #phpcon 付き
で、 Twitter で告知すると思います。
SlideShare :
http://www.slideshare.net/kitoku_magic
Twitter :
https://twitter.com/kitoku_magic

銀の弾丸などないを考える