無料ブログはココログ

« 2013年3月 | トップページ | 2013年5月 »

CMMブームふりかえり

アジャイルブーム到来の兆しに、ようやく来たかと喜んでいますが、1990年代のCMMブームの様にならないかとの懸念も持っています。そこで、CMMブームをふりかえってみました。

K(よかったこと)

  • 過去のソフトウェア工学の知見がプラクティスとして整理された
  • プロセスは継続的に改善されなといけない事が示された
  • プロセスのアセスメントがビジネスになることや、レベル達成というわかり易い表現でプロセス改善が宣伝になる事を示した

P(改善すべきこと)

  • 当初、組織のプロセス能力の成熟を分類した結果がそのまま成熟の道筋とされた
  • 全てのプラクティスを実践する事が、全ての組織のゴールであると誤解させた
  • 組織の活動が注目された反面、チームの活動が軽視された
  • トップダウンでプロセス改善が実施され、形骸化してしまう事が多かった

T(実施すべきこと)

  • プラクティスを実施できる様に整理すること
  • 組織の多様性を認めた上で、プロセス改善を継続する事
  • ブームをビジネスに利用しつつ、チームを中心にプロセスを改善する事

CMMブームの時は間違った方向で実施される事を恐れた方達が、自ら進んでプロセスチャンピオンになられました。そして、プロセス改善の形骸化の抑止と、より良い普及に努力されました。

アジャイル開発ブームでも、意識の高いアジャイラーの奮起によって、より良いプロセスが実現される事を期待しています。

[#TiDD]「アジャイルの夢を現実に!」スライド公開 - XP祭り関西2013 - #xpjugkansai

ソフトウェア開発のプロセスはリーダーやマネージャーのものではありません。そのプロセスによって顧客の求めるプロダクトが開発できるだけでなく、そのプロセスを採用した理由を説明できないといけません。もちろん高い生産性が発揮できる様に、メンバーが納得して前向きに取り組めるプロセスでないといけません。

これは、アジャイル開発の導入でも同じです。ブームだから、良いと言われているから、上司が言ったから、というのでは説明にならないですし、プロセスの変更は少なからず負担を伴うので、メンバーも納得しません。

アジャイル開発では優先順位に基づいてイテレーティブに開発されます。ソフトウェアプロセスも同じ様に、具体的な問題の改善策として、繰り返しプラクティスを導入・見直しをされなくてはいけないのです。プロセス改善もまたイテレーティブでなくてはより良いプロセスを実現できないのです。

このようにアジャイル開発を銀の弾丸の様に考えて、それさえ実施すればうまくいくとリーダーが勝手に始めたり、社内への教育も不十分なままにトップダウンに強制する事が大きな間違いである事がわかるでしょう。

21世紀の初めに私たちが見たアジャイルの夢、それを現実のものにしましょう。現実の問題を改善する方法としてプラクティスを導入すれば、チーム内でゴールを共有できますので現状のプロセスを大きく改善する事ができます。それはより良いアジャイル開発の姿であり、アジャイルになりきれないアダプタブルウォーターフォール開発かもしれません。

書籍「チケット駆動開発」では、アジャイルプラクティスの理解を前提に、現状のプロセスをどのように考えるべきであるを書きました。今回の XP祭り関西2013 では、 アジャイル開発に夢を見た人、アジャイル開発をより良くしたい人に向けて 、現状を見極めた上で導入したい具体的なお勧めのプラクティス・代替プラクティスについて説明しました。

1990年代のCMMブームによって、各企業でプロセス改善が行われ、大きな成果を残しました。しかし、その一方で重装備なプロセス標準の強制により、プロジェクトの本当のゴールを考えずに標準に沿う事を目的として開発するようになり、プロセス改善運動は形骸化しました。この過ちを繰り返してはいけません。

より良いソフトウェア開発の未来を築くべく、今回の講演をしました。スライドを公開いたしますので、ぜひご覧ください。


できる人を観察して勝負する

なに気なくつぶやいたところ、評判が良かったのでブログにまとめておきます。

このように考えだしたきっかけは、会社から奈良先端大に留学した時の事です。周りは旧帝大の卒業生ばかりで、一流とは言えない大学の出身者である私は困ってしまいました。

仕事として留学しているので、下手な成績はとれません。しかし、先生も学生も阪大、京大、九大など、偏差値の高い人達です。昔のような勉強法では勝負になりません。

そこでしたのは観察です。できる人達がどのように考え、どのような行動をとり、どのような特性があるかを分析しました。元々は修士(博士前期)過程の授業対策ではじめましたが、その後の研究の中で感じた事や高校生時代の話を織り交ぜながら説明します。

知識の構造を常にリファクタリングしている

上のつぶやきに書いた様に、新しい情報に接する際には、既にある知識構造に当てはめながら、場合によっては構造を見直しながら理解しているようです。

論文で言葉の定義が重要視されるのはこの事が大きく影響していると思います。短い文章で論理的な事を説明するので、用語を端的に説明して一つの意味でだけ使わないと、理解してもらえなくなるからです。

日本人ならある程度我慢してくれますが、国際会議などではタイトルの意味や背景の説明が不十分だと、すぐに質問されてしまいます(失敗すると面倒くさくなるので「後で説明する」と言って我慢してもらう事が多い様です)。

このような事を考えていて思い出したのは、旧帝大に行った高校時代の友人達です。化学や物理の授業後の休憩になると、必ずと言って良いほど言葉の定義を話し合っていました。

彼らは「XXと言うのはYYということだ!」「でもZZと言う例があるから必ずしもそうではない」などと話しておりました。

当時は本当に勉強が好きな人たちだと思っていましたが、お互いの理解を説明し合って知識の構造を見直していたのだと思います。知識が体系化すると覚えないといけない情報が少なくなるからでしょう。

成績の良い彼らは、勉強していない振りをして陰で猛勉強しているに違いない。と思っていましたが、実は効率よく勉強していただけなのかもしれません。

それなのに凡人の私は、情報を整理しないまま放置して、試験の前日に大量の情報を覚えようとしていたので、勝てる訳がありません。知識獲得の際に随時整理しておくと言う事が大切だったのですね。わからない事は貯めずにきちんと理解して整理する。それが一つ目の戦略でした。

ゴールに合わせる

先端大の授業に出ていると、優秀な学生さん達の話し声が聞こえる事もありました。「大学の推薦を得るには、成績の順位が良くないといけない。」「それは成績の平均点だ。」「優が取れない科目は捨てる。」などと話しているのです。

その後、先端大では単位数も評価に入った様ですが、当時は優、良、可をそれぞれ3点、2点、1点として、その平均で学生を順位付けして推薦を与えていました。そのような評価方法に合わせて、彼らは授業を受ける科目を選んでいたのです。

学校の推薦を得ることが目的ですので、単位が取り易いかどうかではなく、優が取れそうかどうか、場合によっては「優でなければ落としてください」と試験に書いて、少しでも有利にしようとしていました。

私が高校生の時は、試験に合わせて勉強するのはおかしい。と言って予備校式の勉強を否定していたのですが、優秀な彼らは受験勉強はもちろん、大学の単位もゴールに合わせていたのですね。

彼らが大学の先生になったとします。もし、論文の数だけで評価するなら、社会の役に立つかどうかは関係なくなって、論文数を得ようとしても仕方ありません。

大学の先生の評価には、すでに社会貢献なども入っている様ですが、さらに社会貢献の比率を高めれば、もっとすごい研究成果が生まれるかもしれませんね。

価値観が明確

上記2点の影響からか、価値観も明確な人が多い様に思います。興味のある授業を取るという点は普通ですが、それ以外の科目はより多く優を取ることが優先されているようでした。さらに、同じ優なら苦労せず、確実に取れる科目が好まれている様でした。

価値観が明確であるので、就職先を選ぶ際もシンプルでした。彼らは、生活に必要な収入を得る事が就職の目的なので、待遇が良く安定した会社が好まれている様でした。

個人的には、昇格するか、会社が伸びるかどうかで収入は変わると思います。そして何より、その会社に居ると自分が成長できるとか、会社を利用して社会貢献できるとか、会社に居場所ができるとか、そう言った事が豊かな人生につながると思います。

#最近の若い人には難しいかもしれませんね。

戦略その1:授業の取り方

これらの観察を経て、授業の取り方を検討しました。ポイントは

  • 良いところはマネをする
  • 正面から喧嘩をしない
  • 勝てるところで勝負する

です。

まず、知識の構造を常にリファクタリングすることとゴールに合わせるの2点は採用しました。その上で自分の価値観は程々に、勝てるところで勝負しました。

具体的には、リファクタリングにつながると思われる課題(宿題)はきちんとこなしました。しかし、できる人には記憶力では負けていますので、リファクタリングしても雑多な記憶が求められる科目はあきらめました。

逆に、単位を取る事すら体力的に難しい科目は、学生さんは捨てると思われましたので積極的に取りました。大学の先生も単位が取れない学生ばかりではまずいので、必死になって付いていくと、意外と良い成績がもらえるのでした。

このように、戦略的に授業を受けた結果、単位数は少なかったですが、ほとんどの科目が優という予想以上の成績をいただく事ができました。

論文の書き方

論文の執筆も同じような戦略を取りました。論文誌(ジャーナル)に採録されるには完成度が求められますので、いわゆる「落としにくい論文」とされる「抜けのないきちんとした論文」が正攻法です。

このような論文を書くには問題設定が重要です。明確な問題があり、研究の成果が解決する。その2つがきちんと対応してなくてはなりません。そこでゴールに合わせるように、やった事を裏返して問題設定にする。という方法を考え出しました。

しかし、恩師曰く「確かにそうだが、シンプル過ぎても面白くない」とのこと。たしかにできる人の論文を読むと、シンプルな問題設定を重要なものであることを説明できる様に関連研究を充実させ、解決策だけでなく想定外の成果(発見)を示すという努力がされている様でした。

研究生活の短い人間には、このように立派な問題設定と発見は簡単ではありません。そこで、論文を別の方法で面白くする事を考えました。つまり、「落としにくい論文」ではなく「落としたくない論文」を目指しました。

具体的には、やった人でないとわからない事を書くように心がけました。再現するために必要な情報はもちろんの事、ツールの実装時の工夫、得られた結果の現場の人間としての評価を加えました。

これが意外とうまくいき、シンポジウムや国際会議だけでなく、論文誌にも採録されました。中でも、博士論文にも入れたrubyによるプログラムの分析ツールの論文(26枚目以降)は、翻訳までしていただいて海外論文誌にも紹介されました。

まとめ

このように、現状を分析して勝てるところで勝負する方法は、大きな効果が得られます。これはエンピリカルソフトウェア工学やPDCAサイクルによる改善、さらにはアダプタブルウォーターフォール開発にもつながるものです。

いま、目の前のプロジェクトをなんとかするなら、問題を明確にしてそれを解決するプラクティスを導入すべきです。今週末のXP祭り関西2013では、そのような視点でプラクティスを説明する予定です。

お申し込みは2013年4月26日までです。ぜひご参加ください(最後は告知ですみません)。

このエントリーをはてなブックマークに追加

[#TiDD] プロフェッショナルは本物で確認する

プロフェッショナルには色々な定義があると思います。ここで説明するのは、

「プロフェッショナルはきちんと仕事をするために、本物で確認する。」

と言う定義です。

プログラミングの資料

プログラミングをする時に、入門書やハウツー本は便利です。特にクイックリファレンスや逆引き本などは大いに役立つでしょう。しかし、うまく動かないならマニュアルやサポートサイトを確認するでしょう。それが正式な仕様であり、公式な情報だからです。

プロセス改善

規格や標準に沿ってプロセス改善を実践する場合も、本や記事だけでなく、最新の技術情報を入手するでしょう。CMMブームのころ、先駆者であったオムロンの故坂本さんは、マトリクスモデルのない頃でしたが段階モデルを重視せず、現場の問題に応じて改善を進められていました。先進的な方法を勧めながらも、CMMの改善方法と言えるかと公式アセッサーに確認されていました。

世界を変えるとき

幕末の志士である坂本龍馬は、人に頼らないで多くの人と直接対話をしました。元々は尊王攘夷派だったので、対立する開国派の勝海舟を殺す覚悟で合いにいき、その考えに納得して受け入れたのでした。それが明治政府の近代化につながり、海援隊は後の三菱財閥になりました。

論文執筆

論文を書く際にも、参考文献の孫引きは良くないと言われています。大元の文献ではなく、都合良く引用された文献をさらに引用すると、間違った結果を導いてしまうからです。

情報収集

何かを学ぶときもそうです。魚(結論)ではなく魚の捕り方(理論や方法)を知るのには、どのようにすればその情報が得られるかを聞く必要があります。答えを聞いて満足するのではなく、「どの本を読めば良いか」「どのように勉強すれば良いか」を尋ねないと、毎回聞いても成長できません。

品質と価値の確認

ソフトウェア開発において、ソフトウェアの品質やソフトウェアの提供できる価値を確認する場合も同じです。アジャイル開発の様に実装されたもので確認しないと、とても危険です。

開発中の状況

開発中の状況も同じです。報告のために作られた情報ではなく、開発に使われている情報を確認しなければ、本当の情報ではないかも知れません。

このように、チケット駆動開発で見える化するのは、プロが求める本物の情報だったのです。

おあとがよろしいようで、、、

このエントリーをはてなブックマークに追加


日本でスクラムを実践するなら読んでおきたい本(SCRUM BOOT CAMP THE BOOK)

アジャイル開発が話題になって10年以上が経ちました。しかし、この本が登場するまではどこかしっくりこないところがあって、日本ではあまり普及してきませんでした。

ア ジャイル開発では開発者が中心で、自ら進んでタスクを選んでコミットします。それぞれのメンバーがプロジェクト全体を見渡して、ワイワイと見積もり、助け 合いながら実践し、定時になったら帰宅する。そんな理想的なソフトウェア開発の姿を見聞きして、多くの人が夢を見たと思います。しかし、いざ社内を見渡す とシャイな人も居たりして、いきなりアジャイルをやれと言われても困ってしまうというのが現実ではないでしょうか?

この本は日本の現場でどのように実践するかが書かれた本です。スクラムマスターを任された主人公のボク君を中心にお話が進んでいきます。社内で初めてのスクラムプロジェクトなので、プロダクトオーナーやメンバーも初心者です。そして、その中にはシャイなバッチ君もいます。

こ のバッチ君は自信なげに「僕なんかでいいですか?」と言います。いかにもありそうな、日本の現場です。イベントや勉強会で見聞きする、アジャイルの有名人 による理想的なプレゼンからはイメージしにくい現実です。このバッチ君がストーリーに存在することで、この本で説明されているスクラム開発が、理論でなく 現実のものとしてイメージできるものになってます。

この本はマンガのストーリーを中心に関連する多くのノウハウを説明する構成になってい ます。示されているノウハウは大量でメインのストーリーよりも多いですが、マンガで流れが読み取れるのでとても読み易くなっています。もし、ストーリーも 文章ならもっと読みづらい本になっていたと思われますが、マンガと文章のコントラストによって知識の少ない人でもストーリーを見失う事なく読み勧められる ようになってます。

ソフトウェア開発を実践するには多くのノウハウが必要で、プロジェクトをリアルにイメージできないとうまくいきません。この本は、これからスクラムを始めようとする人には、ぜひとも読んでいただきたい本だと思います。

(アマゾンのレビューからの転載)


サーバントリーダーシップで「和」(ハーモニー)を実現する

NHK朝のテレビドラマ「あまちゃん」を見ています。キャストもストーリーも楽しめますが、中でもオープニングが秀逸だと思います。

オープニングでは、最初に主人公がジャンプしますが、あれがすごく良い!

あのシーンが無いなら、軽快な音楽に北三陸の景色が流れているだけで「ふーん」と言う感じですが、あのシーンがある事でぶっ飛んだ感じが良く出ています。しかも、後半にもジャンプシーンがあって、それの前振りにもなっています。

そのような構成も、やはり主人公のキャラクターや音楽があってのことですから、プロデュースというのは、商品の価値を作り出すすごい仕事だと思います。

「きゃりーぱみゅぱみゅ」さん
(ドラえもんがポケットから道具を出す時の様に言い易い)

プロデュースのことを考えはじめたきっかけは「きゃりーぱみゅぱみゅ」さんでした。

初めてミュージックビデオを見た後にTVなどを見ていると、このビデオがフィンランドでアクセス1位になったとかで世界的なブームになっているようでした。

調べてみると「きゃりーぱみゅぱみゅ」さんは読者モデルで、変顔をブログに載せている事で有名だとか。それがなぜ、あんなにぶっ飛んだプロモーションビデオにつながるんだろうと思いました。

音楽チャンネルの番組を見ていると、きっかけはプロデュースした中田ヤスタカ氏のDJコンテストのようなものに出た事だそうです。ラジオでDJをしていた木村カエラさんと似ていますね。

最初のミニアルバムを聞いてみるとperfumeのイメージを受けましたが、最近の楽曲はきゃりーさんの好きなYUKIさんのイメージに近くなっています。たぶん最初の頃はあまり意見も言えなかったようで、最初の曲では「妖精にしてあげる」と赤鬼のようなメイクをされていました。最近はファッションなど、個性が前面に出ていますね。

情熱大陸というTV番組によると、中田ヤスタカ氏は「手伝っているだけだ」と言われている様です。能力が発揮できないならそれを助けるし、能力を発揮できる様になれば応援する。この中田ヤスタカ氏のあり方は、サーバントリーダーシップだと思いました。

「和」はハーモニー

プロデュースというお仕事は、このようにサーバントリーダーシップを発揮して、顧客により多くの価値を提供する仕事だと思いました。

そんなことを考えていたとき、日本に住む外国人のTV番組をやっていました。その中で英語の詩が読まれたとき、「ハーモニー」という言葉が「和」と訳されていました。

「和」と言う言葉を聞くと「和を乱さない」と言う様に、自分を抑えて丸く納めるようなイメージに捉えていました。しかし、加算の答えも「和」と言いますし、自分を抑えてカドを立てないのではなく、お互いの能力が加算されてハーモニーした状態を「和」というのでしょう。

プロジェクトは様々な能力や経験を持つ人の集まりです。管理し易い様に個人を押さえつけたのでは、能力を最大限に発揮できません。時には助け、時には意見を採用し、開発環境とともにコミュニケーションと情報共有の場を用意し、能力が最大限に発揮できる様にして、プロジェクトの「和」を実現したいと思いました。

このエントリーをはてなブックマークに追加

[#TiDD] XP祭り関西2013で「アジャイルの夢を現実に! 」を講演します #xpjugkansai

日本XPユーザ会関西のメイン行事である「XP祭り関西2013」が来る4月27日(土)に開催されます。

今回は「アジャイルの夢を現実に! - プラクティス・プラクティス -」と題して講演させていただきます(以前の告知から内容を変更しました)。

ジャイル開発に夢を抱く人でも、諸般の事情で実践できない方も多いでしょう。アジャイル開発のプラクティスは、ソフトウェア開発によく見かける問題を解決します。プラクティスがどのような問題を解決するかを知ることで、きっと日々のプロジェクトを快適するヒントが見つかるでしょう。
講演では、 チケット駆動開発で用いられる事の多いアジャイル開発のプラクティスを紹介し、従来法からアダプタブルウォーターフォールにどのように進化するかをご説明します。アジャイルの夢をあきらめず、プロジェクトをもっと快適にしまょう。

アジャイル開発のプラクティスは、アジャイル開発でなくとも有用なものがたくさんあります。現状の問題を見極めて効果的に導入すれば、プロジェクトを改善し、理想に近づけることが可能です。

本講演では、書籍「チケット駆動開発」では語りきれなかった「アダプタブルウォーターフォール」の具体的な姿を、プラクティスを中心にお話しします。これはチケット駆動開発によって改善された従来開発であるとともに、アジャイル開発の前段階としても有効です。

ご興味のある方は、ぜひご参加ください。お申し込みはこちらです。

技術を積み上げ可能にして未来を切り開こう!

積み上げ可能な技術

技術と言っても色々な種類があります。基礎技術、実践ノウハウ、ビジョン、方法論、パラダイム、などなどのうち、現場の技術者が勉強会で議論する事が多いのは実践ノウハウにあたるものでしょう。

ワークショップやグループディスカッションに集まった各々の経験を語り合い、色々な考えや感想を聞く事は刺激的で、すぐにでも役立つヒントになります。

とは言うものの、良さそうなアイデアを実践してみてもうまくいかない事もあります。それは、実践ノウハウが積み上げ可能な技術になっていないからです。

積み上げができる技術とは、以下のような技術です。

  • 解決できる問題と効果が示されている
  • なぜ解決できるか説明できる(たまたまでない)
  • 限界が示されている
  • コンテキスト(背景)が明確で再現できる


エンピリカルソフトウェア工学

上に挙げた項目がより具体的に、できれば定量的な情報が示されていれば、どのような技術であるかが明確になるでしょう。このような点が大切なのは、エンピリカルソフトウェア工学が1980年代の反省から生まれた事でもわかります。

ソフトウェア工学が生まれた1980年代は、一種のブームでした。多くの人が様々な提案を行っていた様です。しかし、それらは玉石混合で、良い議論もあれば、言いっぱなしの議論も多くあった様です。

そこで、提案する際はきちんと実証しようという事で生まれたのが、 経験的ソフトウェア工学とも呼ばれるエンピリカルソフトウェア工学です。上に挙げたように適用範囲が明らかな技術は、限定されているかもしれないが役に立つ技術です。

アジャイルを積み上げ可能な技術にしよう

これまで、従来法をベースにしたソフトウェア開発では、産学連携がそれなりに行われていました。シンポジウムなどでは大学関係者だけでなく、企業の管理部門や品質部門の方が参加し、お互いの成果を示し合い交流していました。

ソフトウェア工学の研究では結果の妥当性を示す目的で、統計処理が多く使われます。管理部門や品質部門はソフトウェア開発の統計的なデータを扱う事が多いので、お互いにメリットがあったのでしょう。

しかし、アジャイル開発は日本でようやく2012年頃から本格的な普及期に入ったところです。そして、なにより現場の技術ですので現場の人間でなければ、議論する事が難しいでしょう。

統計的なデータ収集はIPA/SECさんが積極的に行われていますし、アジャイル開発が本格的に普及すれば、従来の枠組みでもある程度は産学連携が行われるかもしれません。

しかし、開発現場の人間が期待するのは、やはり現場での技術を積み上げ可能にすることです。しかし、積み上げの議論を行うにも論文が通らないと議論に参加できないので、現場の人間自身が論文等にまとめる努力が必要になると思います。

現場の論文のヒント

私の失敗談からアジャイル開発の論文作のヒントをまとめておきたいと思います。

ソフトウェア工学国際会議(ICSE)で採録されたの論文の元になった、2004年の川端さん、小林さんとの論文発表をした後の事です。さらに事例を増やし、より良い論文にしようと永和システムマネジメントの木下さんに情報提供をお願いしました。しかし、詳しい情報をいただいたもののうまくいきませんでした。

それは、すでに木下さんのところではバーンダウンチャートやニコニコカレンダーなど多様なプラクティスを導入されていたからです。それまでのXPのサブセットのプラクティスで議論した論文に、フルセット以上のものを加えてはうまく議論をまとめられませんでした。

顔を突き合わせて議論すれば別の論文にできたかモア知れませんが、お互いの所在地の問題もあってうまくいきませんでした。安易にお願いして失敗してしまい、今も申し訳ないと思っています。

このように、無理に完成度を高めようとするとプロジェクトの多様性に混乱します。細かな議論ができる範囲で情報を収集して、量ではなく質で勝負する方が良いと思います。

また、論文誌(ジャーナル)は完成度が求められるので、いきなり狙うのは難しいです。まずは、シンポジウムや国際会議がよいと思います。これらは、完成度にある程度の難があっても、聞きたい発表は採録されるからです。

上に挙げた項目が明確で、新しい方向性を示ている、評価方法に工夫がある、など査読者が聞いてみたいと思う内容の提供を心がけるとよいと思います。

最後に論文で最も落ち易いのは、論旨のわからないものです。論文の書き方(その1その2その3)で書いた様に、論文の構造を意識して書く事です。特に「主張したい点を裏返して問題設定にする」というのは、シンプルな構造を実現するポイントです。

まとめ

ようやく日本でも、アジャイル開発が普及しようとしています。しかし、技術の積み上げがなければ、一通りの市場を獲得した時点で普及が終わってしまいます。常に新しいマーケットを開拓していくには、技術を積み上げていく必要があります。

今回は論文の視点でまとめましたが、これ以外にもIPA/SECなどへの協力や出版、あるいは大学との共同研究、人的交流なども考えられます。私たちが技術を積み上げる事で、新しい未来を切り開く事ができると思います。

最後に、スタートレック・ヴォイジャーのトレス中尉が言った、私の大好きな言葉を書いておきます。

「栄光を築くのは戦士かもしれないけど、社会を築くのはエンジニアよ」

[#TiDD] 「もしも」のための環境構築

ソフトウェア開発では「もしも」を常に考えないといけません。

予定通りに物事が運ぶなら、どんなやり方だってうまくいくでしょう。良くある「もしも」は、変更、障害、修正ミス、情報の錯綜、デプロイミスなどです。これらは人間が覚えていられる範囲であれば、古典的な方法でも可能でした。

しかし、一定量を超えると大変な事になります。管理がうまくできない事で、問題がさらに悪化します。人の投入で解決するなら、それぞれにを担当を割り当てることになります。さて、当初の見積もりにその工数は入っていたのでしょうか?

Redmineやtracなどのチケットシステム、バージョン管理ツール、wiki、CIツールなどを用いることは、「もしも」の保険の一つになります。ツールが人の能力を拡大するからです。

紙ベースの管理やファイル共有など、今までのやり方を変えるのは抵抗があるかもしれません。しかし、改善とは過去の問題を解決して、より良い新しい文化を築き上げる事なのです。

あなたの周りに危険な「もしも」が放置されていませんか?


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

最近、技術的な議論よりも盛り上がりを期待するつぶやきが増えて、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が出て来た時には、アカデミックは置いておいて現場の人間でコミュニティを作って知見を貯めようとする動きがありました。

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

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

« 2013年3月 | トップページ | 2013年5月 »