はてなダイアリーにSoundCloudを埋め込む方法(暫定案)

2011年4月7日現在、はてなダイアリーにはSoundcloudが埋め込みできないようです。(埋め込み用コードを貼っても、コードがテキストとして表示されてしまう)

はてなダイアリーに Flash を埋め込むガジェット - てっく煮ブログ を使えばできます。

1. Soundcloudで貼り付けられたオーディオのShareボタンを押して、埋め込みコードを得る。
2. 得た埋め込みコードの中から

   http://player.soundcloud.com/player.swf?

   で始まるURLをコピーする。
3. Add Gadget to Your Webpage のURLフォームにコピーしたURLを貼り付ける
4. タイトルをつけて、色やサイズをお好みにして…
5. 「コードを取得」ボタンを押して出てくるコードを、はてなダイアリーに貼る。

のようになります。感謝感謝。

目指す品質の共有(気持ちよく仕事をして良い結果を出すために)

自己紹介

こんにちは！Mass Kanekoです。国内メーカーで働いたり飲んだくれたりする傍らで、時々思い出したように曲を作ったりDJをしています。今度の4/23(土曜日)は15:00〜21:00、東京・早稲田の茶箱にてパーティを開催します。
eYecandy

たとえばこんな曲を作ったり。

「そんな自己紹介で本当にIT業界の人なのか…」

そうなんです。ITと言っても色々ありますが、私は特定用途の特別に作られたハードウェアの上で動くソフトウェアを開発する職…組込みソフトウェアエンジニアです。身の回りにある製品はソフトウェアが入っているものばかりです。「あのビルのエレベーター、いつも来るの遅いのよね。」それはソフトウェアのせいかもしれません。「こないだ買った楽器、音いいんだよねー」それはソフトウェアの力かもしれません。私の設計したソフトウェアも、ひょっとしたら皆さんの近くで動いているかもしれません。そんな職について、そろそろ4年経ちます。

新卒準備カレンダー2011春です
さて、この記事は 新卒準備カレンダー 2011春 : ATND という、この春に新しくIT業界へ進んだ方々のために、ブログをリレーしていくという企画です。私の1つ前はbash0C7さんによる 現実へと流されない - koeだめ でした。私もこれまでに書かれた記事を読んで、よい刺激を受けています。このはてなダイアリーも全然使っていなかったのですが、これを機会にちょっとしたことでも開発のことをアウトプットしていこうと思います。では本題。

品質って？
システムを考える上で一番大事なのはユーザに提供する価値…なのはもちろんですが、今回はその価値を実現するシステムの出来について考えてみたいと思います。出来、つまり品質です。システムに関わるなら必ず品質に関わります。システムの品質って何かと考えると、ユーザーにとって欲しい品質と開発者にとって欲しい品質に分けられます。まずはユーザー視点。

高い品質	低い品質
アプリを沢山立ち上げても重くならない	段々もっさりしてきて終いには落ちる
キャッシュカードを表裏逆に入れちゃったけど読んでくれた	出てこなくなっちゃった…
何日動かし続けても安定してる	放っておいたらいつの間にか再起動してた
深刻なエラーが起きても自動で復旧！	電源入れなおさないとダメ

次に、開発者視点。

高い品質	低い品質
バグの原因が突き止めやすい	何が原因か調べるのに時間がかかる
どう変更すればよいかわかりやすい	どう変更すればよいか決めるのに時間がかかる
変更しても影響範囲が限定される	想定外の場所に飛び火して不具合が出る
テストコードの網羅性が良い	テストコードが無いor信用できない

ここで挙げたユーザー視点での品質は信頼性、開発者視点での品質は保守性と呼ばれます。他にも○○性というのはありますが、今回はこれら2つにスポットを当てます。

品質を上げるのは手間がかかる
(信頼性)どんな状況でも規定の動作あるいは安全な動作をする設計とするためには、色々なケースを考えないといけないです。設計上起こり得ないと考えられるケースがあったときにもユーザへの不利益を最小にする設計が必要になります。また、そのような設計としなかったために起きた問題は低頻度であり、解決するのには更にコストがかかります。

(保守性)後々で見直して、わかりやすい、変えやすい設計とするためには、アーキテクチャを良く考える必要があります。大きなまとまりの構造、小さなまとまりの構造、それらの関係を良く考えます。ここは差が出ますし、さぼると後々大変です。アーキテクチャに無頓着に作った設計を後からわかりやすい設計にするのには更に大きなコストがかかります。

「1000回に1回動かない」「1年に1回くらい落ちる」程度なのは良いのか？
信頼性はどのくらいを目指せばよいのでしょうか。

例えば携帯音楽プレーヤーを使っていたとします。買ってから1年間、故障はしていません。ある日いつものように曲を聴いていると曲名が「●×☆※▲」なんて文字化けしてました。しばらく放っておいたら「system error」と表示されました。「故障かなあ」と電源を入れなおしたら何事も無かったかのように正常動作しました。「何だったんだろう？」と思いつつも「まぁいいか」で済ませる人もいるでしょう。後々、そのメーカーの品を避けるようになるかもしれませんが、いずれにしても携帯音楽プレーヤーがごく稀に動かなくなる程度の問題です。

でもそんな程度では全く以ってダメなシステムというのは沢山あります。「1000回に1回動かない」「1年に1回くらい落ちる」程度だと…

• メガバンクの預金管理システムダウン。引き落とし不能！
• 証券取引で誤発注を取り消したが動作せず約定。取引所に多額の損害賠償請求！
• 手術中に医療機器が誤った血圧を表示。投薬の判断が遅れ、患者が死亡！
• ブレーキが効かずに自動車事故多発！
• 超有名アーティスト観客10万人のライブ。最後にキメのフレーズが…鳴らない！

これらのシステムに必要な高い品質とするためにはコストがかかります。慎重に設計し、入念にテストしないといけません。しかし、あまりにも時間をかけていたら商売のチャンスを逃してしまいます。システムが提供する新しい価値の内容によっては、少々のバグは問題にならないこともあるでしょう。後々でアップデートできることが大きな条件だと思います。

• 東京電力の需給がわかるアプリができました！
• 新作ネットゲーム βテスト開始！
• 画期的なライフスタイルを提案するネットガジェット新発売！

きたないけど、まともに動いている。放っておいて良いのか？
1000行のメソッド、10000行のクラス達、依存関係は無茶苦茶、コメントは嘘ばっかり。「あらまー」と思うようなコードに出会うかもしれません。でも、保守性は開発者にとっての品質です。ユーザーにとっては、システムで目的が満たされることが重要であって、それがどう設計されているかはどうでも良いことです。今の時点でまともに動いているのであればユーザにとっては全く問題ないです。うかつに手を出すとバグが出そうです。とはいえ、そのままで良いのでしょうか。

あえて、放っておいてもよい場合から考えてみます。以下3つを全て満たした場合は、きたない設計のままでよいと思います。

• この先、新しい機能を追加する必要がない
• 稀に不具合が起きても再稼動すればよい
• このシステムを母体とした派生開発をしない

しかし実際そのようなケースは少ないでしょう。いざ「新しい機能を追加する必要がある」「不具合が出たら修正しなくてはならない」「このシステムを母体として派生開発をする」となったときに困るのは開発者です。保守性は今の開発者のための品質ですが、未来の信頼性に直接影響します。つまり、良くない設計のまま機能追加や不具合修正を行うと新たに不具合を作りこみやすく、派生システムの信頼性が落ちるということです。

保守性が低いと結局後々でユーザーも困る可能性が高くなります。保守性を高めるために設計を見直すのは信頼性を失うリスクがありますが、両者はトレードオフの関係ではありません。保守性を高めることを常に意識していれば後から信頼性を確保し、両方を高めることができます。

目指す品質をチームで共有しましょう
ここまでで保守性と信頼性について簡単に説明しました。どの程度の品質を目指すかはシステムそれぞれです。目指す品質をチームで共有しておくことは、仕事の優先順位感を共有することに繋がります。

必要な信頼性はターゲットとするユーザーとシステムの用途によります。そこそこの信頼性を確保して一早く新たな価値を届けるべきならば、一定以下の小さな問題は放っておいて、早く価値を実現することに全力を注ぐ。「一定以下の問題」ってどの程度の問題か、共有できていれば早く決断して次に進めます。信頼性を十二分に確保すべきならば、レアケースも考えて、ドキュメントをしっかり書いて、他の人とレビューし、あやふやな箇所・欠陥を叩き潰します。「十二分」とはどの程度か、プロセスを守ることか、信頼性カーブがいい形になったらか。共有できていれば「これでリリースできます！」と言える。

保守性がどれほど必要かは、そのシステムが将来にわたってどれだけ変更されてゆくかによります。ベーシックモデルからエントリーモデル、ハイエンドモデルのラインナップを作ったり、日本向けに作っていたシステムを、中国向け、インド向けにローカライズしたりと枝分かれしてゆくならば…「気持ちよく開発できるように設計しましょう。それが未来のエンドユーザのための信頼性に繋がります。」のように共有できれば良いですね。

保守性は開発者が気持ちよく仕事をするための品質でもあり、その仕事によって作られたシステムの信頼性に影響する重要な品質です。私は保守性を意識しているチームは良いチームだと思いますが、システム用途によっては保守性向上(設計改善)のリスク＞リターンとされる場合もあると思います。その場合、なぜそう見積もられているのか聞いてみるのが良いと思います。

もしかすると、これらについて共有するのは簡単ではないかもしれません。「このバグは直さなくても良いですよね？」「いや、直すべきです。」とか「リファクタリングしましょう」「いや、変更量が大きいからダメです。」などと意見が合わないことが考えられます。しかし気持ちよく仕事をして、かつユーザーのためのシステムを提供するには重要なことだと思います。納得しないままでいるとストレスになりますので、時間をかけてでもお話をすることをすすめます。

• 迷わずスピーディになるために
• 気持ちよく開発するために
• 未来のエンドユーザのために

目指す品質を共有することが必要だと思います。

おすすめの本
学習がなぜ重要か、学習する組織になるためにはが書いてある現実的な本です。

ソフトウェア開発を変革する ?もっと俊敏になるために?

レガシーコードにどう対処すれば良いかが書いてある現実的な本です。

レガシーコード改善ガイド (Object Oriented SELECTION)

次の方

ta2(たた)/Shota Kubotaさん Twitter です。
"仕事"をしてみる - input*output
リレーは続きます。

Sphinxを使ってみた

仕事でちょっとした学生実験以上・学士論文未満程度のリサーチをやっていて、文書にまとめる機会があったので、前からちょっと気になっていたSphinxを使ってみました。Sphinxというのは、reStructedTextという形式で書かれたテキストファイルを、HTMLを始めとした複数の形式に変換できるというもの。実行にはPythonが必要です。

404 Not Found
reStructuredText

なんだかよくわからなくても上記Sphinx-Users.jpの「Sphinxをはじめよう」に従うだけで大丈夫です。例えばカレーの作り方のドキュメントを作るとして、

カレーの作り方
================

今明かされるMass Kaneko式カレーのレシピ！

.. image:: curry.jpg

材料
----------------

* とりにく
* かぼちゃ
* にんじん
* モロヘイヤ
* カシミールカレーパウダー
* ココナッツミルク
* ナンプラー

作ってみよう
----------------

まずはとりにくに塩をすりこみます。 **入れすぎに注意！**

みたいにテキストファイルを書いて、

$ make html

とすると、書いたテキストの内容が見栄えのいいHTMLになる…という具合です。どんな見た目かは 404 Not Found が参考になるでしょう。

SphinxはPythonというソフトウェア開発の世界で生まれたものですが、「階層構造の、ある程度大きい、ハイパーリンクのあるドキュメント」という場合にはうってつけで、ソフトウェア開発に限らず、ドキュメントを書く分野では使えますね。

また、reStructedTextはテキストファイルです。単なるテキストとしても文書構造がわかります。つまり…Subversionなどのバージョン管理システムで差分管理がやりやすい。変更前後で何が変わったのか、誰が変えたのかを簡単に管理することができます。(カレーの例で言えば、誰かがうっかりナンプラーをおたふくソースに書き換えてしまっても、すぐにわかります。)

今私が仕事で書いているレポートにも向いていそうです。しばらく使ってみることにします。

被害の無い関東民向け：東北地震に関する勝手な自己アンケート

地震や津波による物理被害の無い関東民向け…と勝手に思って自己アンケートやってみました。質問と回答を並べればスタンスがわかるかなと思って、ずらずらいきます。

●住所と勤務先の地域を教えて下さい
埼玉県南部

●地震が起きたとき、何をしていましたか？
会社で仕事してました。大きい揺れなので机の下にもぐったら、上から機材が落ちてきました。もぐってみるものですね。

●帰宅難民になりましたか？
いいえ。いつもJRで通勤していますが、3/11はJR運休という情報が早かったので歩いて帰りました。2時間半くらい。

●地震発生から10日経ちました。どのように生活していますか？
計画停電で勤務時間が2/3くらいになりました。また、飲食店に行く人が減ったようです。つまり普段なかなか入れない店に入るチャンスと思い、外食が増えました。ちんたら生きてます。

●あなたの接するメディア、情報源について教えて下さい
ウェブのみ。テレビ、新聞はなし。
NHK Ustreamが大本営発表を見るのに役立った。Twitterは個人間の連絡, 状況確認に役立った。@nhk_seikatsu @team_nakagawa 等、一部のアカウントからは有益な情報が得られた。反面、デマのRTが多い弊害も見られた。その他、原子力発電、放射性物質、放射線の人体への影響について調べるようになった。

●地震が起きてから新しく買ったものはありますか？
・携帯用LEDライト
もともと懐中電灯は持っていたのですが、いつも持ち歩けるように、サイズの小さい物を買いました。

・エネループ
携帯電話の電池の持ちが悪いので、これを機会に買いました。

●食料や日用品などを買い占めましたか？
いいえ

●福島原発事故で東京近郊の人は避難した方が良いと思いますか？
思わない

●原子力発電はやめたほうがいいと思いますか？
思わない

●福島県産ほうれん草を食べたくないと思いますか？
思わない

●地震のドサクサで金融商品取引で大もうけした人は不謹慎だと思いますか？
思わない

●今回の震災から復興するために、あなたは何が貢献できると思いますか？
募金、節電、献血
仕事してお金使って経済を回す

●復興できると思いますか？
もちろん！

組み込みってそんなに表舞台に出てないものなの？

もちろん製品としては生活のあらゆる場面に溶け込んでいて、無くてはならないものとなっています。ただ、組み込みの情報はネット上にあまり無いだとか、同じソフトウェアエンジニアでもWEB系やエンタープライズ系と比べて日の目を見ていない、などという旨の文を目にしました。本当にそうだとさびしいのですが、ひとまずそれらの文章をまとめて現状を見てみましょう。

「組み込みソフトウェア」とは何か　〜PC系ソフトウェアとの違い〜

http://d.hatena.ne.jp/wa-ren/20081130/p2
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/wa-ren/20081130/p2
という記事があります。およそ1年前に書かれた、組み込みソフトウェアのさわりを解説したものです。あくまで内容はさわりなのですが、480人以上にブックマークされています。このブログの記事にいつもこれだけブクマがついてるわけではありません。ということは、それだけ組み込みソフトウェアというものが物珍しかったのかと思います。
業界の特徴を表しているコメントを引用します。まずエントリーについたコメントから。

• ＞逆に今いろいろと情報を出せる人は、注目される....かもしれない。

だから、機密保持契約してるので出せませんって(^^;。開発に関わっていることすら話しちゃだめな場合もある。情報なんか出したら二度と仕事はこないどころか、訴えられる可能性もある。あ、注目って、もしかして職業倫理の無さで注目されるってこと？

• しかし組み込み業界は、保守義務なんかも絡んでいるのでしょうが、やっぱり閉鎖的というか、情報が出にくいところがありますよね。巷のプログラマの勉強会でも、組み込み屋は中々おらず寂しい思いをしてい[[]]ます。

次にはてブのコメントから。

• OSコアからドライバまでかじってる俺が通りますよ｡組込は給料低いよね｡理由はいくつかあって､余りオープン化されず基本部分はある程度作らなきゃいけない､ソフトはハードの付属扱い､など｡
• 組み込みJavaアプリ書いてる俺が通りますよ。CDCなら基本はPCと変わらん感じ。ただしリソース制限が厳しい。メーカーの検証試験もある。オープンじゃないので変なことがあってもぐぐって調べられないのが困る…
• 固有名詞はともかく、OS乗ってるぜとかデバドラ書くぜとかCPUから違うぜとかまで、意外と知られて無い・・？
• 組み込み系な話を組み込み系以外の人にわかってもらう土壌はまだないってことだろうね。作っていかないといけないってことだろうね。

機密保持が重視され情報がオープンではないため、世間に浸透していないことがうかがえます。

組み込み技術を扱うメディア・団体・雑誌の開設・創刊時期

これらが新しければ "世間に浸透するのはこれから" と言えるのではないかと思って幾つか調べてみました。JASAとInterfaceが古くからあり、他は全て2000年以降。特に2005,6年あたりから増えてきているように見えます。私の感覚でも「組み込み」や「エンベデッド」という言葉を耳にし始めたのは確かに2005,6年だったように思えます。

• @IT MONOist, 2007年8月1日, http://corp.itmedia.co.jp/corp/pr/20070801.html
• EE Times Japan, 2005年1月28日, http://eetimes.jp/, http://www.impressholdings.com/info/profiles/e2p.htm
• EDN Japan, 2001年, http://www.reedbusiness.jp/products/ednj.html
• Interface, 1973年12月に創刊, Wikipedia調べ
• 組み込みプレス, 2005年10月26日, http://gihyo.jp/magazine/kumikomi/archive/2005/vol2 , ※vol.1が見つからない
• SESSAME, 2000年11月, http://www.sessame.jp/
• JASA, 昭和61年8月7日設立→2006年4月1日改称, http://www.jasa.or.jp/top/ , http://ednjapan.rbi-j.com/news/2006/4/883
• ETEC, 平成18年11月, http://www.jasa.or.jp/etec/
• エンベデッドシステムスペシャリスト試験(前身を含む), 1996年, Wikipedia調べ

Twitter 深夜のtwitter上での組み込み談義

http://www.swingingblue.net/mt/archives/002738.html
Twitterで特定の話題を話す人達が集まるのはいたって普通のことだと思うのですが、

• 組み込み系の人とネット上でコミュニケーションを取ることはほとんどないので、かなり新鮮。
• いや、ほんとに嬉しい！ET2009やら、MTM04のせいかな？RT @goyoki: @JR0BAK @findup 自分もびっくりです。 RT @findup: 今夜はなんという組み込みTL充なんだろう

と言われているのでネットでの情報交換というのは今まであまり無かったことなのかなと。そして、ほどなくしてハッシュタグ#embedded_jpができました。今はまだ発言数は多くはなくメンバーもある程度固定化されている印象です。これからどんどん増えるといいですね。

Twitter #embedded_jp にて

ET2009や#embedded_jpなどのpostを見ていて感じたことがあります。「どういう面白いものを作ってユーザーに価値を提供するか」というよりも「ある開発プロセスにおける問題をどう解決するか」という視点の展示物や発言が多いなということです。ET2009のすぐ後にMTM04というイベントがあり、そちらは主に個人が趣味で面白いものを作る趣旨があるせいか、#MTM04タグではわくわくさせられるようなpostが多かったのでついつい比較してしまいました。そのことを#embedded_jpでつぶやいてみると守秘義務の話が出てきましたので載せておきます。

	masskaneko	できれば #embedded_jp には、どういう苦労をしたというよりも、どういう面白いものを作ったってのが欲しいんだけど…苦労話もバッドノウハウもためになるし悩ましいわねえ。	2009-12-05 00:04:21
	deusx_tw	わくわくするような話がしたいと！今までの経験を振り返ってみると…orz RT @masskaneko: できれば #embedded_jp には、どういう苦労をしたというよりも、どういう面白いものを作ったってのが欲しいんだけど…苦労話もバッドノウハウもためになるし悩ましいわねえ。	2009-12-05 00:14:20
	findup	@masskaneko 何かを作ったよという話は、Confidentialな案件ばかりやってると話せないんですよね…。どうしても身近な経験談になりがちというのはあるかもしれません。 #embedded_jp	2009-12-05 00:16:27
	masskaneko	@findup 自分も雇われの身で同様なのでわかるのですが、かくいう思いはありますね。革新的なことよりも品質が要求される業界というのもあるでしょうけど。 #embedded_jp	2009-12-05 00:20:32
	masskaneko	@deusx_tw 簡単に言えばそういうことです。といってもまずお前さんが言いなさいよと言われても返せないので何なのですが。実装面の話に搾れば無難なんですけどね。傍目には何の実装かわからないから。 #embedded_jp	2009-12-05 00:22:57
	findup	下請けだと本当にその製品が公になっても話せなかったりするのがなんとも。店頭で製品を見ながら心の中で感慨にふけるくらいしかないんですよね…。 #embedded_jp	2009-12-05 00:40:47
	JR0BAK	私の場合はおそらく比較的コンシューマ向けのものが多いのだけど，それはそれで話しづらいというか… RT @masskaneko: できれば #embedded_jp には、どういう苦労をしたというよりも…(略)	2009-12-05 00:44:15
	JR0BAK	私の店頭デビュー作は L-Router でした．と，話を振ってみる．知ってる人いるかしら？ RT @findup: 店頭で製品を見ながら心の中で感慨にふけるくらいしかないんですよね…。 #embedded_jp	2009-12-05 00:45:53
	JR0BAK	と言う風に，自分の所属とか経歴とかまるわかりになっちまうので書きづらいんだよなぁ #embedded_jp	2009-12-05 01:01:41
	masskaneko	大まかに、何を作るか頑張る人達と、どう作るか頑張る人達に分けられるんでしょうか。特に大規模開発だと。 #embedded_jp	2009-12-05 01:07:15
	boonies	ふと思ったけど、何を開発してたかとか経歴が明らかになるようなことをつぶやくのって、ホントにマズイんだっけ？機密があるのは分かるんだけど。 #embedded_jp	2009-12-05 01:34:51
	JR0BAK	@boonies 少なくとも「どんな感じのものを開発した」ってぐらいはいいんじゃないかなぁ．そこまで機密にしてしまうと，職務経歴書が真っ白になってしまう人もいるんじゃないかと #embedded_jp	2009-12-05 01:47:02
	boonies	@JR0BAK ですよねー。例えば、B2Cだったらこの携帯や車に関わっていた、ぐらいはいいかなーと。B2Bは…説明が大変かなー #embedded_jp	2009-12-05 01:55:42
	JR0BAK	ただ，「誰かに打ち明ける」と「全世界に公表する」の差は大きいかと．twitter でつぶやくのは後者の方 #embedded_jp	2009-12-05 01:55:51
	findup	Link: 組み込みは、もう少しだけ表舞台に出ても良いのでは - きままな日記帳 - 私のブログの記事だけど、ちょっとサルベージ。 #embedded_jp http://tumblr.com/xib4h4b1x	2009-12-06 04:19:10

やっぱり知られてない

要は、知られていない and 教えられない ということみたいです。しかも機密事項にしているわけではない表面的な知識であっても、WEB系などの同じソフトウェアエンジニアにでさえ知られていない。無理もないと思うのは、製品を外から触るだけでは内部のアーキテクチャやソフトウェアの存在にすら気づかないからです。裏方的存在なのですから知られる必要は無いのです。私も炊飯器やポットにソフトウェアが入っているとは思いませんでしたし、自動車も機構制御がほとんどでエレクトロニクスが存在するのは一部だけと思っていました。

組み込みをより広く知らせるべきなのか？

組み込みエンジニアというものがどういう仕事をしているのかを広めていくことは人材確保と個々人のやる気に関して重要だと思います。
2009-11-30 - MassKaneko.Outで書いたように、単なる数ではなく素養のある人が求められています。ただこれは、スキル標準や資格制定、一部教育機関での組み込み分野教育の開始などを見るに、時代の流れで何年後かには解決してゆくと思います。
また、できれば開発者個人にスポットが当たる時代になれば非常にやりがいが出てくると思います。他分野では例えば音楽アーティストとリスナーがSNS上のコミュニティで会話する様だとか、WEBサービスの作成者が困ってるユーザのpostを見つけてreplyでアドバイスする様を見るに、作り手とエンドユーザの距離はインターネットが普及してから短くなってきています。しかし組み込み製品で同じようなエンドユーザとのコミュニケーションがあるかというとそんな気配は全然ありません。大規模開発の一端を担ってオフィスでせこせこ作業しているだけではその製品を作っている気持ちにはならず、下手をすればエンドユーザの存在も希薄になってしまうでしょう。いっそのこと社用公式のTwitterアカウントを使って開発模様を実況するぐらいやれば誰のために仕事してるのかが強く意識できるので、妥協の無い品質や性能が生まれたりしないでしょうか。
技術を駆使した結果が「店頭で製品を見ながら心の中で感慨にふけるくらいしかないんですよね…」なのが現実のようですが、もっと報われてもよいのでは？「あのiPhoneアプリを作ったのは私だよ！」とは言えても「iPhoneの電源制御を頑張って作ったのは私だよ！」と言えないのは同じ製品に対して価値を生み出す側なのに変でしょう。

ET2009感想その3 - 展示会雑感など

ET2009感想の続きです。私の職種上ソフトウェアのことが中心です。歴3年目の若輩者が自分の言葉で書いているので間違いがあるかもしれません。
最後のその3は「展示会雑感」など。

• 展示会雑感
  • とにかくAndroidでいっぱいでしたが予備知識がほとんど無く、後でニュースサイトを見れば事足りると思ったのでAndroidに関するものはほとんどスルーしました。
  • ARMは中央で大きく目立っていて、他のプロセッサはどこ行ったんだっていう印象。
  • IPAのお話を聞いてアンケートに答えたら本をもらえました。「組み込みソフトウェア向け 開発プロセスガイド」を入手。ありがとうIPA。
  • Intelの展示をろくに見ずにアンケートに答えたらサクマドロップスをもらえました。ありがとうIntel。
  • JASAブースで10問だけETECを体験したところ全問正解できす悔しい思いをした。しかも何を間違えたか忘れた。修行が足りない。
  • 電波新聞社で「漫画でわかる組み込み開発ストーリー」という本があって吹いたけど漫画にした意味はあるんだろうか。主任技師 島耕作とかFAE島耕作とかだったら買ってた。
  • IBMでは要求事項の依存関係リンクを持った要求仕様書の編集をプレゼンしていた。Rhapsody以前の工程でもツールがあるものだな、と。
  • ユビキタスではAndroidを1秒で起動するデモを行っていた。Great! あとパイオニアのCDJも置いてあって何かと思うとDeviceSQLというデータベースが乗っかっているそうな。組み込みでもSQLなんですね。
  • 面白い物を作ることよりも性能や品質の良い物を作ることを目標とした展示物が多いと思いました。

• Twitterの#ET2009タグ

予想通りタグがついていました。ほかのカンファレンスを実況している方がいないか期待したのですが残念ながら無かったですね。tsudaるという言葉もある程度普及してそのフォロワーも出てくるかと思っていたのですが。といっても話に集中していると頭の中がいっぱいで実況のためにタイプするのは簡単ではないというのが実際にカンファレンスに参加しての感想です。そもそも実況なんてしちゃったら怒られるのかも(有料セッションなら特に)。

• おわりに

2年半前にESECに行った時はほとんど知識が無かったのでただただ圧巻したのみでしたが、ET2009ではなかなか意志を持ってカンファレンスに参加したり展示ブースを回ることができました。一般人向けの展示会ではないので、ある程度は開発に携わって問題意識を持ったり、業界標準の知識あって初めて得るものがある場だと思います。
あと、ETでお酒を飲んだという話があり「何だそれは」と思って調べてみると、中日はお酒がふるまわれるらしいですね。私が行ったのは三日目でしたし、17:00になるとさっさと帰ってしまいました。来年も良い刺激を得ると共にお酒を逃さないようにしたいです。

• http://d.hatena.ne.jp/satox/20091120/1258724225
• http://blog.goo.ne.jp/kimuchi_nishinippori/e/361396adf934a0a351a8b1947f0b5273

ET2009感想その2 - 楽しく開発するためのモデル駆動型開発、モデル駆動型テスト

ET2009感想の続きです。私の職種上ソフトウェアのことが中心です。歴3年目の若輩者が自分の言葉で書いているので間違いがあるかもしれません。
その2は「楽しく開発するためのモデル駆動型開発、モデル駆動型テスト」について。

• 概要

IBM Rational Rhapsodyのデモ動画に解説を加えながらMDDについて述べてゆくものでした。MDDというのはその場で初めて聞いたのですが、一言で言えば「UMLが動くとこんなメリットがあるよ！」というものかと思います。

• MDDの良さそうな点

良いと思ったのは、設計したモデルがそのままコードになるので狙った設計と実際の動作の差が無さそうということです。テストシナリオを設定してモデルを動作させると、例えばシーケンス図が描かれてゆくというのも良いインパクトでした。もちろん繰り返してテストできるので、振る舞いを少し変えた時に問題が無いかテストするのも楽そうです。また、モデルという中間成果物が確実に生成されるので、管理する方も進捗がわかりやすいのではないでしょうか。

• MDDの懸念点

ただ、逆に言えばモデリングできないことはMDDでは扱えないということです。ターゲット環境とのインテグレーテッドテストでのみ発見される問題というモデリングできないことに起因する問題というのがあると思います。MDDで解決できることとできないことを正しく認識し、それを踏まえた開発プロセスの導入が不可欠なのでしょう。
また、MDDの導入のためには各開発者が当然のごとくモデリング言語を良く理解していることが前提となります。組み込み業界では依然としてCでの開発が多いので(60〜70%だったか)、モデリング言語そのものが十分普及していない可能性があります。オブジェクト指向言語を使った開発も増えてきた(20%〜30%だったか)と思いましたが、その中できちんとモデルを記述しているチームは果たして多いのでしょうか。「時間さえあればUMLを書きたい」というチームと「普段からUMLを書いている」というチームでは、いざMDDを始めるというときのスムーズさが格段に違うと思います。なので、組み込み業界にMDDが普及するのはまだ先でしょう。私もふと、「UMLの図は全部で13種類」と言われて「そんなにあったっけ？」と数えて出てきたのが7種類だったのでMDDの習得には精進が要りそうです。

• 楽しいの？

ところで、講演タイトルにある "楽しく開発するための" というのは一体何が楽しいのか少し考えてみたところ、やはり動かないものより動くものを作る方が楽しいということでしょうね。「仕様書は動かないけどモデルなら動くから楽しいよ！」というメッセージなのだと思います。