ものづくりの心

子ども向けの DVD を見ていたら．思いがけず，ものづくりの心を教わりました．

ティンカーベル

• ものづくりが大事な仕事であること
• ツール・プロセス・チームワークによってものづくりの効率が飛躍的に高まること
• ものづくりのモチベーションを保つには，直接・間接的に顧客と接する機会を持つことが大事であること

ソフトウェア開発の実務家が博士論文を書くことの意義

ソフトウェア開発の実務家がソフトウェア工学の博士論文を書くこと，つまりソフトウェア工学の研究手法を学んで実践できることの最大の意義は，ソフトウェア開発を科学的・工学的に改善することを学ぶことだと私は思います．

実務ではよく PDCA (Plan-Do-Check-Action) のようなサイクルでソフトウェア開発を改善していきますね．しかし，たとえば P 一つとっても，その計画を採用するときに，ただのKKD(勘，経験，度胸)だけを根拠にしていませんか？ その計画に客観的な裏付けはありますか？
たとえば，あるソフトウェアを開発するのに用いる技法を選ぶときのことを考えてみましょう．できるだけ最善に近づけるためにはどうしますか？ たとえば世の中にどのような技法があるのか，今までに技法を実践した前例がないかを網羅的に調べますよね？ 大々的に採用する前に，試験的なプロジェクトで効果を実証してみたりしませんか？ そもそも自分たちがどんな課題に直面しているのか，今までのソフトウェア開発活動をふりかえることもするでしょう．

ソフトウェア工学の実践研究では，実はこのような活動を次のように科学的・工学的に行っています．

1. 問題定義: 今までのソフトウェア開発をふりかえって，何が課題かを定義する
2. サーベイ: 課題に関連する研究や事例，技法などを網羅的に調査する
3. 解決アプローチの検討: 既にある解決法を再利用しながら必要に応じて新たな解決法を追加提案する 
4. 検証: 実際のソフトウェア開発に解決アプローチを適用してみて効果を実測する

このやり方をきちんと身に付けると，実務でも大いに役に立つはずです．博士論文を書くことは，このやり方を身につけるトレーニングになります．

博士号のとり方

社会人(ソフトウェア開発の実務家)が博士論文を書くときのコツは，いかに最小限の内容にするか，だと思います．社会人になると欲張りになって「あれもこれも」と盛り込もうとして収拾がつかなくなって年限オーバーということになりがちです．「引き算」です．一番大事な本質的な問い(リサーチクエッション)をいかに絞り込むかが勝負だと思います．


リサーチクエッションがある程度絞れたら，それを「仮説」「軸」として既存研究をサーベイします．似たようなテーマの研究を分類する「軸」を提案するようなサーベイ論文は，とてもわかりやすく有用です．

サーベイを終えると，何を自分がなすべきかが見えてきます．空白域になっているような領域があるかもしれません．また，軸の全体を統合するような方法論が不在かもしれません．理論が整っていない，あるいは逆に実践を伴っていないような領域があるかもしれません．そこが狙い目だと思います．最初にも述べた通り，博士論文は最小限の内容にするよう心がけるのが大事です．次の記事も参考にしてください．

ソフトウェア工学実践研究において「巨人の肩に乗る」ということ
http://zacky-sel.blogspot.jp/2013/01/blog-post_10.html

私の博士論文はダメダメだったんですが，その後ヨーロッパを中心に行われている「研究方法の研究(メタ研究)」を調べたり，実際に書かれた博士論文をいろいろ読んでみて，こうするべきだったんだということが後でわかった次第です．

博士号を取ろうとするすべての人に，まずは次の書籍を薦めます．

http://www.amazon.co.jp/gp/product/4990455509/ref=as_li_ss_tl?ie=UTF8&camp=247&creative=7399&creativeASIN=4990455509&linkCode=as2&tag=zacky1972-22

ふりかえり再導入

KPT を使ったふりかえりについて，今まで完全に誤解していました。

自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 ～ KPTと進め方のノウハウ ～Social Change!

http://kuranuki.sonicgarden.jp/2013/05/kpt.html

ふりかえりで話すことは「仕事の進め方」についてです。仕事の進捗や報告の場ではありません。普段の仕事をするときより少し視点を変えて、自分たちの仕事の進め方を外から見る感じで考えます。なので、進捗会議とは別の時間をとって実施するのが良いでしょう。

そうなんです，今まで完全に進捗会議と混同していました。それで意義が見いだせず，楽しくないどころか苦痛すら感じていたので，習慣になりませんでした。

倉貫さんのブログを読み，考察した結果，学生に次の4点を強調して KPT を再導入してみました。

1. 日々の作業の中で工夫したことに注目し，うまくいった続けたいことを Keep に，うまくいかなかったことを Problem に書く。
2. Keep に対しては，さらにそれぞれがもっと促進するような工夫のアイデア出しをし，それを Try に書く。
3. Problem に対しては，その問題点を解決するような工夫のアイデア出しをし，それを Try に書く。
4. Try に挙がった項目の中から，明日からすぐに取り掛かりたいことを3つ選び出す。次回の振り返りまでは，それらを強く意識して取り組む。

効果はてきめんで，とても楽しくアイデア出しできました。

実例の写真をいくつか挙げてみます。

惰丸(ダマル)日記 第1章〜「スタンフォードの自分を変える教室」を実践してみた

クリックして新ブログへ

この1週間，「スタンフォードの自分を変える教室」を読みながら実践しました。

http://www.amazon.co.jp/gp/product/4479793631/ref=as_li_ss_tl?ie=UTF8&camp=247&creative=7399&creativeASIN=4479793631&linkCode=as2&tag=zacky1972-22

この本は，目標を確実に達成するための，科学(心理学・生理学)的に有効性が示されている方法を紹介しています。

本に書かれていたことの中で，この1週間で特に有効だったメソッドを挙げていきます。

1. 達成すべき目標を1つに絞り込んで明確にしたこと。私の場合は，他にもいろいろ達成したい目標はありますが，目下の小目標である論文執筆にフォーカスしました。目標を絞り込んだおかげで余裕が生まれ，客観的かつ冷静に取り組めたのがよかったのだと思います。
2. 目標達成を妨げる自己に「惰丸(ダマル)」と名付け，「仮想敵」としたこと。これが一番効果あったかもしれません。自己を責める心情ではなく，外敵をやっつけるのだという心情になることによって，そうとう気持ちが楽になりました。
3. 「惰丸(ダマル)」が現れる状況はどんな時か，日々振り返ったこと。これによって，目標達成を妨げる原因を特定し，具体的な対応策を考えることが可能になりました。
4. 「惰丸(ダマル)」に負けそうになった時に，深呼吸したあと小さなタスクから取り組みなおしたこと。目標達成をおろそかにする衝動的な気分になってしまうことは日々の活動の中で頻繁に起こりえますが，深呼吸すると意欲が生まれます。また小さなタスクから取り組むとペースを取り戻しやすくなります。
5. 極度に疲労しないように調整したこと。体力・気力が削がれると意欲も極端に落ちます。

惰丸(ダマル)日記の第1章は終わりましたが，論文はまだまだ書かなければならないですし，ほかにもやるべきこと，やめるべきこと，意志を貫きたいことはたくさんあります。この本に書かれているメソッドが無意識の習慣になるまで，惰丸(ダマル)日記を続けていきたいと思います。

惰丸(ダマル)日記 第1回

https://www.facebook.com/zacky1972/posts/515594698473500

「スタンフォードの自分を変える教室」を読んで実践していく過程を記録しようと思います。

直近の最大の目標は「論文誌に乗るレベルの論文を投稿しまくる」です。お恥ずかしい話ですが，このまま論文の業績を出さないと大学教員でいつづけることができなくなってしまうのです。

第1章によると，対立する2つの自己(賢い自分，衝動的な自分)を意識し，衝動的な自分の方にあだ名をつけるのが有効なのだそうです。

さっそく妻が命名しました。「惰丸(ダマル)」です。怠惰，無駄の象徴です。そう，ことごとく惰丸(ダマル)のせいで，論文が投稿できないのです。私が，レールの上を猛スピードで疾走している時に，惰丸(ダマル)がコッソリポイントを切り替えるので，私が走るべきレールを見失うのですw

惰丸(ダマル)日記 第2回

https://www.facebook.com/zacky1972/posts/515845741781729

論文を書くか書かないかを「選択した瞬間」を振り返ると，自己コントロールを強化できるのだとか。

昨日は午前中に論文を書く予定だったのだけど，急遽，子を病院に連れて行く必要が出てしまったので予定が狂ってしまいました(幸い，子の病気は大したことありませんでした)。子がいるとどうしてもイレギュラーなことが起こってしまいますね。

そこで，夜に論文を書こうと思ったのですが，子の寝付かせをしたら自分も寝てしまいました。惰丸(ダマル)発動ですね。今思えば，寝付かせを妻にお願いするべきでした。

今，目が醒めたのですがかなりボンヤリしているので，起きて論文を書き始めるか，もう一度寝てスッキリした頭で論文に取り組むべきか，悩ましいところです。

とりあえず，まとまった時間，PCに向かって作業することが大事なので，たとえば Facebook はスキマ時間だけチェックすることにしようかな。(そういうわけで，スミマセン，レスポンス悪くなります)

惰丸(ダマル)，なかなか手ごわい。。。

すぐに寝付けないようなので，単純作業だけでも論文を進めておこう。

だんだん快調になってきて，良い感じで書き進みました。

惰丸(ダマル)日記 第3回

https://www.facebook.com/zacky1972/posts/516412285058408

昨日の後半はすっかり惰丸(ダマル)にやられてしまいました。未明に起きたので論文を書き進めたのですが，頑張りすぎた反動で昼からはあまり進められませんでした。できなかった原因は，雑用が多かったこと，そして何と言っても体力的にきつかったことでした。そのため夜はこんこんと寝てしまいました。 稲見さんの心配があたってしまいました。

「スタンフォードの自分を変える教室」の目次の第3章に「疲れ」の話が載っているので，そのうち実践しようと思います。

さて，第1章の最後に瞑想の話が書いてありました。瞑想の効果については学生時代に剣道をしていたので経験していましたが，「瞑想が下手な方が効果が上がる」のは知りませんでした。さっそくやってみます。久しぶりにやってみて，集中力を研ぎ澄ますのに役立つことは実感しました。が，5分がとても長く，とても耐えられませんでした。また，子が居る中ではなかなか厳しいですね。でも続けていこうと思います。

惰丸(ダマル)日記 第4回

https://www.facebook.com/zacky1972/posts/516900501676253

昨日は博多でとても楽しみにしていたイベントがありましたが，論文を書き進めなければならないので，午前中に諸準備をしていました。

博多に行ってから合間の時間に論文を書こうとも思っていましたが，イベント前は移動と食事で時間がつぶれ，イベント後は興奮と酒の余韻に浸っていて，できませんでした。

その分を取り戻そうと，今朝は惰眠をむさぼりたいとも欲求に駆られたのですが，惰丸(ダマル)に負けてはならんと発奮し，集中して論文を書きました。そのおかげで論文前半のハイライトの最も主要な部分が書けました。昨日午前中の準備が生きて，今朝ははかどりました。よしよし。

「スタンフォードの自分を変える教室」のメソッドは，本当に理にかなっているなぁ。

惰丸(ダマル)日記 第5回

https://www.facebook.com/zacky1972/posts/517126504986986

今日は妻の実家で夕食だったのですが，あまりに長居したので，論文執筆に焦るあまり帰りに，つい妻に激昂して八つ当たりしてしまいました。本当にゴメンナサイ。そもそも締め切り直前になって書き始める私が悪いよね。。。

さて，私は論文を書くことそのものも億劫ですし，英語は苦手意識があってついつい後回しにしてしまいます。今回の論文は苦手な英語なのですが，しばらく書いて慣れ始めると，実は英語で論文を書くことそのものはそれほど嫌いではないことを発見しました。自分の教育研究の成果を英語で書くと，なんかこう，思考が整理されるのです。「あぁ，自分はこういうことをやってきたのね」と気づかされることが多々あります。今書いている論文を書き終えても，この感触を忘れないうちに，次の論文を書こうっと。

たぶん，私が論文嫌いなのは，査読とか発表後の質疑応答とかなんだろうなぁ。

※同僚の先生が熱いコメントを寄せてくれました。

惰丸(ダマル)日記 第6回

https://www.facebook.com/zacky1972/posts/517784191587884

3連休最終日。妻が1日じゅう子を連れて実家や外に遊びに行ってくれる計らいのおかげで，論文執筆にまる1日専念できました。ずっと集中して取り組んだので，手を焼いた執筆中の英語論文も残すところ3項目を書けばひと通り書き終わりです。ようやく終りが見えました。妻に感謝です。

今朝，思い立って Facebook の設定を大きく変えました。「親しい友達」に気になる人を入れておくと，その人がなにか書くと「お知らせ」に表示されるという機能があり，私はそれをフル活用してチェックしていたのですが，思い切って全削除してみました。今まで「お知らせ」が気になってついついチェックしてしまっていましたが，この習慣を断つ効果が期待できます。その代わり，みなさまへのフォローが行き届かなくなるわけですが，ご容赦いただければと思います。今年は論文を含む実質的なアウトプットを行うことで成果を還元していきたいと思います。

惰丸(ダマル)日記 第7回

https://www.facebook.com/zacky1972/posts/518391184860518

ついに目下の懸念であり目標だった英論文1編をひと通り書き終えました。「スタンフォードの自分を変える教室」にしたがい「惰丸(ダマル)」を仮想敵として論文執筆に取り組んで1週間になりますが，まずは当初の目標を達成したといっていいのではないかと思います。

総括をする前にここ数日での取り組みを書き残しておきます。

昨日1月15日ですが，午前中は少しの時間ではありましたが，論文執筆に取り組むことができました。しかしその後モチベーションが下がるような出来事がありました。そのせいで午後はゼミを回すだけで一杯一杯で論文執筆どころではありませんでした。

「スタンフォードの自分を変える教室」にも，意欲・気力が削がれたり疲労したりすると，目標達成に向けた日々の活動に取り組まなくなってしまうことが多いと書かれています。たしかにそのとおりです。

そこで，昨晩は体力回復に全力を注ぎました。おかげで，今日は朝から意欲的に論文執筆に取り組みことができ，ついに達成できた次第です。

ソフトウェア工学実践研究において「巨人の肩に乗る」ということ

私の友達の，あるソフトウェア工学実践研究者の方が，次のようにボヤいていました。

(自分が考案したアイデアについて文献を調べていくと似たような技術がすでに提案されている状況に対し) こういうことの繰り返しなので、オリジナルの方法論を作るのは無理なんじゃ無かろうかと思う次第。

https://twitter.com/mkoszk/status/288920530625638400

このかたは実践経験豊富な実力あるソフトウェア工学実践研究者だと私は思っているのですが，そういう方でもこういうことを思うのだなと興味深く思いました。

もちろん私自身もこういう経験あります。修士論文を書く時に，一生懸命プログラムをいじりながら自分で考えていって，いざ論文を書こうという段階で関連研究調査を始めたところで既に類似の研究があることを見つけたときの無力感。

ちなみに私は研究者としては半端者なので，いまだにこの手の過ちを繰り返しています。なんて進歩がないのだろうか(苦笑)

さて本題です。真のソフトウェア工学者は，こういうとき「巨人の肩に乗る」アプローチを取るものです。「巨人の肩に乗る」ことで常人は自分の背丈以上に遠くを見渡すことができます。「巨人の肩に乗る」でいうところの巨人とは，既存の膨大な研究資産のことを指す比喩です。既存研究資産に乗っかる形で自分の研究を書くことで，その研究が既存研究資産を活用して大きな仕事を行うことができるということを意味しています。

私が修士論文を書いた後の話をしましょう。恥ずかしながら修士論文発表会では散々でした。だって，類似の研究があって，それに対する自分の研究のオリジナリティがどこにあるのかを明示できなかったのですから。でも，転んでもタダでは起きませんでした。発表会が終わった後，猛勉強して研究論文を読みあさり，ついに自分の研究のオリジナリティがどこにあったのかを見出すことができました。それだけでなく，そのオリジナリティの部分をきちんと実現するとどんな可能性がひらけるのか，展望を見出すことができました。そのアイデアを発表会を聞いた周囲の先生方に話したところ「それなら行けるかもしれない」とようやく認めてもらうことができました。そのアイデアを元に学会に論文を投稿することになります。

「巨人の肩に乗る」とは，つまり，こういうことなのです。まずとにかく，自分が思いついたアイデアが，世界の中でどういう位置づけにあるのかを明確にする。そのためには自分のアイデアに関連する研究論文を，とにかく読み漁る。そういうことをすると，真にオリジナルの部分は，ごくごく小さいかもしれない。「自分のしたことは，こんなちっぽけなことなのか」と悲嘆するかもしれない。
でも，むしろそれでいいのです。そこが問題なのではないのです。問題は，その小さな貢献によって，どんな価値が生み出されるか，なのです。「第1章はじめに」で書くべきことですね。




思えば，私は巨人の肩に乗ることが生来的には下手なのだろうと思います。だって，人の話を聞いたり文献を地道に調べたりするよりも，自分で一からアイデアを考えて妄想するほうが好きなんだもの。

こういうタイプの人でも，やりかた次第で巨人の肩に乗ることはできます。

1. 先に自分のアイデアをひと通り書く。
2. その中で重要そうなキーワードを抽出し，それを元に文献を探す。あるいは，アイデアを指導教員など先行する研究者に話し，何を探したらいいかキーワードを尋ねる。
3. 文献を読み漁る。最初に書いた自分のアイデアを適宜書き換える。ただし，主旨を曲げないように！ 新たに思いついたアイデアがあったら足してもいい。
4. 自分のオリジナリティを抽出する。いくつかの構成要素に分解できるかもしれないので，それに合わせて論文や章立てを分割する必要があるかを検討する。

アイデア先行型の人は，こんな感じで研究を進めるといいですよ。

インサイドアウトと相乗効果，これからの就職活動や市民活動のあり方〜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つの習慣を手に取って読んでみてください．また近々，この話の続きを書きたいと思います．

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

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

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

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

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

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

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

----

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

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



Twitter での感想

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

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


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

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

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

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

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

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

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

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

ザ・ファシリテーター

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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


僕が，忙しいけど頑張ってブログを再開しようと思ったきっかけは，金持ち父さん貧乏父さんです．なぜならば，このブログも僕にとっての資産だからです．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 さんが記事を書いてくださいました．このリンクをクリック！