モテる！品質とプロセス（２）

 「Software Test & Quality Advent Calendar 2011」 へのエントリです。 

ソフトウェア開発の世界に飛び込んで数年の「こんな仕事のやり方で大丈夫かな？」と、少し疑問に思い始めた若手に送るキーワード。ブレークスルーのキッカケをつかんで欲しいデス。

今回のキーワードは「プロセス」

 

---

 

ソフトウェア開発とはなにか？

若手エンジニアにとっては所属する会社（もしくは常駐先）の「やり方」が全てであり、それがベストルールなのか悪しき慣例なのか？また、そもそも計画的なのか行き当たりばったりなのか…なんだかよくわからないことが多いかと思います。

 

でも、うまい「やり方」が出来ているかどうかは別にして、モノづくりにはかならずプロセスがあり、プロセスを経て「最終成果物＝動くプログラム」が作られるはずです。

あっ…作っても動かないときは動かないけどね（爆）

さて、普段はこんなこと意識しないと思いますがソフトウェア開発活動は、大きく２つの面から成り立っていると言えます。

ソフトウェア・サイエンスの面と、ソフトウェア・エンジニアリングの面です。

 

 

 

ソフトウェア・サイエンスの面

 

・アルゴリズム、データ構造、ソフトウェア・ロジック技術、フレームワーク技術、コーディング技術

 

ソフトウェア・エンジニアリングの面

 

・開発戦略、品質管理、プロセス管理技術、リスク管理、コスト管理、スケジュール管理、要求開発技術、設計技術、テスト技術

 

  

ソフトウェア・サイエンスとソフトウェア・エンジニアリングの２つが両立して、初めてソフトウェア開発が成功すると言っても過言ではありません。

 

では、この２つの違いはなんでしょう。

 

 

ソフトウェア・サイエンス

 

・動作の速い、コンパクトなコーディングをする

・拡張性に富んだ斬新なアークテクチャの考案

・効率の良いDB検索ロジックの開発

…etc

 

このようにソフトウェア・サイエンスは、ソフトウェア開発作業に直接的に関係するので分かりやすい部分です。テクニックが身に付き始めた若手エンジニアが得意になってくる部分です(笑)

 

他方、ソフトウェア・エンジニアリングは

 

 

ソフトウェア・エンジニアリング

 

・開発手順、開発方法論、ソフトウェアプロセス、ソフトウェアの品質保証、ソフトウェアの構成管理、ソフトウェアメトリクス、部品化と再利用、プロジェクトマネジメント、開発ツール、ピープルウェア…etc

 

 

こういった、過去のソフトウェア開発経験から生まれた理論、技法、考え方を体系化したものです。良いソフトウェアを生み出してきた経験則からのベストプラクティスとも言えます。

経験がまだ浅い若手には知識が少なく、苦手な部分と言えるでしょう。

 

このソフトウェア・エンジニアリングの重要な要素のひとつに、プロセスがあるのです。

さて、最近の若手エンジニアは、プロセスと聞いて何を思い浮かべるのでしょう？

 

まず「アジャイル」でしょうか。今回の 「Software Test & Quality Advent Calendar 2011」でも「アジャイル」というキーワードを含むエントリがたくさん見受けられます。またその対局として語られる「ウォーターフォール」。古くて誰でも知っていてもっぱら悪者扱いされることが多いのに、現場によっては未だ現役バリバリだったりするこのプロセス。

最近は「非」とか付けられて語られることがあり、ちょっと可哀想…(笑)

その他にも、

 

 

CMM、CMMI

→米国、カーネギーメロン大学にあるSEI ( Software Engineering Institute )で研究・開発されている開発Process モデル

 

アジャイルプロセス（XP、クリスタル、スクラム、FDD、リーン、etc…)

→良いものを手早く無駄なく作る。ケント・ベック氏提唱のXP、ジェフ･サザーランド博士たちのスクラムが有名

 

Unified Process (派生にRUP)

→スリー・アミーゴの中でも、特にヤコブソンが提唱したUMLを用いた汎用開発プロセス

 

TSP、PSP

→SEIで研究・開発されている、チーム、個人レベルでの開発プロセス。「ポストモーテム」というプラクティスが有名。（PSPはゲーム機じゃないよ） 

 

 

これは、ほんの一例ね。

「ツールとセット売り」とか「コンサルティングとセット売り」のプロセスを含めると、もっともっとた～くさんあります…ここでは、これらひとつひとつを解説するつもりはありません。

 

若手エンジニア諸君には「えー！プロセスってこんなに種類あるんだぁー！」と認識してくれればそれで良いです。

まずは、これだけの多種多様のプロセスが提唱されている「現実」を認識しましょう。

そして、どのプロセスが優秀でどのプロセスが劣るといった、単純な比較でプロセスを捉えないようにしてください。

賛同者が多い、少ないのような一元的比較や、流行っているから…といった捉え方も微妙です。なぜなら、特定のプロセス教育を生業とするコンサルタント業者などの戦略かもしれないからです。（どんな業界でもこういった話しはありますよね）

 

むしろ、これだけのプロセスがあるということは、それだけ多種多様なソフトウェア開発現場がある…と理解すべきでしょう。そして、それぞれのプロセスは日々の改善を前提にしなければ上手くまわりません。

少なくとも「ウォーターフォール＝悪！」みたいな見方は、自信の視野を狭くすると思いますよ(￣ー￣)ﾆﾔﾘ

正解は一つではない。

勉強してください。ソフトウェア品質向上への手がかりが、たくさんあります。

そして、本質を見極める目を養ってください。

 

では、後日また別のキーワードを紹介したいと想います。

モテる！品質とプロセス（１）

 「Software Test & Quality Advent Calendar 2011」 への 12月6日 エントリです。 

ソフトウェア開発の世界に飛び込んで数年の「こんな仕事のやり方で大丈夫かな？」と、少し疑問に思い始めた若手に送るキーワード。ブレークスルーのキッカケをつかんで欲しいデス。

今回のキーワードは「品質モデル」

 

---

 

品質とは何か

ソフトの世界にいると「品質は良いのは当たり前」、「バグはゼロに！」といったことがよく口にされます。
でも、品質が『よい』『わるい』と言うけれど、それはいったい、なにとくらべて、どれくらい良いことをいうのでしょう？

「日本車は品質が良い」というのは世界的に認められていることですが、具体的に挙げると

 

 

故障しにくい

デザインがいい
低燃費
衝突しても壊れにくい

 

などでしょうか。
実はこれらは「比べられる」という点に気がついてますか？

 

 

故障しにくい
→ メーカーは「無償」保障期間で品質を担保。1年間だったり、3年間だったり

デザインがいい
→ 決められたサイズ内の居住空間などを計測できるので比べられる

低燃費
→ 達成目標が明確化されている。リッター○○キロ走る！

衝突しても壊れにくい
→ 耐久性が数値化されている。時速○○Kmでの衝撃吸収率とか。

 

こうやってみると「品質」というのは何らかの指標で「比較可能」であることに気付けます。

ところが、なぜかソフトウェアの開発になると、上記のような指標が曖昧なまま品質が語られてしまいます。
ソフトウェアに求められる品質が「開発者」に正しく伝わらないと、まったく製品価値がないものを世に送り出すことになりかねません。
 
例えば、機能ばかりに着目しがちなエンジニアはこんな事を想います・・・

 

ソフトウェア開発エンジニアのAさん：
　「この処理、多少時間がかかるけど、精密な結果をだすためには仕方がないよな」

商品企画部でプロダクトリーダーのBさん：
　「なんだよ、これ時間がかかるなぁ…でもこの結果がでるなら我慢できるかな。」

 

こんな想いを経て、どうにか世に出たソフトウェアが、

 

 

エンドユーザのCさん：
　　「・・・はぁ？なにこれ、処理にこんなに時間がかかるのｗｗｗｗ 使ってらんね、別のソフトを買おう♪」

 

 ソフトウェアは完成し、リリースも出来たのに、いつの間にか「製品価値」を失っていたようです。悲しいかな、このようなケースはすごく沢山ある気がしてます。

ところで、ソフトウェアの品質は表現不可能なのでしょうか？
冒頭の例では、車に於ける品質は、なんらかの指標で比べられるという話をしました。

 

そう、「品質」は定義（仕様化）することが出来るのです。…ピンと来ないかもしれませんが「品質モデル」という考え方があります。これは先人の知恵の結晶、品質を定義するためのモデルです。しかも国際標準。

 

 

国際標準規格
『ISO/IEC9126-1:2001 ソフトウェア製品の品質－第1部：品質モデル』

 

 

これ、今まで聞いたことあります？
となりの先輩知ってます？
会社で教わったことあります？

無いというあなた。

 

本来はここで中身について解説すべきところですが、すでにインターネット上にはたくさんの解説があります。

書籍もたくさん出ています。 

ありがたいことです。 

なので、ぜひ自分で調べてみてください。

検索キーワードは

• 　ソフトウェア品質モデル
• 　ソフトウェア品質特性
• 　ISO/IEC 9126-1:2001
• 　JIS X 0129-1

です。

 

ソフトウェア品質向上への手がかりが、たくさんありますよ。

勉強してくださいね☆

では、後日また別のキーワードを紹介したいと想います。 

Twitterのイベント活用。無料でどこまでできるのか？の考察（その１）

去る2010年6月18日、横浜市開港記念会館で「派生開発カンファレンス2010」というイベントが開催されました。このイベントで広報を担当させて頂き、その際「Twitterのイベント活用」にチャレンジしてみましたのでそのことを書いてみます。
※今回は、個人的に参加していた運営側のお話しです。

今年の2月、株式会社システムクリエイツの清水吉男さんに「派生開発推進協議会とカンファレンス開催を同時立上げするんだけど手伝ってもらえない？」とお誘いを受けました。清水さんは、派生開発プロセスであるXDDPや要求仕様表記法のひとつUSDMの提唱者で、以下のような著書をお持ちの方です。（一匹狼のコンサルタントですｗ）

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

• 作者: 清水 吉男
• 出版社/メーカー: 技術評論社
• 発売日: 2010/05/01
• メディア: 単行本（ソフトカバー）

世間のXDDP導入動向などを知りたかったこともあり、二つ返事でお手伝いを引き受けました。

■アンケートは採らない

程なくしてカンファレンスの準備活動が開始されたわけですが、初期段階で決まった方針のひとつに「終了後のアンケートを採らない」というのがありました。普通なんらかのイベントを開催したらアンケートって採りますよね。でも、やらないことに決めたのです。

理由は大きく２つ。

一つは、スタッフ全員ボランティア。何百人と来て下さるほど作業は大変になりアンケートを集計する余力がない状態。

二つ目は、アンケートという手段そのもの問題。偏った回答を誘導させず、かつ混乱させない質問を考えるのはけっこう至難の業です。専門の業者に頼めるわけでもありませんし、メトリクス収集目的があったわけではないのでアンケートは早々にやらないこととしました。

…しかし、準備が進むにつれ私にはひとつの懸念がふつふつと。それは「カンファレンス参加者からの感想とか聞きたくない？」ということでした。アンケート集計の煩わしさは避けたい。でも、参加者の感想とか運営者への要望とか、そういったフィードバックを得ることは必要だよね？
こう考えて、なんか方法ないかな？…と一人悶々としていたなかで思いついたのがTwitterの活用でした。思いついたなんて書くと大げさなんですけど、今やあらゆるカンファレンスがUstされる時代。Twitterに行く付くのは自然の流れ。ただ何事もそうですが、とりあえずやってみるまえにきちんとした段取りがあってこそ効果も出るはず。といったわけで、事前に作戦計画を立てました。

まず、私の中にはひとつの活用モデルケースがありました。

Twitterをなんとなく登録してからしばらく放置だった私ですが、あるきっかけで仕事に使える可能性を追うようになります。この研究成果は別の機会に書きたいと思いますが、とにかく、ビジネスでの有用性を確信しはじめた頃に、あるイベントに参加しました。それは2010年2月23,24日にわたって開催された、マイクロソフトさんの「Microsoft Tech・Days 2010」というイベントです。このイベントに出展者として参加していたのですが、その際のTwitter利用が秀逸だったため、今回はそれをかなり参考にさせて頂いてます。

また、さらに知見を広める為に、

ツイッター 会社と仕事はこう変わる (日経BPムック)

• 作者: 日経ビジネス
• 出版社/メーカー: 日経BP社
• 発売日: 2010/04/01
• メディア: ムック

を、買って隅から隅まで読んでみたり、第4回DIALOGHOUSE というイベントに赴き、マイクロソフトのソーシャルメディアリード熊村剛輔さん（先のTech・Days でも裏方であったお方）のお話しを拝聴しに言ったりと、いろんな情報収集を経て作戦計画を練りました。

作戦の流れは、以下のとおり

1. 公式ハッシュタグを作る。
2. ハッシュタグ用の分析サーバーを用意する
3. 身内を巻き込む。
4. 公式ハッシュタグを告知する。広める。
5. 世間様のツイートに反応する。 
6. Twitterとクチコミデータを分析し、weeklyでカンファレンス準備委員会へレポート
7. カンファレンス本番を迎える。感想をツイートして頂くようお願いする。
8. カンファレンスに関するツイートのまとめページを用意する。
9. 総括する。←いまここ

といったわけで、次から具体的にどんな事をやったのかを書いていきたいと思います。

■公式ハッシュタグを決める

Twitterを広報的に使おうとしたときに、大きく２つの方法が考えられます。

ひとつは「公式アカウント」を用意する方法。もうひとつは「公式ハッシュタグ」を用意する方法です。本イベントは一過性のもの（終わりが来る）ことから、「公式アカウント」はやめて「公式ハッシュタグ」を活用することにしました。

まず今回のイベント用にハッシュタグを決めこれを運営側としての「公式」と認定しました。
認定というとおこがましいですが、要は「早々に宣言してしまう」という事です。ハッシュタグはTwitterの公式機能ではありますが「登録」という作業が必要なわけではありません。# の後に任意の文字列を添えれば、それがハッシュタグとなります。このお手軽さが逆に、同じトピックに対して複数ハッシュタグが乱立することに繋がってしまいます。

たとえば、今開催中のワールドカップでは、

#worldcup
#2010wc
#wc2010
…

のように色々乱立してしまうわけですね。こうなっちゃうと、せっかく同じワールドカップの話をしているのに別々の大部屋（ハッシュタグ）で話してる状況です。ただの文字列ですので乱立するハッシュタグすべてを書くという手もありますがそれだと140文字をタグだけで食いつぶしてしまうことに。
そこで、なるべく短く意味が分かりやすく（＝覚えやすい）、かつ他のトピックと意味が重ならない（←これ重要）ハッシュタグを考えて、これをできる限り流布させることが重要となります。そこで、カンファレンスのテーマのひとつ、派生開発プロセスのことをXDDPと呼んでいるのでこれを利用することにしました。

#xddp2010

"xddp2010"が他の何かに使われていないかは検索すればすぐにわかります。
次にこれを「公式」へと昇降させる作業をしました。

まず、カンファレンスの案内ページとメールの案内文（ CFP:Call for Participation）に

---

  ◆Twitter 公式タグのお知らせ
     派生開発カンファレンス2010ではTwitterを活用しています。
     公式タグは #xddp2010 です

---

という一文を追加。これで公式っぽさをかもしだします(笑)

次に、決めた #xddp2010 に対して「おれたちのハッシュタグだぜ」的なけん制をしておきます。文言的に他のトピックと重複するとは思えませんでしたが、カンファレンス専用として利用できるように念のためのリスクヘッジです。

私は次の二つのサイトに登録作業を行いました。

hashtagsjp

http://hashtagsjp.appspot.com/tag/xddp2010

hashtagsjpは任意のハッシュタグを登録することで、タグ付きのツイート数、ツイートしたひとの一覧、ツイートに含まれるリンク一覧を得ることができます。イベント終了後に分析データを自動で集めてくれる便利なサイトです。これを使わない手はありません。

ハッシュクラウド

http://hashtagcloud.net/cgi_info?name=xddp2010

ハッシュクラウドはhashtagsjpと似ていますが、ツイートのログがダウンロード可能です。

これで、ハッシュタグの利用宣言と後の分析データー収集という一石二鳥の作業が完了です。

■ツイートを監視する

さて、ここまで準備できたらハッシュタグの監視を開始します。つまり、カンファレンスに関するツイートをキャッチアップするのです。カンファレンスへの質問があったり、期待があったり、意見があったり。そんなツイートを見かけたらコメントを返したり、運営チームへフィードバックをしたり、その人自身をフォローして仲良くなってみたり。

これぞ、Twitterの醍醐味。 

監視といっても、四六時中ガン見するという意味ではありません。私だって普段は仕事がある身。如何に効率よくツイートを拾うかは、多少のテクニックが伴います。ここからが、デキるオトコのTwitterか、ただの遊びのTwitterかの分かれ道です

ところで、ハッシュタグって実は致命的な欠点があるんです。それは、ハッシュタグのグランドルール

ハッシュタグの前後にはツイート文と区別するために半角スペースを入れる
ただし→文頭になるときは、前の空白はいらない
　　　　→文末になるときは、後の空白はいらない

の問題。

この半角スペースルール、みなさん、意外と忘れちゃうんですよね…半角スペースを忘れちゃうと、それハッシュタグにあらず。つまり、検索にひっかからないわけで、せっかくそのトピックについてツイートしたのに、どこかに埋もれてしまう…

そこで、検索にはコツがあります。それは「ハッシュ」を無視すること。…めちゃめちゃ矛盾したことを急に言い出したと思われるかもしれませんが、重要なポイントです。

ハッシュとは「#」のこと。Twitterにおけるハッシュタグの利点は、それ自体がリンクとなってくれること。たとえば、このページをみてください。「#xddp2010」の部分の色が変わっていて、リンクになっていることがわかります。

http://twitter.com/Taka_bow/status/13717128137

そしてクリックすると、Twitterの公式検索ページに飛ぶだけ。つまりハッシュタグの利点は指定した文言を最短でリアルタイム検索出来るようになるってだけなんですね。

ですから、半角スペースをつけわすれた人を救済して検索するのであれば、「#」を除いた「xddp2010」で手動で検索すればよいってだけと考えることができます。

今回は、広く「派生開発」についてツイートしている方とコミュニケーションがとれると良いなと思い、次の文言をリアルタイム検索することにしました。

#xddp2010 ⇒ 公式ハッシュタグ
xddp          ⇒ ハッシュタグを付けたつもりのツイート救済
派生開発      ⇒ 派生開発についてのツイート

私は普段Twitterを読むとき、PCならTweetDeckやHootSuite、iPhoneなら同じくTweetDeckやEchofonを利用しています。これらの専用アプリは、用途毎にTL(タイムライン）別の表示を作れるのが特徴です。

※クリックすると拡大します

ハッシュタグの監視とは、こういった専用アプリを利用して、指定の文言だけのTLを作成するという意味になります。こうしておけば、あとはツイートが逃げることはありませんので時々読めばよいわけです。

…この時はそう思っていました。そのハズでした。

しかし…このあと、皆さんもご存じのように日増しにTwitterサーバーが不安定になっていきます。私は、当初の計画とは違う対応をとって行かざるをえないことになります…

（つづく）

陰陽道プロジェクト・マネジメント

今日は、私の研究テーマである「陰陽道プロジェクト・マネジメント」とはいったい何か？について説明してみたいと思います。

初めにお断りしておきますが、私が取組もうとしている研究は本物の「陰陽道」や宗教のことではありません。「プロジェクト・マネジメント」の本質を見極め、そこに「陰陽道」の技術や思想を取り込み、米国的な手法や思想とは違う、より良き日本的なプロマネ手法を体系にまとめてみようという試みの為の研究です。

さて・・・先日、鎌倉の鶴岡八幡宮からダイレクトメールが届きました。
なんだろう？またお布施の依頼かなぁ？なんて思いながら開けてみたら「厄払いしませんか？」のお知らせ。

そう。私は今年、前厄らしい。
（こう書くと歳がバレてしまうが華麗にスルー。加齢にスルーではない）

ところで「厄年」って何だろうって思いませんか？

いや、それなりに意味は分かっているつもりです。
昔から凶事や災難に遭う率が高い歳と言われ、おとなしくビクビク過ごす3年間。
お祓いによってそれらをなるべく遠ざけようとする行事を「厄払い」と言い、老若男女、多くの方がお祓いをしてもらうのではないでしょうか？

「厄年」を“風習”と片付けてしまえばそれまですが、ここまで日本国民に忌み嫌われる風習って、なんかスゴいなぁと他人事のように思ってしまいます。
そう言いながらも私自身、何らかの見えない力への恐れは否めません。実際、正月に三島大社で厄除けのお守りを頂いてみたりしてｗ

でもね？
この「厄年」に対して、子供の頃からのひとつの疑問がありました。
それは、どうして「厄払い」って「神社」も「お寺」もどっちでもやるの？という点です。

「神社」で花祭り（灌仏会）はしません。
「お寺」で二拝二拍手一拝などの柏手は打ちません。

なのに、厄払いはどちらでも受け付け、厄年の定義も一緒。

起源の違う宗教が、どちらにも「厄年」という概念をもっている点にすごく違和感があり、それはキリスト教徒でもないのにクリスマスを祝う日本人…なんて話とは別の、何か滑稽さ曖昧さを含む奇妙さ…何か日本の原点を発見したような気さえしていました。

そして大人になった今。それは少しずつではあるが分かってきたことがあります。

そもそも「厄年」とは、陰陽道がルーツであるらしいこと。
七五三や、雛祭りなどの現代においても行われる“風習”のいくつかも、やはり陰陽道の儀式がルーツであるらしいこと。
陰陽道とは中国の陰陽五行説を起源として、日本で独自の発展を遂げた自然科学と呪術の体系であること。

…などなど。
一番驚くべきは、陰陽道が確立したであろう7世紀後半あたりで決めた行事（呪術）が、形は変わっていったのかもしれないが現代まで引き継がれている点です。

これは凄い。

この事に気付いた時、一見なんの関係もなさそうな「陰陽道」と、いま専門家として取組んでいる「プロジェクト・マネジメント」が強烈に惹かれあうイメージが、私の頭のなかで閃いたのです。

これは大袈裟に言えば、PMBOKを凌駕しする、良い意味で日本的なプロジェクト・マネジメント手法を見出すことが出来るのではないか？という予感がしているのです。

もうちょっと具体例を言うと、

　「プロジェクト・キックオフ」を「地鎮祭」レベルにまで昇華させる

なんてことも出来るのではないかと。

次回は、もう少し具体的な話を。（つづく）

Happy New Year 2010 !

あけましておめでとうございます！

封印・・・していたわけではないですが、やめてたブログを再開します！
最近は仕事文章ばっかで、自由な文章とかおもしろい文章を書いてないなーと反省しまして。つまんないオトナになりたくないしぃ～
（誰？十分オトナじゃんって言ったひと！）

さて今年はどんな年になるでしょうねー。
・・・違うなー。どんな年にしようかな！（の、ほうがポジティブやね）

去年は不景気でした。この状況、まだ続くでしょうね。
ソフトウェア開発の仕事をしてますけど、じわりじわりとコストが安い海外に仕事が取られています。さらに不景気が追い打ちをかけるようにこの傾向を加速させてます。

この状況を放っておいたら日本でソフトウェアに関わる人たちは、近代史における「炭鉱労働者」のような顛末を辿ってしまうかもしれません。他の知識労働者に比べたら、ソフトウェア開発者の賃金レベルはもっと高くていいはず！
なのに？お給料は下がる一方、仕事は海外へ流れ・・・

なんとかしたーい！

今年は、この「なんとかしたい」を具体的なアクションに繋げていきます。
日本のソフトウェア産業を元気にしたいと思っています！

今年も宜しくお願いします。