よりよい開発手法ってなあに?
ソフトウェア開発というのは人がおこなうものだから、その本質というのは変らない。ソフトウェア産業は日進月歩の技術によってささえられているので目まぐるしい新しい技術を追う事ばかりに気をとられていると、本質が見えなくなる危険性がある。ところが、カーネルにしろ、RDBMSにしろ、言語処理系にしろ、技術的な本質というのもほとんど変化していないのである。技術の変化はむしろゆっくりと流れている。
未来のいつか/hyoshiokの日記
よしおかひろたか さんのこの記事を読んで「そういえばこの本読んだことないな」と思い、さっそく読んでみました。
(実際に読んだのはオリジナルの古い方)
正直yasuhoにはちょっと難しかったかな。大筋では理解できたと思うのだけど、私の単純な頭ではちょっと理解に苦しむ記述も多かった。いつか読み直してみる必要があるかも。
全般としては、よしおかさんの言われていることに同意です。これが書かれたのは30年以上も前らしいんだけど、開発プロセスなどほとんどが現在でも通用するものばかり。
30年しかたってないわりには、この世界の技術は目まぐるしく変化した。開発手法だって様々な方式が提案されている。デバッグ効率だって何十倍・何百倍も上がったはず。なのに・・・
なんで開発プロセスは変わってないの?
まあプログラムの設計や仕様はしょせん人間どうしのコミュニケーションなわけで、それが大きく変わることはないのかもしれない。それもよしおかさんに同意。
けど、それにしても開発プロセスは変わらない。この30年の間に変化がなかったわけじゃないし、変わっている部分はある。あのくだらないフローチャートは確かに絶滅した。パンチャーという職業はなくなり、実装に費やす時間は確実に減った。開発手法も成功している例がないわけじゃない。
それでもぼくが変わってないと感じるのは先人に学ぼうとしない開発者の姿勢にあるんじゃないかと思うんだ。
根拠のない自信
どこの開発チームにも、そのチーム独自のやり方というのがあるよね。プログラムを設計・コーディング・単体テスト・総合テスト。大筋ではほぼ同じなんだけど、細かい部分はローカルルールがあって、開発に携わる人はそれに従わなくちゃならない。
で、そこには「自分たちのやり方が一番いい」という根拠のない自信が感じられることがよくあるんだな。
もちろんそれらは今まで苦労した経験などから作られているんだと思うよ。いろんな開発手法を研究したのかもしれない。それらをうまく消化して取り込んでいればいいんだろうけど、一人よがり的な手法であることがとても多い。それが一番いいと思っている。あるいはよりよくしようとする気概が感じられないというケースが多い気がするんだよね。
だから未だに開発は火の車になるし、デスマーチも繰り返されている。
じゃあどうすれば?
個人的には様々なやり方があっていいと思う。特にスピードが求められることの多い最近の開発においてはプロセスそのものが変わらざるを得ない。
それでも開発における考え方や姿勢は普遍だと思う。開発手法が変わっても、解決すべき問題は変わっていない。先人が何を苦労してきたかを知り、今のやり方をどんどん変えていくこと。それがよりよい開発手法につながっていくんじゃないかなあ。
この本を読みながら、そんなことを思いました。
ところで、あなたの職場の開発はやりやすいですか?