hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

「eureka Meetup #08 -Pairsのビッグデータ基盤の裏側」 に参加してきました

eureka Meetup #08 -Pairsのビッグデータ基盤の裏側-eure.connpass.com

エウレカさんのイベントに参加してきました。

前職でデータマーケティング・BIのエンジニアさんと関わることもあったので興味もあったのですが、とても業務的に、あるいはビジネス的に、技術的に話を聞ける機会でした。
すごく熱量の高い内容で面白かったです。

発表者の皆様、イベントの運営者の皆様、ありがとうございました。

以下メモした内容をまとめています。
(お酒が入っていたこともあり、誤りなどがあればすみません)

Tableauを導入した話

鈴木宏典さん | eureka,Inc.

Pairs
マッチングアプリ

今日のお話はPairsというプロダクトのデータについて

恋愛相手に求めている条件
理想の相手を探せるようにプロフィールを充実させる

興味関心といった情報を利用し分析が可能
(個人の特定はできないようになっている)

ユーザーの行動は
登録 -> 検索 ->いいね -> マッチング
といった流れになっている

各アクションのログに大量にある
ユーザーの行動ログを分析し常にサービスを改善

BIチームに課せられた、「データ可視化」との戰い

データ

  • 行動ログ
  • 課金
  • バイス
  • プロフィール
  • アンケート
  • 広告

PMさん
「こんなすばらしいデータがたくさんあるんだ。 プロダクトに生かそう」

BIチーム
SQLを書く -> 見たい数字が見せられるようにダッシュボードを使う

BigQuery 行動ログ
MySQL ユーザー情報などのマスターデータ

Redashの利用

  • クエリの保管
  • 実行
  • ビジュアライズ

バイス別 いいねの送信数 DAUとか売り上げとか基本

ビジュアライズめんどくさい
ダッシュボードじゃ間に合わない -> 「SQL書いて」

もう少し深掘りできるダッシュボードを作りたい
グルーピング数が大きいローデータを集める

Redash+GAS+Google Spreadsheet
SAMIF関数

シートの内容

  • 施策の効果測定
  • CRM施策の過去結果

ビジュアライズも綺麗
再利用しやすい

だが、
データ更新が不安定 Redashでつまる
可視化めんどくさい
データ量に制限 ,1万5千行あたりから辛い

結局SQL書いて欲しいという依頼が減らない

複雑度 x 依頼数 増大
クエリ作るということが業務になっている部隊に

本来はBIはデータを価値に変えてプロダクトに反映させる部隊

Tableau導入

BigQueryのViewTable(BigQueryから多少加工したもの)

イテレーションの考え方
ダッシュボードを増やしていく方向から、データソースを改善・拡充する方向に

Tableau導入後の世界

「これください」みたいなのを待たない
ビジュアライズなどはマーケティング側に任せられる部分は任せる

BIは高度な析に集中

めっちゃ大規模なデータも余裕
認証とかも楽チン

ただ、ライセンス料が高い

オンラインデーティングのデータは超面白い
本当に見たいデータが大量にある

こういったデータの分析についての本も発売されている

changelogと戦う

山口 将央さん | 株式会社トレタ

クエリの依頼はトレタでもあるある
今日午後から出かけるので こういうデータ用意して

トレタの事業紹介

iPADアプリ

飲食店 予約管理ツール
繁盛店のオーナーさんの意見を反映
飲食店のためになるツールを作っている

予約のフォーム
POSコネクト

グルメ予約サイトとの連携

電話:CTI きたことがある顧客の情報

3方よし
お店 顧客 エンジニア

トレタデータサイエンス研究所

現状のデータインフラについて

Rails, MySQL
GCPレプリケーションBigQuery embulk Digdag

Digdag serverをGithubで管理
トップのtaskだけがサーバー
プルリクベースでtaskがくる

足りないデータでChangelogの話をしていた
アプリケーション側としてはDBが肥大化するので、捨てているものもあった

本当に重要なものについてはとっていた

Reservationのジョブからsidekiq

データ側の要望で本番を重くしたくない
レプリケーションをかけている

Change log

Binlog
MySQLレプリケーションのログ

parseしてBQに突っ込めばいいじゃん
dockerでmysqlのmaster slaveを作ってコンフィグ周りを確認

binlog_format = ROW
Log-slave-updates

binlog-parserのレポジトリをfalk

「あとは取り込むだけ、、、」ではない

個人情報バンバン入っている
データを綺麗に
パースしたデータ
1日4G, 改行ありのjson

Sparkのコンフィグで何度も苦しめられた経験

CloudDataflow

Apache Beamで書いたデータパイプラインの実行環境(runserver)で
runnerをDirectRunnerにすればローカルでも可能

ApacheBeamのコードをどこで作るのをどこでやるか
Datalabでやろうとしている

ローカルで確認して、DataflowRunnerに変換

あとはDigdagに突っ込む

個人情報の削除、mask

サーバーサイドの工数を使うことなくChangelogが取れるようになった
Dataflow便利 処理速度が遅かったら勝手にautoscalingしている
ApacheBeamのデバッグが結構めんどくさい
BQに取り込んだフォーマットが今のままだと使いづらい

今後のやっていくこととして

Firebase

トレタとして欲しい人はどんな人?

最低ラインとしてSQLかける人 機械学習にゴリゴリよっていたというよりはビジネスによっている人が欲しい データサイエンティストが欲しい

パネルディスカッション

  • 鉄本 環さん | eureka,Inc. Head of BI Team. 

  • 山口 将央さん | 株式会社トレタ

  • 前田周輝さん| 株式会社リクルートライフスタイル

  • モデレータ:Eureka CTO 金子さん

  • 鉄本さん
    サーバサイド php -> go
    データの移行を全て担当したところからのBIチーム立ち上げ

  • 山口さん
    データ活用したサービス開発
    (2回目のセッションの内容)

  • 前田さん
    足回り系からデータインサイト
    Tableauユーザ会の代表

業務について

「BIチームとして一番力を入れているプロジェクト」

  • 鉄本さん
    早く正しいデータをいかに出せるか
    データの依頼 煩雑 質がともなわない
    窓口が増えてきた
    リードタイムを減らす

  • 山口さん
    データを使ったプロダクトを作る部分

  • 前田さん
    データを使って利益を出す
    PMO データそのもの
    アナリストも統計より 機械学習よりの人
    データは貴重

扱いに困っているツールとその理由は

「好きでもあり困っているものなど」

  • 前田さん

Redshift
スピードが出ない

Adobe analytics
ツールが進化しているが使いこなすことができず、やれる分析の幅が広がっていない

  • 鉄本さん

Redash
可愛いけど、負荷に耐えられなくなる メンテナンスに時間が割かれる

導入した当時より二次関数的に増えてくる 負荷に耐えられない

  • 山口さん

Metabase
Clousureで書かれたツール
これがあればTableauなくてもいいじゃん 導入した時点で完成度がまだ低かった
一万行のCSVでエラー

データについて

「 データの闇
データを使ってこんな価値を生み出した」

  • 鉄本さん

ゼロイチで管理した管理のカラムが「on, off」のstringで入っていたことが

不正検知
BIと機械学習エンジニアで連携して作っている

課題からブレークダウン
データを使ってボトムアップの提案 比重を強く

  • 前田さん

闇だらけ

10年以上のデータ
カラムが途中でできた
データの欠損 推定で補完
営業も強い 顧客行動 企業名でユニーク 営業担当者名前が入ってユニークになっていない
Distinctにするクエリの発行

中間テーブル マッピングテーブル
Datamart ある程度集約されて、制約が取れたもの
Datamart2

世代管理 ガバナンスがたいへん

よかったこと
レコメンデーション ABテストを金額換算
BI事業 武器となる顧客向けのレポートをTableau 渾身のビジュアライズ
6億 顧客の離脱を防止

  • 山口さん

電話番号をハッシュ化してBQ
グローバル対応 日本の電話番号
電話番号 生きている / 生きていない
日本語が入っている なんで?
店舗のオペレーション上仕方なくというところがある

営業とのやりとりが多い
営業と話しているとこういうデータがほしいというのが雑談ベースで出てくる
営業さんと普通にやるとデータ受け渡しが時間がかかる
今のところ山口さんだけがそういう感じで動いている
営業さんが他の店舗のデータを欲しがるなどリスクもある

組織としてはここから事業が作られていく
予約台帳だけじゃなくなる
データを活かしていこう
ここから新しいプロダクト
チームも

今後チームをどのようにしていきたいか

  • 山口さん

前の話題の最後の部分
情報リテラシーを担保する
B2Bの部分をせめるのは引き続き行う
B2Cをやっても良い

(金子さん)やっぱりデータに理解がある会社は良い

  • 前田さん

データチームの位置付け
組織に存在価値を証明するということを今までのフェーズでやってきた
インサイトの価値をどれだけ出せるか
GPUを使ってみたいんだ 強化学習を使ってみた
知的欲求を満たす
あれやりたい、あれやったほうがいいのではという思いつきが文化として醸成されてきている
前回失敗したことが今は変わっているかもしれない
即ABテストとして実施する
時系列大事

(金子さん)エウレカでも昔と違う ユーザーも全然違う 今過去の施策をやったらどうなるか常に考え続ける必要あり

  • 前田さん

データプロダクト
予測モデルそのもの
直接的な価値を生む
インサイトについては書籍化レベル

エンジニアのデータストーリーテリングのスキルを上げるべき

  • 鉄本さん

データに関わることすべて

マーケティング周りで重視している指標を対応したらどんどんプロダクトの成果が出てきた
データドリブンの風土ができてきた

ユーザーインタビューなどにも力を入れている
でもそこにも統計的な知識があるとなお良い

データがあるからデータを分析すれば何かしらできるんじゃないか、と言う感じでユーザのことよりもデータ第一にしていた感があった時期があった
しかし、一週間かかったことが30分インタビューしたら分かった

データを出せるところ
定量・定性をどちらも大事にする
ドメインナレッジを持っていてデータを出せるのが強い
そこから機械学習 または もっとビジネスよりな提案を出せる
違う分野で力を発揮し始めた
新しいキャリアを考えるのもいいかもしれない
チームの可能性、拡張性を高める
自分が先導してチームを作るくらいのメンバーになって欲しい

(金子さん)Pairsについての印象も ネガティブからポジティブに変わってきている
3ヶ月まえの頭のままだと時代に遅れる 常に自分をアップデートしていく必要がある

おまけ オフィス見学

オフィスを案内してもらいました。
日中はバリスタさんがコーヒーを淹れてくれるそう。
羨ましすぎます。

透明性を大事にする会社なので、会議室の壁も基本は透明とのこと。
ipadでの会議室の予約システムが便利そうです。

ため息が出るほど素晴らしいオフィスでした。

docker-composeで特定のコンテナの中のファイルをホスト側にコピーする

パスや実行ディレクトリなどには注意

gist.github.com

ソフトウェアエンジニアとはどういう人が多い?

  • 一緒に働くとき
  • 採用するとき

「ソフトウェアエンジニアとはどういう人が多いのか」という内容に気を配るといいかもしれない。

または、逆に自分が説明するときの備忘録として。

概要

プログラマー三大美徳」「UNIX哲学」みたいな価値観を大事にしている

「コードを書くことによるものづくり」状態が整っていると楽しいし、そのことに集中して静かに働きたいと思っている。

ソフトウェアエンジニアはどんな価値を大事にしているか

プログラマー三大美徳」

  • 短気
  • 傲慢
  • 怠惰

これの反対側の価値も大切だということは理解しつつ、これらの感覚もプログラミングでの課題解決にとって非常に大切にしている

例えば、矛盾していると感じられるかもしれないが、「こんなダルいことはやりたくない。楽をしたい。楽するためには徹夜してでもコードを書く」というようなこと

UNIX哲学」

  • 小さいものは美しい。
  • 各プログラムが一つのことをうまくやるようにせよ。
  • できる限り早く原型(プロトタイプ)を作れ。
  • 効率よりも移植しやすさを選べ。
  • 単純なテキストファイルにデータを格納せよ。
  • ソフトウェアを梃子(てこ)として利用せよ。
  • 効率と移植性を高めるためにシェルスクリプトを利用せよ。
  • 拘束的なユーザーインターフェースは作るな。
  • 全てのプログラムはフィルタとして振る舞うようにせよ。

Wikipediaより

OSSに対する敬意

好き嫌いはあるかもしれないが、基本的にOSSに対しては敬意を払っていることが多い

それに加えて

多分このへんは好みになるが、ローコンテキストであること。

ソフトウェアエンジニアに必要な環境

静かに、自由に働く

背景として

複雑な問題に対するコーディングは基本的に思考や試作が分岐、分岐、分岐という感じで深く深くなる傾向がある

ある程度まとまった時間に集中してやらないと解決できないことが多い

環境

  • 広めの机、座りやすい椅子
  • 細切れの会議などがたくさん入る状況でなく、静かであること
    • 物理的に静かである、ということよりも意味の薄いインタラプトがないことでコンテキストのスイッチを最小にする
  • インターネットでの検索が自由にできたりするのは必須
  • 散歩したり、場所を変えて「コードを書いたり、ホワイトボードの前で議論する」ことができる環境であることもいいと思う

何を道具にしているか

  • terminal
    • コンピュータにソフトウェアを実行させるのに使う
    • 最小のソフトウェアを連結することで、簡潔にコンピュータを問題解決のために動かすことができる場所
  • editor, IDE
    • コードを書くのに使う
  • git
    • コードをバージョンごと、機能ごとに管理するのに使ったりする

ソフトウェアエンジニアの一般的な開発フロー

WEBアプリケーションの場合の一例

  1. 要求 -> 要件
  2. (システム構成設計)
  3. (開発環境構築)
  4. モデル設計 - 現実的な物事の意味構造からのプログラミング的な意味構造の設計
  5. プロトタイプ
  6. コーディング+テスト
  7. レビュー
  8. (本番環境構築)
  9. (デプロイスクリプトなどの構築)
  10. デプロイ
  11. (公開, ロギング、分析などの設定)

※ ()内は最初期のリリース ※ デプロイとはプログラムのコードをサーバーに配置して動かすこと

アジャイルとスクラムについて

ソフトウェア開発に限らずアジャイルを組織やプロジェクトのマネジメントに活用している会社が多くなってきている。
変化を前提としていないと時流に対応できないという一般的なビジネスの流れに対して、不確実性の高い複雑な領域であるソフトウェア開発やプロジェクトマネジメントに用いられてきたアジャイルプロセスが経営的なプロセスでも実践されてきているらしい。
日本でもそのような企業は存在するのだろうか?

アジャイル、そしてその中の一つの手法であるスクラムについて説明をしてみたい。
個人的な観点のため、偏った説明になるのはご容赦いただきたい。

アジャイルソフトウェア開発宣言

ソフトウェア開発に関するベストプラクティスを、旧来の開発の問題点を様々な方法で改善しようと取り組んでいる有名エンジニアが集まって考えた。
「このやり方がいい、あのやり方がいい。」
結論は出ず、宣言だけが採択された。

宣言とその背景にある原則を忠実に読み込めば、最終的に顧客がほしい「有益なプロダクト」をつくるためには、「動くプロダクトを見ながら常に顧客と対話して、その時々に発生する必要な変化に向けて一緒に戦う。」ということが書かれていることがわかる。

アジャイルソフトウェア開発宣言

アジャイル宣言の背後にある原則

アジャイルソフトウェア開発宣言の「左と右」

アジャイルソフトウェア開発宣言では左に旧来のやり方の特徴、そして右にアジャイルで実現したい特徴が書かれている。
旧来のやり方を否定するのではなく、目的のために最速な手段を右側に書かれているもので見つけてやっていこうという感じになっている。
左に書かれていることを疎かにするとアジャイルに詳しい人に怒られる。

左:プロセスやツールよりも   右:個人と対話を

取り決めやマニュアルに書かれている手順通りツール、プロセス、プロトコルを守る、ということよりも何か変化が必要なのだったら直接対話しましょう。

ただし対話はSlackなどのチャットツールのこともあるのだから、ツールを重視しないというわけではない。

左:包括的なドキュメントよりも   右:動くソフトウェアを

プロダクトについての全ての内容をドキュメントとして起こすと(例えばExcelでつくってそれをプリントアウトする)、キングジムのバインダーに途方もない量の紙が挟まれたものが何冊か用意される。 そしてそれは、殺人バインダーとよばれる。
ちょっとしたカイゼンの修正をするたびに、そのドキュメントを書き直すというのが本当にほしい価値だろうか?

ただし、ドキュメントを書かないというわけではない。
検索性のあるツールを使って、開発の段階から必要な内容を書いていくのが普通。
必要であればマニュアルなどを後追いででもつくる。

左:契約交渉よりも   右:顧客との協調を

有益なコントラクトはとても大事。ただし、本当にいいコントラクトならば顧客と協調できるはず。
プロダクトをつくることに対して顧客を巻き込めるかどうかが、本当にいいプロダクトを作れるかどうかの分岐点になる。

左:計画に従うことよりも   右:変化への対応を

反例として「分析・設計・開発・テストと3ヶ月ごとなど長期的なスパンで計画を区切って、テストの段階で分析が問題だったことがわかったけど計画にはないのでもどれない」みたいな状況を作らないということ。
変化が常に発生する前提のフィードバックループが大事である。

ただし、計画を立てないとそもそも目標がどこにあるのかわからないのでループを回して進む方向がわからなくなる。

スクラムについて

アジャイルソフトウェア開発宣言の前後の流れとして生まれたものの一つがスクラム
スクラムは軽量な開発プロセスフレームワーク。基本的にはチーム開発のためのもの。
アジャイルソフトウェア宣言に則しており、シンプルで「特定領域にしか当てはまらない」ということがないため、アジャイルの主流になってきた。

スクラムの特徴

リリースなどの価値提供を短いスパンで行い続ける、フィードバックループが基本
大きな計画を立てて最後に一斉にアウトプットするのではなく、常にアウトプットし、「フィードバックループ」で軌道修正し続けながら価値提供を行う。

スクラムの原則

スクラムの原則は、透明性・検査・適応の3本柱に支えられている。

透明性

フィードバックループで重要なのは透明化・つまり見える化されていること。
特に結果責任を持っている人、要するにお金を出す決定をする(執行役員などの)責任者に対して見える化されていること。
スクラムは透明化に対する【仕組み】が組み込まれているチーミングフレームワークである

検査

フィードバックするためには、作成物や進捗を検査し、「カイゼン」が必要なものを見つけないといけない
ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。
あくまでチーム単位で行い、最大限の効果のある改善ポイントを見つけ出す。

適応

検査で見つけた不備について、「カイゼン」が必要な場合にはプロセスやプロダクトの構成要素を調整する必要がある。
カイゼン」はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
スクラムは検査と適応に対する【イベント】が組み込まれているチーミングフレームワークである。

アジャイルスクラムで何が生まれるか?

素早い価値提供・素早い学習
ただし、開発プロセスが高速化してもインプットするものがだめだと、高速にゴミが量産されることになる。

というのが売り文句なんだけど、副作用としてチームでの働きやすさを提供してくれる。
働き方ディバイドやコミュニケーションのロスがイベントや仕組みで軽減される。
チームがチームとして透明性やカイゼンを考える頭を持つようになれば、お金出す人としては権限委譲がしやすい。

(IT系の)エンジニアは尖っていたり、コミュニケーション嫌いだったりすることが多いわけだが、結果としてこっちのほうがうまく行くと納得するルールであれば守りやすい。
こうしたことはエンジニアに限らずチームやプロジェクトの進め方の問題だし、構成員の複雑性や多様性が増す社会の中では経営的な視点でも活用できる。

事業会社でのソフトウェア開発と現場コーチについて

事業会社の現場の実例

2017年8月29日に実施された下記のイベントに参加してきました。

guildworks.doorkeeper.jp

エウレカ」 の正しいものを正しくつくる事例

Pairsというデーティングアプリを含む複数プロダクトの開発・運営
累計500万ユーザくらい
自社内のビジネス・経営層とやり取りしながら強いチームを作り、自社プロダクトを開発することについて話されていました。

エウレカとしてCTO室長の梶原成親さん、Guildworks側として中村洋さんが話されていました。

www.slideshare.net

こちらがおそらく梶原さんの講演資料です。

「ポレット」 の正しいものを正しくつくる事例

オズビジョンから派生した金融系のスタートアップ。
ポイントをまとめるサービス
カード会社や金融会社などと、excelやメールベースでのやり取りしかできないなどの超固いコミュニケーションしなければいけなかった困難さがあった。
そういう固いやりとりやスケジューリングを外部と握る必要がある状態で正しい開発をやることについて話されていました。

PolletとしてCEOの鈴木良さん、Guildworksとして市谷聡啓さんが話されていました。

www.slideshare.net

こちらは市谷さんの講演資料です。

エムティーアイ」 の正しいものを正しくつくる事例

SNSなどでの共有を控えてほしいとのことだったので書けないですが、エムティーアイでのリーンスタートアップのお話などをされていました。

エムティーアイとして高橋知朗さん、Guildworksとして川瀬浩也さんがお話しされていました。

以下の話は主にエウレカさん、及びポレットさんの話に基づいています。
しかし、発表された内容をそのままでは書いていませんし、全然講演で話されていないキーワードも書いています。
アジャイルの導入やアジャイルリーンスタートアップの現場コーチなどに興味がある人向け、(導入に向けて)上司や周りの人に話をするためにどういうキーワードを出せば筋がいいのか、といったことを考えながら書いています。

事業会社の開発の中でどのように「アジャイル もしくは DRR」が機能するか

  • プロダクトの課題(エウレカの場合は=経営課題)を解決する
  • 「ソフトウェアの価値をユーザーに正しく早く届けたい」
  • そのための自己組織化されたチームとアジャイルな開発

(※DRR = 正しいものを正しく作るというGuildworks社のキャッチコピー)

自己組織化されたチーム

エウレカさんのお話です。

自己組織化されたチームとは何か

  • 会社の「自立、自律」という行動規範を満たす
  • チーム自身にスキルがある、どうすればそのスキルを得られるか知っている状態にある
  • 自分たちで意思決定できる
  • 「週1回の会議でステークホルダーに意思決定してもらう」といった承認待ち・判断待ち・仕様決定待ちではなく、自分たちで最も良いやり方をチームで合意

自己組織化するメリット

  • 現場で判断し、問題、課題を解決することによって早いサイクルで改善できる
  • デリゲーションが適切にできている
  • 仲良しチームでなく、厳しい指摘をフィードバックしあって改善し、視座が上がる
  • デリゲーションはゼロか1かではなく、エスカレーションすべきものは適切にエスカレーションする。

アジャイルな開発

アジリティ、透明性の担保とは何か、スクラムとの関連性

  • アジリティとは敏捷性のこと
  • ソフトウェアは計画をひたすら厳密にやるよりも、動くソフトウェアを常に見ながら改善するほうが届けるスピードが上がる
  • 価値を届けるスピード(アジリティ)を追求する = アジャイル開発
  • アジリティを追求するにはどうしたらよいか? スピードを測れる状態が必要条件となる。つまり進捗状態や障害の有無などの「透明性」
  • ソフトウェア開発の透明性を常に担保し、可能な限りPDCA的なサイクルを早くクルクル回すためのフレームワークスクラム
  • 透明性に重点を置いて、チームが自己改善を進める = 自己組織化されたチーム
  • スクラムも出自はトヨタ生産方式

線表を引いて、マイルストーン(約束)を守りましょう 

  • スクラムアジャイルも計画を立てないということでは決してない
  • 着地までのリリース計画を全員で見立てる
  • いつ、終わるのかという現実感を全員でもつ
  • どうなれば完成と言えるのかの認識を揃えることで、プロジェクトに背骨が通る
  • チームを守る外堀としての線表が存在することになる (not チームを締め付けるもの)

割り込みとバッファのマネジメントについて 

  • チームの開発を守る内堀としてのバッファマネジメント
  • 割り込みや仕様の変更などの遅れは発生するとわかっている -> マイルストーンを使って空のスプリントで受け止める
  • CCPM的に全体の長さを見て、割合でバッファを入れられるのがベターかもしれない
  • 内堀、外堀で守っているものが仮説検証やアジャイルを中心とした「正しいものを正しく作る開発」。

アジャイルコーチについて

「正しいものを正しく作る」に対してアジャイルコーチが果たす役割

  • 「自分たちで考えて行動する」 ことの習慣づけ
  • アジャイル開発やウォーターフォール開発の開発プロセスの知見全般、見える化や課題解決のためのアイデア = 生き字引、あるいは道具箱
  • 様々な場でのファシリテータ 中立性 言いづらいコミュニケーションの橋渡し
  • 変化を推進するチェンジエージェントの最初の仲間

アジャイルコーチのメリットなどについて

  • CTOやスクラムに詳しい人がスクラムの伝道や運用にフルコミットした場合、他の仕事ができなくなるリスク
  • 書籍などで自習した場合、うまくいかなかったときに立ち直るコストが高い
  • トータルのパフォーマンスやチームの成長スピードを考えるとお得

結局のところ、どういう効果を目指しているのか?

  • チームが自己組織化される
  • プロダクトの価値を追求することに集中する
  • (自己組織化とかぶるが)エンジニア組織として当事者意識を持つ、学習する組織になる、ビジネスや目的に対する意識を持つ
  • ITプロジェクトの実行が変な方向に行かない

現場コーチなどのサービスの効果はこのような感じだろうと思っており、そんなもの自給自足できるよという組織もあれば、難しいという組織もあるだろうと思います。 本当にそんな効果あるのかみたいなのは現場の実例を詳しく聞いてみるしかないと思います。

なぜプログラミングを教育することが必要なのか?

将来的に働くのに必須となる可能性が高いから

単純明快

将来的に働くのに必須となる根拠

GEの採用ではプログラミング能力を義務付けているらしい。
今はGEだけかもしれないけど、将来的に多くの企業がこうなる可能性はある。  

GE: 今後採用する全社員に対してプログラミング能力を義務付け・採用職種に関わりなく 

プログラミングを中心とした情報技術はすでに社会的基盤

現代ではどんな仕事を選んでも、モノづくりや仕事の進め方についてITとは切り離せなくなっている。
例えば、メール、会議室の予約できるカレンダー、Excel

こうした企業活動の現場でモノをつくったりして働いている人たちは、「プログラミングを始めとした情報技術と密接に関わっている人たち」になっている。

情報技術と密接した社会で働いていくとき、プログラミングの基本的な知識の有無でリーダーシップや他者とのコミュニケーション能力に大きな差がついてしまう。
乱暴な言い方をすれば、プログラミングをわかっているふつうのリーダーとわかっていない情弱リーダーという感じ。
アップル、グーグル、アマゾンのような企業と渡り合っていくには、リーダーとなる人が『ITをインフラとして活用する考え』を理解できないと辛い戦いとなる。

ITをインフラとして活用する考え

ITをインフラとして活用するには、プログラミングを中心として『論理的思考力』を身に着けるのが必須になる。

論理的な思考力をさらにブレークダウンすると以下の2つになる。

  • 課題定義能力
  • 問題解決能力

社会的な課題があったとして、それをIT的な課題としてちゃんと定義する(プログラミングで作ったソフトウェアで解決する問題とする)のはかなり難しい。
そうした課題の定義能力の前提となるのが、「作業を分解し、分解した作業を順番通り行うことで問題が解決できる」というプログラミングの経験や知識であり、問題解決能力になる。

「ITをインフラにする」というのはこうした論理的思考力で「こういうシステム(プログラム)を構築すればこの課題は解決できるはずだ」ということがわかることが重要。
実際に手を動かしてプログラミングをやる必要がなくても、手を動かす人と協働を効果的に行うためにはプログラミングの実践や知識が非常に重要。
だからプログラミングの教育が必要なのだ。

プログラミングでどんなことを学ぶのか?

一般的なプログラミング書籍、たとえばプログラミング言語の入門書などでは以下のようなことを学ぶことができる。 順番は適当です。

動かし方

Windows, Mac, Linuxなどでプログラムを動かす方法

ifでの分岐

「もし、〜ならば」でyesならこう動かす、Noならこう動かす

ファイル操作など

多分テキストファイルなどを読み書きする

繰り返し

何回でも同じ操作を繰り返しできるのはプログラミングの魅力かもしれない。
ちょっとだけ変化をつけて繰り返す、というのもできる。

関数

自分が書いた処理を再利用しやすいように関数にする。 たとえば、テキストファイルを読み込む処理を関数として「file_load」のように名前付きで用意したら、「file_loadでメモ1.txtを読み込む」ということが簡単に書けるようになる。

データ構造(型、データ形式

プログラムで処理しやすいデータ形式とは何かを学ぶ。
例えば、Excelの3行目に入った数字を左から順に処理していくのには『繰り返し』で学んだことを使うが、そのためには処理しやすいデータ形式(たとえば配列)にポンポン入れていくことが必要。

エラーと例外

エラーと例外を学ぶ

Debug、テスト

エラーじゃなくても自分が期待した動作をしなければプログラムは意味がない
ちょっとずつプログラムを動かして動作を確認するのをデバッグという。
また、期待している動作かどうかをプログラム自体で判定するのをテストという。
ちょっとずつ、漸進的にやるというのはプログラミングにとって基本的な戦術になる。それを学ぶ

オブジェクト指向

プログラミングをより構造的に出来るようにするやり方。
ちょっと難しいので頑張って理解する

システム・インテグレーション

大きめの課題をプログラムとして実行するにはどうするか?
たぶん簡単なWebアプリケーションとか書いたりする 動くときっと楽しい

ギルドワークスの「中の人」ミートアップ! 〜エンジニア編〜

2017年5月30日に表題のイベントに参加してきました。

guildworks.doorkeeper.jp

以下メモです。

コードを書くほうに携わっている3名

ギルドワークスで働くエンジニアってどんなかんじ? 〜ギルドワークスで過ごした半年間〜

越 智明さん

入社するまで

先輩エンジニアDさん
会社の外で話した
「今どんな開発しているのか?」
Dさんが一番成長した瞬間は?
新規案件でゼロから立ち上げるというのが一番勉強になっている

ほかの現場もみてみたいな

DevTab開発

開発言語
Ruby, go, java

週一開発定例 skype or 六本木オフィス

学びたい人はこの記事を読めばいい

社外の人と接点をもって開発する

採用試験 面接

日々の働き方

slack 入社してすぐ50~80チャンネルくらいに一気に招待された

Guildworks遠方に住所を持ってる人が多い
朝誰もオフィスにいないことが多い

slackは5時6時からフル稼働している

コーディングが主な業務

プルリクだけだとテキストだけになる
skypeをやることが多い

MoviePrint

動画を制作したい人 動画を作れる人
マッチングサイト

会社をまたいでという開発は初めて

開発合宿2人で缶詰

Sonitech

建築資材に的を絞ったEC
ゼロから

スピード感のある開発
一緒に組んだメンバーが良かった

Programing Boot Camp

3周年パーティー
ギルドワークス全員集合

結論
短期間で新しい経験を複数
経験豊富なプロジェクトメンバー

ギルドワークスに入ってやったこと・学んだこと

佐々木将之さん
UXデザインが好き

宮城県松島町
ほぼ毎週東京出張

2014年4月
創業メンバーを除く初めてのメンバー

実家に預けていた娘が小学校にあがる
宮城の企業をまわったが
UXリサーチを必要としてくれるきぎょうはなく

リモートワークでの勤務を模索
やりたいことを探っていたら出会った

スマートカート

顧客開発に追随するアジャイル開発
システム開発よりビジネスとして顧客を見つけないと始まらないよ

設計不足はマジ大変
「MVPなので作り直す」はほぼ作り直さない

シェアウィズ
仮説検証
開発マネジメント

サーバサイドScala
ReactNative

クライアント側の開発メンバーと1チームで開発

境界を越えて開発チームへ踏み込む

RODEM
開発マネジメント プログラマー

事業レベルの相談 市谷さん
コード1行まで

学んだこと
チームあってこそできた

一番学びが多い

学んだこと

一人でできることできないこと
チームとして成果を上げることを考えないと成果を出せない

リモートワークのありがたみ・大変さ
家にいるのに何で働いているといえるのかと家族にきかれたりする
通勤ラッシュに合うみたいなのは減った

いいものを作るためのアレコレ

利用者に役に立つものを作りたい

大学院時代

生命倫理
全12回 オムニバス 毎回講師が違う

倫理に関する 問いかけをする 答えがない

施設見学
西多賀病院 仙台

筋ジストロフィー

入院生活上で、何がほしいですか?
「鏡がほしい」
いつもと違う景色が見たい

利用者がどう利用していいかわからない

開発者のソリューション
ギャップ
顧客のほしいソリューション

大規模メーカーからギルドワークスにJoinした二年間

前川 博志さん

Application Lifecycle Management

開発者 兼 現場コーチ

Java iOS Android

大手企業から転職してきたギルドワークス

ナデラに変わったころにMSMVPをとったので、オープンに変わっていくMSを知ることができた

手段の目的がになりがち
入れるのが大変すぎる

自分は一流のエンジニアでいられるだろうか?
会社の枠を外して一人のエンジニアとして自立できているだろうか?

クラウドを使うルールの制定が一年くらい続いていた

現場感覚とマネジメント層のイメージの差
同世代もどんどん次のステップに進んでいる

このままでいいんだっけ

ギルドワークス
7人目の社員

前職が圧倒的に優位
100年 福利厚生もいい

くいっぱぐれることはないはず
本当に?

自分の仕事はつぶれないか?
ほとんどの仕事はAIになるのでは

10年後あんな仕事がしたいか?

Join to Guildworks

自分が動けば会社が動く
会社で何が起こっているか全部わかる

めまぐるしくってついていけねー
自分が動かないと何も起きない

会社のことを全部知ろうとしないとついていけない

印象的なエピソード
craful

イデアだけがあって ゼロから作っていた
ベンチャー経営者の熱を感じた

iOSエンジニア 四国
API 仙台
デザイナー東京

開発終わってから飲んだ
craful第2弾

人材系の新規立ち上げ

SPA
自分の見立てのあまさから、かなり危ない開発になってしまったプロジェクト

技術的な見立ての大切さ(SPAをはじめてつかった)を痛感

危ないとなったポイントから巻き返しプラン

大企業の新規サービス立ち上げ
大きな企業の中で、新しい取り組みを始める人の熱さ
データ・プロセスをプロジェクトを通して学んでいく楽しさ
どんどん「自分のサービス」と思えるようになってきた

これまででまなんだこと
プロダクトに本気で向き合うこと
本気のクライアントが多い

リスクを冷静に見つめること

パッションが大きいからこそ冷静にリスクを見つめなければならない
計画の遅れ、未確定事項、不安なこと、それらは必ず後で火を噴く

ギルドワークスの創業メンバーは血として持っている
それを体験することができた

これから

正しく作るのこだわりを出していかなければ

QA

プロジェクトの入り方

飛び込みじゃなくて紹介が多い
こういう話あるんだけど興味ある人いる?

洋さんとかが仕事をもってきて

誰も手をあげないときは?
ほんとにやれる人がいないときはお断りする
本気でやるクライアントじゃないと受けない
顧客が適当だとやりがいがなくなる

開発から入るみたいなのはお互いにバリューを感じられない

プロジェクトの巻き戻しよりもつらかったこと

自分の成長につながるからこそつらかったこと

大企業だと事務の人に言えば派遣さんくる
社会人として何も知らなかったということでへこむ

クライアント次第で柔軟に契約が決まる?

準委任にはしない 基本請負
差し引きは合う いいものが作れないときはゆるやかに合意する

スコープは相談するなどは割と気にする

Slackの話

透明性は高い 経営などの話
全員収支を見て 案件取ってくる 案件にジョインするなどが期待されている
どのクライアントにどのくらいお金払ってもらってるなどは意識している

リスク

技術的に困ったとき
社外のメンバーに頼る
仕様がどうしてもわからない
skype
Googleカレンダー 30分間の隙間
タクシーの中から応答

リモート力高まる いかにカフェがうるさいか 相手の声聞こえない こまめにマイクを切りながらしゃべる

Guildworksだけでなくエンジニアカルチャーはあるのか?

Guildメンバー = パートナー

差し引き 会話ができる
緩やかな個々人の会話

開発は制御しきれない

ブルドーザータイプ
整えていくのが得意なタイプ

いってもフリーランスの人が多い
組もうと思っても別の案件のときがある

経営判断 人ひとり入らないと終わらないでしょ
案件を受け入れない

評価について

基本は任せる方針
残業が云々などは言われたことはない

半年ごとに目標 創業メンバーにレビュー
人の評価は難しい

Guildworks定例のアジェンダ
同じことやるのが嫌いなくらい変わる

市谷さんが思考停止が嫌い
常に考えさせられる

全体の感想

参加人数は少なかったんですけど面白かった。
社員それぞれに得意技が違う感じというのも伝わりました。 順調に利益も出しているとのことなので羨ましい感じがします。
大変だけどやりがいがありそう、楽しそう。

Guildworksは理念が「正しいものを正しく作る」なのでわかりやすいです。
本当にそういうことを言い続けるのって大事なんだと思う。自分としても何を大事にして仕事していくのかを常に考えていきたい。