無料ブログはココログ

« 2005年9月 | トップページ | 2005年11月 »

Webアクセシビリティ

今日はKOF2005で開かれたACRI研究会に参加しました。
今回は実習形式でアクセシビリティを考慮したWebページを作成しました。
実習はメモ帳+無料ツールで行われました。

このほか、実習はありませんでしたが、以下も紹介されていました。

メモした内容は以下の点です。

  • JavaScriptへのリンクがあると、設定によっては呼べない人がいる
  • _blankで新しいページに遷移すると、戻れなくなるので、どうしても新しいページに遷移したければJavaScriptで遷移する(JavaScriptが無効になっていれば同じページに表示される)
  • CSSでは総称セレクタ"* {"でブラウザごとに異なる"margin","padding","font-style","font-weight"を指定する

altの指定やセーフカラーの指定などアクセシビリティの基本のほか、Windowsのユーザ補助に合わせて"h1"に"line-height : 100%;"を指定すると良いというのは、ACRIのメーリングリストで議論のあったところで、実ユーザからの情報が得られるのは、コミュニティの強みですね。このほか、リンクで「ここ」と書いてあると、リンク先だけを読ませた際に良くわからないと言うのは忘れがちなところだと思いました。

つぎは、Webエディターの利用方法なども聞いてみたいと思いました。<=わがままです

モンゴルのIT事情

関西オープンソース2005(KOF2005)に参加しました。興味深かったのは末岡さんの「モンゴルのリナックスコミュニティを初めとするモンゴルのIT事情とモンゴル国家として今年から開始したe-Mongoliaの紹介」を聞きました。この方は、大阪市大の学生さんですが、現在休学中で、現在はモンゴルの国立大付属モンゴル日本人材開発センターというところで、オープンソースの普及を進められているそうです。

興味深かった点をあげておきます。

  • 人口は都市部に集中し、地図に道があっても郊外は舗装されていないので、GPSがないと迷ってしまう
  • ソビエトの崩壊による政権交代後、経済状況はあまりよくない。前回の選挙で旧共産党と現政権の議席が同数だった。
  • 文字には昔の文字と、ロシアのキリル文字の影響を受けたものがある
  • ローカライズを個人依存で進めていたら止まってしまった。
  • 光ネットワークの延伸にNTT東日本が協力している
  • 日本から中古パソコンの援助があった
  • インターネットはあまり普及していないが、インターネットカフェでネットワークゲームをする人は多い

オープンソースの普及にゲームを使えばどうかというコメントがあり、採用されそうな幹事でした。人間の欲望を利用すると言う戦略は面白いですね。

とある大学前にて

wara最近の田んぼで、この景色は少なくなりましたね。
うちの近くにも田んぼはあるのですが、藁を使わなくなったのかこんな風に干してあるのは珍しいですね(でも、もうちょっと丁寧に干してほしかった、、)。

お気に入りの一言

スタートレック・ヴォイジャーを見ました。トレス中尉からホログラムのエンジニアへの一言、

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

いい言葉だと思いませんか?

モデル検査とSPIN入門

SEA関西支部プロセス分科会(略称SEA関西SPIN)に参加しました。
トゥルーロジックの野中さんはUNIXカーネルの開発者たちが開発したSPINの解説でした。SPINは状態遷移を検証する処理系で、モデルが取りうる状態と起きてはいけない状態の論理積が空であることをすべての状態を展開して確認します。モデル検証は実装の前に設計を検証するもので、自動、反例を示す、まれにしか起きない問題を検証するといった特徴があります。

言語はPROMELAといい、do-od、if-fiとさすがにUNIXの開発者が作っただけあってshのような表記です。いつかきっとは" <>"、いつもずっとは"[]"、untilは"U"です、このうち、" <>"をひし形はいつかきっと傾くという説明がGOODでした。

モデル検証はアルゴリズムと計算機の高速化で1980年に7日かかったものが今では数秒で処理できるようです。SPINにはモデル検査のCコードを出力する機能もあるそうです。
詳細とツールは、http://www.spinroot.com/にあるようです(私は見れませんでした)。

SRA-KTLの岸田さんは「銀河ヒッチハイクガイド」をつかみに、岸田さんが70年代後半にアメリカのSRAでエドワードミラーと知り合って、カバレージを日本に伝えたお話、LehmanのS(Specificationが定義できる),P(なんとかプログラマブル),E(Embedded)のお話、社会のチリにまみっれているからと大森荘蔵に教えを受けられなかったお話、ソシュールが言語学は規範の額ではない(正しい日本語とか)と同じく、ソフトウェア工学は規範の額ではなく、モデル(文字)はソフトウェア(言語)の正体を隠すものであって、モデルを剥ぎ取ったところに本物のソフトウェアが現れる、E-typeは無限の属性を持つので、仮説は2000年問題のように成り立たなくなる、といったお話で構成されていました。

最後のディスカッションでは、SPINは特定領域に絞って使う、複数の形式手法を組み合わせないといけないのが現状といったわだいが出ていました。

アジャイルプロセス協議会「西日本セミナー」その3"モチベーションとファシリテーション"

セミナーの最後は2件で、一つ目はTDDのバグなし本で有名なアジャイルウェアの川端さんは「アジャイル開発の落とし穴」はプロジェクトのモチベーションをいかに保つかでした。お話の途中で出てきた契約のパターンのお話は聞いたことがあると思ったら「リーンソフトウェア開発」が元ネタだそうです。コミットしたときに自慢げに押すコミットボタンは東急ハンズで千円台で売っていたそうで、「御用の方は、、、」と書いてある上から「コミットしたときはベルを押してください」と書いた紙を張ったそうです。このベルは懇親会でも活躍していました。

NCSの高森さんの「eXtreme Programming とファシリテーション」はぜひ資料を見てください。共有、発散、収束をうまくコントロールすることがポイントだそうです。経験がにじみ出ていてよくわかるお話でした。

SEA関西プロセス分科会

10/21は「モデル検査とSPIN入門」です。野中さんと岸田さんが 講師で、場所は大阪駅前ビルです。まだ、若干の空きがあります。詳しくはこちらの案内を見てください。
(水曜日が締め切りになっていますが、たぶん、ぎりぎりまで大丈夫です)

アジャイルプロセス協議会「西日本セミナー」その2"Software Factories"

アジャイルプロセス協議会「西日本セミナー」の2つ目は、マイクロソフトの荒井さんの「Software Factories ― パターン、モデル、フレームワーク、ツールによるアプリケーションの組立」でした。

ここでいうSoftware Factoriesは昔はやったソフトウェア工場ではなく、ユーザのドメイン用の言語をDSL(Domain-Specific Language) tool で作成し、ドメインに限定された言語(DEL)で要求を書くことで、コードの自動生成を行うものです。自動生成によってより機敏(アジャイル)に開発できるとのこと。従来からコードの自動生成のツールはありましたが、 より抽象度の高いレベルで環境を整えておくところが新しいと思います。

日経BPソフトプレスから「ソフトウェアファクトリ」という本も出るようです(以下の和訳)。
Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools by Jack Greenfield, Keith Short, Steve Cook, Stuart Kent, John Crupi (Wiley)

アジャイルプロセス協議会「西日本セミナー」その1

アジャイルプロセス協議会西日本セミナー」に参加してきました。
オープニング・セッションは新保さんの「開会挨拶・アジャイルプロセスとは」でした。アジャイルの説明の中で興味深かったのは、アジャイルを「ビジネス価値に基づく開発」とし、要求開発アライアンスを引用されていたことです。はじめのビジネス価値というのは、先日のSEPG JapanのVuさんの講演の「ビジネス成果」につながるものです。後のほうの要求開発アライアンスは、SEPG Japanのチュートリアルの内容そのものです。CMM的なSEPGとアジャイルは同じ方向を向いていたのですね。

親バカ

mikanXうちの娘いわく、むかしのTV番組にインスパイヤされたといって、こんな作品を作りました。

SEPG Japan 2005 の感想

SEPG Japan 2005に3日間参加してきました。
参加者は432名だそうで、今回も盛況でした。発表は45件(うち海外6件)で、以前はレベル達成などの発表が多かったですが、より実質的なプロセス改善のお話が増えたように思います。

最優秀発表賞はオリンパス岩見さんで
「ソフトウェア開発委託の実態 -責任回避と丸投げの病理-」
という発表でした。 社内の部門で、外注管理に失敗しているところがあったので支援した経験の報告でした。改善したのは、レビューと検収の強化で、このうち興味深かったのは、検収の強化です。検収ではテスト報告書の確認と受け入れ試験の実施をおこなったとのこと。このテスト報告書を受け取る際に、最終結果だけではなく最初のテスト結果を提出してもらったのがアイデアで、このデータから問題の生じそうなモジュールを特定されたそうです。そういうのもある、ある、と思うような現場の問題を発表されていて、耳の痛い人も多かったかもしれません。

実行委員長賞はニコンシステム今井さんで
「熱意や道徳に訴えないモチベーションのアプローチ」

プログラム委員長賞はSRA杉山さんで
「小さなプロジェクトの小さな改善」

でした。この2件は聞けなかったのですが、杉山さんの発表は、小さな改善ではあるが、現場の人自身が改善して、発表したということが評価されたようです。このお話をSEA関西SPINでしたところ、O社のTさんいわく、SEPGを別グループにすると現場の協力を得ると言うのは難しい、ということで評価が高くなったようです。

レベル取得ブームからカイゼンへ

CMMが普及するにつれ、レベル取得ブームの嵐が吹き荒れていました。PMBOKやCMMIの連続モデルなども知られ、ようやくレベル取得ブームは山を越えたようです。

SEPG Japanのキーノート&プレゼンのVuさんいわく、レベルだけでなく、ビジネス成果が必要であるとのこと。まさにそのとおりだと思います。

質疑応答で出た例がリーンソフトウェア開発のプルシステムに似ていると思ったら、リーンソフトウェア開発を導入していたとのこと、なるほどね。

SEPG Japan 2005に参加しています

SEPGJkanbanキーノートは米国ボーイング社のJohn D. Vuさんのプロセス改善の間違いと実際の話でした。プロセス改善を行う72%は失敗あるいは大きな効果がないそうです。プロセス改善には成熟度レベルの向上だけではなく、ビジネス成果と結びつかないといけないと言うお話でした。

質疑応答で改善の例として、「飛行機では7000万個の部品がいる。在庫が減るとFAXなどで注文するが、その間製造が遅くなる。そこで、在庫情報をDBに入れ、すべてのサプライやが見れるようにした。在庫の上限と加減を決めておき、納入してもらう仕組みにした。サプライヤもカイゼンできた。この結果、FAXや注文書がなくなった。サプライやが在庫管理できるので、効率が50%向上し、5億ドル儲かった」と言うお話がありました。これぞ、リーンソフトウェア開発のプル・システムですね。

リーンソフトウェア開発~できるだけ速く提供する

決定をできるだけ遅らせる」とともに、この「できるだけ速く提供する」は重要です。

変化に対応させて手戻りを生じさせないために、コンカレント広さ優先で、効果的なオプションを残し、最終責任時点まで決定を遅らせて開発することを説明しました。並列処理の効率を上げ、オプションのコストを下げ、最終責任時点をより遅い時期にするのがこのできるだけ遅く提供するです。

できるだけ速くというのはアジャイルすなわち機敏ということで、早い時期という意味ではありません。これを実現するには、前に説明したプルシステムで効率よく開発するとともに、各作業をスムーズに流れさせ、パイプの詰まりを生じさせないようにします。「リーンソフトウェア開発」ではこれを待ち行列理論で説明しています。

待ち行列を効率よくするにはサイクルタイムを短縮する必要があります。それには到着の平準化サービス時間の平準化が有効です。到着の平準化が有効な例としてテストがあげられています。ウォータフォールプロセスではテストが後工程に集中し、十分なテスターがいないとボトルネックになってしまいます。作業を平準化してより速く提供するには、リリースを分ける、つまりイテレーション(繰り返し)開発が必要になります。到着の平準化はテストのみでなくもっと詳細なプロセスにおいても有効だと思います。

サービス時間の平準化には作業を細かな単位に分割することが有効です。作業時間のばらつきをなくすことで待ち行列は効率よく動かすことができます。これは、対象ソフトウェアで制御できるはずです。オブジェクト指向で推奨されているように、より細かなクラス・メソッドに分割することで、実現できると思います。なお、上流でばらつくときは下流に影響が出るので、ばらつきそうな作業は、なるべく下流にもって行くほうが良いようです。

なお、この待ち行列は人間が処理しますので、ゆとりを持たせなければなりません。作業負荷が高くなると人間が疲弊・故障し、待ち行列は止まってしまいします。XPの様に適切な作業量を守らなければなりません。

(全体にカテゴリーを変えてみました。いずれカテゴリーを独自のものに変えるようにします。)

アジャイルとプルシステム

リーソフトウェア開発におけるプルシステムとは、トヨタ式カイゼンの看板方式のことです。後工程で必要なものを前工程で用意する際に用いられるのが看板で、この看板によって生産を管理します。従来のあらかじめ用意する方法は、無駄が多く、機敏に開発することができません。YAGNI(You Aren't Going to Need It:今必要のあることだけをやれ)を実践するために、タスクカードを用いて管理します。

これは、計画の線表を後ろから引くことに似ています。前から順に線を引くと完成できないことでも、後ろから線を引くと各作業間の制約が見えてきて、並列化するなど効率的な計画を立てることができます。最小限のことに限定して、後ろから計画する。それがYAGNIとプルシステムです。

ソフトウェアメトリクス

ソフトウェア工学という言葉を知っていても、メトリクス(尺度)という言葉を知らない人は多いのではないでしょうか?最近、初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方という本が出たようです。ソフトウェア開発を見える化するためには何らかの尺度に基づく定量的なデータが必要です。ひとまず買ってみます。

シンプルルール

シンプルルールは自律的な組織運営を可能にします。「リーンソフトウェア開発」ではシロアリのシンプルルールの例と、それを応用したネットワークルーティングなどの例を示して、以下の特徴を挙げています。

  • 柔軟性:集団が変化する環境にすばやく順応
  • ロバスト性:個体が失敗しても集団はタスクを実行できる
  • 自己組織性:集団に対する指揮やトップダウン管理が少なくてすむ

シンプルなルールを決めておくことで、狭い範囲で物事を決めてしまう深さ優先でなく、システム全体を考慮しながら広さ優先の意思決定が可能になり、コンカレント開発を支援します。また、一般により良い決定である直感的な意思決定ができるようになります。

リーンソフトウェア開発 - 決定をできるだけ遅らせる

アジャイルソフトウェア開発はどこが優れているか?なかなか理解できませんでした。これまでの理解では、無駄なドキュメントを書かない、リファクタリングで変更容易性を維持する。コードの共有とペアプログラミングでコミュニケーションを向上させる、などで、概念的にはわかるものの、経験の不足している私には、なにか欠けているような気がしていました。

リーンソフトウェア開発のなかで、まずショッキングだったのは「決定をできるだけ遅らせる」という説明でした。この基本はコンカレント開発です。従来のようにシーケンシャルに開発すると、まだ決定すべきでない変更の可能性のあることも暫定的な決定が必要とされ、生じるべくして生じた変更の対応のために、ドキュメントの変更、関係者への周知、プログラムの変更、レビュー、テスト&デバッグといった余計な作業が生じていました。

リーンソフトウェア開発は、変更の生じそうことはそれ以上に決定をの最終責任時点まで決定まで決定しません。また、開発上、何らかの決定が必要なときには必要なオプションを保持します。このような方法で全体をコンカレント(平行)に開発します。コンカレント開発は容易でなく、また、オプションを保持することはコストがかかります。しかし、よく考えて計画することで、変更によって生じるリスクを低減するのです。

また、コンカレントに開発する場合は、開発者に自律的な行動が必要とされます。この方法は、次回に説明します。

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

« 2005年9月 | トップページ | 2005年11月 »