定例会：JMock,VirtualMockObjectについて

前回の定例会で、システム開発における支援ツール関連の実務経験・ナレッジの交換を行いました（Hudson、Selenium、他）。

前回予定していながら、業務都合で出席できなくなったメンバーから、Mock系の話をしてもらいました。

具体的には、JMockとVirtualMockObject。
共にDI系の開発で使われるモックの作成支援を行ってくれるものです。
．．．．．と、分かったような書き方をしつつ、「DI系を前提とした」ってことは私は知りませんでしたけど．．．。

大抵のツールに言える事なのでしょうが、今回のMock系も同様。
適用した方が効率的と言える場合と、変わらない場合（或いは既にラップされて、より高いレベルで支援される場合）とが有るようです。

特に、実行時のシーケンスの単純なテストケースが大量に存在し、検証を必要とする場合ほど効果が大きいようです。
コンピューターに任せられることは人がやるな！（コスト比較と敷居のレベルに拠るでしょうが）、という原則通りですね。

話をしてくれたメンバーが現在使っているのが VirtualMockObject。
JMockの方は２年前の経験だったので、少しおさらいで調べ直してくれました。
２者の比較という点ではJMock側に機能的な制限があったようですが、最新版では機能拡張されているので有意な差異は無いかも！？、とのことでした。

プログラム的なレベルで相互依存性を下げたい場合（対象コンポーネントの寿命を長めに想定する場合とか）、クラス数やらインターフェイス数が増える傾向が強いと思います。

完全に自動生成されるクラス群をわざわざテストしよう！、というケースは殆ど無いと思いますが、僅かでも人間の手の入るコンポーネントはテストで検証したい。

どこをツールに任せるのか？
基本的なポリシーと、効率化の選択肢を多く持つこと。
臨機応変に最適性を判断しながら、部分最適と全体最適のバランスを考慮して適用していける事が大切だろうと思います。

ブログランキング！

ランキング挑戦中！

お仕事：カバレッジ測定

ＩＴシステムの「品質」って、定義が難しいですよね！？

先ず何よりも「合目的性」でしょう。
要求を、コストに見合う分だけ満たす・満たし続けることが第一ですね。

上記を大前提として、安定して確実に動き続けること。
必要な性能水準を満たし続けること、使い勝手・見栄えなどを必要十分に満たすこと。
セキュリティ、対障害性（復旧の確度と速度）、対負荷性能、etc....

上流での品質確保ほど大きく影響するわけですが、同時にケースバイケースの度合いが大きくなります。
余り抽象的なことを書いてもつまらないので、開発段階のお話に絞りたいと思います（上流工程での詳細をブログに書くわけにも行きませんし．．．）。

「カバレッジ」って、ありますね。

実装言語上のどのステップが実行・検証されたか？、の目安となるものです。
古くはJMeter（或いはJMeterにラップしたもの）、他にも様々なプロファイラが存在します。

テスト駆動開発を行う場合、AntやMaven2、Hudsonなどでテストを自動実行し、カバレッジが一定以上になるよう、ガイドラインを設けて開発を行います。

但し、このカバレッジが全てを保障してくれる訳ではありません。
また、実装言語にも拠るでしょうが、100%近くを求めようとすればするほど、級数的にコストが上昇します。
ということは、時間も掛かるってことですね。

「テストは、テストの為に行うのではない」
数字自体が目的になってしまったり、一定のリソースとコストを消化することで満足してしまうようなケースは、まさか存在はしないだろうとは思いますが．．．．．

納期的な要求はよりきびしくなり、求められる様々な品質はより高くなっていきます。
単純で画一的なテストガイドラインを適用するのでは、とても納期・コスト条件を満たせません。
利益なんて出ないです、お給料出ません。

リスクの高い部分にカバレッジのラインを適切に(?!)設ける。
ある程度は勘に頼る部分も残るでしょうが、出来る限り機械的（自動・或いは半自動的）に、テストレベルを決定し、効率的に適正品質を確保していかなければなりません。

なんだか面倒臭いですが、これを極力ラクに、楽しく実行したいものです。
勿論、ラクをするためには倍の苦労が必要になるでしょうが、１回の苦労で２回ラクが出来ればチャラです。
３回で元が取れるんですから、やるだけの価値は有るでしょう。

ブログランキング

ランキング挑戦中！

雑記：アスペアの公開サイト

http://www.aspire.co.jp です。
以前にも書きましたが、世界的に普及度の高いオープンソースのCMSツール、「Joomla」を使って自社の公開サイトを再構築しました。

で、ちょこちょこと更新してるんですね。
それほど頻繁ではありませんが、最新版では自社の「開発力：APF（ASPIRE Process Framework）にも触れています。

でも、トップページ（ホームページ）の「News」には何も書いていない．．．。
「ちょこちょこ更新しているんで、逐一は広報していない」とのこと。
何か、勿体無くないっすかあ？

RSSにも対応していないし、「何か変わってないか？」といちいち覗いてくれる人は殆どいないだろうし．．．。

確かに、未だ未完成の半端な情報が少なくないです。
APFにしても、「それって何？」状態で、余り突っ込んだ説明はしていません。
その点では、まだまだこれからです。
一定の区切りが付いてから「News」に載せたいって気持ち・判断も分かりますね。

ちなみに、APF（ASPIRE Process Framework）とは、「開発ツールやドキュメント・ソースファイルの雛形＆ライブラリ、各種の半自動化ツール群を大幅に取り入れた開発プロセス体系」です。
要求・要件定義（或いはRFP作成支援）段階から使用することができ、下流の開発・実装工程まで、可能な限りシームレスに繋げよう！、という思想で組みあがっています。

当然のことながら「どんな場合にでもノンカスタマイズで適用できる」プロセスなど有ろうはずがありません。
先ずは比較的小規模で予算・納期の厳しいプロジェクト、仕様的な手戻りなども比較的発生し易いプロジェクトを前提とした「APF:Falcon」がβ版（？）辺りまで出来上がっています。

「インテグレーションサービス」、或いは「ロールサービス」の如何に関わらず、抽出して適用可能な部分は、適宜でカスタマイズしながら進めていくことができます。

今後は、実践を踏まえながら各種の「APFバリエーション」を増やしていくことが出来れば、と考えているところです。

ブログランキング

ランキング挑戦中！

勉強会：オンライン会議準備しました

昨晩、22時（少し前）から、Skypeを利用したオンライン会議（実際には「ユースケース実践ワークグループ」の活動で利用）の接続テストをしてみました。

22時の2～3分前からSkypeを起動してみると、2人ほどからアクセスリストの追加リクエストが出ている．．．。
厳密な接続手順を事前には明確にしてなかったんですが、とりあえずグループの代表者とアクセスリストを共有しました。

恥ずかしながら、私自身はSkypeの利用はこれが初めてです。
お！、「接続要求に応える」ボタンがある！
これをポチッと行けば、会議に参加できそうだな．．．。

おお！、聞こえてきました！！（当たり前ですが）
もう既に3～4人が参加してます。
ほどなくして、7人にまで増加。
ワークグループ参加予定者の殆どが事前テストに参加した形です。

ヘッドセットで会話するってのも初めてです。
グループ同士でのTV会議・音声会議などは経験がありますが、全員の声がヘッドホンから流れてくるってのも、妙な緊張が伴いますね。

１：１会話なら、確かに快適そうです。
3～4人以上が同時に途切れなく話し続けると、誰かしらの声（のパケット？）が、微妙に途切れ途切れになって内容が聞き取れません。
「妙な雑音？」のようになってしまって、返って気になります。

実用上は「3～4人が同時に話した内容を全て聞き取る」必要は無いのですが、「自分がその時に聞きたいと思った人の発言が聞き取れない」のは困ります。

参加者は皆、自宅からのアクセスのはず。
各人のネット環境や、その時にパケットの通ったルートによっても会話品質が違うんでしょう。

ヘッドセットの性質によってはキーボードの音を拾い易かったり、PCの音声入力（とヘッドセットの相性？）によって雑音が乗ったり、声が小さめだったり、面白いものです。

同時並行してチャットも出来ますが、実際の開催時には書籍やテキストファイルを見ながらのやり取りになります。
当然のことなんでしょうが、「慣れ」が必要ですね。
同時に余り多くの手段を利用してしまうと、どれをどう見れば良いのか？、アタフタしている間に取り残されそうな不安も残ります．．．。

まあ、とにかく１回開催してみよう！
「出来ない」というレベルの結果ではなかったので、本番の勉強会をSkype会議で実施してみることになりました。

ブログランキング！

ランキング挑戦中！

勉強会：オンライン会議準備

勉強会の場合、平日の業務終了後に町田事務所に参加者全員が集るのは大変だ（契約形態の云々に関わらず、客先で業務に当たるメンバーが大半なので）。

２時間前後以上を要する勉強会の場合、平日に実施するのはチョイトきつい。
可能ならばオンラインで行いたい。

そんな声を受けて、「ユースケース実践ワークグループ」の次回開催はオンライン会議（Skype利用）を想定しています。
しかし、いきなり当日本番で「ダメでした」では話にならない。
ちなみに、参加者数は10名には満たないはずです。

事前に全員がSkypeアカウントを取得するのは当然として、本番日以前に接続・試用してみようという事になりました。

基本的には書籍ベースの勉強会なので、事前に決めた担当者からの「担当章のポイント要約」メールを受けておいて、後は音声ベースのディスカッションで何とかなりそうです。

時には整理の為に白板を利用する事もあるので、Web上で共有する電子白板を併用した方が良いかも知れませんが（無償のWebサービスなども有るようです）。

で、今夜（7/2）22時が試行時刻です（各人、自宅からアクセスします）。
私も、ヘッドセット購入（980円）とSkypeアカウント取得・接続確認を済ませました。
問題なく、実用に耐えると良いのですがね。

ブログランキング！

ランキング挑戦中！

勉強会：英語に親しもう！

6/25(木)の夕方の定例会（17:00～19:00）後、「英語に親しもうの会」が実施されました。

17:10～17:25の15分間です。
今回は出席できないメンバーの１人が題材を準備してくれました。
原文：http://www.catb.org/~esr/faqs/hacker-howto.html
和訳：http://cruel.org/freeware/hacker.html

別サイトに和訳もあるので、「ただひたすら読む！」よりも「読んだ感」が得られ易いかも知れませんね。

とにかく、この勉強会は「ライトに、ただ回し読みするだけ」で、英文への抵抗感を減らすのが目的です！
本来は「意味が分からなくてもOK」、「発音もこだわらない（明らかに違えば相互に指摘するくらい？）」というポリシーで運営されてます。
どの回から参加してもOK！

今回は５人のメンツですね。
ほぼ並行して「S2WG（ワーキンググループ）」が行われるので、今回は会議室にこもってます。

「S2WG」が19:30頃からまったりと始まった（夕食の買出しから、環境確認、早々にメシをほお張る者も）ので、大半のメンバーが冷やかしに参加（乱入？）。
と思ったら、２人は最後までいましたね。

ブログランキング！

ランキング挑戦中！

雑記：「鮭」プリッツ

あるんですねえ、「鮭」プリッツ．．．．．。

メンバーが何処かから仕入れて来てくれたんですが、「鮭プリッツ」。
でかいです。
ジャンボサイズですね。

いや、形は普通（？！）に細長いんですが（別に鮭の形をしているわけではない）、ちょっとパイ生地風で太かったでしょうか。

小袋に分けて、１袋に２本だけ入ってました。

ピンク色の粉がいっぱい付いてます。

１袋だけ、試しに食べてみました（後学の為ですので）。

うううむ、確かに鮭の風味と味！？
塩鮭ですな、これは。

「粉にしたらフリカケとしてご飯が食べられる！」と言ったメンバーもいましたが、なるほど、そんな感じですね．．．。

後味が「鮭」です。
意外とリアルに魚独特の生臭さも再現されていたりして。
皆さんも店頭などで見つけましたらお試しあれ（決して強くは勧めませんけど．．．）。

ブログランキング！

ランキング挑戦中！

勉強会：S2WGです！

今回は、夕方の定例会（17:00～19:00）の終了後に「２時間以内で終了」を前提にして実施しました。

前回が出席者不足と、特にチューター側に立てるメンバーの不足で、ちょっと厳しい結果になってしまったので、建て直しの回でもあります。

今回は「SAStruts（Super Ajile Struts）」と「S2JDBC」の組み合わせで、チューターから出題された問題をハンズオンで解いていく（小さなシステムの挙動を拡張していく）というものです。

「ゼロから組み上げたのでは時間が足りない」、「皆、実戦経験者なので、既存アプリを拡張・変更する」というパターンから入った方が習得が早い！、ということで、このような設定になってます。

今回はアーキのメンバー、S2関連の実務経験者などが加わり、ペアプロを基本として実施しました（前回の反省から再決定したポリシーです）。
さすがに「全員が順調にサクサク」というわけには行きませんが、アーキの人物と技術部マネージャは進みが早めです。

時間的に「空腹」との葛藤に苦しむ時間帯なので、皆、晩御飯（或いは間食）を用意してます（写真にもちょっと写ってますね）。
麺類系を選択した人の中には、課題に取り組む方を優先してしまって、晩御飯が悲しい事になったメンバーもいたようですが．．．。
汁がPCに飛ばないように、低い姿勢で「ズゾゾ～ッ」と面をすすっている光景が印象的でした。　　あはは。

いや、笑い事ではない！
皆、自分の（自分達の → 相互の）精進の為に頑張ってくれてます。
別の勉強会（英語WG）からもメンツが合流して、始まって間もなくから結構な賑わいを見せました。
結局、最後（21:00）まで残っていたメンバーもいましたね。

結局は、都合1.5時間しか無かったのですが、土日ではなく平日の開催の分、集中してことに当たる事ができたようです。
最後の15分ほどを使って、次回以降の方向性確認・調整と、次回開催日時を決めました。

次回は日曜日のAM10:00から。
う～～ん、頑張ろう！

ブログランキング！

ランキング挑戦中！

定例会でした（2009/06/25）

6/25(木)-17:00～は定例会でした。

・17:00 ～ 17:15 (15)　社長の話（収支報告、考課面談の話、他）
・17:15 ～ 17:25 (10)　業務連絡等　[業務推進部、他]
・17:25 ～ 17:55 (30)　IT-Tips　[Har]
・17:55 ～ 18:00 ( 5)　（休憩）
・18:00 ～ 18:55 (55)　Eclipseプラグイン大会（２）
　　　　Hudson[Oh]、Selenium[Mas]、VMware関連[Yam]
・18:55 ～ 19:00 (05)　振り返り(KPT)

新社長からは四半期ごとの収支報告（キャッシュフローなどのグラフ提示なども含む）、考課面談のスケジュールなどの話がありました。

Eclipseプラグイン大会は２回目の実施です（実際には「プラグイン」に限定はしていないんですが）。
前回の事前ネゴ不足の反省から、事前に「誰に、何について、どのような視点から話をしてもらうか？（デモは可能かどうか）」を確認・調整し、実施に至りました。

CI（Continuous Integration）サーバーとしての機能を持つ（拡張用のプラグインも、かなり多彩）Hudson（ハドソン）の実務例の話。
カバレッジ管理用のプラグインと併用することで、自動ビルド＆自動テスト＆品質に問題がある場合のメール通知などをすることも出来る。
特徴的なのはプラグインの豊富さ以外に、GUI（Webベース）での各種設定の容易さ、プラグイン拡張のし易さなどがあるとのこと。
各種のオープンソース・プロジェクトでも活用されており、実績と品質にも問題は無さそうです。
AntやMaven2といったツールの話題は聞いていましたが、Hudsonは今回初めて聞きました。　　勉強不足ですねえ。

続いてSelenium（セレニウム）。
何か金属元素のような名前ですね。
WebブラウザとWebサーバーとの間に入って、双方に対してのHTTPイベントなどを起こしてくれる。
通常ならWebブラウザから手動で行わなければならないテストを、JUnitベースのテストコード群で代用できるというものです。
実際の手動操作を記録してくれる機能もあるのかどうか？（プラグイン拡張などで）、ちょっと未だ未調査です。
しかし、Seleniumと協調して動くWebブラウザ用のプラグインもあるようなので、「見かけの厳密なテスト」ではなく「機能上のテストの再現性」は確保できそうです。

JUnit系（テスト駆動）全般に言えることですが、そもそも「テストコードを書くのかどうか？」の前提ポリシーも必要ですね。
闇雲にテストコードを書くのでは、コストばかり跳ね上がってしまい、納期にも影響します。
対象システム／コンポーネントの寿命想定、リリーススケジュールと品質担保計画などから、テストコードを書く対象を定める（絞る？）ポリシーも重要ですね。

利用しているところでは「何をいまさら」と思われるでしょうが、実例として聞く機会は決して多くはありません。
「早速、明日からリソースとスケジュールを立てて、可能なところから調査を進めよう！」。
技術部のマネージャよりも先立って発言してくれるメンバーがいることは、とても嬉しい事です！

ブログランキング！

ランキング挑戦中！

お仕事：キャリア管理システム運用

会社によっては既に稼動・運用されている例も見受けるのですが、アスペア的には未だ本格稼動には至っていません。

α版のWebベースでのシステムは既に立ち上がっているので、既存社員のキャリア情報の入力を行い、並行してβ版（中身的にはαのアップデートと言うよりは新規スクラッチですが）のシステムを立ち上げようとしています。

各人のキャリア・データ入力は着手したところ。
α→β版へのデータベース移行の為の小プロジェクト（担当は１名のみ、短期ですが）は大半が完了しているようですね。

キャリア管理システムのβ版は、別の者が他のタスクと並行して構築中です。
（ちなみに、残業は殆どしてませんので念のため）

このシステム立上げの１つの狙いとして、「チーム構成のシミュレーション」が挙げられます。
「どのようなメンバーリングをすると、どんなところが強い／弱い（リスクが上がる）」を、結果が出る前に予測でき、対処法などの検討やメンバー構成の再検討、導入計画の参考にすることも出来ます。

また、全社的なキャリア傾向も視覚化され、改善方向も認識出来るようになるでしょう。
いままではマネージメント担当者の認識範囲、印象・勘、イメージなどに頼っている部分も（正直を言えば）有りました。

このような面でも、人物依存によるリスクを抑えることが出来ればと思います。

ブログランキング！

ランキング挑戦中！

硬めの話：会社ロードマップとキャリアマネージメント

前回の定例会（6/12）の際に、先ずは５年間＋その先の方向性に関するロードマップが社長から公開されました。

無論のことですが、社長１人が決めただけで自動的に結果（会社実績）が着いて来るわけがありません。

メンバー１人１人のキャリアの積み重ね、スキルセットと力（もったいぶった表現をすれば「コンピテンシー」ってやつ）が前提になります。
勿論、それを実現するための営業活動的な工夫と実践、キャリア・マネージメントの継続実施が必要です。
各人の人生と中期的な経営判断は、同一のものじゃありません（強く影響は出るでしょうが）。

単に、「会社としてこういう方向を向いた」から、それにひたすら合せてキャリアを積もう、というわけではありません。

アスペアはオブジェクト指向技術と各種のWeb関連技術に特化・積上げてきました。
それらの経験値と資産（シーズ）を活かしつつ、我々「アスペアが目指すべき市場の要求（ニーズ）」に応えるべく、方向性とターゲットをより具体化し、絞り、必要要素も従来よりずっと具体化したという事です。

今までも「チャレンジシート」という形で、各人に目標設定してもらい、チーム運営や営業、マネージメント面からの支援をして来ました（必ずしも十分だったとは言えないと思いますが．．．）。
これに対して、アスペアとしての指向性と時間軸上での計画を、今まで以上に関連付けてキャリア・マネージメントをしていく事になります。

市況が厳しくて思うように運ばない部分も有りますが、顧客（エンドユーザー、或いはそれにほぼ近いお客様）からの評価を戴けて可能となっている部分も少なくありません。

ターゲットとすべき市場から求められる、市場に対して提案できるロール（役割）セット、テクノロジー、そして企画・改善提案。
それらから必然的に定義される役割（スキル）セットを自社内で定義している最中です（別にITSSを否定するわけでは有りませんが、自社の主たる基準としては馴染まないと見ています．．．）。

スキルセットは単一のビューから単純に表現できるものではありませんが、表現方法と目的を履き違えないよう、常に見直しながらも大胆に進めて行きたいと考えています。

ブログランキング！

ランキング挑戦中！

定例会：リベンジに向けて！

前回の定例会（6/12）の内容を以前に、その失敗談を直前に書きました。
しつこくも、その後日談を書くことにします。

Eclipseプラグインを中心として、開発支援ツールの利用経験などに関して、社内アンケートを取ってあります。
誰が何を知っていそうか？
当たりは付けられる訳です。

単純な対処法ですが、有用なネタを吐き出せそうなメンバー個別にメール打診をして、「これについて話せるよね？、ダメ？、デモ必須かな？、デモ準備にどのくらい時間が掛かる？」などを確認している最中です。

幾つかのネタを具体化できて来ているので、次回定例会（6/25）時にリベンジ開催（？）する方向で考えてます。
これで、前回ほどのグダグダにはならないで済むでしょう（多分）。

このブログにも別の回で書きましたが、現在、アスペア独自の開発プロセス（先ずは一定の前提に基づく１パターン）を構築中です。
擬似プロジェクトで調査・検証しながら反復を繰り返しますが、ツールの適用とガイドライン策定もプロセスの中に含まれます。

プロセス策定に関わるのは一部の人間のみですが、ベースとなる情報は集約し・共有したい。
開発プロセスを社内公開した際には、皆で叩きたい。
叩く側のレベルを底上げしておきたい。
「ああ、あれは知ってるな」、「あれ？、これはもっと良い選択肢があるんじゃないの？」、「それは違うんじゃないの？」、そんな反応を、良い意味で期待したい。

今回のリベンジ開催も、上記の為に必要な要素の１つだと思ってます。
だから、しつっこいんです。

ブログランキング！

ランキング挑戦中！

定例会：Eclipseプラグイン大会の議事録音

先日の定例会（6/12）に、事前に社内アンケートをしておいた、要はEclipseと連携できる開発支援ツールの類に関しての社内調査（２アンケート）をベースとして、対面でナレッジを交換できる場を設けましょう！、って事でした（このブログにも書きました）。

．．．が、当日の議事録を見る限りでは、最後の振返り（Keep,Problem,Try）で「グダグダだった」と記されてます。
企画者本人である私が当日欠席し、事前ネゴも不足だったことが主因ですが、果たしてどのような進行だったのか？

書記担当者（持ち回り）にも参加して欲しくて音声記録（デジタル）に頼ったんですが、昨日、私の方で聞いてみました！
う～～～ん、確かにグダグダだ．．．。
要約をテキスト化しようと思った（後日の検索などにも活用できるように）のですが、肝心の部分が声が小さくて聞き取れません。
ナレッジを聞きたい人の質問内容、持っている人が吐き出している言葉が聞き取れないのでは話になりません。

企画・進行的な無理も有りましたが（時間も、事前想定より大幅に短くなってしまったが）、記録方法自体にも工夫が必要です。
そんなに広い執務室ではないのですが．．．
座席配置も結構集中していたはずなので、その真ん中辺りの天井から、レコーダーをぶら下げるとか、した方が良かったかも知れませんね。
（コンサートホールなんかに見かけられる集音方法です）

幸か不幸か、欠席した技術者が２名のみだったので、当日話題に上げられたツールに関しての多少の共有（「？？？」の人もイメージだけは掴む）は、概ね出来たんじゃないのかな？、と思います。

コストをかければ、もっと充実させられたのでしょうが、現実的な条件下でどこまで出来るのか？
なかなか難しいですね．．．。

ブログランキング！

ランキング挑戦中！

勉強会：S2WGの今後？

Seasar2とその周辺コンポーネントをベースに、実務とは全く別に技術面での実戦的なナレッジを身に付けて行きましょう！、ってことで発足したS2WG（ワークグループ）。

数日前にここにも書きましたが、今後の開催が危ぶまれていました。
しかし、市場動向や営業状況に依存したスキルアップでは限界がある。
能動的な選択と自己投資により、売れる技術の習得も必要だ！、ということで発足した勉強会ですから、ここで頓挫（とんざ）するってのは情けないです。
と言うか、自分達の近未来の可能性を自ら捨てるようなものです。

そこで、メンバーの集まり易い定例会後に「今後について」ディスカッションしました。
その中で、後続の学習者から最も先に進んだと思われるメンバーをチューター役として再設定し、次回以降の開催日・実施内容も決めました。

基本的に１ヶ月に１回の実施なので、どうしても前回までの内容を忘れてしまう．．．。
今後は、チューターの再設定（【Oon】さん、宜しくー！）と、今までも個別にはやって来た「ペアプロ」を基本前提とすることで改善しようということになりました。
また、開発環境（利用PC）が入れ替わってしまうリスクを考慮して、NotePCに識別番号を貼り直したり、各人（各ペア）のプロジェクト情報をサーバーに保存するなどの幾つかのポリシーも定めました。

また、参加者を一層確保するために、定例会の機会を利用して、定例会の終了後の開催（目処として19:00～21:00）、所要時間も２時間に限定して集中実施する事としました！

体力的にはちょっとしんどいですが、休日にまったりやって実が少ないよりは、時間効率は間違いなく良いでしょう。
その代わり、あまり頻繁には実施できませんが．．．（月１回を超えるペースは辛いでしょうね。体調を崩すようでは、お客様に迷惑がかかりますから）。

今まではTeedaとSAStrutsと並行して各人多少ばらついた進め方になっていましたが、今後は限定統一＆集中して実施し、時間軸的には直列にナレッジを積んでいく事になります！

ブログランキング！

ランキング挑戦中！

勉強会：ユースケース実践WG（４）

6/14(日)-AM10:00～12:55、ユースケース実践ワークグループの４回目の活動を実施しました（名著：「ユースケース実践ガイド」がベース）。
１名が腹痛で欠席、６名での実施になりました。
午前中の頭の冴えている内に集中実施して、終わってから昼メシにしようってことです。

土日はビルの入館制限がされているのですが、各人が所持しているセキュリティカードのセキュリティレベルに差異があるということが始めて分かりました。
レベルの低いカードを持っているメンバーが自力で建物に入れず、ちょっと開始時点でオロオロしましたが．．．。

普段、別プロジェクト、別現場であったりして顔を合わせないメンバーも一同に集まり、書籍ベースに解釈・認識合わせ、身近な現実とのマッピング、実用への適用・応用可能性などについて話し合います。

元々が米国の著者なので、当然（？！）ながら翻訳本をベースにしています。
翻訳時点での日本語・日本の表現習慣などへのマッピングに苦労されたりしたんでしょうね。
実戦的で分かり易い、かつ正確な定義に努めてくれている分、文章構成・表現的に日本人に違和感のある部分が少なくありません。

１人で読んでいると、自分の経験・認識範囲から判断して飲み込んでしまいますが、数名が集まると、すんなりと同一認識に至らない。
当然だと思って読み進めてしまっていながら、実は理解していなかったり。
勉強会として複数名で話す場を設けると、この辺の不完全さ・認識の危うさを客観的に補完できますね。

予定を（やはり？）オーバーして、約２．５時間で終了。
各章末の練習課題（これが最も勉強会として期待していた部分でもあるんですが）で、熱く燃え上がります。
真剣な議論に笑いが混じりながら、活発に和やかに、ワイワイと時間が過ぎていきました．．．。

途中で数分の休憩をしましたが、この機会を活用して具体的な技術解決の為の情報交換、サンプルの受け渡しなどをしているメンバーもいました。
嬉しいですね。

さて、次回の開催に関してはスカイプでのオンラインミーティング（全員！）という方向になりました。
プロジェクト毎にローカルで使用しているケースは有りましたが、グループミーティングに利用するのは初めてです。
事前にスカイプのチェック機会を設けるなどして、最悪は対面で実施しようというバックアップ設定をしつつトライしてみることにします。

ブログランキング！

ランキング挑戦中！

定例会でした（2009/06/12）

6/12(金)-17:00～、定例会でした。
今回は出席率が高い！
技術部としての欠席は２名だけでした！（事務所が狭い～っ！！）

・17:00 ～ 18:10 (70)　社長の話：2009年4月度収支発表、今後に向けて
・18:10 ～ 18:15 (5)   （休憩）
・18:15 ～ 18:55 (40)　Eclipseプラグイン大会
・18:55 ～ 19:05 (10)　振り返り、業務連絡

出席率が高い！、と言いつつ、実はこの記事を書いている私自身は別件があって出席できませんでした．．．。
なので、当日の議事録（社員専用Wikiベース）と事前の調整の流れ・情報から書き込みしてます。

社長から非常に重要な発表がありました！
詳細は出せませんが、体外的な部分は追々、http://www.aspire.co.jp の方に公開されていきます（一部は既に更改されていますね）。
先ずは今の厳しい市況の中でも自社の得意部分を失わず・伸ばしていきながら、ビジネス形態を段階的にシフトしていこう！、というものです。
（概要とみ表現すると、自社コントロール・自社企画の比率を上げていこう！、ということです）

後半では、Eclipseプラグイン大会、やっちゃいました！
事前に２つほど社内アンケートを取って、結果を社員用Wikiにアップしておきましたが、それから発展させて対面で具体的なナレッジ交換と議論をしようじゃないか！？、という企画です。

．．．で、時間枠として40分しか無いのですが、当然ながら全然収まりませんでした。
元々複数回にまたがるだろうとは予測していましたが、事前の調整（私の根回し・準備）不足も効いて、かなり混沌としたみたいです（出席していないので、分からない．．．）。
定例会の書記は、全員が持ち回りで担当しているんですが、今回は「全員が議事に加わる」べきだ。
なので、音声記録を取ってもらって、後で私の方で要約だけを文書化し、音声ファイルも社内Wiki公開する予定です（私もこれを聞くのが楽しみ（不安？）です！！）。

最後の振り返りを見ても、前述の後半コンテンツ（Eclipseプラグイン大会）に関連付けて、「開発効率の向上」という視点で議論したいという希望（Try）も挙がっていますね。

ブログランキング！

ランキング挑戦中！

雑記：ますこっと？

ウチの会社の前田社長に第二子が誕生しました。
前回の定例会で、有志による記念のプレゼントをしましたが、ご本人の赤ちゃんと一緒の写真を見せてくれました（社員用Wikiに上がっていたものを、社長の了承を得て転載してます）。

そばに一緒に横になっている、ポワポワのペンギンのぬいぐるみが、今回送ったものですね。

未だ本当に生まれてから日が経っていないので、お猿さんのようです（失礼！）。
「赤ちゃん」とはよく言ったもので、本当に赤いですよね。
激しく泣くと、もう真っ赤です。
赤ん坊用の小さなバスタブ、懐かしいですね～。
この頃は本当に片腕で軽く抱えられますが、未だ首が座っていない頃は、お風呂に入れるのも恐る恐るでした．．．。

ブログランキング！

ランキング挑戦中！

お仕事：テスト支援ツール、その後．．．

前々回に、「何らかのテスト支援ツールの利用実績（正社員限定）」の書き込みをしましたが、折角なのでその後に関して勝手に報告させて頂きま～す。

未だ応答が返って来ない人（出産・育児などに伴う休職中の人を含む）が若干名いますが、９割は間違いないですね。
良かったです、少しホッとしました。
全社員の２／３じゃあ、幾らなんでも少な過ぎますから。

テスト支援ツールの総数は１６種類。
Javaと.NETの両方ですから、改めてみると結構多いですね。

CheckStyle、
DBUnit、
DJUnit、
EclEmma、
JMeter、
JMock、
JProve、
JUnit、
MicrosoftStressTool、
NUnit、
S2Unit、
VirtualMockObject、
Hudson、
cobertula、
FindBugs、
Selenium、

経験数が重要だとは思いませんが、どのような自動化ツールが存在して、そのメリット・デメリットを理解した上で、ケースバイケースで取捨選択できる必要はあると思います。

別のアンケート調査で、「実在は知っているが気になっている（未だ経験値が無い）」ツールに関しても、社内という括りではナレッジが存在しているので、今のままの「足し算状態」では勿体無いです！

少なくとも伝達が比較的容易な「形式知」に関しては、近日中に可能な限り共有する機会を設けたいと考えてます。

ブログランキング！

ランキング挑戦中！

雑記：運動会でキュ～

私事になってしまうんですが．．．．．
つい先日の日曜日、子供らの小学校の運動会がありました（毎年、春に実施しているんですね）。

その直前の金曜日の夜に、気分転換とストレス解消の為に「軽く」（のつもりで）主に腰から下の筋トレをしたんですが、翌日の土曜日から筋肉痛でバリバリのヨタヨタでした．．．。
ビールを美味しく飲みたくて、意地汚くムキになって短時間に動き過ぎたんでしょうか？

結構な年齢なんで、通常の筋肉痛なら２日後にならないと痛み出しません。
それが、翌日からバリバリ。
これは拙いなーと思いました。
まあいいや。　運動会って言っても、父兄競技とか参加する予定は無いし。

自宅から徒歩で15分ほどの小学校まで、ヨタヨタと歩いていきました。
敷物のビニールシートや弁当やらの荷物を抱えて．．．。

で、到着してみると、係りのPTAのお母さんにいきなり、「あっ、○○さんのパパっ！、父兄競技に出て下さい！、人数が足りなくって困ってるんですっ！、有難う御座います～～！」
「へ！？」と思っている私の意志とは別に、目印のオレンジの鉢巻が手渡されていました。

本番で転びこそしませんでしたが、ヘロヘロしながら競技に参加。
結果は、チーム戦でビリ。
私のせいじゃないですよ！？

そもそも、「軽い運動」のつもりでバキバキの筋肉痛になってしまった時点で情けなかったです。
普段から少しは走ってたんですが、殆ど効かないんだなあと実感しました。

仕事の中では様々な人達と、様々なシチュエーションで会って会話・協議をしますが、気力・体力不足でフニャフニャしていては仕方が無い。
健全な心は健全な体から！
．．．ってことで（他の下世話な目的もあったけど）運動したんですが、体はバランス良く計画的に鍛えましょう！、ということで。

ブログランキング！

ランキング挑戦中！

お仕事：DI&AOP、テストの経験

アスペアは「Webの実装屋」ではありませんが、アーキテクチャの選択幅やテスト方法（生産性、品質に関わりますからね）において経験値の高さは必要だと思ってます。

で、現状でのWebアプリケーションの構築においてフレームワークの適用（既存、或いは新規開発かは別として）が無いということは極めて珍しいのではないでしょうか？

特にここ数年では、DI&AOPはデファクトになって来ましたね。
代表格は、なんと言ってもSeasar2とSpringでしょう。
で、試しに現有社員でのDI&AOP実務経験の経験者率を調べてみました。
約２／３。
Springの方が多いです（DI経験者の中で２／３くらい）！
意外でした。
もうちょっとS2の方が多いような印象だったのですが。

ついでにテスト支援ツールの利用者比率も調査中です。
未だ途中ですが、２／３を超えたところ．．．．．。
これも意外でした！、少ないっ！？
会社で管理しているスキル情報から抽出したものを元に、事実確認をしている途中（社員専用Wikiベースで）なんですが、「テストツールまで書くものなのか？」の基準が統一されていない可能性があります。
ダメですねえ。
Web上での内製システムでキャリア管理を始めようとしている（パイロット版のシステムは、もう稼動可能な状態です）のですが、運用規約の整備が追い付いていません。

しかし、多い者では10種類近いツールを利用して来ています（勿論、Web系限定での話ですよ）。
「テスト工程だけをオフショアにする」ようなケースも見かけますし、小振りのシステム開発においても生産性・精度を大きく引き上げるツールの適用は必須です！

さてさて、最終的にはどのくらいの数字が出るんでしょうか。

ブログランキング！

ランキング挑戦中！