カテゴリー「日記・コラム・つぶやき」の記事

2012年1月 1日 (日)

謹賀新年

本ブログをお休みして、かれこれ数ヶ月・・・ あっという間に新年を迎えてしまいました。coldsweats01


その間、Interface誌での連載も終了。記事に連動して、ネタを書いていくつもりが...ブログ書きは全く追いつかずでした(ネタ切れではありません、決して)。

連載は終了しましたが、ポツポツとこちらでまた書いて行きたいと思います。
そんなわけで、ブログをご覧下さった皆様、今年もよろしくお願いいたします。

2011年3月28日 (月)

九州が、あつい!! ~SPL&MDDセミナー受講記~ (続き)

九州が、あつい!! ~SPL&MDDセミナー受講記~の続きです。

3月25日に福岡で行われた、『プロダクトラインセミナー』+『モデルベース開発セミナー』の午後の部についてお話しします。

午後の部も、午前に負けず劣らず、”あつい” セミナーでした。

『自動車業界におけるモデルベース開発事例』と題した午後の前半では、
 ・自動車業界で実際に行われていモデルベース開発事例についてのご紹介
 ・車載システム仕様化・検証技術として、EAST-ADL2(*)を使った仕様記述の紹介
   (*) EAST-ADL2 :SysMLをベースに車載ドメインに特化した仕様記述言語の定義
      (株)デンソー 佐藤洋介氏の資料より
の2本立てでした。

これまで、車系ドメインにはかかわってこなかった私にとっては、たいへん難しい内容でした。
しかし、先端を行く車関係のソフトウェアが、どのようにして上流で品質を確保しているかが垣間見え、とても勉強になる2時間弱でした。(私の勉強が足らず、詳しいレポートが出来ません。。。sad


午後の後半は、『モデルベース開発とSPL・九州地域の取り組み』と題していました。
 ・MDDを使ってSPLを加速する方策として、MDDツールを使いながら共通部を開発する技術的な事例紹介
 ・九州技術教育専門学校における、初学者へのMDD教育事例の紹介
という、こちらも2本立てです。

エプソンの島氏による、『MDDを使ってSPLを加速する』 の内容は、技術者にとって実践寄りの内容でありました。

”MDD:モデル駆動開発”と聞くと、ベタベタな実装を知らずして、モデルのみでプログラムを語る世界と思われる方もいるかもしれません。しかし、島氏の講演は、そのイメージを払拭するモノでした。

島氏の講演内容は、以下の4つのブロックからなっていました。
 (1) プロダクトライン開発にいたる道
 (2) モデル駆動開発
 (3) よいモデルとは
 (4) ソフトウェアプロダクトライン

(1) の中での島氏は、
構造化 → オブジェクト指向 → モデル駆動 → プロダクトライン開発 とシステムの規模が大きくなり、色々な設計技法を用いて行っても、最初の構造化で作ったコードは一部残る。
また、MDDはあくまでもツールであり、ゴミのようなモデルをINPUTすると、ゴミのようなコードしかOUTPUTされない。
と仰っています。
凝集度・結合度、可変部・共通部の切り分けなど、何が”よいモデル”かを考えられなければ、MDDにもつなぐことも出来ないということでしょう。


このセミナー午前中のパネルディスカッションと同じことが言われています。
ソフトウェア工学的な、基礎知識を持たずして、MDDもSPLもうまくいくわけがないのです。

現在のソフトウェア開発は、ゼロからアーキテクチャを設計するのではなく、何らかの既存システムがあり、そこから派生(一部部分の取込みも含め)であることがほとんどです。
そのような事情の中では、旧来の技法(構造化など)による設計知識も、まだまだ必要です。
更に、一段新しい技法に取り組む(例えば、構造化設計のコードをオブジェクト指向に乗せ変えていく)ためには、両側に関する知識を持ち、よいアーキテクチャにしていくためには、新旧のコードをどのようなインタフェースで接続するか設計できるかが重要shineだと思います。


また、島氏は翌日のTwitterで、こんなことも呟かれていました。

『午前中(島氏の講座の前)に責務・凝集度/結合度、構造化、RTOS並行性分析、タスクマッピング、リバースモデリングの基礎みたいなのをやってもらえると、私のSPLの話がやりやすいんだけどなあ。結局やっているのは、プロダクトラインに近づけるためのモデリングトレーニング。』

『技術的には、構造化設計とオブジェクト指向設計・デザインパターンくらいまでなので、新技術紹介じゃないし。(島氏の作られたセミナー資料には)数値データを出さないので経験論文じゃないし、製品に使っているモデルは皆無なので実例紹介でもないし、基礎教育用の教材と思っています。』

私はこのBlog.などでも、日ごろから「構造化設計の基礎知識を身につけましょう」というお話をするようにしています。MDDであれ、SPLであれ、それら技法に取り組むには、開発の基礎体力が必須です。
「構造化設計なんていまさら...」 とか、 「オブジェクト指向なんて使えないよ...」 なんて、後ろ向きな方がいらしたら、ぜひ今回のようなセミナーを聞いていただきたいと思いました。


~余談~
島氏のプロダクトライン実践は、SESSAMEの主催で東京近辺で1~2日間のセミナーが実施されるそうです。

2011年3月27日 (日)

九州が、あつい!! ~SPL&MDDセミナー受講記~

2011年 3月25日(金)に、福岡にて行われた下記のセミナーに参加してきました。

『プロダクトラインセミナー』+『モデルベース開発セミナー』
  午前の部:プロダクトラインセミナー  ~SPLへの最初の一歩としてのXDDP~

  午後の部:モデルベース開発セミナー  ~モデルベース設計・検証事例~
    第一部 ・・・ 自動車業界におけるモデルベース開発事例
    第二部 ・・・ モデルベース開発とSPL・九州地域の取り組み


午前の部は、
  前半は、派生開発特化したプロセス:XDDPについての紹介 (講演)
  後半は、SPLの導入について(XDDPはSPL導入として使えるか)をテーマにした、パネルディスカッション(*)
    (*) パネル登壇者については、ES-Kyushu のセミナー告知をご覧ください
でした。

私の先月のBlog記事をお読みいただいていた方は、「おやっ どっかで見たような...」と思われた方もおいでではないでしょうか。 昨年11月に行われた、JASA主催のETセミナーとそっくりです。(こちらのセミナーについては、プロダクトラインと派生開発(その2) で触れています。)
似ているどころか、開催・企画もJASAで、後半のパネルディスカッションは、11月のセミナーのまとめをスタート地点として、話が始められました。

前回と今回のパネルでの大きな違いは、SPLを全社導入を試みた、富士通九州ネットワークテクノロジーズ(株)(以下、九ネット)の岩崎氏がパネラーに加わっていたことでしょう。『SPLを導入するためには...』 というお題に対し、九ネットさんの事例で、どうであったかというコメントが要所要所でお話くださいました。


このパネルで記憶に残った登壇者の皆さんのコメントに、以下のようなものがありました。

九ネット 岩崎氏:SPLが成功するための下地としては、(社内で)開発プロセスがしっかりあった。 ものの本から、実践できる開発プロセスに落とし込むのは、かなり大変。 元々プロセスができていれば、そこにアドオンする形でSPLを取り入れるのなら可能である。

SRA 林氏:SPLに取り組むためには、2Fに上がる梯子(**)を一歩一歩上がっていくことを知っていれば、決して難しいことではない。SPLは体質改善(生活習慣を変える)である。それを維持していくことが難しい。また、それを実施するための熱意が必要。それを発する人が一人以上いて、継続していくことが重要(これは、教科書には書かれないポイント!!)。
    (**) SPLは2階建ての2Fの技術、ソフトウェア工学的基礎体力が1Fにある。
          という、前回パネルのまとめのお言葉から。

XDDPの清水氏:XDDPによって、SPL実施のための下地作りはできる。近い将来SPLを考えないと、プロダクトとしてはどんどん他社に後れを取る。早く取り組まないと、後発開発は短期開発に迫られ、また新しい技術を取り入れる余裕もなくなり、差が開く一方になる。

といった、かなり熱い(というか、渇!って感じ)のお言葉。
パネル自体も、後半になればなるほど、話が盛り上がり、質疑も熱さを増すなかでの締めくくりになりました。
また、その間の会場の皆さんも、かなり必死にメモを取っていらっしゃいました。


組込みソフトウェアに限らず、短期に品質の高いソフトウェアを開発できる体質づくりが、早期に求められているのは、納得です。
その体質づくりは、大規模開発の現場以外でも、必要であると思います。
プロダクト開発と並行して、体質づくりは進められる。いつ着手するかなど、迷っている場合ではなくなってきている。
と、今回強く感じました。


...さて、長くなりましたので、午後のセッションについては、次の記事にてご報告とします。

 

2011年3月21日 (月)

自分に出来ること。。。

3月11日の東北地方太平洋沖地震にて、被災された皆様に、
心よりお見舞いを申し上げます。

週に一度のペースでは何か書いていこうと思って始めたこのBlogですが、ここ2週間はすっかりお休みしてしまいました。
震災後の様子を見ていて、のんきにBlog書いていて良いのだろうか。。。と、気持ち的に迷いがあり、手を付けずにいました。しかし、他に自分に何が出来るか。。。 
正直未だにわかりません。
ただ、経済活動を支えるため、また安全・安心なソフトウェア開発につなげるために、Blogに書くことがきっかけにや一助になってもらえればと考え、再開することにしました。

ちょうど今日、Interface誌の第6回目原稿も編集さんに送りました。
これからも、C言語ベースで改善していく方法を、書き続けていきます。

2011年2月17日 (木)

「組込みソフトウェアギルド」への想い

2011年2月14日、有志6人によって、組込みソフトウェアギルドというグループを設立し、活動を開始しました。

このグループは、組込みソフトウェア技術者支援の相談窓口となるべく立ち上げたものです。
”ギルド” は、会社のように収益を共にする団体ではありません。
あくまでも、ギルドの活動目的 「問題解決による社会貢献と所属するメンバーのスキルアップ」 に賛同する、メンバの集まりです。
メンバは、それぞれソフトウェア技術者としての経験を積んだエキスパートです。ギルドへの相談は、個々のメンバがこれまでの知見から相談に対応するだけでなく、ギルド内での相互協力を仰ぐことで、互いの技術を補間することで、より適切な対応を行っていきます。

組込みソフトウェアギルドについて、設立趣旨、メンバ構成などは、
下記のサイトにありますので、詳しいことはこちらをご覧ください。

組込みソフトウェアギルド
 https://sites.google.com/a/embeddedsoftwareguild.com/www/


会としての総意はWebSiteをご覧いただくとして、以下には私個人としての想いを綴ります。

ギルドのメンバ紹介にもありますが、私自身は組込みソフトウェアの開発現場に十数年おりました。
大きな会社ではなかったため、体系的な教育や、整った開発プロセスがない現場でした。
その中で、新しい製品開発を続けていくためには、世の変化に合わせて要素技術(ネットワーク系や、デバイス制御 etc.)の習得、実装に追われ、プロセスの改善や、設計・テストなど開発技術の向上には手を付けられずに走り続けていました。正直、当時はそれがいっぱいいっぱいshockだったのです。


その後、転職をすることで開発支援する側に回り、広い世界を見る機会を得ました。
すると... 大きな会社でなくても、基本的な開発技術を習得し、しっかりしたプロセスの見地を持って開発を回している会社はあるのです。(また、大きな会社であっても、会社全体ではなく一部グループのみで、改善を行い成果をあげているところもあります。)

おそらく、自分が現場どっぷりの頃、そういう話を聞いても、
 話は分かるけど、なかなかねぇ.. (時間がない、人などリソースが不足)
 自分ひとりじゃ、難しいよ (相談する人、もしくは一緒に改善に挑む人がいない)
 なんだかんだ言って、大手はバックアップがしっかりしてるから~
という後ろ向きな感想を持ちつつ、実践には持ち込まなかったでしょう。

確かに、自力で改善するため、すべての技術を学び、プロジェクトメンバにも情報共有をはかり、プロジェクトで実践する。そんな、スーパーマンみたいなことはなかなか出来ません。
しかし、世の中には(ちゃんとした)”コンサルタント”という人たちがいて、その現場の事情を知った上で、できるところから改善策をアドバイスしてくれる人たちflairがいます。
事実、アドバイスを受けて、成功しているところは、いくつもあるのです。


このような成功の事例を知っても一つ問題が...
コンサルタントにアドバイスを受けるといっても、お金dollarがかかる。
それも、高いお金が。

実は、お金をかけなくても、自分がコミュニティに飛び込むと、悩みについてアドバイスしてくれる人がいたり、自分の現場に合うような改善アイテムを教えてくれたりすることはあります。
ただし、そこまでたどり着くには、自分の信頼を得るためのコミュニティ内での活動が必要です(コミュニティはTakeだけではないですから)。 また、会社がオープンなコミュニティを嫌ったり、自身の時間が取れなかったりするため、その信頼獲得までが、また大変だったりします。

語れば、語るほど、次から次ぎへと問題にぶち当たります。
では、どうしたら前に進めるのだろう。。。 と、ここ何年か思っていました。


そんな矢先、ギルドの話を持ちかけられました。
このギルドの考えは、前述の話に出てくるいくつかの障壁
 ・お金に対する問題
 ・問題発生時の相談相手 (一回だけでなく、継続的な)
 ・時間の問題(アドバイスを受けた=ギルド成果になるため他に時間を使わずすむ)
を、いくらか下げられると思いました。

この活動に加わることで、開発現場で頑張っている人たちの、一助ができるかもしれない。
また、成果として”役に立った”という対価を得られ、自分自身にとっても、次へのモチベーションがアップできます。
そう思い、ギルドメンバとして参加して頑張ってみよう! と思った次第です。


組込みソフトウェアギルドは、まだ目を覚ましたばかりです。
これから歩み始め、その軌跡を積み重ねていきます。
ソフトウェア開発の現場の役に立てるよう、小さな相談でも真摯に対応していきたいと思います。

組込みソフトウェアギルド お見知りおきください。
 よろしくお願いいたします。