Win-Win 達成の方法論 〜 Value-Based Software Engineering

ではソフトウェア開発において Win-Win を達成するためには，どうしたらいいでしょうか．それを目指しているのが Value-Based Software Engineering (VBSE) です．VBSE の目指す開発は，ソフトウェア開発に関わる利害関係者(stakeholder)全員が Win-Win になるようにすることです．

VBSE の基本理論は4つあります．ちょうどこの4つの理論がそれぞれ理想的に達成されるのであれば，順番に適用すると Win-Win が達成できると主張しています．

1. Dependency Theory: どんな利害関係者がいるのかを特定する
2. Utility Theory: それぞれの利害関係者の価値観を見える化する
3. Decision Theory: 衝突する利害を調整し，方針を決定する
4. Control Theory: 開発が決められた方針を守っているか，監視する

利害を調整しながら行わなければならないソフトウェア開発プロジェクトは，たいてい無意識のうちにこのように行っているのではないでしょうか？

これらの理論は主に経済学を背景にしています．分かりやすいのは Utility Theory です．みなさん「需要供給曲線」を知りませんか？ これは縦軸に商品の価格，横軸に商品の数量をとったグラフで説明されます(下図)．合理的な消費者は，価格が安くなると大量に購入し，価格が高くなると少量しか購入しません(図中の赤実線)．合理的な生産者は，価格が高くなると大量に出荷し，価格が安くなると少量しか出荷しません(図中の緑実線)．最初は価格が高すぎたり安すぎたりします．高すぎる場合は，消費者が少量しか購入しないのに対し，生産者が大量に出荷します．そうすると商品が余るので買い手がつかず，やむを得ず生産者が価格を下げます．安すぎる場合には逆のことが起こり，消費者が価格が高くても買おうとします．これを繰り返すと次第に均衡価格(図中の青破線)で落ち着きます．これは経済学で最初に習うことです．

これは見方を変えると，図中の赤実線は消費者の，緑実線は生産者の，それぞれ商品の価格と数量に対する価値観を表していると考えられます．経済学的な立場では価値観を一種の関数として表すことができると考えられています．複数の利害関係者の価値観をそれぞれ関数として表現できれば，最適な開発方針を選択することは利害関係者の関数からなる方程式の最適解を求めることを意味します．これが VBSE の基本的な考え方になっています．

価値観の関数化などできるのか？という疑問は当然持つでしょう．これはインタビューを通じて行うことがあります．たとえばアイスクリームの価格と数量の需要曲線を求める場合，消費者Aに「アイスクリームの価格が○○円だったとしたら，何個欲しいですか？」というような質問を投げかけます．それを辛抱強く聞き続けるわけです．統計的な方法もあります．価格が変動したときに，どのくらい需要や供給が変化するかを観察する方法です．

ソフトウェア開発においても，何かの懸案事項に対して「こういう条件だったら採用しますか？しませんか？」と利害関係者に聞いて回ることができるでしょう．あるいは会議の場で，ある条件が提示されたときの利害関係者の反応から推察することもできるでしょう．

このように，VBSE によって，すべての利害関係者が Win-Win になるようになるというわけですが，もちろん実際にはそううまくいきません．VBSE の本を読んでも，そんなに理想的にうまくいくとは限らないだろうという指摘をしたくなることが多々あります．現時点ではあくまで理想論だと私は考えます．

しかし，VBSE が提示しているソフトウェア開発のあり方や，それを実現するためのアイデアの数々は，理想的なソフトウェア開発の姿を示唆しているのではないでしょうか．

インサイドアウトと相乗効果，これからの就職活動や市民活動のあり方〜7つの習慣

今回は7つの習慣―成功には原則があった!の重要な考え方の1つである，インサイドアウトについて考えます．

インサイドアウトは「内から外へ」という意味で，自分の内面にあるものに作用して，外へ波及させるという考え方です．

自分のことを棚に上げて，学校が悪い，会社が悪い，社会が悪い，という人がいます．このような人は，自分の抱えている問題は自分の手に及ばないことのせいにしているので，このままでは決して変わらないです．

それに対しインサイドアウトの考え方は，自分が影響を及ぼして変えられる範囲のことに集中します．具体的には，まず自分自身を変えていくことから始めるのです．この考え方が根底にあるので，7つの習慣の順番は，自分の内面を変えることから始まり，徐々に自分の周りの人に作用することへと続くのです．最初は大して世の中を変えることはできないかもしれませんが，だんだん自分の影響範囲が広がっていき，最終的には大きく世の中を変えていく力にしていくのです．

インサイドアウトを，以前紹介した Win-Win の話と合わせて考えてみます．もしインサイドアウトを考慮せずに Win-Win を目指した場合にはどうなるでしょうか．互いに自分よりも他人に変化を要求しあうことにより，多くの場合 Win-Win に到達することは困難でしょう．交渉の末，なんとか Win-Win を達成したとしても妥協のレベルでしか達成し得ないと考えられます．

相乗効果を狙うとしたら，それぞれの立場を超えてお互いを理解し合うことが必要です．それにはインサイドアウトを実践することが近道です．相手を無理矢理変えさせるより先にまず自分を変えること，具体的にどう変えるのかと言えば，自分の要求ばかり口にするのではなく，まず相手の声に耳を傾け，相手の立場を理解することです．お互いの立場を理解しないことには相乗効果など期待できません．

このようなインサイドアウトの考えに疑問を持った人がいるかもしれません．「そうは言っても，真の原因が社会にあることも考えられるではないか」その例として，私は就職活動のことを連想しました．この未曾有の不況下で就職事情は限りなく悪化しています．その根本的な原因の多くは社会の構造的欠陥にあることが多くの人から指摘されています．このような事例においても，インサイドアウトの考えが正しい，つまり社会を批判するのではなく，まず自分を変えるべきでしょうか．インサイドアウトはそういう，ある意味自虐的な考え方なのでしょうか．

私は，そのような解釈はインサイドアウトの本質を理解していないと考えます．インサイドアウトの教えは，自分が影響を及ぼして変えられる範囲のことに集中することです．したがって，狭義の就職活動だけではなく，微力でも社会に影響を及ぼして変えていくことも含めて自ら率先して活動することがインサイドアウトに基づく就職活動だと思います．

断っておきますが，私がここで言う「社会を変える」活動は，必ずしもいわゆるデモ運動に代表されるような旧来の活動のことを意味しません．なぜならば，旧来のデモ活動は単に一方的な要求を叫ぶのみで相手との建設的な対話を含んでいないため，多くの場合 Win-Win は達成できず，頑張ってせいぜい妥協しか達成できないからです．

もし私が就職活動デモを含む市民活動を企画するとしたら，労使など立場の違う人々を交えたワークショップのような建設的な市民活動を考えるでしょう．この方がはるかに相乗効果を達成できる可能性があります．市民活動は時代時代によって最適なアプローチが異なるはずです．現代の日本の事情にあった市民活動のあり方があると，私は思います．

もちろん，学生さんの立場ではこのような企画をすることは難しいかもしれません．でも，学生には学生なりの社会との関わり方，相乗効果を達成する方法があると私は信じています．就職活動で疲弊している学生さんには，ただただつらいかもしれませんが，目の前の就職活動だけではなく，就職に対する考え方をはじめとする自分の人生のあり方とか，社会との関わりとか，そういう「緊急ではないけれど重要なこと(これは第3の習慣の教えです)」に目を向けることも大切ではないかと思います．

2013/1/13 追記:
変えられるのにあえて変えないタイプの人もいます。そういう人には私が何を言っても変えないかもしれませんね。でも私は，私が変えられる範囲の人を私が善いと信じる方向に導く活動をするだけです。

「みんなを Happy! にする」の背景〜7つの習慣

9つの価値の学生からの一番人気は「みんなを Happy! にする」です．
今回は「みんなを Happy! にする」の大元である7つの習慣―成功には原則があった!から背景を説明していきましょう．

7つの習慣は次の通りです．

1. 主体性を発揮する
2. 目的を持つ 
3. 重要事項を優先する 
4. Win-Winを考える
5. 理解してから理解される 
6. 相乗効果を発揮する 
7. 刃を研ぐ 

ここでキーポイントになっているのが，第4の習慣で掲げられている Win-Win の考え方です．「みんなを Happy! にする」ことは，みんなが勝つ(win)ことと同義だと考えています．

7つの習慣では，Win-Win の状態にもレベルがあると言っています．最初のレベルは，いちおう Win-Win ではありながら，みんながそれぞれ「妥協」している状態です．みんなの持つ利害は全ての面において一致するとは限らず，むしろ衝突することがしばしばあります．衝突する利害について，お互いがそれぞれ譲り合って満足することが妥協です．

Win-Win が妥協だと聞いて，ちょっとがっかりした人はいませんか？ 大学時代に私が「議論で対立することはある」「そのときにどうするのか？」という疑問を抱いたのに対して，先輩から「お互いに賛同できるところは賛同し，残りは妥協する」という答えを聞いて，やはり同様にがっかりしたのを覚えています．

今にして思えば，当時の私が期待したのは，ヘーゲルの弁証法(Wikipedia)にあたる考え方だったのだと思います．つまり，ある命題Aと，Aに対立する命題Bがあったときに，A,B を統合した命題Cを創造するという考えです．Win-Win はこのような考え方を目指すべきではないか？と思っていたわけです．

実際，7つの習慣では，このようなWin-Winの形を示しています．それが第6の習慣に掲げられている「相乗効果(シナジー: synergy)」です．つまり，それぞれの立場を超えてお互いを理解し合う(第5の習慣に相当)ことで，それまで考えつかなかった，みんなにとって真に Happy! な全体最適解を創造するというレベルです．

「みんなを Happy! にする」という価値では，この2つのレベル(妥協と相乗効果)の違いを念頭に置く必要があります．

この価値を大切に思う人は，ぜひ7つの習慣を手に取って読んでみてください．また近々，この話の続きを書きたいと思います．

Software Testing ManiaX vol.4

話題のソフトウェアテストの同人誌 Software Testing ManiaX vol.4 に記事を書きました．

ManiaX の想定読者は品質保証のスペシャリストなので，普通に品質保証技術そのもので記事を書いても私の技術レベルでは太刀打ちできないだろうと考え，変化球として経営学の観点から品質保証の価値を考察しました．

品質保証技術そのものにしか関心のない人にとっては「耳の痛い」「聞きたくない」「聞いたら後悔する」話かもしれないので，タイトルを「世界一受けたくなかった授業」としました．

大晦日のコミケで頒布します．お問い合わせは Twitter: @ikedon さんまで．

OOP演習の成果を熊本で発表します！

12月6日(月)に熊本大学で開かれる組込みシステム研究会で，当ブログでも連載しているOOP演習の成果を発表します．

http://www.ipsj.or.jp/09sig/kaikoku/2010/EMB19.html

意外かもしれませんが，今回が私にとって組込みシステム研究会初の発表です．しかもなぜか教育という，研究会の本流から外れたテーマです．
そういうわけで，事前に教育に関心が高い人を集めないと議論が盛り上がらない恐れがあります．それではせっかく発表してもつまらないので，ソフトウェア工学教育に関心のある多くの人に来て頂けたら幸いです．

Apple 戦略論 Part 2

最近私が気づいた「これって Apple の常套手段じゃね？」という戦略の話をします．

その戦略は次のような流れです．

1. 第1世代の製品では，わざとツボを外したしょぼい「こんなの誰が買うんだ」的な製品を販売する．
2. その実製品で市場動向や技術的課題をリサーチする．
3. 第2世代以降で満を持して本気の製品をリリースして，世間をアッといわせて市場を総取りする．

この実例はとても多いです．最近では Apple TV がこのパターンに該当すると考えています．iPod も2001年に第1世代が登場した当初は散々な評価でした．

変形パターンの戦略は次の通りです．

1. 隠し機能を仕込んで販売する．
2. その実製品で市場動向や技術的課題をリサーチする．
3. 隠し機能を別製品に本格展開する．

この実例としては加速度センサーが挙げられます．iPhone で大々的に取り上げられた加速度センサーは，最近知られたことですが，実はそれ以前に MacBook に隠し機能として搭載されていました．MacBook が落下したときにハードディスクのヘッドを待避するために装備されたのです．当時，既に加速度センサーつきのハードディスクは実用化されていましたが，高級品でした．加速度センサーが装備されていない安価なハードディスクを利用できるようにと，MacBook 本体側に装備したのです．

この戦略パターンで解決する問題は次のようなことです．

• 前例のない新製品を，いきなり大々的に市場に投入するのは，マーケティング面でも実現技術面にも生産面でもリスクが高い．
• 一方で，新製品の真の課題を明らかにするには，βテストで得られる情報だけでは足りない可能性がある．

Apple が目を付けたのはキャズムによる時間差です．Apple には固定客として新し物好きの人たちがついています．世間でどんなに酷評されていても新製品に飛びつく熱心なファンがいます．このような人たちが喜んで求めて，かつマジョリティである一般消費者が手を出さないようなスペックの製品を最初に出すのです．そうすることで意図的に市場を狭く設定します．

市場を狭く設定する理由は，大量生産によるリスクを回避するためです．もし最初から大量生産していると，クレームがつくような事態になったときに，サポートはパンクします．設備投資面でも大きなリスクを抱えるでしょう．何より，マーケティング的に手探り状態で市場に大量投入すると，大量の在庫を抱える事態になります．

新し物好きの人たちはブログや雑誌等に使用感や直面した問題を詳細に記述した記事を書くことがしばしばあります．そういうことを生き甲斐や商売にしている人たちが多いのです．そのような詳細なレポートは，マーケティング面でも技術面でも有益な情報源となります．

そういう「失敗してもいい」試行期間を設定することが大きな意義になります．Apple が次々と打ち出す大胆な戦略は，こういった市場を巻き込んだ意図的な試行錯誤の過程を経て完成度を高めているのではないか？というのが私の仮説です．

この戦略は，Apple ほどのブランドを持っているからこそできる戦略です．普通のメーカーがこの戦略をとったならば，総スカンを食らって市場から退場せざるを得ないでしょう．どんな製品を出しても買ってくれる固定客がいるからこそ，その人たちを人柱にする戦略が成り立つのです．

Apple 戦略論

Jobs 率いる Apple の経営戦略が優れていることは多くの方が認めるところです．一方で Apple に比べると日本メーカー各社はうまくいっていないように見えます．このことから， Jobs の経営戦略，とくに Apple を追い出され NeXT を設立してからの戦略の本質が何なのか？について私は多大な関心を寄せています．


私が考える Apple の経営戦略の本質は「何がコア資産か」についての長期ロードマップを考案し，それを徹底して実践したことだと思います．プロダクトラインにおいてコア資産は，ムーアの言うキャズム(early adopter に売れてから early majority にも受け入れられるまでに存在する大きな「溝」)を超える橋頭堡としての役割も担うと私は考えます．私の仮説は，Jobs は最初に手を付けるべきコア資産(橋頭堡)として OS を選択したのではないか？ということです．

まず1985年の NeXT 設立時に Jobs はニッチ市場として高等教育向けハイエンドワークステーションを選びます．おそらく当時は競合も少なく，ニッチとしてもある程度の魅力があったのでしょう．

1985年前後は PC 向けに MS-DOS が主流の時代でした．日本で組込みシステム用の OS として現在も普及している ITRON の最初のバージョン ITRON1 の仕様策定開始が1984年のことです．またゲーム機の状況はファミリーコンピューターの発売が1983年です．

当時の状況では，計算機資源的に NeXT が狙うハイエンドワークステーションと組込み OS が同じアーキテクチャであることはあり得ません．しかし，ムーアの法則が提唱されたのは 1965 年のことなので，思考実験としてはハイエンドワークステーションのスペックが，いずれは家電にも導入される時代が来ることが机上では予見可能です．実際，プレイステーションの発売が1994年のことで，スペック的には NeXT と同等(あるいはそれ以上)と考えられるので，だいたい10年くらいで NeXT が家電化する時代がやってきたことになります．

この時点で Jobs がどこまで長期ロードマップを考えていたのかは明らかではありませんが，既に Jobs の想像力が家電まで及んでいた可能性はあります．世間に広まっている伝説では，少なくとも Apple に復帰して NeXT を買収する1996年頃までには，iPod に代表されるデジタル家電への進出を視野に入れていたと言われます．さらには NeXT STEP を Mac OS X として取り込む際に，将来 Mac OS X を Mac だけではなく家電の OS として使うことも想定していたとも言われています．これらについては真実を検証することはまず不可能です．しかし，もし今，自分たちのポジションで Jobs のように先を予見するとしたら，何をコア資産とするか？を考察する上で参考になるかもしれません．

このように Jobs は OS を橋頭堡として選んだのですが，Jobs の先見性はむしろ OS の上に載せるアプリケーションやサービスのレイヤーにあります．Jobs のデジタル家電構想により，未来を先取りした生活の中に息づくマルチメディア家電が iPod を皮切りに次々と創造されていきます．これらは OS のレイヤーだけを見ているのでは，けっして生み出せないしろものです．OS のあるべき姿を，OS 以外のレイヤーの将来像を考察することにより創造したのです．

もし日本メーカーの中で Apple に対抗するとしたら，よく名前が挙がるのは Sony でしょう．Sony には Jobs 率いる Apple を封じ込める可能性はなかったのでしょうか？

私はあり得たと考えます．鍵となるのはプレイステーションです．

プレイステーションの登場は1994年のことでした．私は当時の興奮を今でも覚えています．ちょっと前のスーパーコンピューターと同じスペックが，ゲーム機に惜しみなく投入されているのですから．プレイステーションが繰り出す映像や音響は，それまでのスーパーファミコンとは別次元のものでした．これは革命的といって過言ではありません．

しかしその後プレイステーションが進化するにつれて，初期の衝撃はどんどん薄れていくように感じられました．私が感じたのは，プレイステーションシリーズがもたらす新しいゲーム，新しい生活が，それほど革命的なものではない，今までの延長線上にすぎない，想像が容易につくものだということです．

今にして思えば，プレイステーション3で打ち出した Cell を中心とする情報家電への展開の構想は，もっと前にプレイステーション2の時代に行うか，あるいはプレイステーションポータブルを中心に据えるべきでした．そして Cell プロセッサそのものへの投資よりは，ソフトウェアとくに OS や基本アプリケーションへの投資を中心にするべきでした．おそらくプレイステーションでの成功体験が強すぎて，それまでの延長線上でしか思考していなかったのでしょう．だから，プレイステーション3がもたらした新しい生活は，革命的でない，今までの延長線上のものだったのです．

Cell に関して言えば，ゲーム機からの要求・制約と，家電からの要求・制約の両方を満たそうとするあまり，どちらにも中途半端なものになったのではないでしょうか．そのため，ゲーム機は任天堂の Wii にかなわず，家電は Apple にかなわずという結果でした．

任天堂も Apple も共通項として，ハードウェアスペックでは勝負せず，それぞれのサービスがどうあるべきか？を真剣に追求して勝利をつかんだのは，私にとって大変興味深いことです．少なくとも今の時代は，サービスとか価値とかを真正面から捉えないと勝利はおぼつかないのかもしれません．

参考文献: スティーブ・ジョブズの流儀，キャズム

(社)トロン協会 ITRON専門委員会, Introduction to the ITRON Project － Open Real-Time Operating System Standards for Embedded Systems －. http://www.ertl.jp/ITRON/panph98/panph98-j.html#SEC4

9つの価値

現在，卒業研究のテーマを議論しながら決めているところです．その議論の過程で，私はとても重要なことに気づかされました．

それは，私にとって研究テーマは，私の理想とする価値に向かっていさえすれば，どんなテーマでもかまわないということです．だから，研究室のドメインを決めるとしたら，テーマによってではなく，価値によって決めるべきなのです．

そこで，今まで行った研究テーマ，これから取り組みたい研究テーマを思い浮かべながら，私にとって重要な価値とはどのようなものなのかを考察しました．それが次の9つの価値です．

• 革新的なものやサービスを創る
• みんなを Happy ! にする
• エンドユーザーが何を欲しがっているかくみとる
• 既成の枠(文理・産学・分野)を超える
• 少人数の組織で大規模なものを開発する
• 様々な観点を統合し価値の高いものやサービスをつくる
• 個性に合わせた長所を伸ばす教育をする
• 上流から下流まで一貫する
• 誰にとっても使いやすく理解しやすいモデルをつくる

これら9つの価値のうち，1つ以上の価値を目指していれば，テーマは何でもいいのではないかと今のところ思っています．もっと他にも大事な価値はあるかもしれませんが，数的にも9つくらいまでが順当だろうと思います．

今回の記事では，あえてこれら9つの価値について詳しく説明するような野暮なことはしません．また，それぞれの価値を支える基礎理論についてもいろいろ蓄積していますが，それについてはおいおい取り上げていくかもしれません．

最後に，もしこれらの9つの価値のうちのいくつかに賛同する方，ぜひ一緒に研究をしませんか？ 9つの価値にも取り上げているとおり，研究室，分野，産学，文系・理系など，既成の枠を超えて取り組みたいと思います．

これからの思考の教科書 ~論理、直感、統合ー現場に必要な３つの考え方~

ついに，求めていた本が見つかりました．

これからの思考の教科書　~論理、直感、統合ー現場に必要な３つの考え方~

この本の主張は，縦の思考(ロジカルシンキング: logical thinking)だけでなく，横の思考(ラテラルシンキング: lateral thinking)も必要だということ，最終的には統合思考(インテグレーティブシンキング: integrative thinking)を目指す必要がある，ということです．縦の思考と横の思考の関係は，ちょうど縦の思考がツッコミで，横の思考がボケに相当します．

今は誰もがロジカルシンキングを重要だとしていますが，現代のようなインターネット社会／グローバル社会で情報が均質化していく状況では，ロジカルシンキングだけでは誰がやっても同じ解しか得られません．

その限界を超えるために必要なのがラテラルシンキングです．創造的な仕事はあまり定石がないと思われがちですが，実は世の中に発想法の類いは何百種類とあるそうです．そういうツールを生かしつつ，たとえば今まで誰もが試さなかった組合わせを試すというようなことで，ロジカルシンキングの限界を超えるわけです．

この本に難点をつけるなら，具体的な手法が数種類しかあげられておらず，しかも基本的な使い方に終始していて，深く突っ込んだ活用方法があまり見られなかった点です．(早とちりでした．たしかにラテラルシンキングやインテグレーティブシンキングについては数種類しか紹介されていませんが，ロジカルシンキングについてはたくさん，しかもきちんと整理されて紹介されています．)　しかし，パズルのピースを探していた私にとっては，先に紹介したフレームワークだけでも十分価値があります．

----

最近，私の強みをずっと考えていたのですが，分野と分野をまたぐ，文系と理系の枠を越える，産業界と学術界をつなぐ，そういったところに強みがあるように思います．仮にそうだとすると，これからすべきことの1つはラテラルシンキングのツールを収集し，得失を分析して，活用方法を編み出し，さまざまな局面で実践することだと思います．

そういった明確な方向性を与えてくれたという意味で，私にとって大きな価値のある本でした．



Twitter での感想

ロジカル・プレゼンテーション 〜 自分の考えを効果的に伝える戦略コンサルタントの「提案の技術」

今回紹介する本は，ロジカル・プレゼンテーションです．

プレゼンテーションと言っても，PowerPoint の作り方といった内容ではありません．「提案」そのものを，論理思考力，仮説検証力，会議設計力，資料作成力の4つの観点から，どのように緻密に構成していくかという話です．

論理思考力とは，A ならば B であるという論理があったときに，その論理を相手に心から納得させるための技術です．たとえば，論理に抜け落ちている観点や飛躍があったりすると相手は納得できません．この本では，縦と横の論理という整理法で論理を形成する技術を紹介しています．

仮説検証力とは，まず相手の疑問を知り，次にその疑問に対して答えるための技術です．この本では，この一見当たり前に見えることが，実際にはいかにできていないかを指摘しています．それを目的，論点，仮説，検証，示唆の5段階で進めることだ大事だと力説しています．

会議設計力とは，退屈になりがちな会議を，本当に実りある時間に変えるための技術です．この本では，会議しているという認識，会議の論点，提案全体の中での今回の提案の位置づけ，相手に合わせた論理という4つの観点から，会議の「着地点」と「着地スタイル」の設計をする方法を示しています．

資料作成力とは，提案内容を示す資料を効果的に作成するための技術です．メッセージ，チャート，スライド，パッケージ，マテリアルの5つにモジュール化された資料を作るべきだと述べています．

この本自体が上記の4つの観点で整理されたプレゼンテーションの模範例としてよくできています．企業向けのプレゼンテーションをする人全員が読むべき本だと思います．一方，はじめてプレゼンテーションを作る学生には抽象的で高度すぎる内容かもしれません．PowerPoint  をどう使ってどういう資料を作ってという本の方が有益でしょう．むしろ学生のプレゼンテーションをレビューする立場の教員の方が有用かもしれません．

OOP演習の進捗 (2)

授業が始まって3週目が終わりました．
今週はスケジュール的に厳しく，連載作家のように「落ちる！落ちる！」という恐怖に駆られていました．でも，たぶん来週は少しはプレッシャーが弱まると思います．

UML モデリングおすすめ書籍

UML モデリングの本で，かなりおすすめの書籍を2冊紹介します．


UMLによるオブジェクト指向モデリングセルフレビューノート

UML の主要な図について，レビューするときに見るべきポイントを丁寧に解説しています．復刊しないかなぁ．

思考系UMLモデリング即効エクササイズ―モデ力を鍛える13の自主トレメニュー

「モデリング能力にはトレーニングが必要だ」との持論に基づいて，「アイスクリームをモデリングせよ」というような，頭が柔らかくないとできないようなお題が多数掲載されています．もちろん丁寧な解説付きです．

ペルソナ関連

奇しくも研究室の中と外でほぼ同時にペルソナ法が話題になったので，ブログに書こうと思い立ちました．

ペルソナ関連の基本文献を紹介します．

元祖 Alan Cooper の本

本の半ばくらいまでは，既存のコンピューターに対する愚痴です．それはそれで興味深い洞察で面白いのですが，手っ取り早く読みたい人は1,２章愚痴につきあったら，ペルソナ法の紹介の章へ飛んでも十分読めると思います．

The Persona Lifecycle

ペルソナ法の詳細を知りたいならこの本です．洋書は必ず買うべきです．というのは，和書は方法の紹介だけしか載っておらず，カラフルな写真やイラストを多用した事例紹介や，実際にすすめる上での重要なヒントなど，肝心な情報は洋書にしか載っていないからです．

はじめてのファシリテーション

ファシリテーション(facilitation)は，元々の意味は促進するという意味です．

新たな発想を生み出す源になる，議論を活性化するための技術として注目を集めています．

いくつかの本を読んだので，その中からおすすめの本を紹介したいと思います．

ザ・ファシリテーター

小説仕立ての本です．ファシリテーションがどのようなものかよく知らない人が，ファシリテーションがどのような感じで行われるのかの雰囲気をつかむのに最適です．そして，他の書籍を一通り読んだ後，もう一度この本を読むと，ケーススタディとして分析することができます．続編もあります．

ファシリテーション・グラフィック

ホワイトボードに絵を書きながら議論を見える化するのは，ファシリテーションの1つの大きな技術領域です．この本は，議論を「絵」の形でまとめる方法を，たくさんの事例とともに紹介しています．

問題解決ファシリテーター

一方，この本は議論で登場した「概念」を整理する技術領域がまとめられています．タイトルの通り，話題の「問題解決力」にも効く本です．

以上，これら3冊を読めば，後は実地で試しつつ，課題を認識して新たな本を読み，また実地で試して，というサイクルができると思います．

普段の業務の「システム」を考えよう 〜 はじめの一歩を踏み出そう

今日紹介する本は「はじめの一歩を踏み出そう〜成功する人たちの起業術」です．

起業しようという人がたいてい陥る(そして僕も見事に引っかかった)典型的な罠をはじめに紹介し，企業目標・事業目標を立てて，それを実現する「システム」を構築せよ，というのがこの本の教えです．

システムの中には，マニュアルとか，(本の中ではそう書いてはいませんが)標準プロセスとかが含まれています．マニュアルとか標準プロセスというと，画一的で人間らしさを否定するようなものとして受け止められることが多いのですが，あるホテルの例を引き合いに出し，人間らしさを実現するマニュアルや標準プロセスがあり得ると述べています．

目標を考えること，システムを考えることは，起業する前から練ることができます．たとえば普段やっている業務の目標・目的を考えたり，マニュアルやプロセスを書いてみればいいのです．それができないと，起業しても成長できないとこの本は説きます．

僕も既に研究室の運営を行っています．この本のような視点から研究室の「システム」を構築していこうと思います．

学生さんも，起業は自分に縁のない遠い話だとは思わずに，この本を読んでみてください．将来，改善活動に携わることになったときには，この本の知識が役に立つはずです．そこまで先の未来でなくても，自分が取り組んでいる身近なことについて目標やシステムを考察すると，「できる人」に一歩近づくことでしょう．

OOP演習の進捗(1)

ついにαテスト開始．まだまだ序の口．
あっという間に追いつかれたらどうしよう．
でも，どんなに自転車操業が苦しくても，品質を妥協するのはやめよう．

「自分にとっての資産とは何か」を考えよう 〜 金持ち父さん貧乏父さん

ずいぶん久しぶりになってしまいました．

復帰第1弾は，今さらですがベストセラーの「金持ち父さん貧乏父さん」です．



この本，Amazon のレビューでは賛否両論ですね．
否定的な意見になる気持ちも理解はできますが，僕はこの本の真髄を理解していないゆえに湧き出た疑念なのだと考えます．

金持ち父さん(そして著者)の主張は「資産をふやせ」に尽きると思います．資産の定義は，金持ち父さん流では「収入を生むもの」すべてです．
そして，どんな職業の人にとっても普遍的な資産は，不労所得，つまり株や不動産などなので，金持ち父さんはその運用の基礎を教えます．しかし，僕は，不労所得は資産の一部にすぎないと考えます．

僕にとっての最大の資産は何でしょうか．もちろん，株や不動産も資産ですが，僕はこれらの知識やリテラシーに乏しいので，収入を生むようになるためにはかなりの金銭の投資だけではなく，関連書籍やセミナーなどの，情報を得るための投資が必要でしょう．

金持ち父さんは教えます．「自分の頭を使って稼げ」と．つまり，今まで持っている知識も活用方法によっては資産になりうるというのです．だから僕にとっての最大の資産は，ソフトウェア工学と周辺に関する，小学校高学年以来の20年以上の知識と経験なのです．あとは，お金を生むための効果的・効率的な運用(あるいはシステム)を考えればいいのです．


僕が，忙しいけど頑張ってブログを再開しようと思ったきっかけは，金持ち父さん貧乏父さんです．なぜならば，このブログも僕にとっての資産だからです．Twitter も資産ですが，流動資産(フロー)の要素が強いのですよね．ブログは固定資産(ストック)になり得ます．だから，どんなにつらくても資産としてのブログを書きためようと思ったのです．

決意表明をかねて，ブログ再開の最初の記事としたいと思います．

ドラッカー「プロフェッショナルの条件」を読んで

後でちゃんとまとめます．ひとまず，Togetter を貼り付ける．

ADDIE モデル

教育の世界では，ADDIE モデルというのがあります．どんなものかを紹介します．

1. 分析(Analysis)
   
   
   
   1. インストラクションが解決策となるようなニーズを決定する．
   2. コースが対象とする認知的，情意的，運動技能的なゴールを決定する教授分析を実施する．
   3. 学習者の前提スキルと，そのいずれがコースでの学習に影響を与えるかを決定する．
   4. 利用可能な時間や，その時間にどの程度を達成できるかを分析する．
2. 設計(Design)
   
   
   1. コースの目標を行動目標や主要なコース目標(単元目標)に変換する．
   2. 取り上げるトピックと単元と，それぞれにどれだけの時間をかけるかを決定する．
   3. コース目標を考慮して単元を系列化する．
   4. 単元を具体化し，それぞれの単元において達成すべき主要な目標を特定する．
   5. それぞれの単元に対するレッスンと学習活動を定義する．
   6. 学習者が何を学んだかを評価するための指標を開発する．
3. 開発(Development)
   
   
   1. 学習活動と教材の種類について意思決定する．
   2. 教材や活動の草案を準備する．
   3. 対象とする学習者に教材や活動の試用を依頼する．
   4. 教材と活動を改善，精緻化，あるいは作成する．
   5. 教師の研修を実施し，付属教材を開発する．
4. 実施(Implementation)
   
   
   1. 教師や学習者に教材を採用してもらうために市場に出す．
   2. 必要に応じて支援を提供する．
5. 評価(Evaluation)
   
   
   1. 学習者評価の計画を実施する．
   2. プログラム評価の計画を実施する．
   3. コースの保守や改訂の計画を実施する．

なんか，ソフトウェア開発ライフサイクルみたいですね．

ADDIE では，特に分析のところで，教材開発者が答えるべき問いがいくつか設定されており，それらに答えることで分析を進めていきます．

次回から OOP 演習に関して ADDIE にしたがって整理して進めていこうと思います．

日本の進む道(Twitter での議論)

「下士官が優秀なのに将官がそうでもない日本の現状」の話から，「高等教育のあり方」さらには「研究の進め方」に発展．

抽象化とは何か？

SWEBOK 2004 に挙がっている Software Design Enabling Techniques の1つ，Abstraction (抽象化) について考察してみました．

僕が考えた抽象化の定義は次の通りです．

抽象化は，(1)複数の具体的な概念や現象の共通性を見いだして，(2)不要な枝葉の情報をそぎ落として一般化し，(3)それに適切な名前をつける行為である．

これら3つの要素が備わらないと抽象化とは呼ばないような気がしました．まず第1に，抽象化の対象は複数あること．もし対象が1つしかなかったら，抽象化する必要はなく，具体的なまま扱えばよろしい．なおかつそれらを共通化して扱いたいという動機がある．第2に，複雑なまま扱うのではなく，ある観点にしたがって不要な情報をそぎ落とすプロセス(捨象)が大事です．そして第3に，あとで再利用できるように適切な名前をつけることが重要です．

そう思って SWEBOK 2004 を読むと， Liskov と Guttag の書籍[Lis01]を引用して次のように書かれています．

Abstraction is "the process of forgetting information so that things that are different can be treated as if they were the same." [Lis01]

僕の訳文は次の通り． 

抽象化とは，複数の異なるものを，あたかも同じものであるかのように扱うために，捨象するプロセスである．

やはり抽象化の対象は複数あり，それらを共通化して扱いたい動機があります．forgetting information を捨象すると訳しましたが，不要な情報をそぎ落とすことですね．ただし，名前をつけることは含まれていないようです．

SWEBOK 2004 によると，抽象化の道具立ては下記の通りです．

In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction, and control (iteration) abstraction. [Bas98:c6; Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1]

 箇条書きで書くと次のように整理できます．

• 抽象化(abstraction)
• パラメーター化(parameterization)
• 仕様化(specification)
• 手続き抽象(procedural abstraction)
• データ抽象(data abstraction)
• 制御(繰り返し)抽象(control (iteration) abstraction)

これらをそれぞれ教材化すればいいわけですね．さっそく参考書籍をそろえましょう！

SWEBOK 2004

Chapter 3 Section 1.4.1 Abstraction

http://www.computer.org/portal/web/swebok/html/ch3#Ref11

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.

[Bas98] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.

[Jal97] P. Jalote, An Integrated Approach to Software Engineering, second ed., Springer-Verlag, 1997.

[Pre04] R.S. Pressman, Software Engineering: A Practitioner's Approach, sixth ed., McGraw-Hill, 2004.

Twitter のコメント

教材アーキテクチャ: 原理原則・ケーススタディ レイヤーモデル

ブログは久しぶりですね．第1学期の授業もついに始まってしまいました．でも今日は時間が取れたので，OOP演習の教材開発を再開したいと思います．

以前，OOP演習にスパイラルカリキュラムを適用することを提案しましたが，1つ問題があります．1枚岩で作ってしまうと，用いるケーススタディを変更したときに教材全体を開発し直す必要があるからです．毎年毎年同じケーススタディを行うのは飽きてしまうし，時代や学生さんの関心にケーススタディを合わせる必要があると考えられます．

そこでソフトウェアアーキテクチャの1つであるレイヤーアーキテクチャを適用することを考えました．

レイヤーアーキテクチャ(layered architecture)とは階層アーキテクチャともいい，全体を階層構造にすることで変化に対応させるときの変更箇所を最小限にしようという考え方です．レイヤーアーキテクチャでは，各層のインターフェースをきちんと定義し，下の層を基礎として利用することで，上の層の機能やサービスを実現します．そうすると，インターフェースを守っている限り，1つ1つの階層を入れ替えることが可能になります．

OOP演習では次のような階層構造を考えました．

原理原則層は，教授項目をそれぞれ独立に教材として提供します．たとえば抽象化を学習する教材を，簡単な例題を用いながら説明します．

一方，ケーススタディ層は，大きめの例題を開発し，原理原則層で提供される教材を使いながら，スパイラルカリキュラムを実現します．ケーススタディを入れ替えたとしても，原理原則層は再利用できるというわけです．

十分性，完全性，プリミティブ性

SWEBOK 2004 の設計の章で次の基本原理が挙がっていました．

• 抽象化(Abstraction)
• 相互結合と凝集強度(Coupling and cohesion)
• 分割とモジュール化(Decomposition and modularization)
• カプセル化・情報隠蔽(Encapsulation/information hiding)
• インタフェースと実現の分離(Separation of interface and implementation)
• 十分性，完全性，および基本性(Sufficiency, completeness and primitiveness) 

このうち，最後の十分性，完全性，基本性(プリミティブ性)について原典をあたってみました．SWEBOK 2004 によると [Bus96] 第6章と [Lis01] 第5章でした．このうち [Bus96]は既に持っていたので参照しましたが，[Booch90] を引用していました．


[Booch90] には十分性，完全性，プリミティブ性について下記のように書いていました(改段落は僕が入れました)．

By sufficient, we mean that the class or module captures enough characteristics of the abstraction to permit meaningful and efficient interaction. To do otherwise renders the component useless. For example, if we are designing the class Set, it is wise to include an operation that removes an item from the set, but our wisdom is futile if we neglect an operation that adds an item. In practice, violations of this characteristic are detected very early; such shortcomings rise up almost every time we build a client that must use this abstraction.

By complete, we mean that the interface of the class or module captures all of the meaningful characteristics of the abstraction. Whereas sufficiency implies a minimal interface, a complete interface is one that covers all aspects of the abstraction. A complete class or module is thus one whose interface is general enough to be commonly usable to any client. Completeness is a subjective matter, and it can be overdone.

Providing all meaningful operations for a particular abstraction overwhelms the user and is generally unnecessary, since many high-level operations can be composed from low-level ones. For this reason, we also suggest that classes and modules be primitive. Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction. Thus, adding an item to a set is primitive, because to implement this operation Add, the underlying representation must be visible. On the other hand, an operation adding four items to a set is not primitive, since this operation can be implemented just as efficiently upon the more primitive Add operation, without having access to the underlying representation. Of course, efficiency is also a subjective measure. An operation is indisputably primitive if we can implement it only through access to the underlying representation. An operation that could be implemented on top of existing primitive operations, but at the cost of significantly more computational resources, is also a candidate for inclusion as a primitive operation.

--- Grady Booch: Object Oriented Design with Application

僕が訳してみました．突っ込み歓迎．

十分であるとは，そのクラスやモジュールが意味のある効率的な相互作用をするのに十分な抽象化の特性を捉えていることを意味する．十分でなければ部品が役に立たなくなる．たとえばもし Set (集合)クラスを設計しているときに，集合から要素を削除する操作を加えることは賢明であるが，もし要素を追加する操作を無視してしまうと役に立たなくなる．実際には十分性に反することは早期に検出できる．そのような欠点はたいていこの抽象化を使う顧客から指摘される．

完全であるとは，そのクラスやモジュールのインタフェースがその抽象化の全ての意味のある特性を捉えていることを意味する．十分性が最小のインタフェースを意味するのに対し，完全なインタフェースはその抽象化の全ての観点をカバーする．その結果，完全なクラスやモジュールのインタフェースはあらゆる顧客が共通的に利用できるくらい十分一般的である．完全性は主観的な事柄であり，やりすぎになることもある．

多くのハイレベルな操作はローレベルな操作から構成することができるので， ある特定の抽象化に対して全ての意味のある操作を提供することは，ユーザーを困惑させ，一般には不必要である．この理由からクラスやモジュールがプリミティブであるということが導かれる．プリミティブな操作とは，その抽象化の基礎となる表現形式へのアクセスが与えられたときのみに，その操作が効率的に実装できることを意味する．その結果，集合に要素を加えることはプリミティブである．なぜならば，この操作 Add (追加)を実装することにより，その基礎となる操作は明らかになるからである．一方，集合に4つの要素を加える操作はプリミティブではない．なぜならば，この操作はよりプリミティブな操作 Add によって，基礎となる表現形式に対するアクセスをすることなく，効率的に実装できるからである．もちろん，効率性も主観的な尺度である．ある操作を基礎となる表現形式へのアクセスを通してのみ実装できるとき，その操作は議論の余地なくプリミティブである．あらゆる操作は，既存の最上位のプリミティブな操作で実装できるが，より多くの計算資源を犠牲にしてプリミティブな操作として包含する候補にもなる．

[Booch90] Grady Booch. Object Oriented Analysis and Design with Applications. Benjamin-Cummings Publishing Company, Subs of Addison Wesley Longman, Inc.
  

[SWEBOK2004]  英語版 

[Bus96] F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996. 

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.

スパイラルカリキュラム: 鈴木先生との議論

教材設計マニュアルの鈴木先生にOOP演習を見てもらいました．議論は多岐に渡り，たくさんのアドバイスとヒントをいただきました．改めて感謝します．

今回の記事では，鈴木先生からいただいた，OOP演習の核となるアイデアを紹介します．それが，スパイラルカリキュラムという考え方です．

話の発端は，以前「OOP演習で学ばせたいこと(2)」で紹介した学習目標(上図)を見せて，僕が「でもこの学習目標は，そのまま順番通りに教えるのではなく，例題を演習していくうちに，順番が前後しながら重要な学習目標が繰り返し登場して『ほらね，この原則は重要でしょ？』と定着を図りながらすすめていきたい」と言ったことから始まります．すると鈴木先生は「それは良い．それをやるならスパイラルカリキュラムだ！」とおっしゃいました．

僕の理解では，スパイラルカリキュラムは文字通り，まず基礎的な学習目標を一通り習得させ，その後らせん状に発展的な学習目標を習得していくモデルです(上図)．ポイントは1回目の学習では基礎的な学習目標やシチュエーションを厳選し，かつ例題の中でそれらの基礎的な学習目標で完結するように構成することです．2回目以降は，それに発展的な学習目標や例外的なシチュエーションなどを追加してレベルアップしていき，だんだん大きな例題に取り組めるようにしていきます．

例題の設定のしかたはさまざまです．

1. 例題そのものが1つのテーマに沿っていて，最初の例題を部品の一部として発展的な学習を進める方法．学習効率はいいのですが，一貫した適切な例題を考えるのが難しいです．
2. レベルアップするごとに，より複雑な例題に取り組む方法．学習目標に合わせて適切な例題を設定することができますが，例題そのものを理解する時間がかかり効率が悪くなります．
3. 上記の折衷案もあり得ます．たとえば5段のレベルを設ける場合，2,3個の例題を用意して，複数のレベルで例題を共有するなど．

具体的な例として，GDM (Graded Direct Method) による語学の学習を挙げていました．例えば英語だったら，学習中に日本語を含むその他の言語を一切使いません．そして毎回の授業で習う英語とジェスチャーで全ての会話が完結するように構成します．なんでも最初は You と I から始めるそうです．そして第3者が登場して he や she を学ぶ，という具合に発展していきます．面白いのが一般的に中学英語で割と最初に学ぶ "This is a pen." よりも先に "This is my pen." を学習するんだそうです．「これは僕のペンだ」「あれは君のペンだ」と会話をして，そこへひょっこり新たなペンを登場させます．「これは君のペンか？」「いいや」「これは僕のペンではない」ときて，そこで "This is a pen." と来るわけです．こうすると，不定冠詞 a の意味が自然と体感できます．

もう1つのしかけとして鈴木先生が提案したのが，ソフトウェア工学の原理・原則のありがたみを体感させるような構成にしたらどうだ，ということでした．先ほどの GDM の例でも不定冠詞がなぜ必要かを体感する例題になっていましたが，同様のことをOOP演習でもやるべきだというのです．具体的には最初のレベルでは，とにかくグチャグチャで構造化されていないコードでも，とにかく気合いでできてしまうような形にします．そして高度なレベルの例題にトライさせて，何か手立てを打たないとやってられないという気分にさせておいて，構造化を教えるわけです．

この話を受けて1つ思いついたのが，派生開発をやらせるとありがたみを実感できるだろうというアイデアです．似たような製品を開発させてみて「なんか似たようなコードが複数現れるよね，これを何とかまとめたい」と思わせるわけです．

そういう教材設計をするにはどうしたらいいかというと，次の点がポイントです．

1. 教えるべきそれぞれの学習項目に対してどういうシチュエーションでありがたみがあるかを具体的に考える．
2. 学習項目にレベル付けをしてグルーピングする．
3. 上記を考慮して具体例を順番に並べて教材化する．

これらのアイデアがもし実現できたら，それはかなり面白い教材になるでしょう．そう思うとワクワクしてきました！ 問題は，うまくフィットする題材を思いつくかですが，案ずるよりも産む方がやさしいかもしれません．まずはいろいろ手を動かして考えてみたいと思います．

追記: Twitter 上の反応はこちらです．

ソフトウェア工学教育ワークショップ --- 求める人材像(技術スキル)

2010年2月27日(土)〜2月28日(日)に北九州にて，本学の「ソフトウェア工学概論」の授業で特別講師をお願いしている企業の方々をお招きして，ソフトウェア工学教育に関するプライベートワークショップを開催しました．

せっかく貴重な時間を割いていただいて合宿をするので，大上段に構え，大学におけるソフトウェア工学教育はどうあるべきか？という問題について議論を深めようと考えました．もっとも，そういうことは本来なら「ソフトウェア工学概論」の授業を始める前に議論すべきだったのかもしれません．しかし，前向きに解釈すれば，一通り講義がそろった段階で改めて振り返ってみることで，より深い議論になったと考えることもできます．

2日間の議論の成果として，企業が求める人材像，つまり大学でソフトウェア工学を学ぶ新卒学生に対して，企業が求めるスキルとは何かをまとめました．これをたたき台に，より深い議論ができたらいいなと思っています．

前提として，ワークショップ参加者が主に組込みソフトウェアに携わる技術者だったので，ここでいう企業とは組込みシステム開発を主たる業務としている企業だとしています．もしかすると業務系だと事情が異なるかもしれません．

また既に世にあるITSSやETSSなどのスキル標準を多少参考にしましたが，打ち出している方向性はだいぶ違います．

この内容は，学生さんが学習計画を立てる上でも参考になるでしょう．企業の方たちは，ソフトウェア技術者を目指す新卒学生に対して，こういうことを求めているのです．

スキル体系

大別して技術スキルと社会スキル，ヒューマンスキルの3種類があると考えました．ただし，これらは完全に独立しているわけではなく，互いに関連しあっています．今後，このあたりの関連についても考察していく必要があります．今回はこのうち技術スキルについて書きました．

技術スキル

実はワークショップで「ソフトウェア工学で大学が教えるべき技術スキルはない」とおっしゃった方がいました．ソフトウェア工学で話題になる技術は，陳腐化が速く，氷山の一角に過ぎないので，むしろ大学では流行にとらわれず，基礎となる数学や論理的思考，あるいは技術を獲得するためのスキルなどに注力すべきであるという主張でした．

それにたいし，現在どのような技術があって，それらはどういう問題意識で生み出されてきたのかという「土地勘」を身につけることは重要だという議論も出ました．土地勘を身につけるには，具体的な技術の事例を多く知っている必要があるわけです．

そういう議論を踏まえ，現在，企業で問題になっている事柄を意識しながら，基礎として身につけてほしい知識は何かを私たちは考えました．暫定的な結果として，モデリング，標準化，ソフトウェア開発技術，ドキュメンテーション，リーディング，位置づけの把握といった項目を挙げました．

モデリング能力

私たちは，モデリング能力が技術スキルの中で最も重要だと結論づけました．

ここでいうモデリング能力は，たとえば UML の読み方・書き方を知っているという狭い意味だけではありません．モデリング能力は，たとえば高校の物理でも扱われます．物理の授業では，文章題を読んで，図を書き，ニュートン方程式などの数式を立てて解を導くことをします．この行為は，実世界で起こる現象を抽象化し，モデルとしての図や数式を記述して問題を解決するという広い意味で，モデリングの一種だと考えます．今，このような広い意味でのモデリング能力が求められていると私たちは考えました．

モデリング能力につながる基礎的ドメインモデル


モデリング能力を養う観点，組込みシステム開発で必要なドメイン知識を理解する観点から考慮して，次のような基礎的なドメインモデルを知っておくと役に立つという議論になりました．

• 数学
• 物理
• 制御

それぞれについて簡単にまとめます．

• 数学

組込みシステム開発では，離散系(コンピューターの中の世界)と連続系(物理世界)を両方扱うので，どちらにも通じていると応用がききます．また，抽象化のセンスは，数学によって養われると考えられます．

• 物理

組込みシステムではセンサーやアクチュエーターで物理世界を扱うので，基本的な物理の法則や概念を知っておくことは必要です．次の制御理論を勉強するにも，物理を勉強することが重要です．

余談ですが，私は物理実験も担当しています．どうせ物理実験をやるならば，組込みシステムに関連した形で教えられたらと思っています．が，全学横断の科目であり，教材等を新規開発するコストもかかるので，改善をずっと見送っているところです．

• 制御

基本的なフィードバックなどの制御について知っておくと，主にアクチュエーターの制御をどうすればいいかが理解できます．

モデリング能力を鍛えるには何が必要か


モデリング能力を鍛えるには何が必要かという議論で，抽象・捨象，観点といった概念を教えることが必要だと私たちは結論づけました(それで全てだというわけではないです．他にも必要かもしれません)．

抽象・捨象の概念は，前述したような数学や物理の文章題によって鍛えられると考えられます．またモデリングには「ある観点に沿って思い切って捨象する勇気」が必要です．こういったことをモデリング教育で伝えるのが重要だと私たちは考えました．

機能・構造・振る舞いの3面モデリング

観点に関連して，UML で一般的な機能・構造・振る舞いの3面からモデリングをする考え方を身につけさせたいという意見がありました．特に，これらの間の因果関係を事例に結びついた形で身についていると，複数の観点を考慮した「いいモデリング」をしやすいです．

モデリングの教え方

大きくわけて，抽象論から入って具体論に入る教え方と，具体論から入って抽象論に入る教え方があります．大多数の学生さんにとっては後者の方が理解しやすいだろうという意見でした．


標準化

この議論が始まって一番最初に挙がったキーワードが，実は標準化でした．例えば頂上人材としてCIO(Chief Information Officer) やアーキテクトが足りないことを考えると，プロセスやプラットフォームなどの標準化を推進できる人材を育成する必要があります．


ただ標準化を推進する立場の人は少数精鋭でいいかもしれないので，大学生や大学院生の教育を念頭に置いたときには，まずは「標準化についていける人」を育成すべしと結論づけました．その流れで，PSP (Personal Software Process)の話や，AUTOSAR (AUTomotive Open System ARchitecture)などの話，はたまた標準化戦略の話まで発展しました．


今後は，標準化に必要な知識が何かという議論が必要ですね(作る方もついていく方も)．


ソフトウェア開発技術


発端は「いろいろ技術スキルについて議論したけど，今時の新卒にプログラミング能力はどの程度要るの？」という話からでした．さまざまな話が出ましたが，ソフトウェア工学のありがたみが実感できる程度にはプログラミングをしててほしいね，という結論でした．規模としては1000行程度，できれば複数の人間で開発している経験があるのが望ましいでしょう．そこから派生して，せっかく複数の学生さんが同じ場に集まっているので，チームで働く能力を開拓するといいという話になりました(パーソナルスキルに続く)．

他には，基本的な設計手法，UML をつかった開発プロセスについて経験があると望ましいという意見がありました．


ドキュメンテーション


理系文章の基本的な作文能力は，社会で強く求められているにも関わらず，日本の教育では軽視されがちなスキルの1つです．日本における高校以前の作文教育は，感想文などの情緒的な文章ばかりで，いわゆるテクニカルライティングはほとんど教えていないのが現状です．

理系の大学ではまだマシな方で，レポートや卒業論文の作成を通してOJT的に指導をしていますが，指導が行き届いているかというとまだまだです．大学によっては卒業論文で初めて指導を受けたという学生も多く，しかもOJT的なので体系的な教育ではありません．

北九州市立大学では1年次必修科目の物理実験で工夫をしています．3週がセットになっていて，第1週で実験をしたあとレポートを作成し，第2週で教員のもとに来て査読を受けます．そこでいろいろ指導を受けて第3週に提出，という流れです．

私たちは，ソフトウェア工学におけるドキュメンテーションの重要性を考えると，もっとドキュメンテーション能力の開発に注力するべきだという結論を出しました．

リーディング


人が書いたコードやモデル，ドキュメントを読む能力を身につけた方がいいと私たちは結論づけました．まずどういうコード(モデル，ドキュメント)が良く，どういうのが悪いのか，実感できることが重要です．また知識習得の一手段として活用できるでしょう．品質モデルの理解にもなります．


コードリーディングを参考に教材を作るとよさそうです．



位置づけの把握


ここからは純粋な技術というよりはMOT(技術経営)的な話になります．CIOをイメージすると，技術動向の「勘」つまり自社・他社の SWOT 分析や技術ロードマップが書けるのは必須だねという話をしていました．そこで，新卒の時点では，自分や自分が研究した技術の強みや弱みといった位置づけを把握していることが重要だと私たちは結論づけました．


つづく

追記: この記事に対する Twitter 上での反応をまとめてみました．このリンクをクリック！

追記: Satohru さんが記事を書いてくださいました．このリンクをクリック！

OOP演習(2)教材企画書

• 教材設計マニュアル資料2「教材企画書の書き方」(p.164-165)を見ながら，学習目標「構造化できる」の教材企画書を書いてみました(学習目標の全体像はこちら)が，途中で詰まってしまいました．
• 行き詰まった原因は，教材のイメージがまだアイデアレベルで具体的ではないからです．具体的なイメージを思い描けない根源的な理由は，教材の4条件の1つ「自分がよく知っている内容／よくできることか？」を完全には満たしていないからだと分析しました．その結果，学習目標やテストの具体的なイメージが思い描けないのです．
• この教材は根幹的で重要な位置づけなのに対し，上記のように開発のリスクが高いので，早めに対策を練る必要があります．

OOP演習(2)


教材のタイトルと内容
ソフトウェア設計の原理・原則を理解しよう！
ソフトウェア設計で普遍的に用いられる6つの原理・原則(SWEBOK 2004)を UML のイメージとして理解する．

• 抽象化(Abstraction)
• 相互結合と凝集強度(Coupling and cohesion)
• 分割とモジュール化(Decomposition and modularization)
• カプセル化・情報隠蔽(Encapsulation/information hiding)
• インタフェースと実現の分離(Separation of interface and implementation)
• 十分性，完全性，および基本性(Sufficiency, completeness and primitiveness) 

対象者集団
次のことを学習済みの大学生・大学院生もしくは社会人

1. UML の基本的な図(ユースケース図，クラス図，状態機械図，シーケンス図，アクティビティ図)の文法を理解している．
2. 簡単な UML の図(同上)を書ける．

内容選択の理由

1. 自分がよく知っている内容／よくできることか？
• 次の問題がある．
• おおむね理解しているが， 細かいところで再確認したい点がある．SWEBOK 2004 に挙がっている文献を調べ，場合によっては内容について技術者と議論する必要がある．
• 原理・原則を体現する UML 図を考案する必要がある．
2. 教材作りの協力者が得られるか？
• 新たに研究室に配属された新4年生5名に協力してもらう．
• 事前テストの結果次第では新M1の4名にも協力してもらえる可能性がある．
• 場合によっては学生モニターを公募することも可能だろう． 
3. 短時間で学習できるか？
• 何をもって理解したとするかによる．言葉を覚えるだけならば短時間で学習できる．適切な UML 図を提供すれば直観的に意味を理解することもできるかもしれない．しかし，実際に知識を適用してモデリングに応用することまで求めるのは一朝一夕にはできないと思われる．このテーマは実に奥が深いので，開発現場の技術者でも徹底的に追求するのは難しい現状があるからである．
• 上記の理由から，学習目標をよく検討して細分化する必要がある．
4. 個別学習教材で，教材が「独り立ち」できるか？
• 原理・原則をいかにブレークダウンして体系化するか，どのようにテストを自己採点できるようにするかが鍵である．たとえば原理・原則がチェックリストのような形で提供でき，その基準にしたがってテストを自己採点できるならば，教材が独り立ちできる．

学習目標と目標の性質

事前事後テスト

教材利用者の前提条件とそのチェック方法

1. クラス図，状態機械図，シーケンス図，アクティビティ図の図形要素の名称を知っている必要がある．これらの図形要素に提示し，その名称を選択肢から選ばせる．全問正解すること．この前提テストは，OOP演習(1)の前提テスト1と同一である．
2. クラス図，状態機械図，シーケンス図，アクティビティ図の書き方を知っている必要がある．簡単な例題を与えて，これらの図を書かせる．それらしい図が書けていればよい(基準を明確にする必要がある)．

報告書作成者名と点検者名

• 作成者: 山崎 進
• 点検者: 未定

OOP演習(1)教材企画書

• 教材設計マニュアル資料2「教材企画書の書き方」(p.164-165)を見ながら，学習目標「UMLをもとにプログラムが書ける」の教材企画書を書いてみました(学習目標の全体像はこちら)．
• 計算機演習IIとソフトウェア設計論(科目関連図はこちら)をしっかり理解していれば，この教材からスタートできるので，教材の通し番号を1としました．
• 前提テストの結果，理解不足だった場合には，あとで作る補習用の教材を学習することになります．
• まだ具体的なテスト問題はできていないので，あとで作成します．
• 自分で見返してみると，1時間程度の1つの教材で完結させるには学習項目がちょっと多いかなと思います．あとで学習目標ごとに分割するかもしれません．

OOP演習(1)

教材のタイトルと内容
モデル駆動プログラミング: UML をもとにプログラムを書こう！
与えられたUMLの図からオブジェクト指向プログラミング言語でプログラムを書く

対象者集団
次のことを学習済みの大学生・大学院生もしくは社会人

1. UML の基本的な図の文法を理解している
2. C言語の基本的な文法を理解している

内容選択の理由

1. 自分がよく知っている内容／よくできることか？
• UML 2.0 から JDK 1.4 頃までの Java 言語へ変換する方法はよく知っている．
• 最近の Java 言語や，他のプログラミング言語，ライブラリの活用方法については事前に調査が必要である．ただし，これらにあまり依存せずに教材を構成できる．
2. 教材作りの協力者が得られるか？
• 新たに研究室に配属された新4年生5名に協力してもらう．
• 事前テストの結果次第では新M1の4名にも協力してもらえる可能性がある．
• 場合によっては学生モニターを公募することも可能だろう． 
3. 短時間で学習できるか？
• 1時間程度で個別の変換方法を全て暗記するのは難しい．
• 小規模なモデルを個別の変換方法を見ながらプログラミングするならば可能である．
4. 個別学習教材で，教材が「独り立ち」できるか？
• 下記が満たされれば，用意したモデルを元に作成したプログラムを実行して動作を確かめることで，理解しているか確認できる
• 変換方法のアルゴリズムを理解しやすい形で明確に定義する．
• あらかじめ動作確認のためのテストコードを用意しておく．

学習目標と目標の性質

1. クラス図をもとにクラス定義のひな型を作成できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
2. 状態機械図をもとにクラスの状態を記述できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
3. シーケンス図を見ながらメソッドの概要を記述できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
4. アクティビティ図をもとにメソッドの中の処理を記述できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
5. 上記の図を組み合わせた UML モデルをもとにプログラムを完成させられる．上記を応用しながらモデルをプログラムに変換するので，＜知的技能＞の目標である．
6. (副次的な目標) コード実装の視点で UML で書かれた設計図のレビューができる．チェックリストを適用しながらモデルの問題点を指摘するので，＜知的技能＞の目標である．

事前事後テスト

1. 事前テストは，クラス図，状態機械図，シーケンス図，アクティビティ図からなる簡単な UML モデルを与えて Java 言語のプログラムに変換させる．これは学習目標5の事後テストと同じ問題である．うまく変換できなかった人を対象とする．
2. 事後テストは5題(副次的な目標を含めれば6題)からなる．
1. 関連を含む簡単なクラス図をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標1に対応する．
2. 信号機の状態機械図と各色の処理を記述したプログラム断片をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標2に対応する．
3. 簡単なシーケンス図をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標3に対応する．
4. 簡単なアクティビティ図をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標4に対応する．
5. クラス図，状態機械図，シーケンス図，アクティビティ図で構成される簡単な UML モデルをもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標5に対応する．
6. チェックリストを見ながら，誤りを含んだクラス図の問題点を指摘させる．これは学習目標6に対応する．

教材利用者の前提条件とそのチェック方法

1. クラス図，状態機械図，シーケンス図，アクティビティ図の図形要素の名称を知っている必要がある．これらの図形要素に提示し，その名称を選択肢から選ばせる．全問正解すること．
2. C言語の変数型，制御構造，関数について理解している必要がある．これらを使った簡単なC言語のプログラムを提示し，与えられた入力に対しどのような出力をするかを答えさせる．

報告書作成者名と点検者名

• 作成者: 山崎 進
• 点検者: 未定

ソフトウェア工学教育の問題点(2)

ここ最近，複数の方とソフトウェア工学の教育について議論する機会がありました．

前回指摘した問題点で示唆されるのが，大学で行われているソフトウェア工学の教育は企業で求められる水準を満たしていないという点です．では大学で教えるべきソフトウェア工学の教育とはどのようなものでしょうか？

大学も産業界も納得しそうな落としどころとしては大学はすぐに陳腐化しない普遍的な基礎について教えるべきであるという考え方です．実際，他の工学分野ではそのような教育方針がとられており，うまく機能していると考えられます．

しかしソフトウェア工学の場合には，ここに本質的な問題点があると僕は考えます．情報とりわけソフトウェアの分野ではそもそも「陳腐化しない普遍的な基礎」と，それを教育する方法が確立されていないのではないかということです．

たとえば，他の工学から推論すると，古典的な構造化設計で重要視される原理・原則と，(ちょっと古いですが)オブジェクト指向設計で重要視される原理・原則は，何かしらの一貫性をもって説明できると考えられます．もし，それらに一貫して存在する原理・原則があれば，それは陳腐化しない普遍的な基礎である可能性が高いと思います．

しかし古典的な理論と最新の理論をそのように関連づけて一貫性をもって論じている大学がどれほど存在するのでしょうか．コンピューター関連分野の技術進歩は日進月歩なので，古典的な理論との一貫性を考慮している暇がないのでしょう．

それでもソフトウェア工学を自らの議論ですすめている欧米ならば，最新理論も古典的な理論での議論を背景に積み上げているので，彼らの世界の中では一貫性を保っているのでしょう．しかし，それをキャッチアップする立場である日本ではついていくのが精一杯で，キチンと考察するのをサボってきたのだと思います．

産学連携がうまくいかなかったことも大きな要因だと思います．もし産と学が日常的に議論していれば，最新技術と既存技術の整合性についても議論されただろうと思います．その結果，理論・教育と実践に大きなギャップがあります．

とても遠い道のりですが，SWEBOK などを参考に，ソフトウェア工学理論の再解釈をしていく必要があるのでは，と思っています．それを踏まえた上で，最適な教育方法を議論していくのが本筋だと思います．

とはいうものの，今年OOP演習の教材を作らなければならない身としては，そんな悠長なことは言っていられないのも事実です．うまく落としどころを見つけて，ベストではないにしてもベターな教材を開発するしかないと思っています．この大きな問題を認識はしますが，完全な解決を性急に求めないようにしようと思います．

つづく

ソフトウェア工学教育の問題点(1)

前回の記事に対して，酒井さんより Twitter でコメントがありました．

これを教えられる先生は日本では何人ぐらいいると思いますか？ 10人、100人、1000人のうちだいたいどれ？

僕は数字に弱いので，正確な数字はもちろん知らないのですが，思うところあって次のように答えました．

何をもって教えたかというレベルによると思います．教科書に書いてあることを一通り教えるくらいならば，もしかすると100人以上いるかもしれないです．でも，産業界で求められている高いレベルまで教えるとなると，もしかすると日本の大学にはいないかもしれません．

実は僕は酒井さんの質問を額面通りには受け取りませんでした．つまり，現在大学で行われているソフトウェア工学教育には重大な欠陥があることを示唆していると受け止めたのです．もちろん酒井さんの真意がそうだったのかはわかりませんが，酒井さんの質問から連想してしまったのです．

どういう欠陥かを説明します．

前回の科目間の関連図ならびに教授項目は，理論面と実践面の一通りのことを教えているので，当初の計画通りに学生さんたちに教えることができれば，とても素晴らしい教育になり得ます．おそらく他大学でも同様のカリキュラムは持っていて，理想通りに教育できればソフトウェア工学の基礎をきっちり身につけた学生さんがたくさん巣立っていくことでしょう．

しかし，あくまで「理想通り」教えることができれば，という暗黙の前提があります．現実にはそうではないということが，この教育カリキュラムの欠陥なのです．

たとえば現行の C 言語プログラミング教育では，基本的な文法や，アルゴリズムとデータ構造の実装のしかたを一通り教えます．しかし，たとえば関数名・変数名やコメントをどう書くとよいかということは教えていません．学生さんたちは何の疑問も持たずに，次のようなコメントを書きます．

a = 0;  /* 変数 a に 0 を代入する */

もちろん，こんなコメントはナンセンスです．プログラムに書かれていることと全く同じ意味の内容を繰り返してコメントとして書いているだけで，冗長です．

冗長だとムダだというだけでなく，有害ですらあります．実際のソフトウェア開発でよく起こるのが，プログラムは変更したけれど，対応するコメントは変更し忘れることです．その結果，次のような混乱の原因になります．

a = 1;  /* 変数 a に 0 を代入する */

 こういう大事だが細かいことは，大学ではあまり教えていません．つまり，カリキュラムとしては一通り教えているのだけれど，それぞれの教授項目に抜け漏れが多く，企業で要求されるレベルに到達していない，ということになります．

原因としては，大学の先生は実開発の経験がない，もしくはその先生の専門がソフトウェアではないことが多く，そもそもそういう問題があることを知らない場合もあるでしょう．教授項目が多すぎて，細かいところまで行き届かないという問題もあるでしょう．あるいは研究で行っている最先端の技術に比べ，こういった教育内容は古いとされているので，探求するモチベーションがわかないのかもしれません．そもそもソフトウェア工学が未成熟で体系化されておらず，どんどん最新技術が投入されるので追いつくだけでも大変なので，何を教えるべきで何は教えなくてもいいのかの判断基準が不明確だという面もあるでしょう．

その結果，大学で習ったはずのことを企業で再教育する必要があり，大学でのソフトウェア教育は，何の役にも立たない，むしろ先入観を持つ分，有害ですらあるという話になります．

つづく

ソフトウェア工学関連科目の関連図

本学のソフトウェア工学関連科目の関連を下図で示します．

太字は僕が直接関わっている科目です．各科目は次のような内容です．

• 計算機演習I: UNIX, シェルプログラミング，sed/awk, LaTeX, C言語プログラミング(データ型，制御構造)
• アルゴリズムとデータ構造: 配列，リスト，スタック，キュー，木，再帰呼び出し，アルゴリズムの解析，ソート
• 計算機演習II: C言語プログラミング(配列，構造体，関数，ポインタ，ファイル入力，データ処理，リンクリスト，スタック，キュー，木構造)
• 形式言語とオートマトン: 帰納的表現，形式言語，正規表現，有限オートマトン，非決定性有限オートマトン，文脈自由文法，プッシュダウンオートマトン，チューリング機械
• 数理論理学: 命題論理，述語論理
• プログラミング言語処理系: コンパイラの構成と原理を，講義・演習両面で学習する．「メタ」の概念がOOP演習につながっていないこともない．
• ソフトウェア設計論: UML の基本的な図の読み書き
• コンピュータアーキテクチャ: パターソン＆ヘネシー．ハードウェア系の科目だが，プログラミング言語処理系の出口なので記載．
• オペレーティングシステム(OS): 並列プログラミングの基礎．
• オブジェクト指向プログラミング演習(OOP演習): 本科目．
• ソフトウェア工学概論: ソフトウェア開発の各工程ごとの技術の知識体系を講義．企業講師の方から最新技術の説明もあり．
• 組込みソフトウェア: 組込みソフトウェアの基礎である状態機械モデルを，LTSA を使って演習
• 組込みシステム開発演習: 近未来のモデルベース開発を先取りし，演習．安全性・信頼性にフォーカス．
• ソフトウェア検証論: SPIN によるモデルベースの検証方法の理論と実践．

つづく