Sunday, February 19, 2012

デブサミ2012 Day2 2012/02/17 メモ

デブサミ2012 Day2 2012/02/17 メモ

全体俯瞰はこちらが便利。
デブサミ2012 参加セッション一覧 http://bit.ly/A9kjcL

【17-A-1】
Jenkins
川口 耕介 氏
(※部屋変更)
http://togetter.com/li/257791

具体的な利用方法ではなく、Jenkinsの方向性についてのお話。
メモとっていないので、togetter見てください。

【17-A-2】
仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り
鈴木 雄介 氏
(※部屋変更)
http://togetter.com/li/257887

課題管理ツールJIRAの説明。
使い方のポイント
・起票のルール(言葉遣いは丁寧に、記載内容は事実の報告を)
・誰がクローズするのかを決める
・チケットの粒度を定める(切り過ぎ注意)
・定期的な棚卸し必要

アンチパターン
・ワークフローやフィールドの設定し過ぎ
・タスクの階層化
・複数のコミュニケーションツールの併用

要は基本デフォルト設定の利用で問題ないとのことです。

お客さんにも使ってもらうことが大事だとのこと。
印象的だったのはログインを面倒だというお客がいれば、「だったら僕ログインしますよ」と。つまりそれくらいのことをしてもお客さんと役割を決めて、コミュニケーションツールとして使ってもらえ、と解釈しました。

【17-B-3】
言語の世界
まつもと ゆきひろ 氏
http://togetter.com/li/257797

Rubyの言語設計のお話。
言語設計は発想をプログラミングしているのだと。
なので、Rubyを利用している人はまつもとさんの言語仕様を組み込まれているのだと。
つまり、We program You!

【17-C-7】
From Legacy to Agile ~レガシー開発からアジャイル開発へ~
野口 大輔 氏 / 塩谷 啓 氏
http://togetter.com/li/257837

ドワンゴへ転職した人たちのお話。
といいつつ、結構SIerのdisりが多かったような。

紹介されていた書籍やウェブサイト
・アジャイルマニフェスト
・アジャイルサムライ
・アジャイルプラクティス(おすすめ)
・アジャイルな見積もりと計画作り

途中で上司の方が登壇されチームの決まりを披露
・テストを書く
・問題は根性では解決しない
・人を■す以外なら何やってもいい
・失敗を引きずらない
これについては本人のブログも参照。
デブサミで僕が話したことの簡単なまとめ
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437

以上で今年のデブサミも終わりです。
大変楽しかったです。登壇者の皆様、スタッフの皆様、ありがとうございました。

デブサミ2012 Day1 2012/02/16 メモ

デブサミ2012 Day1 2012/02/16 メモ

行ってきました。目一杯セッションを選ぶと消化不良を起こしますね。
全体俯瞰はこちらが便利。
デブサミ2012 参加セッション一覧 http://bit.ly/A9kjcL

【16-E-1】
2015年のアーキテクチャ、マーケティングシステムを題材にして
熊澤 公平 氏
http://togetter.com/li/257811

現在主流なBigDataとBigProcessingがやがて融合されると説いてらっしゃいました。
購買の際、計画をたてていながら、その場の情報により予定外の購入をしていることはよくあることです。これをツカミに「モノと一緒にコトを見る」アプローチについての説明は大変刺激的でした。これは購買支援だけでなく、意思決定支援にも展開されるのではとワクワクしながら聞いていました。

【16-E-2】
ペイパル最新決済ソリューション
水野 博商 氏 / 植野 稔之 氏
http://togetter.com/li/257826

PayPalの説明でした。今後決済可能な手段として広く流通していくことを期待します。
例えば百貨店とかコンビニエンスストアとかね。
紹介していたビデオに描かれていた未来予想図はなかなか楽しめました。


【16-B-3】
教科書と現場のあいだ ~学びを活かすために~
和智 右桂 氏
http://togetter.com/li/257696

自分が価値があると思うことを相手に伝える技術は大切だと説いていらっしゃいました。
説得とか説明というのは自分にとって苦手な部分です。ちょっと反省。

【16-E-5】
デザインの最前線
田川 欣哉 氏
http://togetter.com/li/257704

takramの田川さんによるMUJI NOTEBOOK制作を題材にしたデザイン設計についてのお話。
MUJIとiPadのベン図の交わる部分がMUJI NOTEBOOKという説明はわかりやすかったです。

企業相手のシステムでは機能優先や導入技術に偏ったデザインになり失敗することが多いのですが、
コンシューマー相手ではエンジニアリング(機能)部分とデザイン(操作性、見た目)の両方が重要になります。
このため早い段階からお客さんにプロトタイプを見せることで、お客の理解度が上がり、共感を呼び、アイデアが出てくるとのこと。

企業相手のシステム開発では、設計書という仮説だけで詳細化が進み、不必要な仕様が付け加えられることがあるのですが、プロトタイプの利点は、具体と抽象の両面から製品開発にアプローチできることです。

シミュレーションで動かしても有効な結果は得られないので実機で確認する、というお話は継続的インテグレーションあるいは継続的デリバリーに通じるものを感じました。

まとめ
1 demo is more informative than 100 sketches.
Animation for not only screen.
Test the application with a right setting.

ユーザに残る体験の作り方としてヒントを教えていただきました。
製品の中に強いコントラストをつける
できるだけ複数の感覚を同時に刺激する
(挙げていただいた具体例を失念してしまいました)

お客との間で感覚を共有するのは大事なことだと思います。
企業向けの場合、やたらと機能とか新しい技術にこだわったデザインとなり、
失敗することが多いので気をつけたいと思います。
また、早い段階から実物を見せられるよう、日頃の練習(?)が必要ですね。


【16-B-7】
デブサミオフィシャルコミュニティから選出のLT大会2012
よしおか ひろたか 氏 / ショウジ ユウコ 氏 / 16コミュニティ参加
http://togetter.com/li/257878

Hack For JapanのOikawaさんのLTが印象的でした。

Saturday, January 28, 2012

特許庁情報システム開発中断備忘録

特許庁情報システム開発中断についての備忘録です。

特許庁の発表は次の四点。

1. 作ろうとしていたもの
2005/7 「特許庁業務・システム最適化計画」(改訂版)について http://bit.ly/AmQPeI

2. 収賄事件の調査報告書(開発状況へのダメだし含む)
2010/8/20「特許庁情報システムに関する調査委員会」からの調査報告書の提出について http://bit.ly/xZHjJI

3. ダメだしが改善されていないのでヒアリング
2011/9 - 2011/12 特許庁情報システムに関する技術検証委員会 http://bit.ly/yzTy31

4. 開発中断報告
2012/1/24 特許庁情報システムの技術検証結果について bit.ly/yl0F3m

違和感を感じたのは2010/8の報告書の内容。三つある。
報告書の六割が「再発防止」を理由に開発状況の技術検証となっていること。
報告書第二部の収賄事件の背景にて、「業務要件確認書」が開発会社TSOLから納められていない事実があるとし、開発の停滞原因がTSOLだけにあるかのように書かれていること。
なぜTSOLが「業務要件確認書」を納品できなかったかの真因分析がなされていないこと。
上記三点から考えられるのは、この報告書はTSOLに分が悪く書かれており、TSOLによる開発をやめたかったのではないかということ。ひょっとすると最初から内部でTSOLの開発に反対の声があり、収賄事件を機に開発をやめさせる方向に動いたのかもしれない。

特許庁が提示した最適化計画を見ると、非常に複雑な印象を受けるが、人間が担う作業と、システムに対する操作と同列に書かれていたり、適切な業務分析がなされたかは疑問だ。本来RFPとしてユーザー側が開発するシステムに対して明確なビジョンや方針を作成すると思うが、それがなされていなかったのではないだろうか。

確かにTSOLは設計をスケジュール通りに終わらせられなかったかもしれないけど、その真因は報告書でも明らかにされておらず、依然として不明なまま。開発中断は正しい選択だとは思うけど、また同じことが起こる気がする。


参考
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い http://bit.ly/y6GbjM

特許庁の情報システムについて - myatsumoto blog http://bit.ly/wXHYbb

特許庁の情報システムについて - 技術検証委員会の議事録 - myatsumoto blog http://bit.ly/xD1iN4

Sunday, January 01, 2012

2011 振り返り

2011年 KPT的振り返り

2011年をKPT的に振り返ってみます。KPTふりかえりについてはこちら。
http://www.slideshare.net/esmsec/kpt-5469874

Theme
ITに関すること

Keep
IT系イベント参加
- Agile Japan 2011 4/8 http://www.agilejapan.org/event/2011/
- JJUG Cross Community Conference 2011 Fall 10/12 http://www.java-users.jp/contents/events/ccc2011fall/
- Yapc::Asia 2011 10/14-10/15 http://yapcasia.org/2011/
- Scrum Gathering Tokyo 2011 10/19, 10/22 http://www.scrumgatheringtokyo.org/sgt2011/index.php?id=7

IT系勉強会参加および発表
- nseg #11 01/15, #18 08/27 http://nseg.jp
- jggug #15 2/24, #17 7/29 http://www.jggug.org

発表はnseg #11 Selenium RCの紹介
http://www.slideshare.net/sano66/selenium-rc-web-application-testing-tool

IT系イベントや勉強会は刺激を得られますね。
自身の発表する機会を得られたことが一番の収穫でした。
Selenium-RC使っていてよかった。

Problem
アウトプット不足
もう少しいろいろつくったり、発表できたと思います。
時間が足りないというのは言い訳ですね。
原因はなんだろう。モチベーションが足りないのかな。
IT勉強会やイベントで得る刺激が多すぎて目移りする、というのはありますね。
参加対象を十分に選択しなければいけないかもしれません。
もともと自分の許容量は小さいですし。

プレゼン技量不足
もっと場数をこなさないといかんなぁ。
プレゼンテーションzen
Garr Reynolds ガー・レイノルズ
ピアソン桐原
売り上げランキング: 1138


Try
Selenium 2.x の習得
Seleniumもバージョンがあがりました。
理解を深めまた発表する機会に備えたいと思います。
http://seleniumhq.org/

Project Euler挑戦
twitter経由で知ったProject Eulerですが数学の復習のようで楽しいです。
現在Javaで解いているのですが、これをRubyやGroovyなどの異なる言語で
挑戦することで言語の勉強に生かしたいと思います。
http://projecteuler.net/
http://github.com/sano66/projecteuler/

Yammer関連のアウトプット
yammerはドメインに閉じたマイクロブログサービスです。
APIがそこそこ充実しているのでなんか作ってみたいと思います。
http://yammer.com

読書時間の確保
じっくり本を読む時間を増やしたいと思います。


KPT的ふりかえりはこんな感じでいいのかな?ちょっと違う気もするけど、まぁいいや。
今年もよろしくお願いします。

# スクラムマスターを雇う時に聞いてみるとよい47個の質問

  # スクラムマスターを雇う時に聞いてみるとよい47個の質問 スクラムマスターへの質問というPDFがあるので、回答してみた。 定期的に自分の回答がどう変わっていくのか楽しみだ。 Scrum Master Interview Questions: Free Download of...