都内で働くSEの技術的なひとりごと / Technical soliloquy of System Engineer working in Tokyo

都内でサラリーマンやってます。SQL Server を中心とした (2023年からは Azure も。) マイクロソフト系(たまに、OSS系などマイクロソフト以外の技術も...)の技術的なことについて書いています。日々の仕事の中で、気になったことを技術要素関係なく気まぐれに選んでいるので記事内容は開発言語、インフラ等ばらばらです。なお、当ブログで発信、発言は私個人のものであり、所属する組織、企業、団体等とは何のかかわりもございません。ブログの内容もきちんと検証して使用してください。英語の勉強のため、英語の

Developers Summit 2013 Award & Revival

4/20(土) 楽天タワービルで翔泳社主催の『Developers Summit 2013 Award & Revival』が開催されました。参加してきたので、少し内容について書きたいと思います。

スピーカーは、

です。

※大石さん、野口さん、和田さんの講演を聞いたのは初めてでした。

 

まずは、大石さんの講演。
 大石 内蔵助(おおいし くらのすけ)にかけた持ちネタ?『切腹プレゼン』が非常に面白く、引きこまれます。演題は、『「SIの未来ってどうなのよ?」SIer大淘汰時代にAWS専業で新しいSIの形にチャレンジする企業の舞台裏』です。
 サーバーワークスは、3.11に発生した東日本大震災直後、世界中からのアクセスに耐え切れずダウンした日本赤十字社のサーバを、AWS(Amazon Web Service)を使ったキャッシュサーバを30分で構築・復旧させました。その後、サーバは一度もダウンすることはなかったそうです。また、日本赤十字社の義援金サイトを48時間で要件定義・設計・開発・AWSへのリリースしました。
 巷では、『SIヲワタ』とか『SIオワコン』とか言われはじめて、はや数年たちます。もうSIは求められていない、いやそれは違う、求められた方が変わってきているということです。今までのSIはピラミッド構造で、多くの技術者が連携・コミュニケーションを取りながら、設計・開発・テスト・品質確保・リリースを行なってきました。しかし、クラウドが主流の現在では、それぞれのクラウドサービスの特性を考慮し、作る技術ではなく、それぞれのクラウドサービスの特性を見極め、組み合わせる技術必要だということです。それに加え、予測不能なこの世の中で、将来を推測する力ではなく、将来何か問題が発生した事象への対応力を磨くほうが大事、このような能力が今後の技術者に求められるのでしょう。(しかし、このようなレベルにどれだけの人数の技術者がついてこれるんだろう...私の勤める会社でも例外ではありませんが.....)
※大石さんはAWS Summit 2013講演をされるんですね。仕事が調整できたら行こうかと思います。

 

次は、野口さんの講演。
 ドワンゴでニコニコ静画(電子書籍)開発チームのプロジェクトマネージャを担当されています。演題は、『ニコニコ静画(電子書籍)の作り方 ~みんながニコニコしてくれる読書体験を届けるために~』です。
 社内では、GitHub Enterpriseを使ったソース管理、Jenkinsを使ったビルド・テスト・デプロイを実践されています。テストを書け、問題を根性で解決するな、何をやってもいい、問題を根性でかいけつするな、失敗を引きずるな等のルールを定めているようです。社内のルールは誰にでも理解できるものしかない、非常にシンプルなものばかりです。Simple is Best.やっぱりこれが一番ですね。非常に複雑な承認フロー、押印リレーはよくないです。(あ、これはうちの会社のことか。)

 また、野口さんは社内のチーム作りをよく考えられている感じがしました。楽しくなければ仕事じゃない、メンバーには楽しく仕事してほしいというキーワードがプレゼンの中にも散りばめられていたのが印象的でした。
※GitHubはまだちゃんと使ったことないですね。今度勉強してみようかな。

 

次は、吉羽さんの講演。

 演題は、『ワンクリックデプロイ ~いつまで手でデプロイしてるんですか~』です。

 システム機能の使用割合のグラフで、『まったく使わない』『ほとんど使わない』が7割を超えることにちょっとドキッとしました。自分の設計・開発しているシステムもそんなもんだったりして..その後のプレゼン内容も確かにその通りー、の連続。アジャイル顧客満足を最優先にし、継続的に早く提供するはごもっともだなぁと思いつつ、今の自分の環境では中々難しいなと、プレゼン中にジレンマを感じる連続でした。(このような考えではいけないんだなーとも思いますが....)

 Amazonの開発では、本番環境へのDeployを一時間あたりに1000回も行なっているとのこと。テストから運用環境へのDeployなど完全に自動化されているんでしょう。そこまでのレベルに到達できるのは短時間では無理で、試行錯誤を繰り返し、積み重ねて構築されるものなのでしょう。Silver Bulletは存在しない。うーん、継続的に改善するのも中々難しい....

※この本買って勉強しよう。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

 

最後に和田さんの講演。
 演題は、『SQLアンチパターン - 開発者を待ち受ける25の落とし穴』です。

和田さんは、SQLアンチパターン↓の訳者です。

SQLアンチパターン

SQLアンチパターン


この書籍は、DB設計やSQL記述の際に避けるべき事柄を1章で1つ、25種類紹介する書籍です。講演では、この25のアンチパターンを軽快かつ面白くプレゼンされていました。このプレゼンの途中で、PCのバッテリが切れてしまいメモが取れませんでした(泣)印象に残っているものを書いてみます。

  • ナイーブツリー
    フォルダ階層のような構造をテーブル設計する場合によくある設計ですが、idとparent_idを保持して階層構造を表現すると思います。このような再帰的構造は、RDBMSがCTEに対応していれば使用してもよいらしいです。代表的なRDBMSは大体対応していますね。※SQL Serverは、2005以降CTEに対応しています。
  • ジェイウォーク
    ある列に対してデータをカンマ区切りで格納・利用する方式です。若かりし頃よくやっていた気がします。
  • キーレスエントリ
    外部キー制約を使いましょうということです。プログラムでテーブル間の整合性を保っていると、テーブル間の仕様を知らない開発者が書いたバッチプログラムなどで不整合が発生してしまいます。しかし、外部キー制約って意外と知らない人が多いような気がします。(私の所だけ?)
  • エンティティ・アトリビュート・バリュー
    属性とその値をもったようなテーブルを設計することです。しかしこの手のテーブル設計未だにやってます。
  • インデックスショットガン
    何も考えずにインデックスを作成するのはやめましょう。しかし、最近SSDやFusion IOなどの超高速なIOを実現できる製品も多くでているので、検索性高速化のため、インデックスが多くなる傾向がありますね。とはいってもちゃんと考えましょう。
  • フィア・オブ・ジ・アンノウン
    NOT NULLはだめよということです。NOT NULLを嫌う開発者がNOT NULLで設定し、適当な初期値を設定することで合計を算出する場合などに大きな誤差が出てしまう。それを回避するため、非常に面倒なSQL文を書く必要が出てしまった....これもよくやってたかもしれません。

※その他にも昔やっちゃったなぁというパターンが幾つかありました。この本すごくよさそうですね。ポチってしまおうかな....SCRUM BOOTとSQLの2冊買ったら6,000円、ちょっとお昼ごはんを削ってみましょうかね。

 

いや、ほんとに今回の講演はためになりました。このような講演を拝聴するたびに、自分の知見のなさがわかります。システム設計とかやってていいんだろうかと。もっと頑張らないといけませんね....