どこからかやってくる救世主を待っているほど人生は長くない
自分たちでよくしていくことが、DevLOVEのコンセプト
塹壕にいるすべての同朋へ
「ユーザの声を聞く必要はない」といった受託開発元の考え
受託開発を止める→自らの首を自らで締める行為
自ら責任をとれる環境→会社の立ち上げ
気になったワード
リモートワークに利用
Sqwiggle
サービス立ち上げにあたり
エクスペリエンスマップ
http://www.ajike.co.jp/switch/ux_map/
30代でエンジニアからマーケターにキャリアチェンジしたら○○した！
例外は現場の外で発生する
意思決定の大半は技術の外側で動いている、例外をキャッチするべし
どう生きていくか考えた
WEBはせいぜい15年
定年説35歳
40歳オーバーはフリーランスや化物揃い
営業に異動した時に需要と供給のミスマッチをみた
javascript何？
Gmail使いこなせていない
コピペに数時間
AD TECHNOLOGY
営業の幅が広がり、テクノロジーの理解なしにマーケティング活動ができない
しかし世の中の9割以上の現場スタッフは知らない
エンジニアとして数値解析から導き出される資源の最適配置問題の解決
感想
自分を活かせる場所を見つけることの大切さ
社内スタートアップでの組織の成長に伴い発生する痛みとその解決策（スクラム＆顧客開発＆リーンスタートアップ導入）について
cameranというアプリにおける事業拡大とそれに伴い発生した様々な問題
3日で50万ダウンロード、10日で100万ダウンロード
そのため、メンバを一気に増やした
その結果、問題が発生し
・スケーラブルな組織設計が必要
・少人数ならうまくいく、ように見える
このプロジェクトに必要だったこと
・優先順位付け
スクラムに特化したプロジェクト管理ツール-acunote
→見える化が進んだ→自己組織化が進んだ
ギスギスは解消したが、本当にプロダクトのためのタスクを実施しているか
リーンスタートアップを学んだ
すべての意思決定において、無駄のない判断をしていること
例えば、スタンプ機能をつくろう
試しに10%のユーザにスタンプ機能(ハリボテ)を作成
押されたかどうかで、本当に必要な機能か判断する
この考え方がMVP(検証可能な最小限の機能)
偉い人の言葉、考えるときは、思考プロセスを逆にせよ
エンジニア集団によるゼロからの新規事業開発
新規事業開発の流れは以下
課題/顧客 発見→課題/顧客 検証→解決策 検討→解決策 検証
問題点
Case1 課題/顧客が存在しない
Case2 課題感が浅い
いろいろやって、わかったこと
・少人数チームのほうがよい、熱量が伝わりやすい
・失敗を許容する組織文化、失敗から学ぶ
・体験も検証する、紙ベースのコンセプトではよかったが、作成してみるとそうでもないことも
・たくさんの人と話す、話すたびに不要なセンテンスが削げ落ち、企画が研ぎ澄まされる(5分から30秒に)
5人のユーザでテストすればユーザビリティの85%の問題はわかる
サービスを作るにあたって、多くの人の意見を聞いた
結果ファンが増えた、ファンと一緒にモノづくりは楽しい
クラウドから考えるインフラエンジニア防衛戦略
インフラ1名、プログラマ2名 目標は24H365D 無停止状態
→クラウドで全力対応
すべてクラウドで実施
監視も自動化、自律的に調整する(リクエスト数に応じてオートスケール)システムを構築
資産管理のためにownCloudを利用
コーポレートサイト WordPress
公式サイト Azure Web Sites ＋ Git/FTP
開発環境 – Remote Desktop
イメージを配布して速攻開発開始
自動的gitリポジトリからデータを取得する
MariaDB Galera Cluster
台数を増やし過ぎると性能が下がる
理由はレプリケーションパスが増えるから
Couchbase Clusterでのマルチマスタ
自動化が完了したら、経理のおばちゃんがスケールアウトする時代
プログラマは ニンシキギジュツをおぼえた！
ラジオ体操でエンジニアの体調を守る
顔認識技術にあたり
学校のような勉強会を実施、実装
クラスタリング、ロバスト推定、近似近傍探索、特徴抽出など
技術力の向上(それぞれのアルゴリズムがどこにボトルネックがあるか、それぞれの関係性-どれを組み合わせれば良い処理ができるか)
感想
学校のように社員を教育するという姿勢が新鮮だった
小さなことで大きな成果をだす秘訣は？
ほぼ修正コスト0で売上は2.4倍アップ
ボタンを[引き続き○○サービスを確認する]→[次へ]
に修正しただけで、離脱率がカイゼンした
Problem
・売上低迷
・部門や担当領域の壁
・仮説検証サイクルが回ってこない
・過去の成功体験を捨てられない
秘訣(対応内容)
・対話を増やす。関係者全員をチームとする
・プロダクトを計測して、継続的にカイゼン
アクセス解析の実施などで、目標値を決めて、仮説検証を回すようにした
・ユーザの声を拾ってカイゼンする
ユーザとのギャップを知る
本音でプロダクトを考えたアイデアがたくさん出るように
おすすめツール
・期待マネジメント
なぜ自分がこのチームにいて、何をサポートして欲しいかを伝える
何を期待しているかを伝える
・Google Analyticsの機能
ナビゲーションサマリー
ページ解析
ヒートマップ
・社内でのユーザテスト
付箋を利用、カイゼンポートフォリオ(重要性・実施に時間がかからない)
ヌーラボでのリモートワーク 四年間の軌跡とこれから
nulab スタッフ28人、オフィス5つ、5カ国9営業所
プロジェクト管理ツールBacklogなどを開発
リモートワークの考え方は、チームを分散ということ
ローカルブランディング
目には見えない、見えにくいが各地に人がいることでのメリットを考える
リモートで働き、ローカルにねざすことを意識することが大切
リモート特有の課題と取り組み
・何やっているかわからん-仕事してる？
・寂しい
・コニュニケーション手法が乱立
→多くはコミュニケーションに起因する
コミュニケーションの主従関係が生まれる、「従」がリモート作業者
会議の後の雑談や暗黙的なコミュニケーション、つまりコンテキストが伝わらない
「従」は取り残されている疎外感、「主」としてはもっと積極的に来てほしい
問題に気が付きにくい構造
「主」の人間はそもそも気が付きにくい、「従」も何がストレスかを言語化しにくい
解決方法としては
・適切なツールの選択と運用ルールの構築
情報の共有、透明性の担保
・運用の定期的な見直し
・リアルに会う、全社員での総会、開発合宿などのイベント
・在宅勤務の実験
2ヶ月間、週1回水曜日に実施、全員が対象、それによりリモート側の気持ちも理解しやすい
いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜
「もっと良いコードを書きたいなら凄いプログラムに読んでもらえ」
仕事がしやすいコードでなければ、仕事がしにくい
リファクタリングをする必要があるかどうかにどう気がつくかがポイント
人に読まれていないコードは全てクソコードである可能性がある
Who? – 優れたプログラマ、同じレベルのプログラマが指摘しても内容に限界がある(書いた1行1行に対して、処理内容と理由を聞いて答えが返ってくれば優れたプログラマ)
How? – 観点を明確にする、単位も決める(時間区切りがよい、全員が見れるような状態にする)、よいコードの基準を決める、素直な気持ちで受け入れる
現場のコード意識を変えるために導入したリーダブルコードとガウディの思想
「機械のためでなく人のためにコードを書け」
問題点
現場のコードが読みづらい
現場のコード意識で変えたかったこと
開発者が2人だった時は、リーダブルコードをバイブルとして実施
後ほど参加した開発者が前のコードをコピペして、とりあえず動けばいいやという発想
意識改革の必要がある
コーディング中に考えることを増やす(まず動くというところから、意識を離す)
ガウディの思想を取り入れてみた
ガウディの事故死、戦争での模型、設計書の損失
それでもサグラダファミリアの建設は続いている
設計書よりも小さな模型で説明する(そのほうが伝わる)
設計書よりも設計思想を伝える(雨が当たる部分には石とレンガを使え、建材は特に指定しない、よりよい設計思想ならば取り入れてOK)
仕様が変わることを理解する、柔軟に対応できるようにする
良いコードは
より多くのビジネスチャンスをつかみ
ヒューマンエラーをなくし、特定の人に依存せず
後世の最高の教科書になる
物事をうまくやるために必要なこと
第一に愛を、第二に技術を by ガウディ
モダンな現場にするために実践したこと
It takes two
(2人目が大切)
一休.com(14歳)
宿泊施設、高級レストランのサービス
エンジニアは開発部のインフラ部のいずれかに所属(1：2)
開発業務改善プロジェクトを実施
目的は「ユーザへの価値提供速度を最大にする」
レガシー
・Subversion
・コードレビューなし
・テスト無し
・デプロイはほぼ手動
など、変えたいと思い、naoyaさんに相談して、技術顧問になってもらうことに
技術顧問になってもらう前にしたこと
・CMMI:現在地と目標の見える化
・新しいツールの検証-自分たちにフィットするか
キックオフ
・体制を変更した(それぞれのやりたいを参考にメンバを決定)
・3ヶ月ごとに見直しを実施
その後の変化
・情報共有-Hipchat Slack Qiita Team(カジュアルに情報共有可能)、朝礼で口頭報告
・GitHubの導入、社内での勉強会、ハンズオン
・jenkinsを利用した自動デプロイ
感想
外部からの力を借りる大切さ、また呼び込める力の大切さ