Developer Summit 2017に参加してきました(２日めのみ）
Devsumi 2017 ２日目のメモと感想です。
走り書き風味になっているのですみません。
途中の（）書きは感想です。
今どきのアーキテクチャを現場の立場で斬る（仮）
井上 誠一郎さん [ワークスアプリケーションズ]
すこしメモ取り損ねたのですが、アーキテクチャ選定の意思決定について
YAGNIのジレンマ
YAGNIとは「機能は実際に必要となるまでは追加しないのがよいとする」こと
今必要なければ決定を遅らせる
ミクロには正しいことが多い
（・・・じゃあマクロでは？）
（多分だけど重要だけど緊急じゃないことが先延ばしされるのかな）
合議制のジレンマ
一定の人数以上になるとうまくいかない
合議制と対称的なトップダウンのアプローチ
ただ、規模が大きくなると全てを把握できない
権限委譲するしかない
ミーティングにおいては決定者を決めてしまう その人が決めたことは基本的には従う
（これには賛成。意思決定が不明確にならないことが大事だと思う）
技術的な課題
「適応」は現実的には想定不足に対応すること
『低レイテンシのアーキテクチャ』を目指す
HTML5 Caanvas 最初は使うつもりはなかった
マルチテナント
IAASのコストが上がる サーバレスなどを取り入れる
特定のロールの人しか触れない 認証基盤の問題
「高性能」「非同期」「キャッシュ」などの問題は開発生産性とトレードオフ
プロセス間通信 隠せない キャッシュ一切ナシは難しい
なぜマイクロサービスにしなかったか？
はじめは分割基準がわからないため、そう判断した
だがモノシリックになりすぎた
マイクロサービス：各サービスが独立したデータストアを持っていること
トランザクション：casandra依存なのでデータストアには苦労してない
なぜ最初からマネージドサービスにしなかったか？
サーバレスなど
フロントエンドをサーバサイドレンダリング まだまだ模索中
mutable immutableのハイブリッド
概念をシリアライズ
人が増えることは想定済み だが半分空想
オープソースコミュニティ のように お互いがプルリクを送りあえるようなものを目指す
現実
どこかでうまくコミュニケーション
ワークス伝統のカタログが強み 企業向け製品のパッケージベンダー
ある機能を提供したときに、ユーザがどのようなメリットをえるか？
ダンバー数のジレンマ
人間の関心は有限のリソース 人に対して 技術に対して それをどのようにコントロールしていくか
異能の人材たち
声がでかい 態度がでかい タフな精神力 超人的な体力 綺麗事よりも「闘うプログラマー」 こういう人たちがいると圧倒的にプロジェクトは進みやすい
- 作者: G パスカルザカリー
- 出版社/メーカー: 日経BP社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (7件) を見る
(この本は読んでる。井上さんの話を聞いてカトラーなどの人物は「圧倒的な当事者意識」があるのではないかと感じた。)
（「尖ったエンジニアの多い現場でも間を埋めて、とにかく進めさせる」みたいなイメージ）
(あとやっぱ経営の踊り場問題のブログ記事を思い出す。。)
天才プロダクトマネージャ
色んな人がいる ダイバーシティ
人種のるつぼ
日本がヘッドクォータ
Re: ゼロから文化を創り、技術を伝承する ～客先常駐エンジニアと「社内勉強会」で築いた価値と変化
VSN 須賀俊介さん
www.slideshare.net
現場エンジニアへの技術研修
VSNはエンジニア人材を提供する会社
常駐先では技術研修が行えない
帰属意識が薄れるという問題がある
１，２年目で自己研鑽をする姿勢が持てない
成長する段階
(渇望すごく大事。自分が渇望してることを忘れないようにしなくては)
chatterを活用できないか？
デブサミを聞いて 勉強会をしていきたい 情報共有や育成を行っている
したしらべフェーズ
TokyuRuby会議
もくもく会 永和システムマネジメント
ソフトウェア開発で勉強会
業務ではない
興味ある技術について発表 LT
社外の勉強会 イベントにみんなで参加
ハッカソン もくもく会
一年近くやってみて継続できそうだと判断 数人しか参加しないときもあったけど
（こういう勉強会を継続できるのがすごい）
逆に地方に配属されているエンジニアもリモートで参加
（よさしかない）
ネットワークエンジニア強化プロジェクト
今までと違って上からのお達しでの勉強会
資格を取る
現場が忙しい 一人で追いかけるのが辛い
成果としてはよくなかった
モチベーションにつながることが少なかった
IT分野だけで勉強会やってうらやましい 俺達もやってみたい
こういうことするといいよというノウハウを共有
エレクトロニクス分野でも開始 FPGA や CADの勉強 マイコンのプログラミング
- マウス作ろう勉強会 英語勉強会
- 営業ファッション勉強会 元アパレル業界のエンジニアが講師 みだしなみについて
（参加してみたいぞこれ！）
失敗事例と成功事例の比較
タイトルにもあるように リゼロ 失敗してやり直すこともある
続かない 実践できない 広がらない 参加できない
かたや車 かたやロケットをつくっている現場 さまざまな仕事をしている人がいる
参加者が固定 気づくといつもいるメンバーばっかりという問題
何回か行かないとだんだんめんどくさくなる
１回休んじゃうとかお出しづらい？
シフト勤務しているエンジニア 土日出勤
アナウンスをみてない
勉強会のSNSグループに入ってないとわからない
社内SNS自体をみてない
場所の問題
お客様先を使わせてもらえればいいが
若手の育成
忙しくなる と 参加できなくなる
転籍 転職の問題 引っ張ってる人がいなくなり、次世代のリーダー育成をどうにかしないと 業務とかを通じて サブリーダー 少しずつ課題
複数人もしくは継続できるリーダーがいる
スケジュール 場所の解決 スケジュールを予め決める 会社でも鍵の管理やセキュリティ要件をクリア 遠方の参加者でもウェブ経由で参加：WebEX Skype
年間スケジュールをたておいて 合間で特集の勉強会をやってみる AWS 少しずつレベルアップ
無理しない
プロジェクトルイーダの立案 お互いに仲間を見つけあって 勉強会を立ち上げる支援
お客様 業後に勉強会
お客様先の若手育成やりたいというのに答える お仕事としてももらえることも
エンジニアに対する言葉 「エンジニア魂」を語れる
先輩からちゃんとして場で伝えておきたいと思っていることを効率的に伝えられる
広がりとしての価値 他社のいろいろな考え方 知識
同じ方 向を向いている人と一緒に勉強できる 「場を作る」
若手だけじゃなく キャリアも育成できる
成長が見えないエンジニアの育成 面談などでフォローする人が必要
チャンス
ビジョンの共有
（全体的に素晴らしいなと感じた。） （こういう勉強会に参加できるの本当に羨ましい。）
コンテナをフル活用した現場
wantedly 坂部広大さん
仕事で心躍るひとを増やす
会社のビジョン
Wantedly People: 名刺管理のサービス 名刺の写真をスマホでとってwantedlyの登録ユーザを自動的に情報を入力
ビジネスのSNSへの進化
スキル・評判・つながりの３つ資産を充実
プラットフォームを作っていくのが目指すところで単なるリクルーティングを行うのではない
(Wamtedlyのビジョンの話はもっと聞きたいけど、今回はない感じ)
変化に強いインフラを実現していく
Twelve factor appというアプリケーションのルール
Herokuの中の人が書いた
Herokuのすごいとこ-> 意識しなくてもtwelve factor app になっていく
（djangoのチュートリアルでherokuを使ってみたけど、djangoでもtwelve factor appのことは言及されていた）
コンテナを使い始めたときもTwelve factor appを守る
１つのコードベース 複数のデプロイ
依存関係 Gem
設定config configをgit pushしてしまうとポータビリティがなくなる
(Dockerを使ってるとこの辺のことは本当になるほど、という感じ。)
(環境変数でよみこんだりとかいろいろしているのだけれど)
バックエンドをつなげる
(やっぱりHerokuを意識した作りになっているんだろうと思う)
ビルドも分離
Gitのpushのたびにビルド
最終的に実行はコンテナの起動だけ
プロセスはデーモンで起動しない は dockerではいいのかな
スパイクの対処、逆に小さくするスケールインも安全に
ログは（Railsなどの）フレームワークとして使うと、ファイルに出力することが多い
だが、stdout, stderrに出力するようにする
アプリケーションのルール
Dockerの仕組みでもtwelve factor appを勝手に実現している
コード化とツール化
microservicesをすすめる
script/bootstrap, script/server どの言語のエンジニアでも設定、サーバ起動ができる
script/check_environment 環境チェック すぐにコードをかける状態
環境設定はどんどんモチベーションが下がってしまう それを防ぐ
アプリケーション以外はインフラ、みたいな感じでツールを作っている
CIの結果を取得できる
.env
暗号キーなど 期限付きURLのS3ホスティング
アカウントのIAMをつくるのもプルリクエスト
変化に強いインフラを作る
大きな課題
Dockerfileをアプリエンジニアが書くのが大変 設定 ASG, Monitor, Logging, ALB, DNS
インフラチームは２人 「なんかログ出てないけど違うんじゃないか」みたいなことを言われることがある
８０個位のチェックボックス デプロイ大変
Railsエンジニア いつになったらリリースできるの？
Kubernetes
今までログの設定 サーバに縛られる 純粋にアプリケーションがどう動いてるかだけに集中したい
利用者はどのように見えるか？ マシンスペック CPU デプロイ方法 ブルーグリーンまたはロールデプロイ
Kuberenetesのクラスタリングを作ってしまえば あとはかんたん
サービス
新しくサービスを作るとき * 新しいリポジトリを追加 * 既存のコードベースに追加していく ２番めだとどんどんモノシリックの巨大化する
ブランチ名 + git のハッシュ
ダッシュボード Kubernetes + Datadog
Capistranoでのデプロイ から kubernetesのデプロイに変わった 他の言語でも運用は変わらない 参入の障壁が下がった
（ここがすごい。オーケストレーションをKubernetesで必要なくしたってことだ）
（kubernetes自体どんなコードなのかわからないし、知りたい。。。）
Kubernetesのオフィシャル インフラチームには使いやすいがアプリチームには使いやすいとはいえない？
Unix philosophy
(小さく作ってつなげるとか色々大事な考えの宝庫だ)
Microservicesを支えるMicrotools
ツール自体のバージョニングがKubeサーバーで一括管理する
どうかわったか？
アプリケーションエンジニア側でtwelve factor appを作った
wantedly people
すべてのサービスが同じ運用方法
インフラチームも積極的にコードを書く 全体最適のために
（アプリのエンジニアとうまくやるための仕組みをインフラチームが積極的に押し進めているのがいいなぁ） （インフラのコードまだまだ知らないことが多いので知りたいと思いました。）
スタディサプリを支えるデータ分析基盤 ～設計の勘所と利活用事例～
www.slideshare.net
スクラッチから構築した スタディサプリ
カリスマ講師の動画 ゲームをしながら学べる
予備校などよりは安い
公教育でも利用 先生がログインすると課題を配信することができる
宿題の傾向から苦手や得意などを分析して提供する
チーム Dev, Data, Biz SRE
データの基盤 トレジャーデータ cloudでhadoop
一般的なKPIのモニタリング 離脱状況などをレポート
資料を作る
カスタマーサポートのサポート
動画のコンテンツがどのように見られているか コンテンツのパフォーマンスのモニタリング
re dash googel spreadsheet slack
見るもの tableau jupyter
（Dataの人もjupyterも使うんだ。）
学校で利用する人 夏休みの終わりに一気に見る
個別に利用してる人 平均的
アカデミックな話 講義の関係性をマップしたもの
膨大な学習データ 講義間の依存関係がデータからわかる
（単純にすごい。ビジネスとしてどう売上をのばすかということだけでなく、学習そのものの研究につながるとは）
アダプティブラーニングの実証実験
何か躓いてるところ それを理解するための勉強をレコメンドを行う
レコメンドをやっていない生徒とやった生徒
リクルート次世代教育院
受験サプリ 勉強サプリ リクルートテクノロジーパートナーズ 英語サプリ 英単語サプリ リクルートパートナーズ
先生と生徒とのコミュニケーションを活発にするサービスを買収
ブランド変更とシステム移管を同時に実施
（やっぱやることのすけーるでかい・・・。）
データの収集と構造化
テーブルのジョインが一般的
ナマのテーブルには興味がない リレーションが入ったテーブルをみる 細かいロジックを入れたカラムを作る
集約して
Dataからopsに依頼をして一週間後に反映
集約、抽象化された情報しかない
データの取得元やスキーマを柔軟に追加変更できない ブラックボックス
データがおかしいときに調査に時間がかかる
（たしかにこういう経験はある。）
移行後 データを全部引っ張ってくる embulk
Extract, load and transform
手元にすべての生データ 異種のDBを結合するることができる
細部を理解してビジネスロジックを基板側で再現しなければならない
アプリのビジネスロジックとずれる可能性
データ分析チームの持っているスキルセットに依存する
（デブサミの別のスライドでも見たけれど、ほんとすごい） （自分の前職のデータ分析でもこういうふうに仕組みづくりすればいいのかというのがわかる）
行動ログ
web SPA フロントTDのSDK バック rails -> kinesis -> lambda scriptでトレジャーへ
クライアントサイドのログ SPAなのでサーバサイドでは取れない
信頼性が低い 欠損する割合
タグマネージャ経由 クリックイベント ちょくトラッキングに比べて安定して９割欠損
太古や未来からのログ 信頼できない
（あるあるすぎる。変なUAとかも面白いｗ）
サーバサイドのログ 信頼性は高い サーバに到達しない DBに反映されない 行動しないと同義 冗長化がかんたん
実装はしにくい
embulk-filter-hash ハッシュ化 embluk-filter-mask 特定の値だけフィルターするプラグイン
embulkを基盤にしたデータ連携
（embulkすっごーい）
マスタデータ連携 並列実行性 帯域
障害発生を前提とした再実行のべき等性
Hive, Prestoによるデータ集計 設計 ワークフローエンジン luigiジョブ
実行計画DAG 有向無閉路グラフ
Digdagジョブ
pythonでガリガリ書くより宣言的 yaml + js slackに通知
(Pythonでがりがり書くの好きだ・・・・)
timeline形式 上から下に流れる
データはどうやって提供するか
Google spreadsheet が至高
（至高なのか！）
スケジュール実行ができる
データに関わるようになってから思うこと
データは組織をまたいで流れる
データはナマモノ 継続的な鮮度管理 機能開発・ログデータのメンテナンス
文脈を考える人が必要
データでみえていると思った部分 サービスの本質を定めるデータ 次のフェーズで重要になるデータ 見えている部分を本質的な部分に近づける ただし、プロダクトはつねに変質しているので、たえまない軌道修正が必要 データの文脈に向き合うチームへ
目指すところを変えて常に探索を続けなければないけない データだけで見ていても解釈できないこともある 「先生が色々操作していた」 というアドホックなところ
一番の勘所
組織設計ではないか
data, dev, bizが小さく一体的になってぐるぐるまわす
足元のKPI指標からアカデミックなデータまで biz x dev x data
（なるほど。。やっぱ小さくぐるぐる回すのが基本か） （そのためにはメトリクスをどうきっちりとるかが重要なんじゃないかな）
全体的な感想
データ分析基盤の話が自分にとっては新鮮だったかも
BIは日々進化してる。。。
スピーカーの皆様、スタッフの皆様、ありがとうございました。
「けものフレンズ」がいい感じです
最近ちまたで人気の「けものフレンズ」というアニメについてです。
(ものすごく主観的な感想のため、内容に誤りや過大な評価がある可能性があります。また、見ていない人には意味不明な文章です。)
私自身は１話目の冒頭で脱落して、いったん離れたのですが３・４話目くらいからの評判を見聞きして、Ｄアニメストアなどを利用して１話目から見て追いつきました。
一言で感想を言うと、「癒されるアニメだなー」という感じです。
あの世界がなぜ自分にとって癒しとして捉えられているのか？
ある記事にこんなことが書かれていました。
「日本の企業はこう考えるからダメ。欧米のスタートアップはこう考えるから、そんなことにはならない」
「日本の企業」とひとくくりにする主語がでかい案件、といえばそうなんだけどそれを除いてもこの言い方はちょっと攻撃的です。
「俺（欧米のスタートアップ）」はイエス、「おまえ（日本の企業）」はノーという感じで論破を行うコミュニケーションになっています。
俗にいう『WIN-LOSE』の関係です。
こういう論破やマウンティングのコミュニケーションはちょっとだけど疲れます。
本来であればただしい「意識高い系」では「WIN-WIN」で「シナジー」を生み出すコミュニケーションをしなければなりません。
翻って、けものフレンズの世界ではどんなコミュニケーションでしょうか？
まずサーバルのように
「すっごーい。君は〜ができるんだね」
と始まってお互いのリスペクトできるところを承認するところが基本です。
さらに、ビーバーとプレーリードッグみたいに得意とするところで苦手を補いあうような「シナジー」を生み出すことをかばんちゃんが考えて実行します。
さらに、悪いところがあって直さなきゃいけないことを言うときでも、相手への承認(リスペクト)が前提にあるため、ディベートで言い負かすのではなく、弁証法的な正しい批評、つまり自分も相手も高め合うための批評を行うことになっているのです。
このようなコミュニケーションではお互いの心理的安全性は確保され、のびのびと能力が発揮できるでしょう。
こういうのって理想だな、と感じる人にとってはこのアニメは「癒し」と捉えられるんじゃないでしょうか？
オープニングにもある通り、「けものはいてものけものはいない」世界、すごいと思います。
現実の世界は、気づかないところで精神を摩耗してます。
たとえそれが良いことでも変化はストレスになる。
けものフレンズは30分見たはずなのに5分アニメ見たような読後感のある不思議なアニメ（この表現はある方のブコメの引用です）。
たぶん摩耗してるところにビビッドに優しい承認をきりこんでくるからじゃないかなと思います。
みんなのPython勉強会#21 に参加してきました
Python3の進化について
辻真吾さん
いろんな意味で3に移行したほうがいい気はする
ライブラリが移行しきってないとかそういう問題はあるんだろうけど。
3.6から非同期処理のサポートがstableになっているそうです。
また、型ヒントが必須じゃないけれど使えるようになっているそうです。
動的型づけは今後も続くので、型ヒントは厳密な運用にはならないかも、とのことらしいです。
virtualenvやcondaの話については、環境を完全に固めるならDockerをちゃんと使ったほうがいいなーと思いました。
それでUbuntuを入れようと思い至った感じです。
Ubuntu入れようと思ったもう一つのきかっけは、Macbook-> Lenovo -> Macbookに戻した人の記事を受けて、Lenovoでgentoo入れて開発環境作ってる人の記事を読みました。 いろいろ思うところはあるけれど、自分もVagrantとかDocker-toolboxとか使ってファイルシステムの問題気にするより普通にLinux入れたほうがいいなと思ってWindowsのマシン(ノート)にgentooは難しそうなのでUbuntuを入れ始めています。 キーボードの問題についてはHHKB持ち運びで良いんじゃないかと思うんですよね 16.04LTSを入れたのですが、ubuntu16.10からはSurface 3にも対応してるみたいなので、いきなり16.10にアップグレードしました。 ちょっとドキドキ
システムトレードとPythonの利用
森谷博之さん
話の内容も非常によかったのですが、Jupyter Notebookでそのままプレゼンをしていることに驚いた。 気軽に使えて当たり前のツールになっているんですね。 Pandasのデータリーダーを使うとスクレイピングなどを頑張らなくても１行でダウンロードできる 統計学の可能性と限界について詳しくお話をされていて、システムトレードに応用するんだったらその実際の取引の知識もあったほうが圧倒的にいいとのこと。 現在は１０万円でも試してみることはできるし、取引場のＨＰなどは端から端まで、見尽くすことなどをやってみるべき。
「明日から使える AIシステム開発シナリオ事例特選10〜pythonを使ったAI開発」
井原 渉さん
機械学習やＡＩについてのお話でした。
データ分析のレベルを４段階に分けて説明されていていました。
いきなり「AIやりたいんだけど」「DeepLearningやりたいんだけど」みたいなことを言う人はちゃんと処理したいデータが何なのかが決まってからやるべき、とのことです。
機械学習などを応用された様々な実例を紹介されていて非常に面白かったです。
特にバイトのシフト問題の最大幸福最適化問題とか
画像評価システムについては、TensorFlowつかえば４時間くらいで使える物が書けるそう たとえば不動産の部屋の画像写真をDeepLearningさせたとき、D-89のタグ コンバージョン率が高いということがわかる。 人間に認知不可能なタグでも役に立つことがあるとのことでした。
感想
一番受けた感想としてはデータ分析計のPythonの流れもしっかりつかんでおかないとエンジニアとしては時代遅れになるんじゃないかということです。 今はWebの技術を使いこなすことを急務にしていますが、PandasやJupyterNotebook、TensorFlowなどのキーワードが当たり前のように使われている感じがします。
StaPyの勉強会自体は初心者だったり、これからPythonで何か始めたいという人向けの勉強会とのことなので非常に参加しやすい感じでよかったです。
発表者の皆様、運営の皆様、ありがとうございました。
DevLOVE199 越境CONに参加してきました
2017年1月28日のDevLOVEの越境CONというイベントに参加してきました。
イベント趣旨としては（若手の人が）現場で取り組んでいる工夫や挑戦について語る、という感じで、どれも非常によかったのですがその一つについて書いてみたいと思います。
『ガチガチの SIer が一皮むけようとしている話 ～Arumon の紹介～（仮）』
盛 慎さん
なぜ越境するのか？
Innovationを起こすため
組織の枠に縛られない、スキルではなくパッション、変化に対応できる、
responsive to change
１００年以上続いている会社も大きな変革を経ている
e.g. ノキア
NRIでは本業は社内の受託内製だけれど、Arumonというイノベーションの活動を行っている。
イノベーションへのパッションを持ち、失敗を恐れずにチャレンジしていくこと、どんどん失敗しようという心構え
大企業病 価値を守ることを重視し、どんどん変化できなくなり、リスクを取れなくなる
最初に海に飛び込むfirst penguin（新しい市場の新しいチャレンジャー）になれない
だから、Arumonがかわりにどんどん失敗する
Arumonがどのように起こったか？
新しいことをやりたい パッションを持つ人参加しているとけっこうわかる
そんなつながりの有志で活動開始 草の根で勉強会やプロダクトを作ったりする活動をやり始めた
かっこいい上司（役員の方？）「ハッカソンをやるような元気な人を応援したい。」
結びついて、予算もついたちゃんとした活動に
活動内容
やってみたいことをどんどんバックログにためておき、「これいいんじゃね？」と引っ張り上げる ジョインする人が挙手して参加
大体１つのバックログアイテムを３－４人で
コンセプトの段階だとペーパープロトを使ったり、Googleが提唱しているアイデアだしのフォーマット（クレイジーエイト）を使ったりしている
最終的にはスマートフォンのアプリをローンチしたりするところまで。
課題
- Arumonもいいけど仕事もちゃんとやってねという意見がある。
理由はArumonのような活動が遊びに見える。
きっちりと決めるウォーターフォールの受託開発に比べると仕事の進め方が「クイック ＆ ダーティ」だったりする。
ロジカルシンキング VS デザイン指向
何が必要だったか
社内への意識改革
- デザイナーにとの協業
何をお願いしたらいいのか？
エンジニアは「見た目なんてどうでもいいんだよ」みたいな人も多かった
デザイナーの生産性基準の判断が難しい。良いものは工数で測れない。
エンジニアの常識が通用しない 使う言葉も違ったり
お互い若干押し付け合いがあった
解決策：違いを受け入れること
デザインボードの作り方を教えてもらう
とにかく話し合う
収穫
Arumonでやったことが本業で生きる
ブロックチェーン、機械学習
大切なこと
アピール：ハッカソンなどのイベントの参加
エンジニア以外の交友も広げる
組織としてチームとして動くという意識
社内で個別に動いているイノベーターは意外と多いのでそれを結び付けていける
質問
- 変わりたくない人はどうしたらいいの？
強制はしない
「今までやってきたお金を稼ぐこと と イノベーション」の２階建て、どちらも大事
認めてもらうことを目指す
- 機械学習やブロックチェーンなど学習コストが高い問題は？
本来解決したいこと 技術で解決すること
そういう人が集まるのでそんなに困らなかった
- デザイン指向について
ロジカルシンキングだけでなく、付け加えて考える
まずつくってみて、機能的なところじゃない快感などがあるかどうかなどを考える
例えばヒースロー空港の手荷物受取りのように、たどり着くまでの距離を長く調節することで、待っている時間を感じさせない。
感想
エンジニアとしての学習のアジリティをどう確保したらいいのか、っていうことを常日頃悩んでいる感じですが、このようにイノベーションに情熱をもって取り組むことができるというのは非常に素晴らしいと思います。
開発者はプロダクトのインクリメントを作ることだけに集中する、というのが一見正しく思えるけれど本当はそれだけじゃなく、「売上」だったり「顧客に向き合うこと」だったりを総合したプロダクトを売っていく生産活動やエコシステムそのものが大事だと思います。
当然、顧客に向き合うならよりよい経験を提供するために、イノベーションを起こしたり、最新の技術を取り入れたりしなければいけないかんじです。
それもどっちかというと枯れた技術の水平思考的なイノベーションな気がする。。。
他の発表でもありましたが、「停滞は後退と同じ」ととらえられることもあるので、こうした活動のやり方や精神はまねていきたいと思いました。
開発合宿とか社内アイデアソンとかよさそうです。
話はそれますが、Titan Fall2というゲームが面白いとのことでめちゃくちゃプッシュされてました。
気になる…
イベント全体の感想
いろんな人がいろんな現場で挑戦してることを知ることができ、encourageされる場だったと思います。
自分も自分の現場で、あるいは自分の学びの場の中でチャレンジして行きたいなーと思わせる良さがありました。
スピーカーの皆様、スタッフの皆様、会場のYahoo様、ありがとうございました。
エンジニアリングマネージャー勉強会に参加しました
2016年12月13日に「エンジニアリングマネージャー勉強会」に参加してきました。
（結構前のメモになるのでうろ覚えでの記述になります。すみません。）
「エンジニアのマネージャ(リーダ)による、メンタリング、指導、立ち居振舞いについて現状を共有します」というテーマだったのですが、全体的にキーワードとして「心理的安全性」というのが出ていました。
@muddydixon さんの「ボトムアップとトップダウンの技術組織への変革をしている話」というお話では、動機づけ要因とか衛星要因というキーワードが出てました。「組織としての目標やゴールに対して、責任を持つ（モチベーションを保つ）ということ」と「心理的安全性を作るということ」とを両立するというお話だったと思います。
面白かったのが、メンタリングを考える際にその人の「指向・姿勢・その人が持つアセット」を「キャリアアンカー改」という方法で分析されていることです。詳細についてはスライドでわかると思います。
あんちぽさんの「『いるだけで成長できる環境』を作るメンタリング」というお話では、基本的に「いいじゃん いい感じに ばーんと」という3つの言葉しか言っていないという話をされていました。
「いいじゃん」が、まだ最初の段階であまり信頼関係がないときに「肯定」をすること
「いい感じに」が、だんだん信頼できるようになってきてその「信頼」を示すこと
「ばーんと」は、もう完全に信頼しているので完全に任せきる「期待」を示すこと
という感じでやってるそうです。
あんちぽさんがCTOをしているGMOペパボではメンターを受けたひと（メンティー）が次の世代のメンターになるような親方と弟子みたいな関係や、同僚だったり同じような役割の人たちからの横からのメンタリングも入れて「上から下から横から」「公式にも非公式にも」というメンタリングモデルを目指しているそうです。
あと、質問の時に話されていたのですが定例会議を完全にリセットする取り組みをやって実際にうまくいったとのこと。。すごい。
@kenchan さんの「メンタリングはじめの一歩」というお話でも、心理的安全性を高めることと達成感を高めるということの両立の話をされていました。
1 on 1で心理的安全性アップをおこない、目標の面談で責任と期待のマネジメントを行うようにしてるとのこと。
目標の設定は、達成できないと評価されないので達成できるレベルよりも若干楽にしてしまうような「防御的」な目標にしてほしくないということを考えているそうです。
@takesako さんの「エンジニアリングマネージャの職務要件」という話では、他のロールとの比較のお話が出ていました。
プロデューサーは思いがつよく、「あれもやりたいこれもやりたい」
プロダクトマネージャーは逆にやらないことを決めることで映画の監督のような立ち回りをする
そしてエンジニアリングマネージャーは最初からチームに関わる
エンジニアリングマネージャーはエンジニアの「得意なことを伸ばす」ということが重要。
まず「快適」ということめざし、それだけでは堕落してしまうので「チャレンジ」というステータスを目指す。
エンジニアはとがった人が多かったりもするのだけども、「チームの隙間を埋めていく人材」にならなければならない。
それを実現するのがリクルートグループで共通で用いられている用語のATIを持つ人。
ATIとは圧倒的当事者意識のことで、その人は完全に枠にとらわれない。
ずっと前に、DevLove甲子園でリクルートの黒田さんという方が話されていたお話を聞きましたが、問題を解決するために上限を設定しないという態度は確かにという感じでした。
具体的にはスクラムを導入するコーチの選定の仕方や、スクラムで働きやすくなったということは利益の成長につながっていないことをちゃんと評価してそこから先に進むためにリーンの手法を導入したこと。
というのを思い出しました。
@yuku_t さんの話と@tatsushim さんの話はビアバッシュ中のLTだったのでちょっとメモもなくて申し訳ないのですが、@yuku_tさんの話は「スタートアップ的な組織」だと組織の規模が小さい黎明期はメンバーが本当に知っている人しかいないのでコミュニケーションなどに問題は起きないんだけど、組織が成長すると知らない人が増えて難易度が上がるというお話だったと思います。
特に意思決定の適切なプロセスや、メンバーの良好な関係をつくることが難しくてそれがマネジメントに影響を及ぼすという感じだったと思います。
@tatsushim さんの話もそれと似た感じの文脈はあるのですが、そのようなマネジメントの問題に対してスクラムを導入したお話をされていました。
案件管理のスプレッドシートの「優先度」カラムが最重要が複数あったり、「must」や「スター」などの別のカラムが追加されたりしてカオスになるという話はすごくよくわかる感じです。
スクラムを導入するのでも、拒否反応っていう結構難しい問題をはらんでいるのでその辺の心理的安全性をどう保つか、というお話だったと思います。
どの話もすごく面白く、今後自分がどのように仕事に向き合うかということにもかかわってくるものだったと思いました。
２回目のエンジニアリングマネージャー勉強会があるならまた参加したいです。
additional
@kenchan さんのお話でも少し出ていましたが、RebuildFMというポッドキャストで過去にポッドキャストのオーナーの@miyagawaさんと@naoyaさんが心理的安全性や「チームが機能するとはどういうことか」ということについて話されていた回があったと思います。
また、直近の171でもお話されていて、そちらも聞くといろいろと考えさせられて非常に良いと思います。
プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
- これはそもそも、７つの習慣などで言及されているWin-Loseなコミュニケーションをしている状態であると思います。こんな人とは一緒に仕事はしたくなくなります。
- アジャイルやウォーターフォールといったプロセス論にだけこだわり、プロジェクトの危機的な状況にたいして本当に見える化や継続的改善することに対してフォーカスされていないこと
こういった状況は仕事をする上では犠牲的つまり主体的でない状態の仕事であると思います。
こうしたことが起こる原因は、もっとマネジメントに関して、プロダクトファーストな考え方にシフトしていないせいではないでしょうか？
プロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
こうした状況で出来上がるプロダクトとして、「こんなはずではなかった」とか「かかったリソースの割合にできたものの売り上げが見合わない」といった状況も起こりうるだけでなく、継続的にそのプロダクトをメンテナンスすることに関しても弊害が出るはずです。 「言われたとおりに作ったんだから、なんで改修しなければならないんだ」とかいう気持ちになることはよくあります。
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は（プロフェッショナルであるべきアーキテクトに関して）アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成や他のエンジニアとしての交渉）についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることが重要な差をつけるものになってくるなのではないかと思います。
そういう意味では、DDDなどの考え方を自然に開発に取り入れられているKRAYさんの取り組みなどには本当に感心させられます。 かかわる人間すべてが同じ言葉で会話できるだけでなく、設計や要件についても善しあしを交渉する足がかかりになっているのではないかと思います。この辺は推測でしかないのですが。
プロダクトファーストな考え方で仕事をするのが望ましいとは思うのですが、「そうは言うが大佐、このプロジェクトは納期だけが決まっているんだ」「オーナーとは交渉する余地がない」みたいなときはどうしたらいいかというと、メンタルだけには気を付けて「仕事は金のため」と割り切りましょう。
その上で「メンタルがやばい」とか「ソウルジェムが濁って魔女化しそうだ」みたいなときは「手を手遅れになる前に」転職先を探したり、よいカウンセリングのサービスでも探すしかないかと思っています。こんな解決方法しか思いつかなくて申し訳ないです。
理想を言えば、以下のスライドにあるようなチームに所属したいですね。 このスライドは本当に素晴らしいです。
とにかく自分の仕事が犠牲的な考え方（他の人のせいで私は仕事ができない）になっているかどうかについては気を付けつつ、基本的には「プロダクト」をよりよくするためにはどうしたらよいか、なんかあったら自分がそのプロダクトに対して責任を持つ(アカウンタブルである)ということを考えながら仕事をするべきです。 自分もそれがまだまだできてるとはいい難い状況なので恐縮なのですが。。。
あと最後に日曜朝にやっていた戦隊ものの特撮番組「トッキュウジャー」の中で怪人が「世の中金だー！」と叫んでいましたが、「お金は大事」です。 これについては自戒も含めて。
プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
結論としてはプロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は（プロフェッショナルであるべきアーキテクトに関して）アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成）についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
もちろん、個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることなのではないかと思います。
