神泉で働くCTOのアメブロ

このエントリはmakoga's memoに移設しました。

VOYAGE ChinaTechで感じたアプリエンジニアとインフラエンジニアの違い

12/13-16はVOYAGE China Technologyに行ってました。
今回の一番の目的は、日本のインフラエンジニアによるインフラスキルトランスファーです。

以下、インフラ講座のコンテンツ。

VOYAGE GROUPのサービス用インフラの概要
- サービスの概要
- インフラエンジニアの業務

設計・運用時に注意していること
- 耐障害性
- セキュリティ
- 運用負荷の軽減

運用のための管理
- 構成管理
- 性能管理
- 障害管理
- セキュリティ管理

その後は実際のサーバの改善案を検討し、一部構築しました。

その中で実感したのは、インフラエンジニアは最初に全てを閉じてから必要な穴を開けていくのに対し、中国のアプリエンジニアは基本デフォルトのまま運用し足りないものを追加していくことが多かったことです。特に中国では起きないかもしれない問題に事前にコストを掛けることに抵抗感がある人が多いようです。この辺りは口を酸っぱくなるほど言い続けるしかないかなと思います。

また、今回の出張を通してうちのインフラエンジニアの頼もしさを改めて感じました。先を見越して事前に手を打っておくってホント大事ですよね。

羽生さんの考え方はとても共感できる。

宇佐美さんがブログに羽生さんのことを書いてますが私も負けないくらい羽生さんが好きです。

私は子供のころ一時期将棋にハマり夏休みに1日中詰め将棋をしていることもありました。中学卒業後は熱が冷め、将棋ソフト相手にしか指してませんでしたが、羽生さんが7冠取ったときは1人でテンション上がりまくりでした。その後はたまーに最強将棋21シリーズを買って読んでたりしました。

そんな訳で羽生さんの『決断力』は何回も読んだし、『大局観』も読みました。その中でも1番共感できたのは直感、読み、大局観をバランスよく使い決断するということです。もちろん羽生さんとはレベルが違うと思いますが私も同じような複数の軸で決断するよう心がけでいたので自信に繋がりました。

大局観を身につけるのはとても難しいと思います。私もまだまだ未熟ですが、方法の1つはSystems thinkingを学ぶことではないかと考えています。

参考
・学習する組織ーピーター・センゲ
・システム思考ーチェンジ・エージェント

今年から始めたエンジニア向けインターン「Sunrise」の振り返り

前半が終わったときにエントリを書いたエンジニア向けインターン Sunriseが11/27に終了しました。
結果は、手前味噌で恐縮ですが、大成功だったと思います。

まず参加者の質が高かったというのがあります。最初は少し苦戦しましたが、人事と共に最後まで質にこだわった甲斐があり優秀な学生が参加してくれました。VOYAGE GROUPのインターンは本気のグループワークが特徴だと思います。弊社クルーのサポーターは本気で取り組んでいるかについてはサポートしますが、創るものについては極力学生たち自身で生み出してもらう方針です。なので、参加者の質が高ければ高いほど参加者同士の濃密なディスカッションが生まれます。今回は参加者のほぼ全員が他の参加者のレベルが高くとても良い刺激を受けたと言っていたのが印象的です。

アウトプットの機会を多く取り入れたことも成功の大きな要因と思います。gihyo.jpの取材でも話をしましたが、頭で理解するだけではなかなかハラオチできません。手を動かす、人に説明することとセットにするのが重要です。企画段階では講義内容の濃さゆえ、アウトプットが表面的になってしまわないか若干不安があったのですが、どのチームも短い時間で自分たちの考えを述べていました。とても素晴らしいと思います。

とはいえ改善点は多々あります。改善点があるということは次はもっと良いものにできるということなので、気が早いかもしれませんが、今から来年が楽しみです。

最後にVOYAGE GROUPのFacebookの写真にどどーんと50枚アップされている中から何枚か抜粋。

gihyo.jpに掲載された「Webクリエイティブ職の学び場研究」インタビューの補足

このエントリはmakoga's memoに移設しました。

エンジニア向け新インターン『Sunrise』が始まりました。

VOYAGE GROUPのインターンは「ミチをソウゾウせよ」というコンセプトで企画・運営しています。
今年から始まったSunriseの対象者は、例えばシンプルな掲示板くらいなら1人で作れるスキルを持った人です。100万人以上が使うという彼らにとって「未知」の規模を支えるシステムを「創造」してもらいます。

今日のメインはDBAによるデータベース戦略です。

第1章　単一のデータベースサーバの性能とデータベースの性質を知る

第2章　データベースシステムのシステム要件

第3章　サービスの成長とあわせたデータベースの拡張戦略について

第4章　データベースサーバのI/O戦略

第5章　データベースサーバの視点からBtoCモデルのWebサイトの性質を考える

第6章　VOYAGE GROUPでのサイトの成長にあわせたデータベースサーバの拡張事例

かなり濃い内容なのでみんな真剣です。

休憩中も講師に質問してます。

講義の間にはチームでの発表もありました

今回の参加者は12人なので弊社のライブラリ兼集中スペースのOASISで行いましたが、とても良い雰囲気でした！

VOYAGE CUP 2011では悔しい思いをしたので、来年は余裕を持った事前準備を心がけたい。

VOYAGE CUPについては下記CEO、CCOのエントリを読んでもらえればと思います。
ナビリンピックからVOYAGE　CUPへ
VOYAGE　CUPをなぜ開催するのか
VOYAGE CUP開催！
VOYAGE CUP閉幕！

私のいる黄色チームは下馬評が高く、私自身も本気で優勝を狙っていました。しかし、結果は6チーム中6位。とても悔しいです。

3Dボール(特殊なドッチボール)では1位と1人差、2位とは同点のすえジャンケンで3位。リレーでは最初から上位をキープし途中1位にもなったけど結果3位。チーム全体の運動能力の高さは示せたと思います。
しかし、10人11脚や大縄跳びなど事前練習がものをいう競技はいい結果が出せませんでした。1人ひとりの能力が高く全員が全力を出したのにも関わらず結果を出なかった事実を受け止め、まず反省し、そして必ず来年に繋げていきたいと思います。

黄色チームは普段一緒に仕事してる人が少なくなるよう意識してメンバー構成をしたと聞いています。その中で黄色チームのコンセプトである「楽しんで勝つ＝楽勝」の楽しむ部分は実現できたことはとても良かったと思ってます。来年はお互いを助け合うことがもっとさりげなくできるように余裕をもった事前準備を行い、今年よりも楽しんで優勝を狙いたいと思います。

キャプテンはじめ、チームメンバーのみなさんお疲れ様でした。
来年も優勝目指して頑張ろう！

VOYAGE札幌ラボで各種レビュー＆Ruby on Rails開発講座

11/2夜から11/4夕方までVOYAGE札幌ラボに行ってきました。今回の目的は各種レビュー(サービスレビュー、システム設計レビュー、コードレビュー)とRuby on Rails(以下RoR)開発講座です。

札幌ラボではサーバサイドでRoRを利用しています。6月中旬にワークショップを開催しインストールからチュートリアルまで行い、その後各チームでアプリを開発してきました。しかしこれまであまりレビューできていませんでした。そこで今回はECナビ事業本部の@kuromatuくんを連れてがっつりレビュー＆開発の進め方について説明してきました。おかげで札幌ラボのレベルが1つ上がりました。休日にボランティアで対応してくれた@kuromatuくん、および送り出してくれた関係者の皆様には大変感謝です。

今回最も強く感じたことはユーザ目線で考えるということはそんなに簡単じゃないよねということでした。

例えば、札幌ラボでは

カラオケどストライクというアプリをリリースしてます。もちろんまだまだ改善の余地があるアプリです。次のバージョンはどうしよっかと聞いたらソーシャルサービスとの連携を考えていますという返答でした。何となく聞こえはいいですが本当に必要でしょうか。そもそも自分たちはこのアプリ使ってるのかと聞くと、なんと企画者自身が使っていませんでした。なぜ使っていないのかと聞くと曲を登録するのが手間だからということでした。そこで改めて手書きでA4に収まるくらいのざっくりしたユーザーストーリーを書きました。そこから出た結論は、曲登録をもっと簡単にすることを最優先とすることでした。

このような最初は自分たちが欲しいものを作っていたはずがいつの間にか何となくあると良さそうなものを作ろうとしてたという話は珍しいことではないので今後はより意識していきたいと思います。

そして、もっともっと良いサービスを札幌ラボから提供していきたいと思います。

『複雑さと共に暮らす』をベースにした社内勉強会を開催しました。

認知科学者であり『誰のためのデザイン？』でuser-centered design (UCD)を提唱したことでも有名なドナルド・ノーマンの『複雑さと共に暮らす』を読んで思うところがあったので10/24(月)に社内勉強会を開催しました。

複雑さと共に暮らす―デザインの挑戦/ドナルド・ノーマン: ￥2,940; Amazon.co.jp

この勉強会で伝えたかったことは以下の3つでした。

デザインは全ての職種に必要
複雑さと分かりにくさを区別する
テスラーの複雑性保存則

Webサービスはユーザが直接使うWebサイトだけで成り立っている訳ではなく、裏側でもユーザーサポート、商品管理、広告管理、など様々な役割があります。それを全体的にデザインすることでユーザに快適なエクスペリエンスを提供できます。ゆえに全ての職種でデザインする必要があります。また、複雑さと簡単さはトレードオフと考えがちですが、そうではありません。ユーザが求めているのは求める機能が全てあり、(つまり簡単ではない)、理解しやすい、分かりやすいものです。複雑さと分かりにくさは区別しなければなりません。全体の複雑さは一定であり、移動させることしかできないとテスラーは言っています。それをいかにユーザから離すのがデザイナー、エンジニア、運用者の腕の見せ所だと思います。

まだまだ私も確固たる考えを持っているわけではありませんので、今後もクルーと一緒に本質を追い求めていきたいと思います。

事業を成功させるためのデザインとソフトウェア開発

最近一番時間を使っているのが事業を成功させるためのデザインとソフトウェア開発についてです。

もちろん唯一の正しい方法(いわゆる銀の弾丸)はありませんので、ガチガチに標準化するつもりはありません。技術や開発プロセスの進歩に合わせてよりよい方法を考え続けることが重要だと思っています。

考える上でのキーワードは現状は以下になります。

System Thinking
UX
agile
Discovery and Delivery
Business goal and User goal

いろいろなクルーを巻き込んで考えていきたいと思っていますので、お酒を飲みながらアツく語り合う人募集中です。；）

1 | 2 次のページへ >>

ブログ画像一覧を見る

このブログをフォローする