デブサミ2013に行ってきました!

おっさん、社内SEだよね?おっさんの会社、開発してないよね?おっさん、フロント向けサービスにあんま関係してないよね?
数々の疑問を蹴散らして、デブサミ2013へ行ってきました。
今年のテーマはAction!だそうです。聞いただけじゃなく、行動しやがれ!ってことなんでしょうね。
おっさんはデブサミの存在は前々から知っていましたが、転職によって現場を離れたこともあり、参加には躊躇していました。(現場時代はそんな暇ないレベルだったので行けませんでしたw)
申し込んだセッションは属性がエンタープライズ、それもプロジェクトオーナー側という特殊な立場であるため、少々マニアックでした。(非ITの方にすれば集まり自体がマニアックではあるのですがw)開発にどっぷりつかっている人はあまり注目されない事柄ですが、同じような立場の人が見ることを期待して、いくつかピックアップで書いてみます。

  1. 600億件を数十秒で検索するクラウド規模クエリサービスBigQuery
    いまどきらしい、クラウド&BigDataのお話でした。まとめると、GoogleBigQueryの縁の下にいる力持ちはDremelというエンジン。こいつのおかげで毎回全検索を数千個のCPU=数千台のマシンで分散して走らせる。爆速。バッチ処理メインのMapReduseなどとベクトルが若干違うから、両方を組み合わせることでバカデカイデータを使っていきましょう、といった感じ。

    あまり深くは話されませんでしたが、おっさんが気になったのは「カラム指向ストレージ」のところ。
    おっさんの業界では法律によって、抑えるべきデータがちょくちょく変わります。解決法は2つ。カラムを追加するか、既存カラムに別要素を突っ込むか。当然RDBを使っている以上、きれいな方法など思いつきません。(リファクタするレベルで制度対応を考えられる発注者はいませんから。)
    後に残る負の遺産、Indexの変更、行オーバヘッドによる無駄領域の浪費、カーディナリティの無理やりな変化に伴う性能劣化・・・・などなど。わかっていても避けられない問題です。
    カラム指向ストレージは文字通りカラムごとにデータを残していく方法だそうです。これはうまく使うと、おっさんの業界のようなデータモデル自体が変化してしまうシステムにとってはかなり救世主的な存在になるかもしれません。おっさん、俄然勉強したくなりました。
    BigQueryの利用法でお話しされた「トライ&エラーによる分析手前の作業」については、もう100回ほどうなずきたくなりました。馬鹿でかいRDBのデータファイルを相手に叩いては待ちを繰り返すこと自体が無駄なコストです。待って済むならまだしも、場合によっては待つ→返ってこない→kill→ゾンビ残って再起動なんてこともwもう、バカとしか言いようがないです。
    こういう作業の無駄と戦うのがナウなヤングのITなんでしょうね。(爆)

    BigQueryのBIツール(?)なども紹介されましたが、一番気になったのはGoogleスプレッドシートとの連携。エクセルでもOracle、SQL Serverあたりとはできるようになっていますが、結構設定がめんどくさい。Googleスプレッドシートだとどのくらいの捜査難度なのかな。

    あと、セッション後のアスクザスピーカーにて、演者の佐藤一憲氏にお話しをうかがうことができました。
    正直、おっさんの個人的質問は後回しで、会社的に有用な質問ばかりしてしまいました。佐藤さんには畑違いの質問ばかりで申し訳なかったのですが、エンタープライズで利用する場合の方法や事例をうかがえたことで、クラウドに否定的な会社の人に説明できる材料がいただけたことはとても感謝しています。

  2. 「SIの未来ってどうなのよ?」SIer大淘汰時代にAWS専業で新しいSIの形にチャレンジする企業の舞台裏
    SIerの偉い人向け的なお話。人売りやコンサルで儲けるより、大手基盤を使うノウハウで儲けて行こうというタイトル通りSIerの将来を考えるセッションでした。
    おっさんからすると「敵情視察」になるんですかね。もしくはSIerのお客として新製品のプロモーションを見た感覚かな。

    違う視点からお話しを聞いて、気になったのは「クラウド導入に躊躇する企業側の懸念」という部分。やはり、というか「セキュリティ」が一番にあがりました。
    AWSでの事例は責任分界点があること。外部からの攻撃や、クラッキングなどによる情報漏えい。これは企業が責任もって防御しなさい。ただし内側からの不正なアクセスによる情報漏えいや物理的防御はNASA、アメリカ政府からのお墨付きがもらえるレベルで防御します、だそうです。ものすごく理に適った話です。
    たとえばおっさんの会社のDCでNASA、アメリカ政府からお墨付きがもらえるほどのセキュリティを敷けるか。答えはNOです。セキュリティってのはお高いもんなのです。そんなお金出してくれる会社じゃないです。
    演者の大石良氏は銀行に例えていましたが、大事なお金は銀行に預けて安心。じゃぁ、大事なデータも高いセキュリティを持つサービスに預ければ安心なんじゃないの?全くその通りです。
    銀行にお金を預けたら、預金者が必ずしなければならないこと。それは通帳、印鑑、キャッシュカードと暗証番号の管理です。自己防衛です。同じようにクラウドにデータを預けたら、ユーザも自己防衛をしなきゃいけません。当然のことです。
    つまり、「クラウド導入にはセキュリティが課題」というのは、結局のところ、「クラウド導入には自分たちのセキュリティ意識が課題」なのだと思いました。自己防衛をしていないorしたくないことを理由にオンプレミスだけで莫大な時間とお金をかけてシステムを運用していく。
    高いセキュリティは弊害として業務の複雑化や管理コストの上昇をもたらします。オンプレ環境で物理的な危険の排除を信じている人が認証システム導入やや承認プロセスを嫌う一因でもあります。でもそれって守るためのセキュリティじゃないからなんじゃない?役場や監査に報告するためのセキュリティにしてるからじゃない?
    クラウド導入における課題に対峙するというのは、本質的な自己防衛を考えるいいチャンスなのかもしれません。

  3. ソーシャルコーディング革命後の開発委託の世界0QA@ITの事例
    これは正直、おっさんにとっては夢の国のお話でした。
    今のシステムベンダとお客の関係、現状はとてもじゃないが正気の沙汰じゃないです。
    開発ではHWに払う金はあっても技術者に払う作業費用、開発費は「タダでやって」から交渉する。
    保守費をくれというと「銭ゲバ」呼ばわり。
    「バグのないシステムを作れ」(なら自分らはクレームのこない商品を売れよ)。
    コード一行書けないのに技術者を御用聞き扱いにし、金がないから社内の人間にコードをコピペさせる矛盾だらけで品質無視の暴挙。
    枚挙に暇がないとはまさにこのこと。
    ソーシャルコーディングはお客の側がコードが書けることが前提です。ぶっちゃけ、情報システム部門の人間でもそういった人は少ないです。(今の情報システム部門の大半はコンサルくずれの寄せ集めがいいところ)多少書ける人がいても、プロダクトとして出せるレベルの人はまずいない。
    必要ないから、というのが一番大きな理由で、社内で教育することもありませんし、技術を持った人間を採用することも稀です。システムがなければ業務が回らないのに、技術を学ぶことに徹底して否定的です。こういった現状から「夢の国のお話」と思ってしまいました。
    コードを書けることが必要、というのは手段としての条件であって、その前段階が重要だと思います。技術を学ぶこと、pull reqをして委託先から「コードレビュを受ける」という姿勢になること、そしてなにより、一行のコードを動かす労力はどのくらいなのかを知ること。考え方の話になっていますが、今の委託側は実技に入れるレベルじゃないので、まずは考え方から入らないとだめです。
    よくおっさんは「技術的に無理、という事例はほとんどない。お金を払い、時間を割き、リスクを背負えば大抵のことはできる」と言っていますが、これは金満開発をしろ、と言っているのではありません。技術の価値はとても大きく、そこに制約を課して「無理」を作っているのは開発者ではなく、ユーザなのだということを伝えたいのです。
    ソーシャルコーディング、作っていく中に本当に委託側が参加していく開発の在り方は僕たち発注者がいかにして「無理」を作り出し、いかにしてそれを取り除けるかを学ぶことができる最良の手段なのではないでしょうか。

以上が1日目のセッションのハイライトと感想です。
2日目はSQLアンチパターンなどちょっと趣味にも走ってみましたwクラウディアさんにも会ってみたり、お祭り的楽しさも十分感じられてテンション(´∀`∩)↑age↑の2日間でした。
さて、今年のテーマ、Actionですが、おっさんはまだどう動けばいいか模索中という感じ。デブサミ参加者の多くがweb系とエンタープライズ系の技術ギャップを感じ、或る者はm9(^Д^)プギャーし、或る者は(´;ω;`)してました。おっさんはそこからさらにギャップがある発注者側、委託側です。
おっさんはある意味、デブサミという属性を全く無視した会合に行くことがActionでもありました。開発者の人からすればずいぶんと進歩のない話ですが、残念なことに今の一般事業会社におけるITの立ち位置はまさにこの状況です。お客様としてではなく、利用者としてでもなく、サービスを自分の会社の看板で世に出す「開発者」としてこういった集まりに参加することすら、大半の人は考えてもいません。
それではだめなんです。たとえ経費削減のためだけであったとしても、プロダクション環境に一行のコードを埋めるなら、ベンダさんに「手順書を出せ」とリリースが迫っていても要求するのなら、社内だけで使うとしてもサーバを立てるなら、所属会社の事業内容によらず、僕たちは「開発者」なのです。技術なくして行動してはいけない人間なのです。
しかし聞いてきた話をそのままバーン!と会社に出しても会社のメールはチラシの裏じゃねぇから、とか言われそう。そういう現状を、どう打破していくのかがおっさんのActionになるんだと思います。
西川きよし師匠の言葉を胸に、おっさんはActionを起こしていきたいと思います。
ちいさなことからコツコツと。

広告
カテゴリー: お仕事 パーマリンク

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中