無料ブログはココログ

« 工夫が凝らされたSCRUM BOOT CAMP THE BOOKの構成 | トップページ | [#TiDD] 「もしも」のための環境構築 »

ソフトウェアエンジニアリングしよう!

最近、技術的な議論よりも盛り上がりを期待するつぶやきが増えて、Twitterに疲れ気味です。そのような中で、にし先生がソフトウェア工学についてほとんど言っていただきました

私も色々考えて以下の様につぶやきましたので、今回はこれをまとめておきます。

ソフトウェア工学というのは工学の一つのジャンルだと考えています。Wikipediaによれば、ソフトウェア工学とは

ソフトウェア工学はソフトウェアの開発・運用・保守に関して体系的・定量的にその応用を考察する分野である

ということで、ソフトウェア開発や利用に関わる人なら、関係する分野です。

とは言うものの「ソフトウェア工学って役に立たないよね。」と以前は私も思っていました。今回は、その理由を含めて考えてみました。

先生の評価は論文中心

技術に感心のある技術者なら、その情報源として本を読まれると思います。しかし、研究の成果は論文を中心として発表されます。しかも研究は以下のような段階で発表されます。

研究会など査読のない発表:ジャンル違いでなければ発表させてもらえるもの。あまり評価されない

シンポジウムなど査読のあるもの:プログラム委員が新規性・有効性・信憑性などで評価し、点数の高いものから採録するもの(採録率は5割から8割ぐらいが多い)。評価はされるが、博士号や大学院の指導などの重要な基準にはならない

国際会議:世界レベルで行われるシンポジウム。採録率が10%ぐらいのものもあるり、有名な国際会議は論文波に評価される事もある

論文:ジャーナルと呼ばれる雑誌に掲載されるものです。必ずしも採録率は低くないのですが、完成度が低いとなかなか通りません

これらを順番に発表される事もありますし、シンポジウムや論文から書かれる事もあります。

もし、実験に基づくものなら、実験の計画、実施、集計、検討、論文化と言う順序に行いますので、1つの研究は早くて数ヶ月、場合によっては年単位でかかる事もあるでしょう。

このような研究成果がある程度たまると、本にまとめられます。また、同じ分野の研究が注目されると学会の雑誌に特集が掲載される事もあります。

この一連の研究の流れの中で、ソフトウェア工学全般の書籍になるものは出てきません。社会貢献という評価基準も一応はある様ですが、大学の先生には評価対象である論文の実績が常に求められます。

つまり、現場の技術者が期待している本というかたちでの技術公開は求められていないと言えます。本がないので、現場からは役に立たない様に思えるのですね。

共同研究の依頼が少ない

産学連携の典型的なパターンとして共同研究があります。噂によると、海外の大学では研究費の半分を学外から得ている場合もある様ですが、日本は少ない様です。

1人月にも満たない金額が多い科研費を得るためのセミナーが開かれるほどですので、興味深い研究をされている先生を見つけられたら、共同研究の話をされてみると良いかもしれません。

共同研究をすると論文を書いてもらえる可能性が高いので、現状の問題の整理、関連研究の調査、解決策の検討、試行のコントロール、評価、考察、などが形式知にできる事が期待できます。

教科書は安い方が良い/出版社は儲からない難しい本は出さない

大学の先生も授業に教科書は使いますので、教科書用ならそれなりの数が出ますので書籍として技術が公開される可能性があります。

かつてお世話になった通信関係の先生が教科書を出されていました。学生のために出そうとされた先生ですので「教科書は安くないといけない」という方針で出されたそうで、実際1000円ぐらいの本でした。

国立の先生でしたのでそれほどの册数を見込めません。本を書いても印税もわずかだったでしょうし、出版社もあまりもうけはなかったでしょうね。

一般の専門書では、儲からない本の場合は著者に一定の買い取りを求める場合もあるそうです。そもそも技術的に高度な内容を本に期待するのは難しいのかもしれません。

専門書の印税は1割もありません。1万冊出れば良く売れたと言われる様ですから、あまり売れない本だと1000冊程度のものもあるのではないでしょうか?1000円の本なら売り上げ100万円、印税は10万円足らずです。

電子出版には期待したいところですが、在庫リスクがなくなっても著者の負担、出版社の校正や事務作業等のコスト、などを考えると、やはり本に期待できません。

院卒の待遇が悪い

20世紀末の話ですが、中国の企業で名刺交換すると博士がたくさんおられて、危機感を抱きました。技術的なレベルは別にしても、問題を整理し、解決し、それを知見としてまとめる事ができる人だからです。

別の中国人の知り合いに聞いたところ、博士は部長並みの待遇で迎えられるそうです。この知り合いは、奥さんが働いて自分は留学させてもらっていた様です。文化的な違いがあるにしろ、そのような待遇が期待できるなら理解できますね。

ちなみに、中国では大学の先生が関わる企業もある様です。また、米国では地元の消防署で使われるソフトウェア開発を請け負うと言う例もある様です。海外では、大学で実践的な教育を行い、企業が高待遇で採用するという良い流れができている様です。

日本の場合、高度な研究を行った学生さんは、実践的な経験がないので、現場でバリバリと開発するのではなく、待遇の良い大手企業の管理部門や品質部門を目指す事が多い様です。

シンポジウムに来るのは管理・品質部門

産学がソフトウェア工学について議論する場は意外とあります。学会や産業界の団体等が主催するシンポジウムやワークショップがそれにあたります。

学会の後援を受けて査読をしていれば、大学の先生も実績にできますから、産学連携の必要性を感じておられる先生が積極的に参加されています。

しかし上記のような人の流れもあり、産業界からは管理・品質部門の方が多く参加されています。ソフトウェア工学の世界では80年代から産学の距離が議論されていましたが、今や現場と管理・品質部門の距離が問題になっている様に思います。

かつて日立グループにおられた奈良さんは、品質管理は本来現場で行うべきだと「大政奉還」を説かれています。管理や品質保証はその存在が不要になった時が成功なのだと思います。それには、現場がソフトウェア工学を実践する様にならないといけません。

エンジニアは論文を読まないし書かない(良くて技報)

しかし、ソフトウェア開発の現場ではシンポジウムに出る機会も少なく、論文を読む人も少数でしょう。

シンポジウムは研究成果を発表し合う場です。しかし論文を書くには、既存の技術を調査して研究の新規性を述べる必要があるので、発表できない状況なのです。

技報と言うのは各社の基準で出されますので、その辺は緩いのかもしれませんね。

エンジニアリングは工学

エンジニアはエンジニアリングする人のはずです。でも、エンジニアは技術者で、エンジニアリングは開発や工学という言葉が使い分けられています。元の言葉が一つなのでソフトウェアエンジニアリングで良いと思うのですがいかがでしょう。

アカデミアと現場のエンジニアが壁を作らずに議論する事が、今後の発展につながると思っています。

ソフトウェア工学では成果を明確にして再利用制を高める(つまり論文にする)目的で、問題領域を限定することが多いです。しかし、問題を見極めないで、良さそうな対策を適当にやろうとしてもうまくいきません。きちんと理解して実践しなければいけないのです。

アジャイル開発については、2003年のIEEE Computer紙上でベーム先生とケントベック氏が議論しています。ここにある金額ベースで多い大規模ソフトウェア開発か、件数ベースで多い小規模開発のどちらを重視するかと言う議論からもわかるように、アジャイル開発によって問題設定の異なる技術が増えたと理解しています。

アジャイル開発も Jeff Sutherland氏の論文リストを見ればわかる様に、オブジェクト指向を中心に多くの研究成果の上に発展して来たのだと思います。高度な議論をする事で技術は発展して来たのです。

ふりかえれば、CMMも1980年代のISPW(国際ソフトウェアプロセスワークショップ)から始まっていて、ソフトウェア工学の成果をうまく取り入れて成功しました。しかし、CMMが出て来た時には、アカデミックは置いておいて現場の人間でコミュニティを作って知見を貯めようとする動きがありました。

それはそれで良かったと思うのですが、技術をきちんと整理しないと、同じような経験談の発表に終始してしまうと思います。ビジネスの道具ではなく、技術論として研究者と議論できれば、もっと違った発展もあったかもしれません。

我々が技術者と名乗るのであれば、その基盤となるエンジニアリングを発展させないといけない思います。海外にできている事が日本にできない訳がありません。技術発表や交流を通じて、少しずつでもより良い方向に向かっていきたいと思います。

« 工夫が凝らされたSCRUM BOOT CAMP THE BOOKの構成 | トップページ | [#TiDD] 「もしも」のための環境構築 »

論文の書き方」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« 工夫が凝らされたSCRUM BOOT CAMP THE BOOKの構成 | トップページ | [#TiDD] 「もしも」のための環境構築 »