Posts by atware:
- ライブラリやDBなどが5年前・10年前とでは充実度が違う
- 高速性ではなく落ちないサービスであれば良い
- １年間にメンテナンスでストップする時間は許容される
- 最低ラインの底上げがすごい
- 本当に必要な分を必要な分だけ使う
- 小さい分工夫することを忘れない
- 小回り重要
- かじが取りやすい事に繋がる可能性を秘めている
- 「ブレードを導入すると…」
- 「アジャイルを導入すると…」
- 「仮想化を導入すると…」
- クラウドサービス + オンプレミス
- AWS
- Heroku
- Rackspace
- 他多数のPaas・Iaas
- クラウドは便利だけど過信は禁物
- 最低限の可用性は考えておこう
- 方法は色々ある
- サービスや会社など特性にあわせて整えよう
- クラウドはおいしいよ
- 先ずは、自分が楽しむことを考える
なんといっても、デートですから。自分も楽しまなきゃウソですよね？
自分が楽しくなければ、彼女を心から喜ばせることは出来ないと思うのです。
先ずはわがままになって、自分が楽しみたいことをベースに色々とアイデアを考えます。 - 次に、彼女の希望を取り入れる
とはいえ、彼女の誕生日です。わがままばかりでは、いけないはずです。
いくら、自分が楽しみたいことが凄く魅力的に見えても、これで完璧だって思ってちゃダメなはずです。
ここで、冷静になって「彼女の希望」を過去の発言から思い出したりしなければいけません。
ここ重要ですよ。 - ミックス
自分がやりたい事。彼女がやりたい事。
これが出揃ったらそれをうまい事ミックスさせましょう。
これで、自分も、彼女も楽しめる素敵な素敵なデートプランが出来るはずです。
なんたって、二人の希望を取り込んだプランなのですから。 - 実行
せっかく考えた、素敵なデートプラン。
実行せねば何の意味もありません。
自信を持って実行しましょう。 - 何故休む事にしたのかを聞く
- 自分のような考えもあるが、それについてどう思うかを聞く
- 自分の考えを理解させ、説得する
- クラスタリングソフトが不要
- 負荷分散装置・共有ストレージが不要
- 動的なスケールアウト
- 分散型インメモリデータベース
- １秒以内のフェイルオーバー
- 「ブレードを導入すると…」
- 「アジャイルを導入すると…」
- 「仮想化を導入すると…」
- クラウドサービス + オンプレミス
- AWS
- Heroku
- Rackspace
- 他多数のPaas・Iaas
- クラウドは便利だけど過信は禁物
- 最低限の可用性は考えておこう
- 方法は色々ある
- サービスや会社など特性にあわせて整えよう
- クラウドはおいしいよ
スモールスタートと制約・節約
6月 9th, 2011
スモールスタートのお話です。
クラウドという快適な環境にどっぷりと使っており、リソースを湯水の如く使えるようになってきたので、スモールスタートの大切さと制約を書いてみたいと思います。
現実
個人・企業のサービスを含め、ほとんどのスタートアップサービスで「SLA 99.9X」「巨大トラフィック」というケースはほとんどないのではないでしょうか。
実際には上記ほどの規模ではないにしても、設計時にはSLAや現実を数十?数百倍を超えたトラフィックが要件となっており試算して設計・開発をおこなう事がしばしばあります。
そうなると、メモリ8Gでクアッドコアなどの高スペックサーバが選択され、クラウドを利用した可用性まで考えてしまいます。
本当にそこまで必要でしょうか？VPSの768MBじゃ足りませんか。
うまくやれば、多くのケースではVPSスペックで処理を捌けてしまうのです。
低スペックで良い理由
環境一つとってみても、CPUとメモリ以外に考えられるポジティブな要因。→ 非同期やイベント駆動型ライブラリや高性能でリソースをあまり使わないデータストアやアプリケーションサーバ。プロトコルの活用方法のナレッジやメッセージングサービス。ストレージの分離とローコスト化。
十二分に処理を捌ききれる要素はたくさんあります。
また、作り次第では幾ら高性能のサーバを要していても、そもそもスレッドセーフになっていなかったり、DBやキャッシュの使い方がまずかったら、サーバの性能が意味のないとまではいかなくても全く活かしきれていないシステムとなってしまいますね。
レスポンスの速度も数msの差が命取りになるというケースは、スモールスタートのサービスには少なく、落ちずに待ち時間なく快適に使えればユーザは満足します。
一人のユーザが365日欠かさずそのサービスを使ってくれたら、それはそれで信じられないくらいの大成功ですが、年に数えれるくらいのメンテナンスもユーザは許容してくれるでしょう。
信頼性の担保はバッファがあるとは同一でもありませんし、そうなると、低スペックマシンでもいいんじゃないかという気にもなってきませんか？
低スペック環境の価値
信頼性と将来性の担保が欲しい為に高スペックや過度な可用性と仕組みを最初に作るとします。それはそれで良い事かもしれませんが、逆の発想をしてみたいと思います。
低スペックであるという事は、今手持ちのリソースをフルに活用しないとやっていけません。チューニングや最適なシステムを設計する事は必須となります。小さくても基本的にチューニングが必要ないほどデフォルト設定を弄らなくても良いシステムは素晴らしいシステムです。
ですが、トラフィックやデータが増えると性能低下がでてきます。早い段階でボトルネックに遭遇できるのでシステムが機能によって肥大化する前にかじ取りをすることができるので、柔軟性が高いシステムとユーザやデータ特性を理解やすくなります。
ユーザの意見をとりいれつつ洗練された仕組みで動くシステムであれば、拡張性がでてくるのは想像に容易いことでしょう。スモールスタートにそれなりの規模なインフラや性能を最初から用意するとサービス的に画期的でもヒットしなかった時のリスクは大きく、次のスモールスタートの足かせになってしまいます。
つまり、結果的により早く価値あるサービスと拡張性あるサービスを作りつづけて行きたいのであれば、低スペックな環境から始めるのも悪くないと思います。*1
ローマの道はLinuxBoxに通じる
個人的にLinuxBoxも触っています。LinuxBoxもVPSのロープランに通じるところがあってCPU ARM1.2GHZ,ROM 512MB,RAM 512MB,SDカード拡張というものです。
ROM512MBの中にOSが入っていて512MBのメモリの中でやりくりしないといけません。LinuxBoxはついこの間までは64MBや128MBが主流で多くても256MBでした。ですが、今は512MBや1GBのメモリのLinuxBoxが多いのです。前者と後者の差は普段デスクトップやノートパソコンで使っている以上に歴然とした差があって、512MBだとかなりの性能を出す事が出きるのです。
aptやyumでopen-sslをインストールすると依存関係で何MBのパッケージがインストールされるかご存知でしょうか？私が好きなVimをインストールすると依存関係で何MBでしょうか？MySQLやPostgresは…？
下手するとそれぞれ10数%以上占有します。
open-sslは必要に応じてインストールする必要がありますが、用途によってはインストールしないという選択もありますね。Vimをいれないと開発効率が落ちまくって作業にならないと思いますよね。*2でも、vim-tinyでは駄目ですか？LinuxBoxで作業する時はvim-tinyでなんとかしのいで、vimの機能を使いたければ、sshfsでLinuxBoxをマウントしてローカルのVimで作業するのはどうでしょうか？DBはSQLiteがぴったりかもしれませんね。
そういう風に環境をWebサーバやアプリケーションサーバを含め言語やツールまで用途に合わせて選択していくと、2世代くらい前のラックマウントが担当していた事をLinuxBoxにさせることができるんです。
消費電力とスペースと音の差は歴然ですよ！LinuxBoxは無音ですし。稼働部品が少ない分しっかり作ってLinuxBoxであれば故障率やリスクはラックマウントより少ないかもしれないとか。そうじゃないとか。真相はSLA測定できる機会もあると思うので、試してみたいと思います。そう考えると、LinuxBoxは低スペックでもメリットはいっぱいありますね。
まとめ
クラウドが大好きな私ですが、きっと小さな環境でカスタマイズしたりVimが好きだということもわかって頂けたと :)
是非、皆さんも気軽にスモールスタートアップをやってみましょう！
*1：低スペック環境でも可用性や複数台構成に発展できるように考慮しておくのは大前提ですが
*2：えぇっ。えっ？
コメントは受け付けていません。
クラウドとディザスタリカバリのおいしい関係
6月 3rd, 2011
今日は、クラウドとディザスタリカバリのおいしい関係について考えてみたいと思います。
あの東日本を襲った大地震の後『ディザスタリカバリ（disaster recovery）』という言葉をよく聞くようになりましたね。
ディザスタリカバリとは「災害時の復旧」や「大規模システム障害」などの運用ができなくならないように、復旧や対策からシステムを回復させたり、予防させる事をいいます。
序章
4月に開催された「アマゾン・ウェブ・サービス(AWS) クラウド・アドバンテージ・セミナー」ではAWSジャパンの玉川さんセッションでは、震災後に企業の合言葉で「夏までに作れ」というのが流行ったそうです。今までは、クラウドを使うと今までより安くなるからという理由で企業は検討を導入していたケースが多かったそうですが、本来のクラウドの特性を活かした導入推進に変わってきているとのお話されてました。
これは、すごいことだと思います。
に通じる所があって、コストで判断するだけでなく、各特性を活かしてこその導入だと思います。きっかけというのは大事なもので、クラウド化に拍車がかかり当社も震災日の数日後に一部の社内インフラをクラウドに移行しました。
激震の再来
AWSやVPSなどのクラウド環境を提供しているサービスに一気にユーザがなだれ込んだけ結果。一部のVPSではリソースが足りず申し込み待ちの状態になります。*1
そんな中、4月の末にAWSの米国東リージョンに大規模障害が発生してしまいました。簡単に説明しますとデータを永続化するEBSに障害が発生し、EBSを使用しているEC2のサーバインスタンスとクラウド型RDBサービスRDSにまで影響しました。詳細な障害内容は下記レポートをご参照下さい。
今回のAWSの障害はユーザ数が増えた事（トラフィック）とは直接的に関連せず、特定の障害が連鎖して大きなシステム障害至ってしまいました。AWSほどのSLAを誇るサービスでも、障害は発生するのだというのを身近なスマートフォンアプリやサービスが実はAWSを使っていて、使用できなくなった方は身に染みて体感したのではないでしょうか？
天変地異でデータセンターやサーバールームが使えなくなる事もあれば、大規模障害でクラウドサービスでも使えなくなってしまう事があります。
ディザスタリカバリに備えるには
AWSではリージョンごとに独立して（異なるデータセンターで稼動と思って頂ければ）サービスを提供しています。複数リージョンにまたがってシステムを構成すれば、今回のように特定のリージョンでサービスを維持して提供ができることでしょう。そういう事を想定して複数のリージョンが提供されていますし、RDSでは複数のAvailability Zoneを利用したMulti-AZという最新のデータベース更新を保護しながらデータベースの可用性担保できる仕組みが供されています。AWSのサービスとは関連はありませんが、例えば、分散KVSのデータストアである「Cassandra」も複数のリージョンに設定で分散できるように意識して作られています。
これで、クラウドにだけ移行すれば「ディザスタリカバリに備えた事になる」とは言えない事が簡単にわかりますね。
上記のサービスや利用すればこれで完了でしょうか？
いえまだです。
私が考えるベターな対応
ここからは、システム規模・好み・完璧性・コスト・手間のバランスになりますが、こんな対応がいいのではないでしょうか。
ハイブリッド型
企業に向いているタイプでは。プライベートクラウドとパブリックグラウドを組み合わせます。サービスをクラウドとオンプレミスの双方で提供する場合、クラウドが落ちた時にどのようにオンプレミスで継続させてサービスできるように切り替えれるようにするかということを予め色々と考えておく必要がありますね。
マルチクラウド型
クラウドサービスのいい所はインフラ管理がとにかく楽なところですね。勘所がわかってくると手放せなくなります。ですが、特定のクラウドサービスだけ利用していると、リスクが高くなります。そういう時に、RightScaleのようなマルチクラウドマネージメントサービスを利用したり、同じような管理の仕組みを作ったりする事が必要ですね。
サーバーテンプレートのような仕組みはとても便利で、1度書けば1台でも10台でも管理・構築が簡単にでき、マルチクラウドを意識したデプロイやサーバーテンプレートを作っておけば、リカバリ時にも役立ちますね。マルチクラウドを扱う事はリスクは減りますがコストが増大するので、信頼できるクラウドサービスであれば事前にリージョンを活用する例でほとんど事足りてしまうのです。
依存が嫌なのですよ。というケースや複数環境で動くようなシステムを意識するような人には向いているのかもしませんね。
まとめ
AWSとGAEを筆頭として日々進化しているクラウドプラットホームですが、クラウドの特性を活かすとコストやリスクを減らすだけでなく、すごく楽しいシステムが作れます。活用できそうなケースがあれば、波にのって色々なサービスで利用してみるといいと思います！
*1：私個人の考えですが「クラウド」とはユーザ自身または、クラウドのプラットホーム自身で伸び縮みができてこそクラウドではないかと思います
コメントは受け付けていません。
Pomodoro Technique
4月 13th, 2011
はじめまして木村です。
今回は時間管理テクニックのひとつであるPomodoro Techniqueを紹介します。
Pomodoro Techniqueは、Francesco Cirillo が考案した時間管理術です。
イタリア語で「Pomodoro」とはトマトを意味し、
Cirillo が学生時代に、「割り込みを減らし、集中して勉強をしよう」と、
10分間集中して勉強をするために、時間を教えてくれるものとして
トマトの形をしたキッチンタイマーを使ったことが由来となっています。
slideshare 「Pomodoro Techniqueのすすめ」をご覧下さい。
色々と応用も効くので、だらだら作業してしまうより、Pomodoro Techniqueを利用し、
メリハリをつけて作業をしてみてはいかがですか？
参考URL the Pomodoro TECHNIQUE
コメントは受け付けていません。
はこだてIT見本市
(2日目)
3月 6th, 2011
函館ラボラトリーの高橋です。
先日の3/4(金)、3/5(土)、『はこだてIKA』主催による
ビッグイベント【はこだてIT見本市】が
函館市若松町のWAKOビル3Fにて開催されました。
前回分に引き続き、2日目のレポートを書いてみます。
拙い文章ですがお付き合いください。
2011/03/05 (土)
昨日に引き続き肌寒い天候の函館。
旭川から出展された企業の方に「寒いねー」と言われてしまいます。
「まぁ朝10時からは人来ないよねー」なんて話していたことが嘘のように、朝から徐々に人が入り始めます。
私は午後からの当番だったのですが、ちょっと油断していました。
嬉しい誤算です。
弊社のブースも中々の人の入りで、説明員が応対に追われています。
2日目の人の入りにアルティスタの進藤さんも説明に熱が入ります。
ちなみにこちらのブースでも来場者にノベルティを用意してました。
オシャレ可愛い缶バッジでした。抜け目無いです。
他のブースもご家族連れの来場者様や
地元の学生などで、なかなか盛況の様子で一安心。
本当はひとつひとつのブースを
ご紹介したいところなのですが
私自身ほぼ自社ブースに詰めていたため
全てを写真に収める時間も
ゆっくり説明を頂く時間もありませんでした。。。
出展して頂いた企業の方々には
充分なご紹介が出来ず本当に申し訳ないです。
そして、この日も取材ラッシュは続き
地元のケーブルテレビNCVさんが
全ブースをインタビューして回っていました。
なんとIT見本市をニュースの1コーナーではなく
1本の特番として番組を作成して頂けるとのこと！
ありがたやありがたや。
弊社ブースは当然松舘が対応します。(今回広報担当)
2日目の終了時間間際の取材だったため
誇張無しでフラフラになりながら、最後の大仕事でした。
NCVのアナウンサーの方が
美人さんだったから頑張れたんだと思います。
NCVのアナウンサーの方が
美人さんだったから頑張れたんだと思います。
(大事なことなので2回言いました。誤植じゃないです)
そうこうしている内に2日目も終了の時刻を迎えてしまいます。
半年以上前から準備していたお祭りが終わってしまうことに肩の荷が下りて胸を撫で下ろす気持ち半分、もう終わってしまうのかという気持ち半分。
どんなものでも祭りのあとは寂しいものですね。
この場を借りて、今回のお祭りに関わってくれた全ての方々にお礼を申し上げます。
ありがとうございます。ありがとうございます。
業務で忙しい時期に出展してくださった企業の方々、寒い中来場してくださった方々
その他の形でこのお祭りを支えてくださった全ての方々に感謝です。
不慣れな運営でご迷惑をかけた方や不愉快な思いをされた方も少なくないかもしれません。
ごめんなさい。反省点は山ほどあります。
全て次に活かしてみせます。
次回開催の予定は全くの白紙の状態ですが、いつか必ずまたやります。
来年かもしれないし、再来年もなるかもしれません。
でも、必ずやります。
今回のお祭りが地域に根付くものになるようこれからも尽力して参ります！
コメントは受け付けていません。
はこだてIT見本市
(1日目)
3月 5th, 2011
函館ラボラトリーの高橋です。
先日の3/4(金)、3/5(土)、『はこだてIKA』主催による
ビッグイベント【はこだてIT見本市】が
函館市若松町のWAKOビル3Fにて開催されました。
今回はその開催レポートを当日の熱気冷めやらぬままに
書いてみようと思います。
2011/03/04 (金)
前日までの穏やかな天候とは一転して3月の函館らしからぬ肌寒い空気が市内一帯を包んでいました。
この日は開催初日のため、各社のブース設営から始まります。
14:00の開場に向けて準備を急がなければいけません。
私は業務の都合により14:00少し前に会場入りしたのですが、アットウェアのブースはバッチリ準備OK！
ARコンテンツ：『新鮮！イカール星人』と
Androidと連携したネットショップ：『函館ゆめはち村』を引っさげての参戦です！
ちなみにこのWAKOビル3Fは、現在一部しか使用されておらず、メンテナンスもされていなかったため、はこだてIKAの推進メンバーが仕事の合間を縫ってこの日のために少しずつ掃除や修繕を進めてきたのです。
出展企業の方から「思ったより全然綺麗だったよ」との声を頂き報われた思いと同時に、ホッと胸を撫で下ろします。
入り口には大きなスクリーンを用意し、各社の出展内容を写しています。
これも前日になってギリギリで用意したものでした。
間に合って良かったです。
右手に貼ってあるポスターは知人のデザイナーにご好意で作成頂きました。
今回はフライヤーに当日のパンフにと大活躍！
(大助かりでした。ありがとう！！ ※私信)
他の出展企業の準備も着々と進んでいる様子。
ミュートネットの濱田さんが何やら自身満々です。
手前にあるのは、アンケートに答えた方へ配られる
ノベルティグッズ。抜け目無いです。
もともと服飾などのテナントとして使われいたので
元の造りを活かして、どこのブースも見栄え良く
飾られていきます。
そしていよいよ開場の時刻。
「全然人来なかったらどうしよう」という心配を他所に
まず詰め掛けたのが地元メディアの方々。
函館では初のイベントとなるため、
地元メディアの関心も高い様子。
各社のブースに『取材待ち』の行列が
出来るシーンも見受けられました。
この日は平日だったためか、スーツ姿や、ご高齢の
来場者様が多かったように思います。
会場があっという間に外の寒さを
吹き飛ばすほどの熱気に覆われました。
もちろん弊社のブースに足を止めてくださる方も多く、
不慣れながらも精一杯応対させて頂きました。
そして次から次へとやってくる人の波に
あれよあれよ時間が流れ、
初日の開場時間が終了してしまいました。
会場からの撤収作業もそこそこに、この後は出展企業者同士の懇親会に雪崩れ込みます。
函館グランポルトさんを貸し切っての立食パーティ。
製品の説明に枯らした喉が、冷たいビールを求めて止みません。
各社の紹介を行う2分半のライトニングトークにも感嘆の声や、笑い声が沸き起こり、
次々と運ばれる美味しそうな料理に、会場も盛り上がりを見せます。
ライトニングトークの後は、お決まりのご歓談タイム。
ライトニングトークの内容で盛り上がったり、展示内容に関する興味深いお話を聞いたりと皆様も思い思いに楽しんで頂けていたようです。
楽しい時間は過ぎるのも早いもので、ちょうどよく酔いがまわってきた所で会もお開きの時間を迎えてしまいます。
函館市役所の方から労いの言葉を頂き、弊社松舘による『IKA締め』という名の謎の締め方で
懇親会も終了し、第一日目の日程が全て完了しました。
ちなみに懇親会は楽し過ぎて写真撮るの忘れてました。
ごめんなさい。
コメントは受け付けていません。
朝の一作業
7月 14th, 2010
石上です。お久しぶりです。
前回書いてからずいぶんと時間が経過してしまいました。
弊社では、「作業効率を上げる」という取り組みを以前から行っており、
時間を意識し、作業効率を上げる一環で、水曜定時退社（19時）デーと言うものがありました。これには
・家族と接する時間を作ろう。
・友達や仕事関係の方と交流しよう。
・セミナーなどへ参加する時間を作ろう。
などの目的が含まれています。
この試みを行って数ヶ月、「水曜だけじゃなくてもいいよね？」という意見が上がり、水曜だけでなく、毎日、定時（17時に変わりました）をより意識して作業を行おうということになりました。
ですが、これまでと作業量が変わることはありませんので、
「定時に帰る」という期待通りの結果を生むには、より効率よく、より集中して、仕事を終わらせなくてはいけません。
もちろん、品質は落とさずに。
そこで、私が効率よく集中して作業できるだろうと考え実践している（しようとしている）ことを１つご紹介させていただきます。それは、
「毎朝、その日のタスクを整理することからはじめる」
です。
「そんなの当たり前だよ」というご意見も聞こえてきそうですが、私はそんなことをやっています。
では、タスクを整理するとはどういうことかと言いますと、
１．自分の抱えているタスクを見る
２．１の中でその日実施するものをピックアップする
ということだけになります。
また、上記に挙げたことを実施するには、
・自分が抱えているタスク全体
・自分が抱えているタスク全体のボリューム
・自分が抱えているタスクの期限
が把握できていること（これが大変なのですが；）が必要になり、
1つのタスクを必要以上に深追いしてしまうことを避けることや、
今やる必要がなければ後回しにしたり、スケジュールに間に合いそうになければ、他の人にお願いしたりすることも考えて実践しています。
これを実践している効果は、毎日定時に帰れるとまでは言えませんが、
その日実行するタスクが明確になることで、効率よく作業が行えていると感じています。
みなさんも「毎朝、その日のタスクを整理することからはじめる」を実施して、
時間というものに対する意識を強めてはいかがでしょうか。
コメントは受け付けていません。
横浜FC 選手の方々と記念撮影
4月 27th, 2010
みなさん、こんにちは。
先日、横浜FC 選手の方々が弊社に来てくださいました!!
DF 15 金裕晋選手
DF 22 中田 健太郎選手
DF 26 伊藤 竜司選手
お越しいただいた瞬間に私が感じたことは
「デカッ!!」
身長が高かったり、体格がガッチリしていたり、加えて、プロのオーラが出ているから、より大きく感じたのかも知れないです。
記念撮影をする前に、お話をさせて頂きました。
個人的には、通訳付きの会話というものが初経験で、不思議な感覚を体験しました。
(横浜FC 通訳 金 明豪さんありがとうございます)
そして、記念撮影の時間です。
まずは、まじめにパシャリ。
社員を集めて、パシャリ。
あれ、そのボールは・・・
そして、大きさを強調するためにパシャリ。(伝わりますか？)
テレビの向こう側でしかお目にかかれないような方々とお会いでき、とても素敵な時間を過ごさせて頂きました。
今期、まだ、試合の観戦に行けていないので近いうちに三ツ沢に伺います!
選手の方々の勇姿とご活躍を楽しみにしています♪
コメントは受け付けていません。
企画する人！
3月 15th, 2010
皆様。こんにちは、アットウェアの梶平と申します。
突然ですが、僕は妄想（発想）することが大好きです。自分の武器にしたいと思ってます。
いつの日か、凄く面白い妄想を生んで、出来るだけ多くの皆様に愛されるような ”企画”を企てたいと思い、修行の日々をおくっております。
未だ未だ修行中の身でありながら、企画する人！なんてタイトルのコラムを書かせて頂くのは、大変、恐縮なのですが・・・
これも、修行の一環です！！
なので、頑張って＆楽しんで書かせて頂こうとおもいます。
是非、お付き合い下さいませ。
突然ですが・・・
妄想とは考えることですよね。
では、”企画”ってなんでしょうか？
うーん。。
新規の事柄を計画すること？
面白いことを企てること？
・・・なんか、イメージが沸きづらい気がします。
僕が、企画者になりたい！と強く思った時、尊敬する僕の企画のお師匠様より、それはそれは、ありがた?いお言葉を授かりました。
それを紹介させていただきます。
梶平：「師匠！！企画って、いまいち、どういう事をすればよいのか、イメージが沸かないんですよね！？」
師匠：「うむ。企画って、そんなに難しく考える必要は無いんだよ。」
師匠：「たとえば・・・」
師匠：「彼女の誕生日、彼女の喜ぶ顔や、驚いた顔を見たくて、デートで何処に行こうかな？とか
プレゼントは何にしようかな？とか考えて実行するでしょ？」
梶平：「はいー、考えますー！！」
師匠：「それが、企画する ってこと。」
梶平：「！？！？????っ☆★☆★」
どうですか！？！？
凄く分かりやすくて、企画って言葉を身近に感じませんか？
僕は、この師匠様のお言葉が大好きです。
企画とは何か？という質問に対する「答えの本質」が全て詰まっていると思うからです。
デートプランを考えるとき、皆様はどの様なプロセスで考えます？ちなみに僕は・・・
どうです？どうです？？
企画を考えるときも、基本的には上記のとおりのプロセスで進めていけば・・・
自分も、相手も喜んでくれる素敵な企画が生まれそうな気がしてきませんか？
では、次に、企画の大切な要素である「アイデア」はどうやって生み出すのでしょう？
また、生み出したアイデアをどうやって管理すればよいのでしょう？
次回は、その辺りのことについてお話をさせて頂きたいとおもいます。
最後まで読んでくださった方、本当に有難う御座いました。
コメントは受け付けていません。
ソフトウェア開発の格言
3月 2nd, 2010
世の中には数多の「格言」と呼ばれる言葉があります。
それは偉大な先人達が後世に残した財産であり
ある時には1人の人間の人生を左右するほどの力を持つ言葉達です。
我々ソフトウェア開発の業界にも「格言」は存在します。
今日はそんなソフトウェア開発の格言をいくつか紹介してみましょう。
まずは有名なところで
『Good code is its own best documentation.』
Steve McConnell
（優れたコードというのは、それ自体が既に最良のドキュメントである。）
耳が痛い部分もありますが、まさしくその通りですね。
開発者として、常にこの心がけを持って開発にあたりたいものです。
「優れたコード」とは、難しい処理を行うことでも、
独創的な手法で書くことでもありません。
誰もが読める、理解出来るコードのことであり、
そしてそれが最も高度な技術なのだと思います。
『There is no programming language
no matter how structured
that will prevent programmers from making bad programs.』
Larry Flon
（悪いプログラムを防止するプログラミング言語は存在しない。
たとえどんなに構造化されていても。）
これまた耳が痛いですね。
「悪いプログラムは言語ではなく、人が作る」といったところでしょうか。
どんな言語であろうと、それ自体が悪いなんてことは稀で
大抵の場合はそれを使う人間が未熟であったりするものです。
『The trouble with programmers is that you can never tell
what a programmer is doing until it’s too late.』
Seymour Cray
（プログラマーは何をしているか、決して分からない。手遅れになるまで。）
なかなかグサリときます。
プログラミングはやはりPCに向かって作業をしている時間が1番長いわけで、
(ソフトウェア開発全体のスパンで見ると、決してそうとも限りませんが)
確かに管理者からすると実作業の中身が見えづらいことが往々にしてあります。
そうなる前に手を回し、見えないことを見えないままにしないのが
優れた管理者であり、優れた開発手法、管理手法なのでしょう。
他の人のコラムでもいくつか紹介されているので割愛しますが
もちろん我が社でもこうならないための予防策はいくつも実践されています。
(馴染めなくてボツになった策もいっぱいありますが)
私はアジャイル開発の現場に飛び込んで、まだ1年半ほどですが
アジャイル開発はこういった手法を「実践しやすい環境」のように思います。
『You can’t have great software without a great team,
and most software teams behave like dysfunctional families.』
Jim McCarthy
（素晴らしいソフトウェアは素晴らしいチームから生まれる。
そして、大部分の開発チームは崩壊した家庭のようだ。）
後半は皮肉を込めたブラックジョークなのでしょうが
前半の一文はまさにその通りだと思います。
ソフトウェア開発のほとんどは、大なり小なりチームで行われるものです。
残念なことにこの業界は体(または心も)を壊し、
去って行く人が多い業界と言われています。
「素晴らしいチーム」の定義は人それぞれになってしまうかもしれませんが
こういったメンバーを1人でも出してしまったチームは
少なくとも「素晴らしいチーム」とは呼べないでしょうし
どんなに利益を上げようと、そのプロジェクトは「失敗」です。
私も良いチームを作っていくことが、
より良いソフトウェアを作る最善の道であると信じています。
どうですか？
いくつか紹介した中にあなたの心に響いた言葉はあったでしょうか？
改めて見直すと「戒め」の格言が多いように思えますが
それはソフトウェア開発の世界において、
まだまだ改善する余地があるということなのかもしれませんね。
自分の仕事を見つめ直す意味でも、
今後もこういった言葉に触れる機会は大事にしていこうと思います。
コメントは受け付けていません。
第5回atWorksレポート
11月 26th, 2009
ソフトウェア開発プロジェクトでは、大きく2つの役割があります。
1つは、プロジェクトで作り手として活躍するエンジニア。
もう1つは、プロジェクトの舵を取るマネージャ。
この2つの役割における「心得」が、11/20に開催された第5回atWorksのテーマです。
当日は多くの方にお越しいただきました。
ご来場いただいた皆様、ありがとうございました。
「ソフトウェアエンジニアの心得」と題して講演いただいたのは、多くの著書、翻訳でも有名な柴田芳樹様。
現在もソフトウェアエンジニアとしてご活躍されています。
講演の中で印象に残った内容をいくつかご紹介しますと・・・
・ラッキーな業界
新しい技術が次々と出てくるので、ネタが尽きない。常に成長する機会が与えられるこの業界はラッキーなのです。
・ソフトウェアは資産
保守性の高いソフトウェアは資産である一方、メンテナンスが困難で多大なコストがかかる、あるいは作り直しが必要なソフトウェアは負債となります。常にコードをクリーンな状態を保つことの重要性を再認識しました。
・技術書を読むときのポイント
間違いがあるかもしれないと思って読む、というのが目からウロコでした。筆者が間違っていれば筆者へのフィードバックになり、自分が間違っていれば理解が深まる。なるほどです。
・早起き
ご自身の学習や執筆活動にあてる時間を設けているそうです。夜型で眠い目をこすりながらやるよりも効率的ですね（ちなみに、講演当日は4時起床だそうです！）。
・英語
最新技術動向を知るためには、やはり英語力。質問タイムでTOEICの点数を聞かれていましたが、その点数に脱帽でした。
IT業界は特別な資格がなくてもその職に就けるなど、参入障壁はそれほど高くありませんが、新陳代謝が活発で、そのスピードについていけない人はすぐに取り残されてしまいます。
その中で、自身の価値を高めながら現役を続行するための、1つのありかたを示していただいたと思っています。
2つめの講演は、弊社松舘による「プロジェクトマネージャの心得」。
文字通り、手法よりもマインドに焦点をおいた講演でした。
ブログではあまり内容に触れていませんので、簡単にダイジェストを。
・目標やスケジュールは重要。しかしすべてがスケジュールどおりにうまくいくと思わないこと
・現実をよく見きわめ、どうすれば目標に近づけるかを考える
・マネジメントを経験しながら自身のスタイルを確立していくこと
・現在の問題に取り組みながら、先のリスクを考えること
ほかにもたくさんの話題がありましたが、最後のスライドのメッセージ「Never Give Up!」がすべてを物語っているような気がします。
詳細は、ブログに掲載されるのを期待しましょう（フィードの登録をオススメします）。
2つの講演で出てきた共通のトピックが「コミュニケーションの重要性」。
ソフトウェアは人がつくるということ＝つくる人同士が相手の言うことを理解すること
というのを再確認することができました。
今回のatWorksは、
エンジニアにとっては、これからのキャリアを決める上での参考に。
マネージャにとっては、エンジニアの成長を援ける上での参考に。
ということで、どちらの立場の方にも「一粒で二度おいしい」セミナーになったのではないでしょうか。
ただ、1セッション60分という短時間に凝縮された内容だったので、若干の物足りなさがあったかもしれません。
皆様のご意見を次回以降のatWorksに反映してまいりますので、ご期待ください！
今回ご参加いただいた皆様も、都合によりご参加いただけなかった皆様も、次回のご参加をお待ちしております。
開催日が決まりましたら、弊社ホームページにて告知いたしますので、よろしくお願いいたします。
コメントは受け付けていません。
ジェネレーションギャップ
9月 24th, 2009
ジェネレーションギャップとは、
｢世代による文化、価値観、思想などの相違のこと。｣
とあります。(ウィキペディアより)
最近、20代前半の人達との間で身近に感じる事が多く、いろいろと考えさせられます。
(全員とは思っていません。そのように感じる人が多くいると感じています。)
何故そのように感じるのか･･･
一番の原因は『自分を基準に』考えているからではないでしょうか。
しかし、自分を基準に考える事は当然です。自分が変わり者だと思う人はあまりいない
と思います。
例えば、私はサッカーをやっているのですが、チームのメンバーで怪我をした人がいました。
すると、そのメンバーは｢怪我をしたので試合の日は休みます。｣と言います。
私だったら応援も出来るし、試合の準備や試合に出る人の手伝いも出来ると考えます。
ここで
『何故？(ギャップ)』
が発生します。
(実はここでストレスが溜まっていたり･･･)
このような場合に頭ごなしに試合に来るように言うとします。(本当は思いっきり言って
やりたいのですが･･･)
きっとその後は同じような状況となった場合、試合に来るようになると思います。
ですが、これではギャップは埋まらないと思います。
行動の内容は明らかに私のほうが良いように思えます。(多分ですが･･･)
では、次のように対応してみたらどうでしょうか。
このようにすればお互いの考えも伝わり、ギャップも小さくなるのではないでしょうか。
そして、ここで大切な事は『コミュニケーションをきちんととる』という事だと思います。
上記の例は趣味の話なので、あまり真剣に考える必要はないかもしれません。
では、仕事だったらどうでしょうか。
このようなギャップはある程度、業務の進捗・遂行に影響を及ぼすのではないでしょうか。
あるテレビ番組で女性アナウンサーの特集があり、そのアナウンサーの教育係りであった
先輩アナウンサーが当時の様子を話すコーナーがありました。
｢少しきつい事を言うとすぐに泣き、少し褒めれば調子に乗る。私達の価値観では対応
できないと思った。｣と笑い話として紹介していました。
しかし、その後で真顔になり｢この子達と一緒にやっていくためには自分が変わらなければ
ならないとわかった。｣と言いました。
何故、自分が･･･と思う人もいるかもしれませんが、仕事を円滑に進めるためには動ける人、
変われる人が行動するべきだと思いますし、しなければなりません。
今後、もっと歳の離れた人と一緒に仕事に取り組んだり、お客様として応対していく事になる
はずです。
自分の価値観、思いを一方的に伝えるだけではなく、自分の価値観の範囲外の物事に対し
ても柔軟に対応できる力を身に付けたいと思います。
コメントは受け付けていません。
MySQL Clusterを調べてみた
9月 7th, 2009
弊社のプロジェクトで、利用頻度の多いデータベースはOracleなのだが、
最近、実際のプロジェクトでOracleを使用した際に、あまりいいサーバ構成
でないケースにおいて、Oracle本来の性能が発揮されないことがあった。
そこで、同様なケースのとき、MySQL Clusterではどのようなパフォーマンス
になるのか調べてみることにした。
興味があった特徴は以下の通り。
仕様上は、高速に動作しそうだったため、実際どうなるのか試してみることにした。
まず、
・VMWareで、仮想マシンを用意。
・CentOSをインストール。
次に、
・MySQL Clusterをインストール。
・管理ノードを１つ、データノード/SQLノードを２つ作成。
・２つのMySQLが同時に動作している状態。
そして、
・１つのMySQLで、テーブルを作成し、データを登録してみる。
すると、
・もう１つのMySQLにもテーブルが作成され、同じデータが登録されている。
うまくインストール出来たようだ。
よし、
とりあえず、１セッション、１レコード、１トランザクションで、
大量にデータを登録してみた。
10万件のデータを登録。133秒
普通のMySQLでも同じ処理を試す。
10万件のデータを登録。48秒
# insert処理で、約2.8倍の性能差があった。
これは２つのSQLノードへの負荷分散をしていなかったり、
チューニングしていないので、メモリをちゃんと使えていなかったり、
ネットワークの状況に影響されたりと、MySQL Clusterの性能が出る
ようにしてあげれば、実プロジェクトで利用可能な状態に持っていく
ことが可能だろう。
今日のところは、簡単な動作確認をした程度だが、
引き続き、実プロジェクトで適用可能かどうか調査を
進めたいと思う。
コメントは受け付けていません。
私が仕事をしながら常に気にかけている２つの事柄
7月 31st, 2009
『肉じゃがとカレー』
とある夕飯の出来事、その日のメニューは肉じゃがでした。
いつも美味しい料理を作ってくれる妻に対して
「肉じゃが美味しいねー」
と、感謝の意を述べる。
その翌日の夕飯の出来事。
メニューはカレーでした。
これまた美味しいカレーを作ってくれる妻に対して
「カレー旨いねー」
と、敬意を表する。
ここで妻が一言。
「肉じゃがもカレーも、材料と作り方ほとんど同じなんだけどね。」
…
そうなんですか、気付かなかったなぁ。
出来上がった料理の味は全く違うのに、作る工程はほとんど同じだなんて。
と、中学の家庭科の授業で得意料理を「冷凍みかん」と答えた私は思うのでした。
さて、私はシステムを創ることを生業としておりますが、
仕事をする上で気を付けていることがあります。
それは
「一見違うように見える複数の事象の中に共通点を見つけ出す」
ということと
「一見同じように見える複数の事象の中に異なる点を見つけ出す」
ということです。
【一見違うように見える複数の事象の中に共通点を見つけ出す】
先ほどの肉じゃがとカレーでの話しに戻りますが、
・じゃがいもの皮をむき、適当な大きさに切る
・にんじんの皮をむき、適当な大きさに切る
（カレーの具は口の中でゴロゴロする位主張している方が好きです）
・玉ねぎをスライスする
・鍋に油を引き、材料を炒める
・灰汁が出てきたら丁寧に除去する
など、共通のタスクが多いです。
例え話なので少し現実味に欠けますが、これをプログラムのコードで表した時に、
cookNikujaga()
cookCurry()
という二つのコードそれぞれに実装してしまうと、
「玉ねぎの真ん中に発癌性物質が発見されました。」（もちろん仮説です、誰も信じないと思うけど…）
という新事実が発生した時に、
cookNikujaga()
cookCurry()
双方のコードで玉ねぎの真ん中を撤去する修正が必要になってしまいます。
ややもすると、cookCurry()の修正を忘れてカレーを食べるたびに発癌性物質が蓄積されることになってしまいます。
現実のシステム開発では、このような新事実（仕様変更）はかなりの頻度で発生します。
お客様の要件に柔軟に対応するため、またバグを出しにくくするために
共通の処理は１箇所にコーディングすることが重要です。
また共通の処理を探し出す努力を惜しまないことが大切です。
壊すのは容易いが、修復するのは難しい。
処理を分けるのは容易いが、後から同じにするのは難しいのです。
【一見同じように見える複数の事象の中に異なる点を見つけ出す】
こちらは共通点を見つけ出すことのアンチテーゼです。
これを疎かにするとお客様の詳細な要求を取りこぼすことになります。
行き過ぎた抽象化は何にも当てはまらなくなってしまう。
「何でも出来る」は「何にも出来ない」のです。
医者の薬もさじ加減｡
肉じゃがはお箸で食べますが、カレーはスプーンですよね！
以上、私が仕事をしながら常に気にかけている２つの事柄でした。
皆様も「あれ」と「これ」のどこが同じで、どこが違うのか、
日常の生活であれこれ考えてみては如何でしょうか？
頭の体操になりますよ！！
コメントは受け付けていません。
アウトプットしてモチベーションをあげよう！
7月 22nd, 2009
今日は、クラウドとディザスタリカバリのおいしい関係について考えてみたいと思います。
あの東日本を襲った大地震の後『ディザスタリカバリ』という言葉をよく聞くようになりましたね。
ディザスタリカバリとは「災害時の復旧」や「大規模システム障害」などの運用ができなくならないように、復旧や対策からシステムを回復させたり、予防させる事をいいます。
序章
4月に開催された「アマゾン・ウェブ・サービス クラウド・アドバンテージ・セミナー」ではAWSジャパンの玉川さんセッションでは、震災後に企業の合言葉で「夏までに作れ」というのが流行ったそうです。今までは、クラウドを使うと今までより安くなるからという理由で企業は検討を導入していたケースが多かったそうですが、本来のクラウドの特性を活かした導入推進に変わってきているとのお話されてました。
これは、すごいことだと思います。
に通じる所があって、コストで判断するだけでなく、各特性を活かしてこその導入だと思います。きっかけというのは大事なもので、クラウド化に拍車がかかり当社も震災日の数日後に一部の社内インフラをクラウドに移行しました。
激震の再来
AWSやVPSなどのクラウド環境を提供しているサービスに一気にユーザがなだれ込んだけ結果。一部のVPSではリソースが足りず申し込み待ちの状態になります。
そんな中、4月の末にAWSの米国東リージョンに大規模障害が発生してしまいました。簡単に説明しますとデータを永続化するEBSに障害が発生しEC2とクラウド型RDBサービスRDSにまで影響しました。詳細な障害内容は下記レポートをご参照下さい。
今回のAWSの障害はユーザ数が増えた事（トラフィック）とは直接的に関連せず、特定の障害が連鎖して大きなシステム障害至ってしまいました。AWSほどのSLAを誇るサービスでも、障害は発生するのだというのを身近なスマートフォンアプリやサービスが実はAWSを使っていて、使用できなくなった方は身に染みて体感したのではないでしょうか？
天変地異でデータセンターやサーバールームが使えなくなる事もあれば、大規模障害でクラウドサービスでも使えなくなってしまう事があります。
ディザスタリカバリに備えるには
AWSではリージョンごと（異なるデータセンターと思って頂ければ）サービス提供しています。複数リージョンにまたがってシステムを構成すれば、今回のように特定のリージョンでサービスを維持して提供ができることでしょう。そういう事を想定して複数のリージョンが提供されていますし、RDSでは複数のAvailability Zoneを利用したMulti-AZという最新のデータベース更新を保護しながらデータベースの可用性担保できる仕組みが供されています。AWSのサービスだけでなく、例えば、分散KVSのデータストアである「Cassandra」も複数のリージョンやAvailability Zoneに設定で分散できるように作れています。
これで、クラウドにだけ移行すれば「ディザスタリカバリに備えた事になる」とは言えない事が簡単にわかりますね。
上記のサービスや利用すればこれで完了でしょうか？
いえまだです。
私が考えるベターな対応
ここからは、システム規模・好み・完璧性・コスト・手間のバランスになりますが、こんな対応がいいのではないでしょうか。
ハイブリッド型
企業に向いているタイプでは。プライベートクラウドとパブリックグラウドを組み合わせます。サービスをクラウドとオンプレミスの双方で提供する場合、クラウドが落ちた時にどのようにオンプレミスで継続させてサービスできるように切り替えれるようにするかということを予め色々と考えておく必要がありますね。
マルチクラウド型
クラウドサービスのいい所はインフラ管理がとにかく楽なところですね。勘所がわかってくると手放せなくなります。ですが、特定のクラウドサービスだけ利用していると、リスクが高くなります。そういう時に、RightScaleのようなマルチクラウドマネージメントサービスを利用したり、同じような管理の仕組みを作ったりする事ですね。
サーバーテンプレートのような仕組みはとても便利で、1度書けば1台でも10台でも管理・構築が簡単にでき、マルチクラウドを意識したデプロイやサーバーテンプレートを作っておけば、リカバリ時にも役立ちますね。マルチクラウドを扱う事はリスクは減りますがコストが増大するので、信頼できるクラウドサービスであれば事前にリージョンを活用する例でほとんど事足りてしまうのです。
依存が嫌なのですよ。というケースや複数環境で動くようなシステムを意識するような人には向いているのかもしませんね。
まとめ
AWSとGAEを筆頭として日々進化しているクラウドプラットホームですが、クラウドの特性を活かすとコストやリスクを減らすだけでなく、すごく楽しいシステムが作れます。活用できそうなケースがあれば、波にのって色々なサービスで利用してみるといいと思います！
コメントは受け付けていません。
横浜FC・観戦記
6月 24th, 2009
最近、横浜市内、様々なところで「横濱開港150周年」という文字を目にします。
横浜在住・在勤の方、その他の方もご存知だとはおもいますが、今年、横浜は開港150周年を迎えます。これに伴い「開国博Ｙ150」が開催されています。
私も、期間中に「開国博Ｙ150」にいってみようと思っています。
(詳細は⇒こちら)
さて、ご存知の方もいらっしゃるとは思いますが、アットウェアは横浜FC(サッカーJ2)のホームタウンパートナーです。
実は、「開国博Y150」も横浜FCのホームタウンパートナーとして協賛しており、共に横浜FCを応援しています。
先日、横浜FCの試合の応援に行ってきたのですが、スポンサー紹介でも、同一画面で表示されていました。
この日(6/3)のニッパツ三ツ沢球技場は、6月にも関わらずとても寒く、身震いしながらの応援でした。それでも、スタメンで【カズ】が出場していたので、テンションは上がりっぱなしでした。
周囲で観戦していた方々の話に耳をダンボにしながら、サポーターの応援にのりながら、応援しました。
フリエ フリエ 起こせハマの友よ♪
フリエ フリエ 青と白の革命を♪
試合結果は、0対1と残念な結果ではありましたが、楽しく観戦させて頂き、普段、感じないような高揚を感じることができ、リフレッシュされました。
また、応援に行きます!!
そういえば、横浜と同じ港町の函館。実は、函館も開国150周年をもうすぐ迎えます。
(詳細は⇒こちら)
可能であれば、こちらのイベントにも足を運んでみたいと思っています。
コメントは受け付けていません。
JavaOne2009 現地?レポ(6/5号)
6月 9th, 2009
こんにちは、佐竹です。
6/5はJavaOne2009最終日のレポートなのですが、すっかり遅くなって「現地」レポートじゃなくなってしまいました・・・。というのも、最終日は日本人の参加者（及び関係者）が集まる通称「蟹パーティー」に参加して深夜にホテルに戻り、翌朝はホテルのチェックアウトにずいぶんと手間取り（ネット費込みの予約のはずだったのに別に請求されて抗議するもナカナカ通じず・・・最終的にはタダになりましたが）、現地の土曜の朝出発して自宅に戻ったのがもう日曜の夜だったり・・・。
—-
最終日の朝の General Session は例年、Java の父 James Gosling による Toy Show ということで、Duke’s Choice Awards を受賞したプロダクト/プログラム/プロジェクトや、その他の注目すべき（というか、Sunが注目してほしいと思っている）プロジェクトの紹介が行われました。自動車への組み込み事例が2つも含まれていたことが印象的です。その他、JavaFXのための開発ツールやJavaFXを組み込んだジュークボックスにTVなど、従来の情報端末の枠外への進出ぶり、あるいはその可能性を押し出したものでした。まさに「Java＝everywhere」。このフレーズはカンファレンス中のあちこちで使用されていました。
ところで、General Session の終わりに、今回のJavaOneでのホスト役を務めた Chris Melissions が、「また次のJavaOneで会いましょう」的な事を言った気がするのですが、どうなのでしょう。あると良いのですが。ちなみに去年はこのタイミングですでに次回（つまり今年）の開催日程が決まっていて、来年も来いよという呼びかけがあったのですが、さすがに今回はそういう発表はありませんでした。
General Session が終わると、一瞬JavaOneもが終わったかのような気分になりますが、そんなことはありません、前日までとは違って夕方までではありますが、引き続き 通常の Session が開催され続けます。ただし、Pavilion は前日で終わっていますし、記念品や書籍の販売も最後のSessionを待たずに終了するので、会場の一部では片づけが行われる中でのSession聴講となり、少し淋しい感じです。そんなわけで、実際にGenerarl Session の終了をもって JavaOne終了とする参加者も多いようで、人口はかなり減ります。そして、そのまま自然解散…の形でJavaOneは終わります。
—-
ほんのおまけの、どーでもいい話ですが・・・
朝の General Session の冒頭、Toy Show に先立って、「Dukeと記念撮影を忘れずに」と呼びかける一幕があったのですが、なんとその際にスクリーンに映し出された記念合成写真例の真ん中に私の作った合成写真が！
といっても、背景もなくDukeだけを配置したもので、自分が入っていないのですが。その中立性が採用理由でしょうか。
→佐竹作成の合成写真（？）
コメントは受け付けていません。
JavaOne2009 現地レポ(6/4号)
6月 5th, 2009
こんにちは、佐竹です。
朝のGeneral Session はMicrosoftでした。
Registration時に貰ったJavaOne2009ガイドブックには入ってなかったので、もしかしてスポンサーが減ってGeneralSessionが無くなったのかと思ったのですが、そんなことはありませんでした。ガイドブックの作製時期が古かっただけですかね。
さて、本日の聴講 Session は、午前中は JVM 上で動かすスクリプト言語についての Technical Session を2本（選択肢についての調査と、スクリプト言語ならではのデザインパターンについて）選択しました。
午後からは シングルサインオンのためのプロダクト OpenSSO を使ってみよう、という HandsOnLab に参加。100分と長めのSessionです。が、これが大変でした。PCが会場に用意してあるタイプのHandsOnLabなので準備不要で気軽に参加できる…はずだったのですが、最初に座った席のPCは何か環境が破壊されていたらしくサーバが正しく立ち上がらない。ヘルプの人もいろいろ試してくれたのですが解決しないので別の席へ移動することに。ところが今度はキーボードが壊れているらしくキーがうまく反応しない！
というわけで再び席を移動し、3台目でようやくまともに動かすことができました。
OpenSSO 自体は興味深かったのですが、ただでさえ英語でハードなのにトラブル続きで大変でした。でもまぁ、Tシャツとか貰いましたし、良しとしましょう。
HandsOnLabが中途半端な時間で終わるため、1時間ほど時間が空きます。Pavilion は今日の夕方で一足早く終了するということもあったので、ずっと Pavilion で過ごしました。Pavilion に行ってまず行くのは Amazon のブースです。去年もそうでしたが Amazon のブースは「Ninja Coder」というプログラムの日替わり問題を出しているので、それを解きに行くのです。プログラムなら言語の壁は低いので、心休まる瞬間です。解いたら英語で説明しなきゃいけないのですが。解くとステッカーと人形？が貰えます。ちなみにAmazon、ブースで何をしてるかと言うと純粋に求人活動っぽいです。他の企業はたいていプロダクトの宣伝とかしてるのですが、そういうの全くなくて、置いてあるパンフも思いっきり求人職種の説明と募集要項と、ちょっと珍しいです。
NinjaCoder、自社の面接で使ってみようかな（＾＾；
そのほか、興味深かったのは Alice という教育用のプロダクトで、いわゆるアバターのような感覚で作成した3Dの人形に動きを設定するのですが、最初は自然言語で設定していき、それが内部でJavaとして書かれているのを見ることができて、直接Javaコードを修正して動きを変更することができて…というのが、実はこのアプリは最初からNetBeans（Eclipseだったかも）にバンドルされているのでそのままIDEでJavaを書くことができるようになるという。LEGO・マインドストームでも同じようなことをしていると思いますが、プログラムに向いている子供が必ずしもメカ好きとは限らないと思うので、メカの興味から入るのとはまた違ってアリだと思いました
更にもう一本 Technical Session を聴講したのちは、IBMの General Session です。内容は・・・すみません、聞いてませんでした（・・；
General Session の後は After Dark というパーティがありました。去年は会場のすぐ隣（というか、Pavilion 会場の上）にある Yabe ガーデンという広場で行われ、今年もその予定だったのですが、雨天の可能性があったために近くのホテルに会場が変更になっていました。
私はというと、昨日も一昨日もBOF Session 不参加だったので今日ぐらいは・・・ということで、最初にちょっとだけ会場入りしてピザをつまんだ後、戻ってきて当初の予定通りの BOF Session を3つ聴講しました。ちょっと勿体なかった気もしますけど、ずっと残っている人も結構いました。
最後まで居ると9時を回るので、シャトルバスでホテルに戻りました。
—-
Pavilion も終わったことなので、整理を兼ねてこれまでの戦利品を確認してみたら、諸々あわせて50以上ありました。
前述のAmazonのアイテムのように重複しているものもありますが、それ抜きでも40種類くらいはあります。
去年のように飛んできたTシャツをキャッチできたりはしなかったのですが、気が付いたらこんなに。
とりあえず、同僚へのお土産は確保できたかな…。
コメントは受け付けていません。
JavaOne2009 現地レポ(6/3号)
6月 4th, 2009
こんにちは、佐竹です。
昨日は初日ということもあり、朝食からしっかり参加しましたが、実はホテルの部屋にスターバックスの朝食クーポンがあるので、今日はそちらを利用し、会場入りは朝の General Session １０分前といったところでした。今日の朝の General Session はスポンサーである Sony Ericsson によるもので、去年もそうでしたがスポンサーの General Session は若干不人気です。そのあたりは主催者側も重々承知なのでしょう、前日夕方に参加者へ送られたメールにて、スポンサーの Session に出ると賞品が当たるかもよ、というお知らせが。
Session の内容は、まぁ、Sony Ericsson の端末向けにJavaFXなアプリを開発してね（プラットフォームは用意するからさ） という感じでしょうか。
賞品の抽選は、どうやら開場前に椅子の裏？に何かが仕込まれていたらしく。よくわからないまま周りに合わせて椅子の裏を調べましたが何もありません。どこかで歓声と拍手が起こっていたので、きっと当選者がいたのでしょう。。。
さて、本日の聴講 Technical Session は、まず１本目は９時半から Project Jigsaw の解説から・・・だったのですが、昨日のTechnical General Session の中で使われていたプレゼンがそのまま使われて・・・でも１時間はなかったはずだから、後半は新しいことを言うに違いない、と思っていたら、途中のデモも全く同じで、半分ほどの時間で終わってしまいました。いきなり肩透かしをくらってしまった感じで納得がいかないので、次の Session の予定を変更してもう一つ同じ会場で別のSpeaker がやる、やはり Modul 関連の Session を受けることに。
早く終わった分は自由時間が生まれたということで、Duke と記念撮影をしてきました。本物の（といっても着ぐるみですが）の Duke は居ない時間だったのですが、今年は disital Duke との記念撮影ということで、CG合成した写真をメールで届けてくれるサービス（もちろん無料）がありました。
気を取り直しての２コマ目は、すごし具体的な言語仕様の変更点と記述方法などがあったので良かったです。午後からは Effective Java の作者による、ここ数年での Java の変化に伴って追加された新しいお勧め設計パターンを一部紹介する Session 、GlassFish を Mobile 向けに使うことの Session、Google スタッフによるメモリ管理に着目した Session 「Ghost in the Virtual Machine: A Reference to Reference」を聴講。真中の GlassFish と Mobility の話は恐ろしく不人気でした…GlassFish とタイトルにあるけれど、あまり GlassFish 前面に出てきませんでしたし…。（佐竹は今回の JavaOne で Session を選ぶ際にあまり余裕がなかったので、GlassFish と書いてあると取りあえず登録してたりします）
そして夕方にまた General Session です。今度は Sun による、JavaFX TV の話。JavaFX を使えば Desktop と Mobile だけでなく、 Entertainment 機器にもそのまま対応できるというわけです、と。スポンサー Session でもないけれど、最後に賞品引き換え券付きTシャツ投げをしてました。Tシャツだけでも羨ましい。
—-
本当は General Session の後も、BOF Session を２つほど聴講するつもりだったのですが、すこし疲れがあったので帰ってしまいました。BOFは「類は友を呼ぶ」のことで、Community などが発表をするのですが、ドキュメントよりもその場での聴講者とのやり取りに重点がおかれたりして、英語がデキないとかなりつらいです。多分寝ちゃうと思って潔く？諦めました。そしてホテルに戻って、このコラム書きながら寝てました…そんなわけで今すでに 6/4 の朝7時なわけです。
コメントは受け付けていません。
JavaOne2009 現地レポ(6/2号)
6月 3rd, 2009
こんにちは、佐竹です。
さて、いよいよ今回からが Java One 2009 本体のレポートです！
Java One 本体は朝食と昼食とおやつが出ます。なので朝は早くに行って朝食から参加です。朝食時間は7時から8時半ですが、8時半には General Session が始まってしまうので、ぎりぎりというわけにはいきません。（といいつつ、2回目以降の参加者は Alumni と呼ばれて、General Session に限り専用席があるので比較的良い席に座れますが。）
特に初日の朝、一番最初の General Session は基調講演になるので人出も多いです。
ところで、去年は「JAVA ＋ YOU」というメッセージ性の強い殺し文句が派手にプレゼンされていたのですが、今年はそれほどのものがありませんでした。基調講演のタイトルになっている「Change (Y)our World」がそれに当たるのかな、と思いますが、あまり派手に謳っている感じはありませんでした。どうなんでしょう、去年が派手すぎただけなのでしょうか・・・。
なお、基調講演の内容ですが、Javaがエンタープライズからモバイルまで幅広い端末で使われていることを、エンタープライズの例としてeBay、モバイルの例としてブラックベリーの開発メーカーと携帯電話回線業者から、それぞれゲストを迎えて語らせていました。また、情報端末に限らずエンターテイメント機器として、Sony Pictures Home Entertainment のブルーレイを、さらに Sun で開発している JavaFX TV の紹介・・・などなど・・・詳しくは私がここで書くより Java One のサイトを見た方が良いかもしれません。
そして最後には、「Sun が Oracle に買われたらJavaはどうなるの？」という質問に対しての答えとして、Oracleのゲストが壇上にあがり、Java はなくならないし、Java は Sun のもとでやっていかないといけない、というようなことを言っていました。個人的には Java よりも（というか、さすがに Java 自体をどうこうするなんて言わないだろうと思いますから）、Java One がどうなるのか、知りたかったのですが、それについてはあまり触れていなかった気がします。聞き取れなかっただけかもしれませんが、周りのネイティブの方々の反応から推測して・・・。
ちなみにですが、不況だとか新型のアレとかの影響で参加者が少ないのではないかとも思われましたが、そんなことはなかったようです。うじゃうじゃいました。なお、もはや周知の事実だと思いますが、マスクメンは皆無でした。
と、基調講演までの話でずいぶん文字数を食ってしまいましたが、その後 Technical Session 及び Technical General Session を夕方までみっちり受けております。本当は Java One 1発目の通常 Session として JDK 7 の話を聞くはずだったのですが、これが昼過ぎに行われる Technical General Session に土壇場で吸収された？らしく（ちなみに General とつく Session は基本的に、同じ時間に他の Session を一切行わず、全員の参加を促しています）。これが前日の夜になって中止の連絡があったため、急遽、まだ空いていて興味のある単語が含まれていた「GlassFish で ESB」な話を聞きました。が、恥ずかしながら ESB（Enterprize Service Bus） について勉強不足でついていけず。Session 聞きながら、というか Session そっちのけで、ESB について調べて勉強していました。（Java One の会場はFreeの無線LANに接続できます。部屋によっては電波が届かなかったり激重だったりしますが。）
Technical General Session （Java の今後の技術的展望）とその後に受けた Java SE 7 project coin （小さな言語修正の積み重ね）の Session は、特にそのあたりを重視して見ていることもあって目新しいことばかり、ではありませんでしたが、Java SE 7 で取り入れられる（パッケージの上位に位置するような）「モジュール」の定義方法と管理方法が具体的にデモで動いているのを見ることができましたし、project coin にも、調整中だったものの具体的な書き方が決まったものや、新たに採用されたらしいものも幾つかはあって、とても有意義でした。通常の Session は大体資料がDLできるのですが、 General のは資料なし（代わりに？動画が残りますが）なので結構必死にメモりました。
そして今日は（今日も？）夕方はパーティーです。 「Welcome Reception」として pavilion のスペースにて、ビールにワイン、更には割と豪勢なおつまみもあり。昨日に続いて Reception 参加がてらに Pavilion を廻って記念品をgetしたりしつつ、実は本当は前日に予定していた洗濯ができなかったので、テキトーなところで退散致しました。（こまめ2回行こうと思っていたんですが1回で乗り切ることになりそう、ぎりぎりかな・・・ なんかF1の給油回数の調整みたいです。）
今日はちょっと時間がないので、写真は後で付け加えようかと思います。でも今日の写真は特に出来の悪いのばかりなんですよね・・・そもそも枚数撮らないし（携帯のカメラなのでそんなにスパスパ撮れないし）・・・。期待せずお待ちください。
コメントは受け付けていません。
JavaOne2009 現地レポ(6/1号)
6月 2nd, 2009
こんにちは、佐竹です。
本当は昨日の Community One もレポートを出したかったのですが、訳あって書けなかったので今日まとめて書きます。
6/1 Community One の日
朝は9時から General Session があります。
といっても Community One は朝食が出ないしJavaOne本番程の混雑もしないので、 Java One の朝の Generarl Session は8時半開始な事を思えば、まだゆっくりできます。
General Session の内容は「Sun Cloud」と「Open Solaris」の話でした。Open Solaris の方は正直言って興味の方向性が違うのと、パネルディスカッション的な進行だったため、英語についていけません。しかしまぁ、Sunが力を入れているのだということはわかりました。「Sun Cluod」の方はというと、GUIの管理ツールを使ってドラッグ＆ドロップで Server から Firewall から Switch Hub に Lan 接続まで、Virtual に作成できるというのが驚きでした。
Data Center を Cloud に置き換えると言っていました。もちろん Virtual でも論理的に故障しますし、冗長化や監視などは同様に必要になるわけですが、「API が公開されている」というタイプの Cloud とは一味違った可能性を感じました。
そのほか、 Subversion 1.6 についてのセッション、Pragmatic Identity 2.0という、Identity 管理（権限\認証や SSO）を内部向けの REST Server を立てて行うアプローチの Session、 Servlet API 3.0 （とその標準実装である GrassFish ）における権限認証の方法のついて説明するセッション、それから最後に GlassFish を Eclipse プラグインと連携して使ってみる Hands On Lab 形式のセッションに参加しました。
初日からいきなり Hands On Lab に参加するつもりはなかったのですが、気にしているキーワード（GlassFish）だけで選んだら Hands On Lab だった（そもそも Community One に Hands On Lab があると思っていなかったのですが）という。資料に沿って割と淡々と操作していくだけだったのですが、英語を読むスピードが違いますから（聞くのと違って聞き逃したら終わりってことがないのは幸いですが）、残念ながら最後まであと一歩で時間切れになってしまいました。もっとも、ごく初歩的なというか、レールの上を動いてみただけなので、これが最後までできたからどう、ということはないのですが。
それはさておき、セッションのあとはレセプション、いわゆるJavOne前夜祭です。
今年は18時から「Pavilion Reception」、19時から「Sun Cloud＆Open Solaris Party」と2つになっていました。
Reception では若干お子様には刺激の強い装束をしたダンサー建ちとブラスバンドが練り歩いたり、Partyの方では何かいろいろ夜店のようなテントが彼方此方に張られ、的当てやら輪投げやら。
ここで同僚へのお土産を収奪しなければいけない・・のですが、日本から来た他の方達（というか重鎮な方々）とお食事に行くことになりまして、OpenSolarisのトレーナーに後ろ髪をひかれながらステーキハウスへ。
こちらで飲んだワインが帰ってからジワリと効いてか、昨日はレポートを作成できませんでした・・・。
コメントは受け付けていません。
JavaOne2009 現地レポ(準備号)
5月 31st, 2009
こんにちは、サービス創生事業部の佐竹です。
重田のブログにもありましたが、去年に続いて2回目の JavaOne 参加となりまして、現在 SanFrancisco 真っ只中です。
JavaOne は6/2から6/5の4日間ですが、その前日6/1は CommunityOne といって Free ＆ OpenSourceSoftware なプロダクトに関するコミュニティが集って多数のセッションやJavaOne前夜祭的なパーティーを開催するイベントがあります。
また、更にそれに先立って5/31からは JavaUniversity という半日または丸一日をひとつのテーマでみっちり勉強するセミナータイプのセッションも開催されている・・・のですが、コチラは別費用なので参加しません。
そんなこんなで、今日はまだ JavaOne は始まっていないのですが、ここに至るまでや、この先の私の予定を少し紹介したいと思います。
—-
今年の JavaOne の参加登録受付が始まったのは2/10頃ですが、私が登録したのは（社内での調整などがあり）3月の下旬でした。この時点ではそれ以上することはなく、参加登録の有無に関わらず参照可能なセッション情報をながめて、どんなセッションがあるのかな?とワクワク・・・ただし全部英語なので翻訳サイトにお世話になりながら・・・します。
4月の末頃になって、Schedule Builder が公開されました。使い方は去年とほぼ同じなのですが、今年は登録済みセッションのスケジュール単純ながテーブル表示ではなくカレンダー風に表示されて時間関係が分かりやすくなっていました。
聴講したいセッションは必ずスケジューラから登録して置くように！という脅しのメールも来るのですが、Schedule Builder は単に本人の予定を管理しているだけは無く、スケジュールにセッションを登録するとこイコール席を予約することになっているので、非常に重要です。残席数もリアルタイムに表示されて、一杯になると予定に登録できません。
実際はというと、席に余りがあれば無登録でも聴講できますし、セッションによりますが立ち見も可能です。ただし予約者が優先なのでずっと列に並んで待たされますし、最悪は入れません。特に HandsOnLab系のセッションは席数が少ない上に立ち見も不能なので予約必須です。
ちなみに以下が、現時点での私のスケジュールです。実は正直言うとまだ十分に吟味できていなくて、気になったキーワードで目に付いたセッションをとにかく埋めてみたという感じです。今考えてみるとパビリオンをめぐる時間がないし（特に2日の夕方はレセプションも開催されるし）、4日の夜は野外でイベントがあるんだったり・・・というわけで、直前に変更したりすると思います。
それでは、今日のところはこれぐらいで・・・。
コメントは受け付けていません。
サービスをとめないために
4月 16th, 2009
私たちはお客様にシステムを提供させていただいています。
そのシステムを使ってお客様がビジネスを行います。
ということはシステムが動いている時間がお客様がビジネスをおこない、利益を生み出せる
時間というわけです。
例えば、ショッピングサイトを作ったとしたら、システムが動いている時間がお店が開いてい
る時間となります。
そう考えると、当然システムの動いている時間は長いほうがよい。
というよりむしろ止まっていてはいけないということになります。
では、どうしたらシステムを止まらないようにできるのでしょうか。
システムが止まってしまう要因はいろいろありますが、そのうちのひとつに、ハードウェアの
故障による停止があります。
機械は必ず壊れるものなので。壊れることは仕方が無いのですが、その代わり壊れたその
ときにサービスをとめない、もしくは止まってしまう時間を最小にする工夫をします。その工夫
のうちのひとつが冗長化です。
冗長というと、なにか回りくどい、だらだら長いなどマイナスのイメージのある言葉ですが、
ことITの世界においての冗長化とは、故障などのいざというときのために予備を用意する
などして耐障害性を高めた状態のことをいいます。
さて、冗長化と一口に言ってもシステムの規模、サービスの重要性などによって用いられる
いくつかの形態があります。
その１：パーツの冗長化
まずはパーツの冗長化です。
私たちが日々使っているパソコンは、おおむね ハードディスクは1つですし、CPUも1つ、
電源ユニットも1つです。
当然、普通に使う分にはそれで十分ですが、ハードディスクが壊れたらデータは消えて
しまいますし、 CPUや電源ユニットが壊れたらパソコンは起動しなくなってしまいます。
それでは困るので、止めたくないシステムにおいては、これを冗長化します。
ハードディスクが壊れてもデータがなくならないように複数のディスクに同じデータを
書き込んで、たとえひとつが故障してもデータがなくならないようにします。
CPUも複数用意し、もしそのうちひとつが故障した場合も、（処理速度は低下しますが）
サービスが止まらないようにします。
電源ユニットも複数用意することによって、片方の電源ユニットが故障してもサービスが
停止しないようにします。
その２：サーバー（ノード）の冗長化
しかしながらパーツを冗長化しても、マザーボードなど冗長化できない部分の故障の際
にはシステムは停止してしまいます。
そういったケースにおいてもサービスを止められない場合は、サーバー本体（ノードと
いったりします）を複数台用意し冗長化します。
このことをクラスタ構成と呼びます
ひとつのサービスを複数のノードで行いどこかのノードが故障した場合、故障していない
ノードでサービスを行ったり、動いているサーバーと同じものを常に用意しておき、故障の際
には予備に切り替えてサービス停止時間を最小に抑えるようにします。
その３：拠点の冗長化
サーバーを冗長化し、これで一安心と思っても、実はまだまだです。
日本は地震が多い国ですし、火事だって無いとはいえません、空から何かが降ってこない
とも限らないです。
そうなってくると、ひとつのビルにすべてを置いておいてはいざというときどうにもならなく
なってしまいます。
そこで、今度は拠点を冗長化します。
このことをディザスタリカバリといいます、いろいろと形態はありますが、データのコピーを
毎日トラックに載せて遠隔地に運ぶ形式もあれば、 関東と関西など遠隔地に同じような
機材を配置して、リアルタイムでデータをコピーし合うという形態もあります。
このようにいろいろな冗長化の形態があり、サービスを止めないためにいろいろな工夫が
されています。
いろいろと冗長化の話をさせていただきましたが、大規模システムを構築する際に使用さ
れるこれらの技術とほとんど同等のことが実はすべてフリーソフトで実現できてしまいます。
例えば、RAIDはLnuxに標準で含まれていますし。クラスタリングに関しても、Linux上で動作
するフリーのソフトウェア（LVS、KeepAlived、Heartbeatなど）を利用すれば実現できてしまい
ます。
実は雲の上の存在だった大規模システム（もどき）が自宅で手軽に構築できるのです、これ
を機に「自宅で作る冗長化システム」などをゴールデンウィークの自由研究の課題にしてみ
てはいかがでしょうか。
コメントは受け付けていません。
アジャイル開発の実際（後編）
3月 30th, 2009
こんにちは。
前回はアジャイル開発での実施イベントについてでしたが、
今回はプロジェクトで実際に使用したツール類をご紹介したいと思います。
ではさっそく。
「Eclipse」
言わずと知れたEclipseです。バージョンは3.3を使用していました。
主に使用してたプラグインは以下です。
CheckStyle・・・・・コーディング規約を守らせてくれます。
PropertiesEditer・・propertiesファイルを書くときには必須
Subversive・・・・・Subversion を Eclipse で使うためのプラグインです。
m2eclipse・・・・・ Maven2をEclipseから利用するプラグインです。
「Maven2」
ソフトウェアプロジェクト管理ツールです。
ライブラリの依存関係管理、WARやJARなどの作成が楽です。
イテレーション開発を行っていたため、２週間に一度
WARやJARをバージョンを上げて作成・管理するのにも重宝しました。
「Subversion」
バージョン管理システムです。
ファイルの共有、バージョンの管理が楽です。
「Hudson」
継続的インテグレーション（CI）ツールです。
Hudson(https://hudson.dev.java.net/)はインストールやセットアップが簡単で、
なにより日本語なので誰でも理解しやすく使いやすいのでおすすめです。
今回のプロジェクトでは１時間に一度、JUnitの単体テストケースを
全て実行するように設定していました。
ビルドに失敗するとメーリングリストにメールが届くようにしていたため、
バグの早期発見、品質向上には欠かせない存在でした。
「Trac」
TracはSubversionと連携できるオープンソースのバグ管理システム(BTS)です。
チケットによるバグ管理やWikiで情報共有ができます。
開発環境の構築手順やプロジェクトで決まった開発ルールなど共有すべきことは
く全てTracに記入するようにしていました。
ファイルで管理していると、どこに何が書いてあるかわからなくなることが
ありがちですが、Tracで一元管理することでわかりやすくなります。
「JUDE」
JUDEはUMLモデリングツールです。
設計書は基本的にすべてJUDEで作成していました。
「Skype」
Skypeはコミュニケーションツールとしてチャット機能を使用していました。
開発でのちょっとした質問や確認、ときには仕事に関係ない笑い話をして
盛り上がるなど、いつのまにかプロジェクトになくてはならない存在になっていました。
会話しているのに近い感覚でメンバーとコミュニケーションがとれる
（ログが残るので後から見ても確認できる！）ため、
問題の早期発見・解決などにとても役立ちました。
「22型ワイドディスプレイ」
最後に、これはツールといいますかハードウェアなのですが、
ペアで作業するときに試しにワイドディスプレイを使用してもらったところ、
仕事の効率がとても良くなった！とメンバーから絶賛の声をたくさん
いただいていたためご紹介することにしました。
ペアで作業されている方はぜひ一度お試しいただければと思います。
ツールは上手く使うと作業をものすごく楽にしてくれます。
みなさんも気になるツールがありましたら、積極的に使ってみてはいかがでしょうか？
長い付き合いになる出会いがあるかもしれないですよ。
コメントは受け付けていません。
第4回atWorksレポート
3月 23rd, 2009
去る3/13(金)、第4回atWorksが開催されました。
当日はあいにくの雨にもかかわらず、多くの方にご参加いただきました。
今回の講演は、浅海智晴先生による「Agile Modegramming for Cloud」。
タイトルからして内容てんこ盛りの予感。期待度も高まります。
参加できなかった方のために、講演内容をさらっとご紹介しましょう。
・ クラウド時代の新しいソフトウェア開発のコンセプト
「あちら側」にアプリケーションを動かすためのハードウェアやアプリケーションフレームワーク等
があるという形態（クラウド）の出現は、従来「こちら側」で行ってきた開発・保守・運用の多くがク
ラウドに飲み込まれてしまうということです。
そうなると、ソフトウェア開発の形態もコンポーネントをベースとした開発へと変わってきます。
そのコンポーネントの開発にモデル駆動開発が適しているのではないかということで、モデグラミ
ング技術の紹介が行われました。
・ モデグラミング技術の紹介
モデグラミングとは、モデリングとプログラミングを同時に行うことで、テキストDSL(Domain
Specific Language)とモデルコンパイラで行われます。
DSLのホスト言語には、関数型言語がクラウドと相性が良いと考えられており、Scala(http://www.scala-lang.org/)を採用しています。
モデルコンパイラ「SimpleModeler」を使ったデモンストレーションでは、モデルを記述したCSVファ
イルからXMind(http://www.xmind.net/)形式のマインドマップが生成され、さらにそのマインドマッ
プからScala DSLが生成されます。
Scala DSLからUML、Grailsアプリ、Google App Engine Oil(http://code.google.com/p/google-app-
engine-oil/)のアプリケーションが生成され、SimpleModelerを動かす以外は、一切コーディングな
しで実際に動くアプリケーションができてしまうデモは一見の価値ありです。
・ アジャイル開発とモデグラミング技術
クラウド・プラットフォームにおいて、オブジェクトモデリング、モデル駆動開発、アジャイル開発の
融合に、テキストDSLとモデルコンパイラを利用したモデグラミング技術を採用することで、アジャ
イル開発における問題点を解決できるのではないかという問題提起がありました。
クラウド・アプリケーションの開発をする機会があれば、ケーススタディとしてやってみたいと感じ
ました。
1時間半の講演はあっという間で、途中、用意していた資料を端折ってお話される場面もありまし
た。
(個人的には、お話されなかった部分が気になるところです・・・)
ソフトウェア開発のあり方や将来像を考えされられる、大変有意義な講演であったと思います。
クラウド時代のソフトウェア開発に関する研究活動は、edge2.ccで詳細がご覧になれます。
また、3/18発売のUNIX Magazine4月号にクラウドが特集されており、浅海先生の執筆も掲載されて
おりますので、そちらもどうぞ。
これまでのatWorksは、外部の講師を招いた社内勉強会的な色合いが強いものでしたが、今回
は参加者の多くが社外からの申し込みで、どちらかと言えば、社外の勉強会に参加しているよう
な雰囲気でした。
とはいえ、atWorksには決まったスタイルがないので、今後もいろんな形態で開催していくことに
なると思います。
興味のある方は、次回以降の参加をお待ちしております！！
講演資料は「こちら」からダウンロード可能です。
20090313AgileModegrammingForCloud.pdf
コメントは受け付けていません。
アジャイル開発の実際（前編）
2月 16th, 2009
アジャイル開発というとみなさんはどのようなイメージをもたれるでしょうか？
イテレーション開発やペアプログラミングというイメージは広く知られているところかと思いますが、他にもドキュメントが少なそう・・であるとか、一度やってみたいけどどうやっていいのかわからない、そもそも実際の開発にホントに適用できるの？という不安でいっぱいな声も聞こえてきます。
そこで今回は実際にアジャイル開発で行ったプロジェクトをご紹介し、みなさんの一助になれればと思います。
【 実施イベント 】
朝会
毎朝、全員がそろってからスタンドアップミーティングを行います。
マネージャおよびメンバーが報告することは以下です。
・昨日やったこと
・今日やること
・問題点
朝会の主な目的は、メンバーが自分の「やったこと」「やること」を皆に話すことにより、毎日のゴールを明確にすることです。また、メンバー全員が進捗を共有し、問題点があればチームとして解決する意識付けを行うことも重要です。
時間は１５分程度です。必要以上に長引かないためにもスタンドアップ形式は有効です。
イテレーション開発
２週間で「動作するもの」をリリースし、お客様に見てもらえるようにします。
２週間の作業内容は計画ゲームで決定します。
計画ゲーム
イテレーション開発の最初の一日目に、「今回のイテレーションでなにを作るか」ということを計画ゲームを行い明確にします。
計画ゲームはお客様を交えて、半日?一日程度ぶっとおしで打ち合わせを行います。
流れとしては以下のような感じです。
・機能の明確化
ホワイトボードに作成予定の機能を書き出していって、お客様と合意をとります。その場でも様々な意見がでて、頻繁に書き直されるため、パソコンで書いていくよりもホワイトボードのほうが有効だったように思います。
（重要なポイントはパソコンを使用してメモ書きします。）
・機能の詳細化
明確になった機能を、詳細なタスクに落としていきます。タスクの見積もりは原則３時間以内とします。
（例えば、○○クラスの△△メソッド作成は1.5時間など。）
ポイントとして見積もり時間は「全力でやったときの時間」を崩さないようにします。
・トリアージ
詳細化の見積もりを進めていくにつれて、明確化した機能が２週間でおさまらない場合があります。そんなときは、ここの部分をこうすれば収まりそうですがどうでしょう？など、お客様と合意できるポイントを話すのが最善だと思います。
・ホワイトボードを写真に取る
ホワイトボードに書いた内容は写真を取って保存しておきます。ですので、ホワイトボードは最終的にはきれいにまとめて書いておくようにします。
タスクかんばん
まず、計画ゲームで決まったタスクをすべて名刺サイズの厚紙（タスクカード）に記入します。
タスクカードには以下の情報を記入します。
・タスクNo
・ストーリーNo
・タスク内容
・作業開始日時
・作業終了日時
・作業者
・予想工数
・実績工数
（作業日時、作業者、実績工数はタスクを実際に消化する人が後で記入します。）
このタスクカードをタスクかんばんと呼ばれるA3くらいのコルクボードにぶらさげておきます。
タスクかんばんは以下の４つの領域に分けられています。
・未着手
・現在作業中
・本日作業予定
・消化済み
朝会では基本的にこのタスクカードを元にその日の作業を決めていきます。
ペアプログラミング
ペアプログラミングと呼んでいますが、プログラミングだけではなく、基本的に作業はすべて
ペアで行う（ペアワーク）こととします。ペアはそれぞれナビゲーターとドライバーという役割
を持ちます。ナビゲーターはドライバーに細かい作業指示を出し、ドライバーは指示通りに
作業を行います。ペアプログラミングの一番の利点は、タスクの作業内容を共有化できると
いうことです。
例えば、作業者の一人が会社を休んでも、もう一人が知っているためある部分を「誰も知ら
ない」ということが起こりにくいです。また、お互いに自然と作業をチェックする仕組みが働く
ため、「ついうっかり」ということがほとんど無くなります。ただし、ペアには現実的に「相性」と
いうものがあるのも事実だと思います。ペアでやってみてそれなりの成果がでていないと感
じた場合はやめたほうがよいかもしれません。
リリース
リリースとはイテレーションの最後に、お客様がアクセス可能なリリース環境にイテレーシ
ョンの成果物をアップロードすることを言います。リリース後、お客様に実際にシステムを
動かしてもらって、想定どおりの仕上がりであるかを確認していただきます。
もし、想定どおりで無い場合はフィードバック表にその旨を記載していただき、対応を後日
相談することになります。
ふりかえり
ふりかえりは文字通り、後ろ（実施したイテレーション）を見てみることです。手法としては
「KPT」を使い、全員で良かったところ(Keep)、悪かったところ(Problem)を挙げていき、最
後に悪かったところの対応策(Try)を話し合います。所要時間は１時間程度とします。
ふりかえりで重要なのは、「問題」対「チーム」の構図を作ることだと思います。例えば、
悪かったところが挙げられたときに特定の個人を責めたりしてしまうと、萎縮してしまい
「悪かったところ」が今後誰からもでてこないということになりかねません。
主な実施イベントを挙げていきましたが、いかがでしたでしょうか？
アジャイル開発ではなくても実施できるものが多数あるかと思います。
次回はプロジェクトで使用したツールについてご紹介します。
コメントは受け付けていません。
新卒プログラマに求めるモノ
2月 11th, 2009
冬の寒さも厳しくなってくるこの時期。
外の気温とは裏腹に、若々しくフレッシュな息吹を感じる機会がありました。
先日、函館で行われた合同企業説明に出展者として参加してきたのです。
来年の春卒業予定の学生さん達は、そろそろ就職活動が始まる時期でもあり
今年の春卒業予定の学生さん達は、内定先への就職を前に希望や不安を抱
いていることでしょう。
さて、話を先日の合同企業説明に戻しますが、その合同企業説明会というの
は、実はIT産業限定のものでして、参加していた学生さん達も情報学科など
を専攻したいわゆるIT系の学生さんが大半だったようです。
我が社のブースにも様々な学生さん達に訪れて頂き、簡単な会社説明や質
問に対しての受け答えをしていたのですが、意外と多かった質問が
「Javaの経験が無いのですけど大丈夫でしょうか？」
という内容のものでした。
我が社の業務内容を聞き、Javaは学校で習っていなかったとのこと。
自分としては「そういうことが気になるのか」と正直意外でした。
ハッキリ言ってしまいます。
「わかりません」
ただ１つわかるのは、もし「大丈夫ではなかった」場合、その原因は
「学生時代の経験が無かったから」
では有り得ません。
何故なら、学生時代の経験が無くとも立派にやってらっしゃる先輩の
方も沢山いますし、情報系学科卒にも関わらず、この業界を去ってし
まった方も少なくありません。
「学生時代の経験が無いからダメ、あるから大丈夫」なんてことは
絶対に無いのです。
ここからは個人的な意見になってしまいますが、私は新卒の方に経験
などは求めていません。
(そもそも経験を求めるなら、新卒採用せずに中途採用の枠を設けた方
が手っ取り早いですしね)
「学生時代に経験がある」というのは確かにアドバンテージにはなると
思うのですが、「学生時代に経験が無い」ということが即マイナスになる
とは考えていません。
わからないことだらけで当然だからです。
ちょっと極端な例を出しますが・・・
・「今まで学校でJava習ってきたし、プログラマにでもなるか」
・「学校ではパソコンの『パ』の字も習っていないけど、どうしてもプログラマになりたい」
私なら後者の方と一緒に仕事がしたいです。
「プログラマにでもなるか」で就職した人と「プログラマになりたい」
と思い就職した人。スタートダッシュこそ出遅れるかもしれませんが、数年後
には明確な差が出ていることでしょう。
『経験よりも意欲』
これが私が新卒プログラマの方々に求めるモノです。
そして最後に学生さん達にメッセージを。
今年の４月に就職を迎える新卒の皆さん。
・「わからないことをわからないと言い、素直に教えを乞う」
これが新人の大事な最初のお仕事だと思います。
・「どんなに忙しい先輩でも足を引っ張って教えて貰うことが出来る」
これは新人だけに許された特権です。利用しない手はありません。
この２つは忘れないでください。
先輩達はあなた達の教育も仕事の内です。
堂々と頼ればいいのです。
来年春卒業予定の現在就職活動中の皆さん。
あなた達はまだまだ「原石」でしかありません。
「経験が無いから」などと悲観せず
自分がやりたいと思うなら、もう一歩踏み出してみませんか？
本当にやりたいことなら、きっと「大丈夫」ですよ。
コメントは受け付けていません。
新年のご挨拶
1月 6th, 2009
新年あけましておめでとうございます。
昨年後半から急激に世界経済が悪化し、厳しい年明けとなりました。
従来までは世の中の景気に比較的左右されづらいとされていたＩＴ業界にも少
なからず影響が出始めてきています。
一方で、数年から十数年かけて技術の革新がなされるであろうと予想されてい
たものが、この経済の悪化で一気に加速する可能性を指摘する声もあります。
私共としてはこれをチャンスととらえ、世の中のニーズに先行して技術の革新
に取り組み、従来にも増してお客様にとって価値のあるシステムをご提供して
いきたいと考えております。
具体的には、かねてより取り組んでまいりましたアジャイルプロセスをベース
に大規模プロジェクトに適用した独自の開発プロセスを洗練し、ビジネス要求
をシームレスにシステム開発につなげる要求開発とアジャイルプロセスの融合
とそれを可能とするソフトウェアフレームワークの整備、バスワードとも揶揄
されるクラウドコンピューティングの現実的なエンタープライズシステムへの
適用に取り組んで参ります。
厳しい時代ではありますが、だからこそ「システムで人々を幸せにする」時で
あると思います。努力を惜しまず、何事にも前向きに取り組んで参る所存です。
本年も何卒よろしくお願い申し上げます。
コメントは受け付けていません。
箱庭作成のススメ
12月 22nd, 2008
私は趣味で、箱庭を作っています。
箱庭を辞書で調べてみたところ、このような意味だそうです。
—-
はこにわ 【箱庭】
浅い箱や鉢に土を盛り、小さな草木や石などを配し、
模型の橋・家その他を置いて山水や庭園の姿を模して観賞するもの。
［季］夏。《―の人に古りゆく月日かな/虚子》
三省堂「大辞林 第二版」より引用
—-
唐突に何を言ってるのかと思われるかもしれませんが、
実は箱庭といっても、私の作っている箱庭はこのような風流なものではなく、
自宅で作る小さい情報システムのことを個人的にそう呼んでいます。
実際のところどんなものかということを、
辞書で言うところの箱庭と私の箱庭を対比しながら紹介させていただきます。
＜箱＞
まず箱です。
すべてのものを配置するベースとなるもの、ハードウェアです。
少し前でしたら、使い古しのパソコンや、オークションで落札したＵＮＩＸサーバーなど
を使っていましたが、今はＶＭｗａｒｅなどの仮想化ソフトウェアが無料で使用できるように
なったため、その恩恵を受けて、ＶＭｗａｒｅとＸｅｎを使用しています。
＜土台＞
次に、箱に盛る土です。
配置する小物を載せる土台となるもの、ＯＳです。
仕事で使うサーバーのＯＳがＵＮＩＸ、Ｌｉｎｕｘであることがほとんどなので、
コマンドライン操作の練習もかねて、Ｌｉｎｕｘ（Ｄｅｂｉａｎ、ＣｅｎｔＯＳ）を使用しています。
＜草木、建物＞
最後にその上に草木や建物です。
土台の上にのるもの、ミドルウェアや、アプリケーションプログラムです。
Ｗｅｂサーバーや、サーブレットコンテナ、データベースをはじめ、
普段はちょっとかかわらないようなＤＮＳ、メールサーバーなども配置しています。
以上、簡単ながら箱庭の紹介です。
こんなことをして何が面白いのかと思われる方もいらっしゃるかも知れませんが、
以下のようなメリットがあると思います。
（あくまで個人の感想であり、実際の効果を表すものではありません。）
１．システムを箱庭サイズに単純化することにより、システム全体が見渡せ、
どのような構成でシステムが成り立っているかがわかります。
２．システムを実際に構築することにより、
サーバーを構築管理しているシステム管理者の気持ちが（ちょっと）わかります。
３．意識しないで使っていた、「情報インフラ」にあたるサーバー（ＤＮＳなど）を自分の
手で構築することにより、情報システムの裏側の仕組みがわかります。
「Write Great Code」という書籍の副題に「ハードウェアを知り、ソフトウェアを書く」という
言葉がありました。
箱庭作りは「情報システムインフラを知り、ソフトウェアを書く」を実現するための手段と
いったところでしょうか。
知らなかったときより、知った後のほうがよりよいシステムが構築できるように思えます。
— 基本的には、自分の好奇心を満足させるためですが。
「プログラマは毎年1つの言語を学ぶべきである。」という有名な言葉がありますが、
ひとつの言語を覚える代わりに、箱庭を作って遊んでみてはいかがでしょうか？
コメントは受け付けていません。
みんなが笑顔になれますように
11月 20th, 2008
こんにちは。
私はアットウェアで唯一、物創り以外の仕事をしています。
そんな私が、このコラムで何を書くのかと疑問に思う人もいるかもしれません。
今回は物創りとではなく、【働く】もっと大きく言えば、【生活】という観点でお話させて頂きます。
実は、私の名刺の肩書きには「ファシリテーター」と書かれています。
この名刺をお客さまにお渡しすると、大抵、何を担当している人？ときかれます。
【facilitate】という言葉の意味は「促進する」「容易にする」です。ファシリテーターというと「会議の進行役」というイメージが強いと思いますが、ファシリテーターの活躍する場は、会議室に留まらず、様々なところにあります。
あなたの近くにも、縁の下の力持ちといわれている人や、黒子のような方がいませんか？ こういった方々は、きっと、ファシリテートするのが上手な方なのだと私は思います。
では、本題に入りましょう。
みなさん、子供のころ「相手の立場になって考えましょう」といわれたことはありませんか？
これは、
(1) 相手が何を求めているか
(2) 何をしたら相手に喜んでもらえるか
(3) 何が相手のためか
というように読み解くことができると思います。
例えば
(1) 「相手が何を求めているか」
目玉焼きは、何をかけて食べますか？
お醤油、ソース、お塩、ケチャップ･･･好みがわかれますよね？
私は、お醤油派。でも、隣の席の人は違うかもしれない。自分の前に調味料がおいてあったら、「何をかける？」ときいてとってあげませんか？
例えば
(2) 「何をしたら相手に喜んでもらえるか」
もうすぐ友達の誕生日。というとき、何をプレゼントしようか考えるのは楽しいですよね。
そんなとき、友達の好み、性別、年齢を考えて、プレゼントを選びませんか？
自分が好きなデザインではなく、友達が好きそうなデザインを選びませんか？
例えば
(3) 「何が相手のためか」
子育てをしているママは、子供が野菜嫌いだからと、日々の食事で野菜を出さない。なんてことはしないですよね。
きっと、どうしたら野菜を食べてくれるかなと工夫をするでしょう。
「相手の立場になって考える」これは、対顧客でとらえても大切だと思います。
先の例を使うと、
(1)は、「お客さまは何を求めているのか」
(2)は、「どうしたら、お客様は満足してくれるのか」
(3)は、「どの手段が、一番お客様にとってベストか」
といえます。
そして、「相手の立場になって考える」というのは、(1) (2) (3)を個々に実践すればいいわけではありません。ケーキを欲しがる子供に毎日ケーキを与えていたら、数ヵ月後、体重が10キロも増加していた。なんていうことがあるかもしれません。
つまり、相手が求めるから、喜ぶからという観点だけみていると、結果が、相手の為になっているとは限りません。
目先のHAPPYよりも、少し先、もっと先にあるHAPPYを見据えることも必要です。かといって、ケーキは一切食べちゃ駄目。というと、「なんで？」と子供は窮屈さを感じてしまうと思います。
これが、毎日のおやつには出てこないけど、お誕生日のときは、いつもケーキが出てくる。となると、特別な日にはケーキが食べられる。と我慢していた分だけ、より子供は喜ぶでしょう。
つまり、(1) (2) (3)をバランスよくすることが大事なのだと考えています。
私は、日々、(1) (2) (3)をバランスよく実践するようにしています。
その対象は、会社であり、上司であり、同僚であり、そして、お客様であり、友人であり、家族であり、様々ではありますが、みんながHAPPYになるためにはどうしたらよいか？ということを大事にしています。
(とはいっても、自分本位に考えていることも多々あり、反省の毎日ですが･･･)
子供のころに言われた「相手の立場になって考える」という言葉を、みなさんはどうとらえますか？
そして、あなたの【facilitate】にそれをどうとりいれますか？
コメントは受け付けていません。
システム開発の戦術
11月 12th, 2008
システム開発もフットボールに例えられることが多々あります。
（１） 監督の選考
フットボール界は、監督のマネージメント力がとても重要とされています。システム開発でも同様に、チームがいかに楽しく開発を行っているかの組織作りが大切です。組織作りの成否如何によって、システムを開発している人達の熱意や雰囲気が向上し、よいシステムを創るための下地となります。
（２） 選手の選考
歴代のUEFAチャンピオンズリーグ制覇チームを見ると、そのチームには必ずスーパースターが存在しております。システム開発も同様に、チームの中心人物が必要で、精神的支柱がいることが大切です。
（３） 戦術
プレッシングに代表される近代フットボール戦術は、昨今さらに洗練され、プレスの位置による攻撃への変化が重要となっています。これもまた、システム開発と同様に、スケジュールが遅れてから人を集めるのではなく、開発状況に合わせて先に人を集めて全員の意識を一致させ人員配置することでゴールへの足がかりが生まれます。
（４） コミュニケーション
フットボールはアイコンタクトが重要だと言われています。アイコンタクトで次にやることがわかるらしいです。これは、お互いが状況に合わせて何をしなければいけないかを理解しているからです。これもシステム開発と同様に開発者同士が状況を把握し何をしなければいけないのかを理解していることが重要です。監督からの指示を待っているようではゴールは生まれません。
（５） 分析
ゴールに至った高度な分析と、それに合わせた戦術の改善が必要です。これはシステム開発でいうふりかえりに相当します。ふりかえりを行うことでシステム開発はよりよくなります。
このようにフットボールからシステム開発をよりよくするための戦術をたくさん学ぶことができます。フットボールで勝利をあげることと、システムを完成させることはとても似ていますね。
最後に元ブラジル代表、ペレ氏の名言をご紹介します。
「成功は偶然の出来事ではない。勤勉、忍耐、練習、研究、謙虚、そして何よりも愛情が必要である。」
コメントは受け付けていません。