Entries

スポンサーサイト

カテゴリ:スポンサー広告
更新日:--------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ソフトウェア開発はぬるいか?

カテゴリ:システム考
更新日:2015-02-19
昨日のTwitterで、ソフトウェア開発はぬるい云々、というのを見かけた。
ちょっと燃えていたらしいが、元は、想いを140字に収めようとして言葉足らずという印象のツイート。
私もよくやる。だから、それについての言及はしない。
けど、夜中(いや朝方かな)に目が覚めて、ふと思い出してつらつら考えたことを残しておこうと思う。

ソフトウェア開発がぬるいか?といえば、私もぬるいほうだと思ってる。
一番は「バグのないソフトウェアはない」ということが公然と認められていること。

多くの、ソフトウェア以外の産業では、表立って発売(リリース)時に不具合があることを認めたりはしない。
不具合が発見されれば、回収することになったりする。
でも、ソフトウェアの場合は、不具合が出ても、パッチを出すだけだ。

そりゃ、人命に関わるようなものなら、不具合が出ること自体が問題だったりもするけれど、
ほとんどの分野では、そこまで致命的なことはない。
あと、回収騒ぎになった時の担当者や責任者の評価や行く末なんて問題もあるけど、ここでは除外する。

まぁ、パッチを当てるといっても、インストールするソフトウェアの場合、ということになるかな?
ROMやCDのまま実行するゲーム機の場合は、ハードウェア準拠か。

してみると「固定化」というのがキーワードなのかもしれない。

ソフトウェアというのは、その名の通り、柔らかいもの。
柔らかいってのは、修正ができるということ。

これはプログラムに限った話でもない。

例えば、文章。
ワープロで文章を書いていると、いつまでたっても完成しない、という話がある。
印刷しないと、校正がうまくできない、とか。

一部を変更すると、全体に波及したりすることがある。
誤字や、てにをはを直すだけのつもりが、文をいじりたくなり、段落で変えたくなり、文章全体に影響がでてきたりする。
容易に変更できると、それが起こりやすくなるのだろう。

いじれるうちは、いじりたい、というのが人の性なのかもしれない。
印刷をすると、その影響を押さえ込めるのだろう。

一般の開発では、固定化の順番でスケジュールが決まっている。
そうして、固定化して後戻りできなくなる前に、その段階での不具合がないことが確かめられ、次のステップへと移行する。
してみると「ウォーターフォール」というのは、ソフトウェア以外の産業の影響を色濃く受け継いでいる、といことになるのだろう。

固定化の順番でスケジュールが決まる。つまり、マイルストーンがある。そうして、それが締切になる。

「学生症候群」と呼ばれる現象がある。
期限ギリギリにならないとレポートをやらない、という学生の習慣から発見されたということらしいけど、ひどいネーミングだと思っている。
だって、それ。学生だけじゃないじゃん。
ま、それはともかく。

なぜ人は、ギリギリにならないとやらないのか?

おそらく人は、ギリギリまで固定化したくないのだ。
そして、変更できる状態で、長く手元においておくことは、心的負担が大きいのだ。

時間的に余裕があるうちに手を付けないのは、期限までの長期にわたって、それに関わり続けることになるのを避けるためではないのか?
ギリギリになって手を付けて、締切が来たら、えいや!でリリースする。
リリースして、自分の責任から手放してしまえば、もはや変更することはできない。
そうして、不安定な状態に関わる時間を短くしようとしているのではないか?

「ウォーターフォール」が上手くいかない理由も、これでよく分かる。
ソフトウェアの開発は、上から下まで柔らかいままだ。
どの段階においても、固定化されることはない。
そうして、だから、簡単に手戻りし、スケジュールは乱れる。

だけど、ソフトウェア以外の分野では不具合は出ないのだろうか?

なわけないよね。「人はミスを犯す」
「バグのないソフトウェアはない」は、それを言い換えているだけだ。
回収までいかなくても、妥協されている不具合は、たくさんあるはずだ。
ならば、そこには避ける知恵もあるはずだ。

例えば、毎年マイナーチェンジした新機種が出るのは、不具合対策ではないのか?
固定化の後に発見された不具合は、次の機種で修正されるのだろう。
外観は同じで機種名も同じでも、同等品ということで内部が違うということはある。

新しい機種が出るたびに、「何で変えたの?」という疑問を聞くけれど、
こうなれば、理由は明白だ。
人は完全ではないから、ということになる。

ソフトウェア開発でも、アジャイル化が進んでいる理由も同じだろう。

ソフトウェアは、抱えている限り、いつまででも変更できる。
だけどそれは、いつまでも完成しない、ということでもある。
どこかで固定化は必要だ。
だけど、それはどこでやればいいのだろう?

Gitを使ったワークフローに、git-flowとGitHub Flowがある。
端的な違いは、リリースの考え方にあるように思う。

git-flowは、どちらかというと従来型で、リリースの前に正当性を確認しよう、という考え方。
GitHub Flowは、マージするときに正当性が確認して、マージしたならリリースしてしまえばいい、という考え方。

どんどんリリース(固定化)して、不具合があっても、新しいリリースで上書きしていけばいい。
まさに、ソフトウェア的だ。

そうして、これは仕事に対する取り組み方を変える。

マージしてしまえば、仕事は終わりだ。
締切まで待つ必要はない。
ならば、どんどん手を付けて、どんどん終わらせていけばいい。

学生症候群には陥らないだろう。
締切で仕事が終わる、という考え方は古いと言えよう。
締切には仕事は終わっている、のだ。

これはなにもプログラミングに限らないだろう。

ITによって、たいていのものがソフトウェア化している。
文章はワープロで書き、イラストはPCで描く。
配布だって、オンライン配信で、紙やCDに固定化する必要がない。
小説も、音楽も、イラストも。もはやソフトウェアだ。

固定化に則ったスケジュールと仕事のやり方は、ITの影響を受ける部分から変わっていくだろう。
そうして、固定化に対する責任は軽くなる。
それは、いずれソフトウェア以外の分野も、ぬるくなっていく、ということだ。

スポンサーサイト

Appendix

プロフィール

いむら@fintopo いむら@fintopo

ガーデニングが趣味のフリーのシステムエンジニア兼プログラマ(フルスタックエンジニア)です。

仕事募集中です。個人なので、融通がききます。 大規模な開発はできないかもしれませんが、研究や製品開発レベルでの小規模開発、特に相談しながら新しいものを作っていくのが得意です。詳しくはWebサイトをご覧ください。
詳しくは「fintopoとは」をご覧ください。

> fintopoとは

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。