重要なのは「分かっている」ということ

もうずいぶん前から、10年近くはなるんじゃないだろうか。いまに至るまでもずうっと考えていて、文章にはしていなかったこと。「関数プログラミング実践入門」という本にそのまま書いてあった。

…ここでの「分かっている」は「言語機能として処理系の基準で判断できる」ということ…

開発プロセスのノウハウや明らかになった理論をソースコードとの関連を持ったまま作業できる環境とすること。これにより次のことを可能にできる。

…プログラマ自身が人間として限界のある記憶力でいつまで覚えているか、また、手を入れる他のプログラマも同様に分かっているか、は一切保証していません。…プログラマが言語の制約を破ることがそもそもできなければ、誰が処理に手を加えても性質は保証されるのです。

事業継続のために情報が落ちずに引き継がれ、品質が確保しながら作業性を向上する。

…多くの場合、プログラムはメンテナンスなりアップデートしてユーザーに提供しなけれなりません。仕様として正しい動作を定め直し、現実的なコストと時間内で、できればプログラマに過度の負担がかからない範囲で、プログラムに手を入れ続ける…

プロダクトを提供し続けながら、実務者の負担を押さえていくことが可能ということだ。

そう、これがずっと欲しいと思っていたことだ。

問題は明瞭で、ソフトウェアのライフサイクルはある技術者が担当する期間よりも遥かに長く、派生するソフトウェアまで含めてしまえば現役期間よりも長くなる場合が想定されるということ。そのため情報の漏れない伝承と教育が必要。この作業は個人には後ろ向きに捉えられやすく、後回しになりやすいということ。結果、ソフトウェアの品質は徐々に下がっていくということ。

課題は単純で、ソフトウェアが満たすべき性質(仕様)をソフトウェアの本体であるソースコードと一体で扱える環境がないこと。仕様の検証やテストが人力であり、振り返り、現状調査、情報の整合確認が必要となり、綿密な作業計画までも必要とされる場合さえあること。

これをいち早く解決できた事業はソフトウェア開発において大きなアドバンテーを得ることができるはずである。しかし、この分野はあまり注目をされない。バラダイムシフト以上のインパクトがあるし、技術者判断で適用困難な状況があるかもしれない。開発プロセスと密接に関連することであり、現状維持に傾きやすいのかもしれない。

この本が述べている関数プログラミングもパラダイムシフトである。現場への負担は小さくない。けれども課題の解消を実現できることを説明している。関数プログラミングを採用できなくても、なにがウィークポイントなのか、どのようにプロダクト開発へ適用できるのかのヒントにもなるだろう。考えるだけの価値は十分あると思う。

参照:

設計するということ

Z3 – guide

興味あってZ3のチュートリアルをやってみた。設計や検証に使えるのかを知りたかったので。

関数の定義や取りうる値の範囲を決めるところなど、なんとなくソフトウェア設計そのものをやっているみたいだ。しかも、設計をしながら検証を同時におこなえる。

設計の検証をいつでもおこなえるというのはとても良いことではないだろうか。

Qt4.5でてた~!

LGPLを選択できるQt, Version4.5がリリースされていた。

4.5より前は商用とするソフトウェアにQtを使用する場合、GPLを選択してソースコードを公開するか、商用ライセンスを選択してライセンス料を支払うかだった。

TorolltechはQt自体から収益を上げていたからこれは仕方が無いことだ。

しかし、Torolltechを買収したNokiaはそれを止めてしまった。Symbianで成功しているNokiaは、同じようにQtを広めることに魅力を感じたのかもしれない。

ともあれ、プロプラエタラリなソフトウェアを開発する企業にとっては朗報だ。高機能なGUIライブラリを高額のライセンス料無しに使うことができるようになる。また、クロスプラットフォームというのはリーン開発の思想に合うし、プラットフォームを数種類使用する企業にも有利だ。

主開発がマンマシンインターフェースであるエンジニアには受難となるかもしれない。プロダクトがQtを採用することになったら、新たなGUIライブラリの学習が必要となる。

既存のGUIライブラリ提供者にとってはどうか?

MFCやVCLはこのまま安泰というわけにはいかないだろう。GUI以外のライブラリで差別化するか、マンマシンインターフェースの開発コストの低減を狙うか、何かしらアクションが必要だと思う。エンジニアが離れてしまってからでは遅い。

テストの改善を言える

テスト仕様ある場合「なぜそれを確認できなかったか?」には明確に回答できる。つまり、テストできなかった理由を言うことができる。そして、それを改善できる。

なぜなら、テスト仕様の作成方法、もしくはテスト仕様のインプット文書に誤りがあるはずだからである。

これがテスト仕様が無い場合にはどうか?闇雲の工程から改善すべき部分を探す…..運良く何が悪のかに気がつく場合もあるかも。大抵はもっともな理由を探す事になるだろう。

テストできている

「テストできている」ということは、そのテスト仕様において正常に動作することが確認できているということである。ということは、「リリース後に発見された不具合」は正常を確認できていないケースということである。

そして「プログラムが正常に動作しないケースがありました。」と言うことになる。すると、なぜそれを確認できなかったのか?という所に辿り着く。

何かあやうきこと

あたらしいことをやってみなと、改良点も見えてきません。それなら、とにかく、やってみなきゃ。一回やってみて、それが失敗でも、いいんです。五回、六回とやって、うまくいけば、モトがとれるんじゃないですか。<斉須政雄さんが『調理場という戦場。』の中で&rt;

[ほぼ日手帳 2008-09-21日より]

そのとおりだと思う。やってみたからこそ見えてくるものがある。見えたからこそ次につながる。だから、意見を出す人を疎んじたりするような雰囲気は、なにかとても危うく思う。

開発プロセスの価値

ソフトウェア開発プロセスの価値はどこにあるのだろうか。

「仕事の進め方」で良いものを生み出す

職人はモノを作り出す過程においてその「やり方」を決めている。品質の良いものをコンスタントに量産しようとするならば研究を重ねて「やり方」を固定するという手法をとるはずだ。そうでなければまぐれで良いものができて世に送り出せたとしても、次が駄目なら続かない。

たとえば旨い料理を作る料理人なら、材料とベースとなる味付けの組み合わせ、煮る、焼く、蒸すなど調理の方法との組み合わせ、おそらくもっとあるだろうが、そのひとつひとつでうまく行く「やり方」を体得ているはずだ。そして、さらに上位で組み合わせて新しい味の料理をつぎつぎと作りだし、結果、多彩なメニューを持つことで良い料理人となることができる。

ソフトウェア開発プロセスでも同じことが言える。ウォータフロー、スパイラル、XP、アジャイルなどいろいろなあるが、良い品質を生む「やり方」として価値がある。

問題解決キッズ

問題解決キッズは、問題解決をわかりやすく説明するサイトだ。先日紹介した「問題解決の授業」を書いた渡辺健介のデルタスタジオのサイトでもある。

問題解決のさわりというか、こういうものだよという説明的な内容ではあるが、ここを見るだけでも問題解決には手法があり、闇雲に扱うものではないことに気がつく。

大事であるのは問題に直面しているは当事者であるので、解決策に納得、理解できていなければならないことだ。

問題解決には手法があり、それが、納得、理解の助けになる事もあるだろう。それゆえにこういったわかりやすいサイトは貴重だと言える。