The T World

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

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

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

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

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

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

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

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

• www.qtsoftware.com
• Nokia releases new Qt developer offerings to increase productivity and performan
• C++アプリケーションフレームワーク「Ｑｔ」の
  LGPL版向けサポートメニューおよびサポートパック「Ｑｔスイート」を発表

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

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

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

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

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

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

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

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

wp-mixipublisherのテスト投稿です。

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

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

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

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

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

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

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

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

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

まだぱらぱらとしか読んでいないけれど基本的な所をわかりやすく書いている。

子育て親向け?かもしれないけれど、意外と仕事の日常でも役に立つかもしれない。基本的ができていないのは応用もできないものだ。

構えず気軽に読めるし、導入にも良いと思う

問題を解決を行う場合に考えること。いろいろあると思うけれど、師匠の図はそのいろいろを網羅する一例だ。

MECEに考えるための11W6H(Ver.2)

押さえておきたい事柄は載っている。また、色によって問題解決の本質に事柄が収束していて使いやすい。

良い図です！

[Joshua Kerievsky - Refactoring to Patterns]

フレームワークが価値あるものとなるための方法だそうだ。実現難しいアイデアだと思う。アプリケーションの規模や種類によってはアプリケーション部分がひとつのチームで構成できない場合があるだろう。そうすると必然的にフレームワークを主体に扱うチームが形成されるだろうから。