積読リスト

　4月から購入して読んでいる本たちは下記の3冊。
　システム工学、モデリング、ファシリテーションと様々。興味が発散しているかも。

　システム工学の辞書みたいな本。集中して読まないと難しい。。

　SEに必要なモデリング技術をまとめた本。
　通勤電車で読めるような楽な本だが、内容は濃い。
　問題解決に必要なスキル、考え方について、的確にまとめられている。
　この本に書かれているツールを自分流に解釈すると、PGならデシジョンテーブルやステートチャート図、SEならワークフローと機能モデル(プロセス図に近い)が重要かな。

　プロジェクトマネージャに必要なスキルをまとめた本。
　この本も通勤電車で読める気楽な本だが、色々考えさせられる。
　ファシリテーション、コーチングが最近のIT業界でも流行しているが、コーチングのようにパラダイムシフトが重要なものは、システム思考の発想がすごく重要。
　結局、ファシリテーションやコーチングはリーダーシップを後天的に鍛えるツールだな、と改めて実感する。

　落ち着いたら、もう少し詳しく書いてみたい。

ソフトウェアプロダクトラインとXPは何が違うのか？

細谷さん、トラックバックありがとう。
ソフトウェアプロダクトラインとXPの違いについて考えたことを記述しておく。

【それぞれの定義】
1.ソフトウェアプロダクトライン

2.XP

【1】ソフトウェアプロダクトライン
　品質を保持するには、インフラに近いレイヤーはできるだけ変えず、アプリケーションやUIに近い部分は変更可能とするように設計する。
　これはビジネスの要求に対し、コアとなる部分は再利用可能な資産とし、それぞれの顧客に対してカスタマイズする戦略を取る。
　当然、変化しやすい部分と変化しにくい部分をアーキテクチャだけでなくビジネスドメインの観点からも切り分ける。
　
　対象とするシステムの境界は、ソフトウェアやDBだけでなく、ネットワークインフラやハードウェアまで含む。
　だからこそ、再利用できるものとそうでないもの区別が大切なのだろう。
　
　また、ビジネス関係者だけでなく、ハード開発者、ソフト開発者などと利害関係者が多すぎる。
　ゆえに、意思決定を持つグループと権限はないが影響力を持つ開発グループでワークショップを定期的に開いて意見交換するプロセスも内部に持つ。
　
　この開発スタイルがマッチする例は、組み込み系のように、似たような仕様の製品を少数生産する時だろう。

【2】XP
　過剰な設計、過剰な仕様書、過剰な機能実装は不要だ。再利用することを考えるよりもYANGIを重視する。
　まずはシンプルに作り、早期リリースと頻繁なリリースでシステムを成長させていく。
　リーンソフトウェア開発の1個流しという概念が似ている。
　
　テスト駆動、リファクタリングなどのプログラミング技術で品質をカバーする。プログラマの観点からすると、この技術が面白い。
　だが、プログラミングは重視するが、インフラやハードまで意識していない時が多い。
　
　当然、変化しないものはなく、変化は受け入れるものであり、変化を受け入れる環境や技術を重視する。この観点から、プログラマが働きやすい環境とは何か、という方向に行き、40時間労働とか、最近ならプロジェクトファシリテーションなどのような人間系に向かっているのだろう。
　
　また、オンサイト顧客のように開発チームへ顧客も引きずり込む。
　このやり方だと、顧客は敵というよりも同じチームの仲間という雰囲気になる。利害関係者の数はそれほど多くない。
　
　この開発スタイルがマッチする例は、BlogやSNSのように、永遠にベータバージョンであるようなWebシステム開発が向いているのだろう。

【感想】
　このように、品質を保持するプロセス、操作対象とするシステムの境界が全く異なる。
　それだけでなく、おそらく根本的には、変化に対する態度、再利用性に対する態度が大きく異なるように思う。
　
　ソフトウェアプロダクトラインの考え方は、時間が経つほどシステムは複雑化し、変更に対するコストが大きくなる発想。
　逆に、XPは、うまくコントロールすれば、時間が経っても、変更に対するコストはある上限で落ち着く発想。ウォーターフォールのような計画駆動は、恐竜みたいなものであり、XPを含むアジャイル開発は小さい哺乳類のように素早く変化に対応できるという信念を持っているように見える。

　XPは技術的にも発想も面白いし、人間系も最近はすごく活発だ。
　でも、ソフトウェア工学の昔からの難問であるソフトウェアの再利用性について、確固たる解答を提示していない。
　ソフトウェアプロダクトラインは、少なくとも一つの解答を提示している。

　少なくとも、どちらが絶対的に良いと言うよりも、向いているシステム開発の例が極端なだけかもしれない。

ITの地殻変動はどこで起きているのか？

　Javaエンジニアと開発手法について議論していたら、彼は、お客が求めているのは使いやすいユーザーインターフェイスなんだ、JSFがこれからの主流になる、と言っていた。
　僕は、JSFなんて、ASP.NETのJava版に過ぎないでしょ、と思っている。

　.NETエンジニアと、Javaと.NETの違いについて議論していたら、Javaよりも.NETの方がユーザーインターフェイスを重視したクライアントアプリケーションを作りやすい、と言っていた。
　僕は、Javaに対する.NETの優位性はクライアントアプリ開発だけにあると思っている。

　Javaエンジニアと、RDBとオブジェクト指向の相性の悪さについて議論していたら、JavaならHibernateを使うのが一番の解決策だ、と言っていた。
　僕は、Hibernateは確かに良い技術だが、結局HQLに書く所が納得できていなかった。

　最近、自分の興味がちょっとずつ変わってきた。

　IT技術の地殻変動はどこで起きているのだろうか？

　以前は、「ORマッピング」で事件が起きているように見えていたが、最近はちょっと異なる視点を持っている。
　事件は「プロセス」で起きている。
　キーワードは「ソフトウェアプロダクトライン」だろう。

　ITシステムがこれだけ普及した今、大規模なシステムを最初からスクラッチ開発するプロジェクトはそう多くない。
　既存システムにサブシステムを追加する、あるいは、既存システムをカスタマイズするプロジェクトが多い。
　最初の顧客に売ったシステムをカスタマイズして、別の顧客へ売るビジネスは非常に多い。

　その時に重要な点は、「ソフトウェア部品を再利用したい」こと。
　つまり、古くから続く難問が横たわる。

　その一つの解決手法が「ソフトウェアプロダクトライン」。
　似通った仕様で少数生産するための開発手法。
　コア資産（フレームワーク）とアプリケーションの分離。
　再利用資産の開発（ドメインエンジニアリング）と再利用資産に基づくプロダクトの開発（アプリケーションエンジニアリング）。

　EP法で言えば、プロセス供給レイヤーパターンに相当する。

　でも、コア資産を作ると言う別プロセスが発生するため、普通の開発に比べると、1.5～3倍ものコストがかかると聞く。
　また、コア資産を作っていたのに、時代の変化で使えないものになったというリスクもはらむ。

　事件は技術よりもプロセスに移っている。