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

2月13日にDevelopers Summit 2014の1日目のセッションを聞きに行ってきました。2日目も午後のセッションに申し込んでいましたが、雪なので欠席。前回はデブサミ2013に行ってきました。2年連続で行ったのは初めてかも。

資料はデブサミ2014、講演関連資料まとめにリンクがあります。動画配信もしたらよいのにと思いますけど、技術やコスト以外での何らかの事情があるのでしょうね。

以下はセッションの感想兼仕事の愚痴など。

【13-A-1】クラウドがもたらした多様な破壊と創造

みなさんのプレゼンがおもしろいセッションでした。新野さんのPublickeyは職場で休み時間などによく見ています。

クラウドが破壊しそうなものとして従来型のSIや労働集約的なシステム運用が紹介されていて、受注単価が2桁下がったとか運用担当者が削減された例の紹介。SIの先行きについては何年も前から暗いというか変化の話が出てはいるものの身の回りでは実感がないというのが正直なところ。まだ数年は影響をあまり受けない可能性もありますが、気がついた時にはどうにもならなくなってしまったなんていう怖い可能性もあるので世間の情報を見つつ、変化に追随してゆけるような行動をとっておかないと危なそうです。

クラウドが創造するものの一つに「活発なコミュニティによる個人の成長」というのがあげられていて「会社の先輩が教えてくれますか？」という問いかけがありました。こういう問いが出てくるということは、これまでは会社の先輩が教えてくれていたということですよね。事務処理とかプロジェクト固有のドキュメント化されていない諸々とか全社標準の品質管理プロセス(←未だに納得してない部分も多いけど)は教わりましたが、技術的なことのほとんどは自宅での独学かWeb上の情報で学んでいました。見方によってはお金ももらわずに仕事を持ち帰ってやっているという不幸な状況ともいえるわけですが、結果的にはそれがよい方に転ぶ可能性が高そうです。

AWS玉川さんのお話。「プラットフォームであるクラウドが創造的破壊を起こす時　その境界線で破壊と創造がはじまる」とありましたが、境界線というのが自分の中で実感できていないです。エンタープライズとソーシャル、生産者と消費者、有料と無料あたりは振り返ってみれはこういうことがあったねという出来事がいろいろあったり、これからもさらにいろいろなことが起きていくという感じも受けます。

ハンズラボの長谷川さんのお話。内容だけではなくて話し方もおもしろかったです。これは本来あるべき情シスの形の一つでしょうね。

「2017年に営業部門のIT予算が情報システム部門のIT予算を超える」という予想。本当に超えるかどうかはわかりませんが、今後情報システム部門のIT予算が増えていくという雰囲気がないとするとそれ以外の部門からの案件受注が重要ということに間違いはなさそう。そうなった時に今のSI事業者がやっているようなウォーターフォールの開発プロセスが成り立つような気がぜんぜんしません。販促とか企画の人相手に、「最初に要件をすべて洗い出してください」とか、「こういうシステムを作るということでよいですよねといって紙のドキュメントを承認してもらう」とか、「これで承認されてますからそれ以外は費用追加になります」なんていう進め方は納得してもらえるのでしょうか。代わりとしてはアジャイル開発のプロセスが最有力候補だと思いますが、規模の大きいSI事業者においてはアジャイル開発プロセス導入の最大の障壁は自社のシステム部門だと予想しています。

サーバーワークスの大石さんのお話。動画やスライドで切腹ネタは見たことがありましたけど、生で見られたのがよかったです。

時間の重要性に関する手紙と電話の例。まったくもってその通りですし誰もが納得すると思いますが、現実の受託開発の世界ですと時間がかかる方がお金になるということになっていて、発注側受注側双方それを受け入れているという状況。これに関しては非情報システム部門のIT予算によるシステム開発が増えるとともに是正されるのではないかと思っています。

「お客様のためのコードを書かない」とはすごいですね。業務と技術の両方がわかるからこそできることなのではないかと思います。

コンカーの三村さんのお話。予想よりもコンカーを知っている人が少なかったです。そういえば自分がコンカーを知ったのは技術系のブログではなくコンサル系のブログだったので、デブサミ参加者の観測範囲ではそれほど目立ってなかったのかも。

「IT部門主導 → 業務部門主導」や「年・月 → 週・日」というのは共通の話題。

パーフェクトトリップの動画はこれですね。The Perfect Trip。YouTubeにも同じ動画があって4万5千再生を超えていました。わかりやすい動画です。

Wantedlyの仲さんのお話。ここからはスタートアップの方のお話です。

「シゴトでココロオドル人を増やす」とはすばらしい。近いことを読んだことがあって、メモしておいたものがあるので紹介しておきます。

道は開ける　新装版

仕事に興味をもつことがあなたのためになるということだけを考えてほしい。あなたは人生から得る幸福を倍増させることができるかもしれない。なぜなら、あなたは起きている時間の半分近くを仕事に費やしており、その仕事の中に幸福を発見できないのなら、幸福などどこにも見いだすことはできないであろう。 仕事に興味を持てば悩みからも解放されるし、長い目で見れば昇進や昇給にもつながるであろう。仮にそんな効果がなくても、疲労は最小限に軽くなり、余暇を楽しむことができるようになるだろう。

仕事の価値で「お金 → 自己実現ややりがい」については異論のある方もいるとは思いますが、お金は必要条件であって仕事を選ぶ上での最優先項目ではないというのを素直にサービスにしたという感じでしょうか。

Coineyの佐俣さんのお話。決済ルールを変える、決済情報のあり方を変えるとはすごい目標。

「決済情報をインターネットですべてつなげる」みたいな構想は好きなのですけど、世の中には情報を悪用することもいとわないという人がいる現実があるので、じゃあ自分がその流れに率先して乗るかといわれると躊躇してしまいます。

「既存のルールを変えるのが一番大変」というのは、社内関係者の説得コストが高いので妥協する道を選んでいる身としては共感できますし、そこに挑戦しているのはすごいなと思います。

最後はクラウドワークスの吉田さんのお話。時間が押していたのか速いペースのトーク。

「スキルの空き枠」というところから人材の仮想化という言葉を思いついて、それはSI業界では多重請負構造で何年も前から実現しているなと思ったりしました。もっとも、クラウドソーシングは時間単位・ネットで完結というところが新しいですし、多重請負構造は構成員の人生を犠牲にして成り立っている部分があったりなかったりするのに対して、クラウドソーシングは余剰時間の活用というところで性格が全然違いますね。

「所有 → 借りる → 従量課金」なんですよね。そのうち正社員が在庫並みに負の資産扱いされる時代が来るのでしょうか。というか来ているのでしょうか。リストラの話題を見る限りでは来ていますよね。これからは自分を課金アイテム化する時代とか？

【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略

「手順書がメンテされないリスク」はうちの職場ではリスクではなく現実です。手順書にかかわらずドキュメント全般がそうなのですけど。初版作成まではドキュメント命というぐらいに時間をかけているのに、そのあとが続かないのはおかしな話です。

基本的に納めて終わりの受託開発の世界なので運用環境においては手作業で一発勝負の世界です。しかし開発環境においては何度もデプロイすることになるので参考にしたいところ。ということで「最初から始める」というのは取り入れたいです。「バージョン管理は躾」は耳が痛い。ブランチなしのメインライン一本での運用になっています。ここは改善しなくては。

「Infrastructure as code」は自分にとってはうれしい流れかも。ここ最近のクラウド化の流れで自社のクラウド基盤なんていうものもあるのですが、私の中ではなんちゃってクラウドと呼ばれている代物で運用はたぶんほとんど手作業。何かをするにはExcelで申請書を出して処理されるまでリードタイムが数日という世界です。これがコードで制御できるようになって自分の好きなタイミングですぐに実行できると助かります。だったらAWSを使おうよということなのですけど技術的にではなくて政治的にいろいろ大変です。将来的にはどの基盤を使うにせよAPIはAWS互換になりそうですし、サービスのラインナップもAWSを参考にしたものがでてくるだろうと思うので、今のうちからAWSで経験値を稼いでおくのも悪くなさそう。

【13-C-4】iOSにAndroid、百花繚乱モバイル開発環境を比較する

仕事ではネイティブかWeb、趣味ではネイティブかDelphiとほとんど決まっているので情報収集目当てで話を聞きました。

Sencha TouchだとWindowsでipaが作れるとは。自宅はMacなのであまり関係ありませんが、職場は基本的にMacがないのでちょっとよいかも。

Xamarinもよさそうかなと思いましたが、UIをネイティブで書くなら全部ネイティブで書く方を選びたいところ。職場で使うことを考えたらObjectieve-Cを書かなくてもよいというのは魅力ですが、どうせC#を書ける人もいないので情報を見つけやすそうなObjective-Cの方が苦労が少なくてすみそう。

Delphiのワンソースで済むというのはよいですね。趣味プログラミングで活用してゆきたいです。仕事ではDelphi言語もC++も無理ですね。世間的にiOSとAndroidの両対応ではDelphiがデファクトスタンダードというぐらいになれば別ですが。

【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント

「期待マネジメント」。部下に対しては自分が期待することを明示していました。効果はあったと思うのですが明示された側からしたらどうだったのか聞いておけばよかったかも。明示することにしたのはこれの影響です。

速効! SEのための部下と後輩を育てる20のテクニック (日経ITプロフェッショナルBOOKS)

OJTを実施する際の基本的な心構えで最も大切なのは、「その部下や後輩に、こうなって欲しい」という人材像を明確にしたうえで、それを部下や後輩に伝えることである。目指す人材像が明らかでないと、行き当たりばったりの指導になり、「その時々で、言うことが違う」ことになりかねない。OJTを受ける側の部下や後輩も、「自分に何を期待されているのか」が分からなければ、積極的に学ぶ意欲を持ちにくい。

ただし、OJTで目指す人材像を部下や後輩に伝える際には、抽象的な言葉を使わないように気を付けたい。

マネジャー向けの人材育成セミナーで、参加者に「部下や後輩をどんな人に育てたいですか」と問うと、「自立型人間」とか「プロ意識のあるメンバー」、「ビジネス・マインドを持ったエンジニア」、「人間力がある人」といった漠然とした答えが 返ってくることが多い。

しかし、「自立型人間とは、どんな人ですか？」、「プロ意識のあるメンバーとは、具体的に何をどんな風にできる人ですか？」と問い掛けると、「うーん…」と考え込んでしまう。指導する側が人材像を具体的に表現できないのに、指導を受ける相手にそれが伝わるはずがない。

最近ではプロジェクトの開始時にプロジェクトメンバーに対して「今回のプロジェクトで挑戦したいこと」を考えてもらうようにしてもらっていますけど、新たにドラッカー風エクササイズを取り入れてみようかなと思いました。

「モチベーションマネジメント」。手助けは結構やっているつもりで、その人にとって楽しくない＆その人の成長につながらないようなことを多くは割り振らないように気をつけています。なので、立場を変わってほしいと思うこともしばしば。

反面、自分自身はモチベーションに頼らずにタスクをこなすにはどうすればよいかという後ろ向きなことを考える事態に陥っています。健全ではないなと思うのですけど、上司は「仕事なんだからいわれたことはやろうよ」とか「仕事ってそういうものだから」という考え方だったりするのでなかなか難しい。自分も上司の立場になったらそういう考え方になるか、自分で抱え込みすぎてどうしようもなくなるかしてしまうと思うので、今の状態で楽しく過ごせるようにするのがよいのかななんて思います。

「褒めるのではなく、一緒に喜ぶ」は大事かも。自分の環境では褒めたり褒められたりすることはほとんどなく感謝するという方が多くて「ありがとう」という言葉を自分も相手もよく使っています。それはそれでよいと思いますが、一緒に喜べるようになるとさらに仕事が楽しくなりそうです。

【13-B-6】mobile backend活用事例から見る「これからのスマホアプリ開発とクラウドの展望」

情報収集目当てでの参加。

「mBaaS」。サーバー側の処理を全部やってくれるのは楽。自分でも必要な機能を作ることはできると思いますが、作るのと使うのでは開発の速度が違います。他でもいわれていることですが、これからは各種サービスをいかに組み合わせるかというのが開発のポイントとなりそうです。

ビジネス的にはデータは自分たちが押さえておきたいという面もあると思うので、そことの折り合いをどうつけるのかというのが課題になってくるかも。

mBaaSもそうですがニフティはクラウドサービスがんばっている印象です。AWSがすごすぎでかすんでしまう面はありますが、国産のサービスの中ではユーザーが制御可能なサービスメニューの多さやAPIでの制御可能な範囲は一つ抜けているかなと思います。

【13-C-7】「ITエンジニアに読んでほしい！技術書・ビジネス書大賞」LT大会

やっぱりみなさんプレゼンうまいですよね。持っている本は再読したくなったし、持っていない本は買って読みたくなりました。

小さなチーム、大きな仕事は早川書房でしたか。たしかに早川はSFという印象が強いです。

日経BPはデマルコ本の印象が強くて、あの系統の表紙とは違うリーンスタートアップは日経BPという印象はまったくありませんでした。

技術書やビジネス書は書名買いが多いので出版社を意識するケースは少ないですね。オライリーは別ですけど。余談ですが、小説は出版社別の作者別で並んでいることが多いので書店で買っていた頃は出版社の意識がそれなりにありましたけど、最近は電子書籍になってそれもなくなってきました。

和田さんからリーンスタートアップについて「ユーザーの話を聞けと言っていて自分の考えと合わない」というような趣旨の発言がありましたが、自分は「利益につながっているかどうかの検証のため、ユーザーの行動を計測せよ」というとらえ方をしていたので違和感がありました。読み手によって、記憶に残る部分や物事のとらえ方は違いますね。

「プログラミング作法」は「さくほう」と読んでいました。作り方という印象に引っ張られたせいです、きっと。