【勉強会メモ】関西Node学園 3時限目
- 日時：2018/08/03 (金) 19:00 〜 21:30
- 場所：LINE KYOTOオフィス
今回も多種多様なテーマでどの発表もためになる内容でした。個人的にはpuppeteer、Serverless Frameworkあたりは気になってはいたものの手が出せていない領域だったので、具体的な活用方法が聞けたのはとても良かったです。
LINEの京都オフィスに初めて行ってきましたが、地下組織のアジトみたいなかっこいい雰囲気でした。
node-canvasでアニメーションGifをつくって遊ぶぞ！
kawasako3 さん
www.slideshare.net
- ガチャ演出みたいのがあるといい
- トークに時間軸のあるコンテンツをカジュアルに送りたい
ライブラリ
アニメーションを作る基本
- 最初に目標値を決める
- どのくらいの長さにするか決める
- フレーム毎に描画する
- 変化に緩急をつける
LINE Messaging API で動かす
⇒GifアニメーションがBOTから送れない
⇒mp4で作る
学び
- Photo movie 的なこともできそう
- ただし事前生成じゃないと厳しいかも
- Messaging APIではGifアニメは使えない
サンプル
N-APIとPromise
C++ Addons
C++連携
- 速度がほしい
- jsではできないOSの機能を呼び出したい
- 全てをjsで書きたい
実際に書いてみると全然わからん
- V8理解していないとよくわからない概念が多い
- V8に依存している
- v8バージョンアップのたびにビルドが必要
N-APIの登場
- わかりやすい
- 型がシンプル
- V8に依存しない
- 他のjsエンジンでも動く
- V8バージョンアップの旅にビルドしなくてもいい
- 10.0.0からstableになった
サンプル
N-API と Promise
何がしたいか
- 諸事情でLZW圧縮の亜種をnodeで扱う
- jsで組んでみるも遅い
- child_processも遅い
⇒N-APIで組んでみたが問題発生
基本的に同期的
- イベントループの中で実行
- 重い処理はイベントループを止める
async_work を使って非同期にする
- ExecuteCallback
- 非同期で実行
- イベントループの外で実行
- ここで重い処理
- イベントループの外なので
napi_hoge()関数を呼ぶと落ちる
- CompleteCallback
- Excuteが終わるとイベントループのキューで実行
- イベントループの中で実行
- jsにcallbackしたり戻り値を作る
非同期にするうえでの注意点
- C++上で変数のポインタを持っていてもjsの参照カウンタは増えません
- 自分で参照カウンタを増やしておく
N-APIのPromiseはそんなに難しくないので割愛
参考
LINEで馬券を購入する
@sbntaminif さん
馬券ネット購入サービス
※参考
LINEで馬券を買ってみたい
- 馬券を購入するアプリを作りたい
※日本語はところどころ間違いがあるので英語のほうがおすすめ
Headless Chromeとは
puppeteer
Chromeを自動で動かして馬券購入まで
しかしこのMacでしか使えない⇒このAPIをサーバで動かせるようにしたい
Lambdaで実行
AWS管理コンソールからしか使えない⇒API Gatewayから呼び出す
- タイムアウトが2分⇒メモリの制限？うまく動かない
- LambdaからLambdaをコール
どこからでもAPIを呼び出せる⇒ネットワーク経由ならAPIで馬券を購入可能
LINEでAPIを呼び出す⇒LINE Messaging APIを使う
⇒買えるようになったが送信のみ
応答メッセージ機能
- メッセージを送ったら1回だけ返却
- パラメータの中のユーザーIDを使う
- 自由にユーザーに送信するPush APIは有料
実践編
puppeteerでつまづいたこと
- 範囲外の要素クリック
- 画面外の要素のクリックが発火しない
- 画面を大きくする
waitの使い分け
- waitFor
- 指定した時間まで待つ
- waitForNavigation
- 引数なし
- waifForSelector
- セレクタで指定した要素の表示を待つ
アピール編
Hedless Chromeの魅力
Warning
- 常識的にやりすぎない範囲で
動画で強く話されていること
- この話はテスト自動化の話ではありません
- 自動化することができる
- 普段の作業を自動化する
これこそエンジニアリング⇒自動化やっていこう
AWS Serverless Express 入門
AWS Lambdaを使ってExpressを一瞬で公開する方法
@nkgrnkgr さん
テーマ：AWS Serverless Express
そもそもServerlessとは？
Serverless Platform
AWS Lambda
- pros
- cons
- 初回起動にやや時間がかかる
- デプロイできるファイルサイズが50MB
- 1リクエストあたりの最大実行時間が300秒
AWS Serverless Express
- LambdaとAPI Gatewayの上にExpressを使用してサーバレスアプリケーションとREST APIを実行できるAWS公式ライブラリ
- Express のMiddlewareに追加するだけでLambdaで実行可能になる
How to Use
npm installするだけawsServerlessExpress.proxyをかます
LambdaへのデプロイはServerless Frameworkを利用
npm installでインストール- serverless.ymlで設定
参考
ライブコーディング（省略）
【勉強会メモ】MonotaRO Tech Talk #6 (大阪梅田オフィスオープン記念)
- 日時：2018/07/25(水) 18:30 〜 22:00
- 場所：MonotaRO 梅田オフィス
BigQueryを中心とした大規模データ基盤開発
香川 和哉 さん
データの種類
- 商品、在庫、顧客、サプライヤ問い合わせ、受発注
- WMS(Warehouse Management SYstem)
- プロモーション
- Webサーバログ
- アプリログ
- GA
- 1,000テーブル
- 受注5,000万行
- 明細1億5,000万
- ログ4,000万行/日
ETL / Binlog Connector
旧DWHでのMySQLデータ同期における課題
- 依頼ベースでの同期テーブル追加
- 割り込み差魚う、そもそも依頼が面倒
- 差分更新だと物理削除に対応できない
- 数億レコード右や全件洗い替えが難しい
- 全件更新も差分更新も困難
⇒課題を解決するために作ったのがBinlog Connector
DWH/DataMart
- Raw Dataから何段階か加工してDataMartを作る
- エンジニアはdigdagを使う
- マーケターなどはGAS制のツールを使う
Google Sheet JobScheduler
## バッチ処理基盤
- Solr（検索エンジン） への転送
- 並列処理で180分
- BigQueryで15分
- 実行時に新しいテーブルを作成して実行時にできるだけ並列化
データ基盤のこれから
- データの民主化
- 安全な仕組み
- メタデータ基盤（いつどこからきてつかわれたか）
- データマート構築
- 社内での勉強会やサポートの充実
- より高度なデータ分析・処理基盤
- 機械学習基盤の高速化
- リアルタイムデータ処理基盤
- マーケティングプラットフォームの構築
- より早く、より最適化されたアクションにつなげる仕組み
- WMSなど連携システムの拡大
チームの戦闘力をガンガンにあげろ！
鈴木 圭 さん
チームが抱えていた色々なこと
- 時間がない
- 本来の仕事が進まない
- リリースに2時間かかる
- 開発環境が頻繁に壊れる
- リファクタリングしたい
- 昼も夜もアラート対応
キックオフでどうなりたいかを伝える
- 組織のはなし
- グループのはなし
- 意識してほしいこと
第一に仕事をコントロールして第二に生産性を向上する
- 生産性だけ上げても仕事が楽にならない
取り組んだこと
- 障害対応訓練
- リリースマネジメント
- 愚直なリファクタリング
- ペアワーク
- 1人案件をなくす
- マネージャーにできること
障害対応
- 障害対応のプレッシャー
- スピーディー
- イレギュラー
- 平常業務よりも難易度が高い
- 障害対応のプラスの側面
- エンジニアを強くする⇒貴重なリソース、発生頻度が低い
- 障害対応訓練は効果あり
- 事前に経験値を高める
- 心理的な負担も軽減
- 心理的負担を軽減する事前のすり合わせ
- 自分で手に負えなかったら⇒電話
- システム負荷が下がらない⇒再起動
- 深夜アラートに気づけない⇒仕方ない
- 会社の制度面でケアが必要な場合もある
- 待機手当は？
- プライベートを侵害しすぎてない？
- 夜間対応した場合の出勤時間の調整
- アラート対応はボランティアではない
例えば、
- 待機メンバーの当番制
- システムのことを完全忘れられる日を作る
スキル面、体制面、制度面それぞれのケアが必要
ペアワーク
- 予想通り品質が向上
- 予想外に生産性も向上
品質向上の理由
- 人数が2人
- フィードバックの心理的コストが低い
生産性向上の理由
- 立ち止まっている時間が圧倒的に減る
マネージャにできること
- グループの成果を最大化
- メンバーがパフォーマンスを発揮できる環境を作る
具体的には
- 意思決定を行う
- 期待値を伝える
- リアクションを返す
- なるべく予測可能に振る舞う
- 環境面の課題に取り組む
- 会社の制度に働きかける
まとめ
- 前を向けるメンバーに恵まれたならきっと今よりも良い状態にたどり着ける
- 個人ではなくちーむとしてパフォーマンスを発揮することを考える
モノタロウAIストアの話
牛島 真一 さん
AIストア
- 佐賀県
- 電車で約5時間
- 自動車で約8時間
2017年7月社内キックオフ
- だったが約2ヶ月半プロジェクトメンバーから外れる
- 2017年9月再キックオフ
- システム側のPL担当
条件
材料
社内リソースは最小限
やってみた
- アプリ本体はパケージソフトを利用
- バーコードリーダー部分のみネイティブ
- 残りはWebView
- スマホサイトをカスタマイズして利用
- 商品情報、顧客情報、決済処理
- 既存サイトに裏でつなげる
- 必要最小限のサーバを別途作成して別サービスドメイとして作る
注意したこと
- 外部システムとの連携
- サイトシステム以外に店舗ゲートなどの物理的なシステムが絡む部分を疎結合にする
- 新規システム開発を最小限に抑える
- アプリ操作はわかりやすくシンプルにかつ将来的に内製可能な仕様にしておく
- 約束したスケジュールに遅れない
やらないと決めたこと
ちょっと危なかったこと
- スマホアプリとして採用したパッケージソフトでJANコード以外のバーコードが読めなかった問題
- ゲートのQRコードリーダーの読み取り制度が想定以上に悪くゲートが開かないor正しくデータを読み取れない問題
- 予定外の店舗改装工事が入り、テストスケジュールを大幅に圧縮、短期間で実施せざるを得なくなった問題
2018年4月2日に無事サービスIN
まとめ
- 実店舗という商品を直接手にとって見る事ができるサービスを提供
- Webサイトから注文し社内システムでのフローを一部省略することができるようになった
- Web注文⇒在庫引当⇒売上計上⇒請求処理⇒ピッキング⇒梱包⇒発送
- 少し発想を変えることで化けるシステムができたこと
これからのモノタロウのIT開発
久保 征人 さん
これから3〜5年
- より大規模に
- よりデータドリブンに
- よりグローバルに
売上1,000億〜の売上を支える
- 高度なデータサイエンスに基づいたシステム開発
- これをさらにグローバルプラットフォームにする
つまり
- 自社開発を中心に
- 外部のプロダクトもうまく組み合わせて
- 差別化と生産性の両立
具体的には
日々使われるシステム／大きな売上／急成長するビジネス／拡大するチーム／で良いITを継続して開発することがチャレンジ
生産性＝①向上する売上や利益／②かけたコスト
事業会社なので①も重要
- 機能追加変更が容易変化に強い②
- バグが少なく安定運用②
- 差別化できる（売上を上げる）①
①の例
- 検索
- レコメンデーション
- カート員・ユーザー登録、購入ステップ改善
- LPO(Landing Page Optimization)
②の例
その前に足元の課題にも愚直に取り組む
- ユニットテストE2Eテスト
- リファクタリング
- リリース時間短縮
- 自前FWからOSSのFW
- プロジェクトマネジメント・プロダクトマネジメント
- 生産性のモニタリングと改善
まとめ
- フロントエンド/バックエンド
- プロダクト/プロセス
- 個人スキル/チーム開発
- 日本/グローバル
- SoE/SoR
多くの切り口で様々なチャレンジ
【勉強会メモ】大阪Ruby会議01
- 日時：2018-07-21（土）10:00 - 17:00
- 場所：大阪科学技術センター 4階 401号室
Rubyはほとんど使ったことが無いのですが、まつもとゆきひろさんの話を聞きたかったのと、先日同じようにあまり使わないレベルのPHPについても PHPカンファレンス関西 に行ってきたので、それならRubyのコミュニティにも参加してみたいという思いもあって行ってきました。今回聞いてきたどのテーマも根底は言語に依存しない普遍的なテーマだったので「Rubyじゃなくても大切だよなぁ」と思いながら聞きつつ、それが言語の特性を踏まえた知見から語られているので「Rubyだとそうなんだなぁ」という気づきも得られて非常に参考になりました。
keynote : Rubyはなんでできてるの？
まつもとゆきひろ さん
Ruby25周年
Rubyをつくったきっかけ
- 1993年ごろバブル崩壊
- 不況の産物
- 社内システムの開発⇒景気が悪くなって解散
- 大半のメンバーはお金を稼ぐ部署に移動
- 社内システムのメンテのために2人だけ残された
- そのうちの1人がまつもとさん
- 基本ひまだった
- なんかやるかと思って作ったのがRuby
高校時代の夢
- BASIC使っていてこれよりましな言語がほしい
- 言語を勉強しているうちに言語は面白い⇒言語作りたいになった
- 当時はまだネットがなかったので情報が本か雑誌しかない
- やさしいコンパイルのつくりかた
- 高校生には難しかった
結局何に興味があったか？
過去の言語のいいとこ取り
Rubyの発想の源
- 大学時代Sun3ワークステーションを学部生100人で共有
- Emacs使うことは禁止されていた
- ソースコードリーディング⇒Emacsの中身を読み始めた
- Tagged Pointer
- Garbage Collector
- auto-indent
ruby-mode.elを作ってからRubyの文法を決めた
CとRubyを交互に使う
- 視覚的にコンテクストスイッチが行われる
- シンボル⇒当たり前と思っていた
- Bignum⇒すごい悩んだ
fcntlを追加した時…Tagged Pointerを使っているので整数は32bitしかない
- メタプログラミング
- CLOS
- bit 別冊 Commpn Lisp オブジェクトシステム
- 1988年インスパイアされた本
- nil
Eiffel
- オブジェクト指向Ara
- マイナー言語
- 昔は金融系などで使われていた
- Object-criented software constructionオブジェクト指向入門
- タイトル詐欺⇒入門じゃない
- 卒業研究でプログラミング言語を作った
- 静的型
- 多重継承
- プロファイル（インターフェース）
- これらは結果的に次に作ったRubyには全部入っていない
- 櫛形構文
- require
- ensure
- rescue
- ↑Rubyも影響
- 櫛形構文
CLU
- Barbara Liskov
- リスコフ置換原則の人
- 抽象型言語
iter() do|i| ... end
Sather
- UCBで開発されたEiffel類似言語
- undef
- alias
- Sather 1.0にはundefはない
- バージョンが進んだ時にすれられた⇒LSPに反するせい？
- Rubyにコピーされて生き残った
- class
- def
Smaltalk
- select
- collect
- detect
- reject
- ブロック引数の
||
- 演算字優先順位
- 目標：Perlと同じような仕事ができること
- これらをオブジェクト指向で再構成⇒正解だった
- グローバル変数は不正解
- 正直後悔している
- 未来は予想しづらい
- RoRやWebアプリケーションになることは想像していなかった
真似なかった言語
デザインの困難さ
- なにをパクるか
- どれだけパクるか
- そのままパクるか
- 周囲との整合性
- Rubyにしかない要素はあまりない
バランスが大切
- エクストリーム
- ボリュームのつまみを一番上まで上げる
- 極端は簡単
- バランスが大切⇒すごいむずかしい
- 「ちょうどいい」が必要
- 答えがない
- 人によって違う、時代によって違う、条件によって変わる
- 誰かが決めないといけない
安定と進歩
- 互換性は重要
- 互換性がないと古いバージョンを使い続ける人がでてくる
- しかし、変化は止められない
- テクノロジーの進歩
- 「昔はそんなのあったよね」と言われる
- 緩やかな死
- 進歩を止める≒死
- Rubyがそうならないように進歩を止めるわけにはいかない
- バージョンアップ地獄
- 下にいる人が苦労して互換性を保っても上側で壊れる
- なぜか？⇒Webというドメインの変化が早い
- たとえ互換性を壊してでも変化を続けなければ取り残されてしまう世界
- JavaScript
- フレームワークさえ交代
言語のデザイン
- 困難
- 柔軟性と性能
- 厳密さと気分
- 静的と動的
- デザインの面白さ
- デザインの困難さ
Ruby3について
- 2020年ぐらい出したい
- バランス
- 互換性の維持
- 「盲腸」の切除（誰も使っていないもの）
- 性能の改善
- Ruby3x3
- JITコンパイラ
- MJIT
- MIR
- まだ動くだけ
- 将来に期待
- マルチコア時代
- GIL⇒外せるけどクラシュする
- Guild
- メモリ容量
- GC改善
- 関数型プログラミング
- 列指向プログラミング
- パターンマッチ
- 鋭意開発中
つまり
- バランス
- 既存のコードを壊さない
- 性能改善
- より良いRubyのために一本橋の上を駆け抜ける
- 既存のソフトウェアを壊さない選択肢を探す細い一本道しかない
- ソフトウェア開発・デザインの困難さ
- すべてのデザインの面白さ
- Rubyの特異さ
Rubyは良い言語
- ただデザインは厳しくなって狭くなる選択の余地
- 言語デザインの難しさ⇒言語デザイナーの醍醐味
- プログラマー≒デザイナー
プログラミングの醍醐味
- 自分はデザイナーであるということも頭におく
- 困難はつきまとうけどそれが一番おもしろい
Tech Talk：Complexity and You
@yuki24 さん
過去のWeb開発
- HTTPサーバは基本Apach
- ファイル構造が表示されるだけで感動
- PerlやPHPでページごとにゴリゴリ書く
- 単なるテキストファイルをデータベースっぽく使用
- アクセスがあるたびにデスクI/O
- 適当なロック処理
- なんとなく動かしていた
- 紙のページを彷彿とさせるデザイン
- JavaScriptは悪
- ページ遷移でキラキラアニメーション
- マウスポインタを追従する画像
- JS使うな
↓このようなWebサイト
bitfission.com - Will Leinweber
今日のWeb開発
- 数多に存在するフレームワーク
- 当たり前のようにRDBMSを使用
- Node.jsでSSR
- バックエンドなしでもアプリ開発
- Firebase
- Google Mapの登場でJS復活
- Protorype.js
- jQuery
- フロントエンドライブラリ
- React Angular Vue
- SPA
- Virtual Dom SSR PWA
- GraphQL
何使ったらええねん
今日のWeb開発のぱっと見の印象
- とてもスムーズに動くUI複数の要素が同時にロード
- ページングなしで画面遷移
- エッジケースも簡単
プロジェクトが始まってから明らかになる事実
- JS難しい
- AngularとかFW難しい
- SEO難しい
- Bundled JSのファイルサイズ大きすぎ
- PWAまだわからん
- JS依存ライブラリがメンテされず死んでいる
- ちゃんとテストされていない
それRailsで5分でできるよ
- ソフトウェア開発とは単なる線形な仕事ではない
- 日々積み重なる複雑度により同じ機能でも別アプリだと実装の速度が変わってしまう
Complexity
- Apach + PHP
- 高価値／実現困難
- JS before Google Map
- 低価値／実現困難
- Rails
- 高価値／実現困難⇒高価値／実現容易 価値があって難しいものが簡単に移動
- JS after Google Maps
- 低価値／実現困難⇒高価値／実現容易
- 高価値で実現困難
それReactで簡単にできるよ
- Railsだけでやろうと思うと見当もつかない
- JSならさっと思い浮かぶ
- Reduxでデータを共通管理
- イベントもRedux
Reactで実現した後…
また高価値で実現困難な要求が発生
- 認証系機能
- 管理画面
- バージネーション
⇒それRailsで5分でできるよ
Railsでできる⇒Reactでできる⇒循環
いいとこどりしようとした結果
ソフトウェア開発!=コーディング
- 高価値／実現容易でユーザーを獲得できないと実は価値がない可能性もある
- リスク・不確実性
本当にhigh valueか？
常にXを使え（使うな）族
道具はツールボックスのように整理されていて使わないといけない
- 学習はツールボクスの中身を増やしていくこと
- 慣れたツールもあれば慣れていないツールもある
- よく使うツールもあれば使わないツールもある
- 高価値／実現容易でユーザーを獲得しないと何もできない
- 高価値／実現困難にフォーカスできているのはプロジェクトとしてはヘルシーな状態
- 高価値／実現困難をシンプルにするにはどうしたら良いか
それXでできるよの投げ合いは解決に至らない
- 過去の成果に対するリスペクトがあるか
- 道具に対する知識が十分あるか
y=f(x) x=使用可能な技術 y=テックスタックの決断
y=g(x) x=開発を始めるときの年 y=使用可能な技術
y=f(g(x)) g(x)は使用可能な技術を返す関数 関数fは人間
あなたの関数f(x)はなんですか？
Tech Talk:GR-CITRUSいろいろ
たろサ さん
GR-CITRUS
- 極小Rubyボード
- mruby
- 2,200円
- 2014年ごろからWakayama.rbで開発
- ルネサスさんが企画して秋月電子通商さんが商品化
- オープンソースハードウェア
- Ras-Pi Zeroより小さい
Ruby Cam-Robo360
VS-Code Studioで開発
- VS Code Rubicを入れる
参考
開発当初からの変更点
- プログラムサイズ制限をなくした（4KBから無制限）
- 大きなコードが動かないという声が多数
- ただし暴走は自己責任
- プログラム実行の自動切り替え
- 電源起動すると
main.mrbが自動起動 - USBでPCにつないだときはデバックモードで手動実行
- 電源起動すると
- 強制ブレイク
- 無限ループでもブレイクできる
サンプル
【勉強会メモ】Sansanの開発の現場
- 日時：2018-07-20（金）19:30 - 21:30
- 場所：楽天 大阪支社
名刺管理サービスSansanの開発現場について、PM、デザイナー、開発チームそれぞれの立場から開発を前進させている話を聞いてきました。 @mmmmao0530 さんには以前からアジャイル系の勉強会でお会いしたことがあったのと、個人的に同じtoBのサービスを展開するクラウドサービスの企業ということで以前からウォッチさせてもらっていたこともあり、興味を持って話を聞きに行ってきました。
個人的にはインセプションデッキやトレードオフスライダーの扱いどころについて今ひとつイメージできていなかったところが、ひとつのヒントを得られたことが大きな収穫でした。あとは新規ビジネスの話については理論を知るよりもやはり現場の話を聞くのが一番参考になると改めて感じました。
ビジネス仮説を検証する - Sansanの新規事業開発 -
プロダクトマネージャー 加藤 淳さん
- 新規ビジネスは不確実性が高い
- 不確実なものとどう向き合っていくか
アイデアはうまくいったけどビジネスとして成り立たないこともある
不確実なものと向き合うマインド
- 不確実なものはなにか探索し、実験と学習によって意思決定（リーン）
- 全てのアイデアを仮設と捉え、仮設がただしいか検証
なぜ仮設の検証が必要？⇒リスクを抑えるため
仮説検証とリスクの関係
- 正しくないものを作ると時間が経過するとリスクが上がる
- 顧客開発モデルは構築⇒計測⇒学習を繰り返す
- 学んだ結果、リスクが抑えられる
- 新規事業開発はこれを繰り返す
Sansanの新規事業開発
独自の価値
- 名刺から調査対象を抽出し、BtoB企業の〜（※製品に関する詳細はオフレコ推奨により自粛）
- 仮説のスタートは自社の課題から
Sansanの課題
- 自社ブランディング対策に力を入れているが、効果が不明
- 他の会社も困ってそう⇒ビジネスの予感！
仮説検証の流れ
- 課題の検証
- ソリューションの検証
↑ここまで 課題とソリューションのフィット
- 製品の検証（訂正）
- 製品の検証（定量）
↑製品と市場のフィット
後の工程になるほどお金がかかる
1. 課題の検証
解決に値する課題か？
- 課題を持っている人はいますか
- どのような課題？
- どうやって解決する？
他社も困ってそう⇒検証する
- インタビューしにいく
- 課題をもった人たちとのコミュニティ形成を始める
なんか悩んでそうな人に会いに行く
- 動かずに考えるのはだめ
- 課題を持った顧客とのコミュニティ形成を目指す
2. ソリューション検証
必要なソリューションはなにか？
- 課題を解決できそうか？
- すぐに欲しがる人はいるか？それは誰か？
- 価格モデルは適切そうか？
⇒MVPを決める
どうやって検証するか
- 独自の価値に共感してくれる最初の顧客を見つける
- インタビューではなく買ってもらう
- できるだけリアルなものを見せる
アーリーアダプターがこんなものがほしいと言ってくれる ⇒ これがMVPになる！
リアルな内容
こんな製品があるので買ってください、月額ｘｘ円です
- 価値のあるフィードバック
- リアルじゃないと得られない
- アーリーアダプターはコアな部分に投資してくれる
- 少しぐらい変わっても気にしない
検証で変わるものと変わらないもの
- 独自の価値⇒ほとんど変わらない
- 開発を進めてOK
- 価値のインターフェース⇒変わりまくる
- 開発しても無駄になる可能性がある
3. 製品の検証（定性）
- 必要とされるものをつくれたか
- つくった製品が適切か
定性情報をどう判断するか
- 1の売上になる1つの機能に集中する
- 情報を集めすぎない
プロダクトバックログの上位であるMVPの開発に集中する
- 価値を検証できれば作り込まなくて良い
確からしい情報が得られたらすばやく判断
4. 製品の検証（定量）
- 必要とされるモノをつくれたか
- 大規模に検証し、拡大へのパターンを見つける
⇒残念ながら今回はここまで（開発中）
Sansanデザインクオリティ向上への取り組み
デザイナー 佃 望さん
SansanのUIデザイン
- デザイン＝設計
- ユーザーの目的
BtoBサービスのユーザー
- 導入する人と使う人の立場が違う
- 嫌でも使わざるを得ないゆえに真摯なフィードバックを頂く
Sansanのデザイナーとしてできること
Sansanの世界観とユーザーをつなぎ混乱を排除する
プロダクトの実現したい世界
- 社内人脈をフル活用
- 出会うべき人と最短距離で出会える世界
デザイナーは各開発チームに所属
開発チームの日々
- PM：まずなにやるんだっけ
- デザイナー：なんでやるんだっけ
- 開発：どれくらいでできるんだっけ？
デザインチームの取り組み
デザインチームの課題
- 増え続ける機能・画面
- 忙しい
- デザイナーの増員
ビジュアル・体験の統一感をいかに高い水準で保つか
- 目指すはさらなるSansan体験価値の向上
チーム内のコミュニケーション強化
- GKPT（Good,Keep,Problem,Try）で業務と日々の振り返り
- ワークショップやストレングスファインダー
- 相互理解を深める
受け方・診断方法 | ストレングスファインダー®とは | ストレングスファインダーで強みを活かす 株式会社ハート･ラボ･ジャパン
デザインレビュー
- 週１回MTG
- 案件共有＆レビュー実施
- Slack上でも気軽にレビューし合う
- 制作の途中段階でも見せる
ツールのちからで業務の効率アップ
- InVisionでプロトタイプドリブンな設計
- sketchのコンポーネントを使い倒す
普段の業務では得られない新しいアイデアにふれるための＋αの取り組み
- ICE
- Sansanのクリエーターが集い創作する
まとめ
- Sansanのデザイナーとしてできること
- Sansanの世界観とユーザーをつなぎ混乱を排除する
- デザインクオリティ向上へ大切にしていること
- 綿密なコミュニケション。レビューツールを活用して制作・検証・改善のサイクルを早く回すこと
新メンバーが多いチームにおけるプロジェクトマネジメントのコツ（苦労話）
チーフエンジニアリングマネージャー 大西 真央さん
大阪拠点の立ち上げ
- 新メンバーを採用しながら新たなチームづくりプロジェクト推進
- 拠点立ち上げ
- 2017年1月 東京メンバーとリモートで仕事しながら採用活動
- 採用：2名⇒8名
どんどん新しい人が入ってきて育成環境が整わない状況だと 採用基準を下げないことが重要
- 立ち上げと育成の両輪は難しい
- 人数が増えたら育成込みで採用しても良いかもしれない
プロジェクト
時期4名のときのプロジェクト
- IDプロビジョニングの機能実装
- WebAPIを作って自動連携
チームのスペック
トレードオフ・スライダー
- 納期＞品質＞＞コスト＞＞スコープ
プロジェクトマネジメントのコツ（苦労話）
参考：アジャイルな見積りと計画づくり
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 74人 クリック: 764回
- この商品を含むブログ (226件) を見る
日々得られた全ての情報から計画を考え続けること
うまくいかなかったポイント
大前提として全員の認識合わせを初期にやる - インセプションデッキ - プランニングポーカー - ドラッカーエクセサイズ
その1：バーンダウンせず - 想定内 - 新メンバーの立ち上がり時期 - ドメイン知識の習得時期 - ボトルネック - 設計に時間がかかる - IDプロビジョニングの技術知識の理解 - 新メンバーの立ち上がり遅れ - ドメイン知識習得に時間がかかる
新メンバーの立ち上り遅れにフォーカス
その2：死守できなかったポイント
- ベロシティ推移が4スプリント目で理想線に比べて現実のパフォーマンスが出なかった
やったこと
- レードオフ・スライダーを再検討
- 主体性、成長の観点を追加
それでも納期優先
納期＞品質＞成長＞主体性＞コスト＞スコープ
チーム全員でリリース最優先の認識合わせ後、今後の進め方を検討
変更1：マネジメントスタイルの変更
- 学習モード⇒サバイバルモード
参考：エラスティックリーダーシップ
- 作者: Roy Osherove,島田浩二
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/05/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
変更2：プルリクレビュー＆ペアプロ専任者を用意
- 日々チェックして数字を見たうえで専任をおいたほうが早いと判断
変更3：タスクに対して作業時間の見積りを実施
- 見積り通りいかなかったら個別にメンバーと一緒に考えた
- チーム全員でサバイバルモードと決めたので見積り通りのタスク実行を徹底
⇒リリースできました
まとめ
【読書メモ】 孫社長のむちゃぶりをすべて解決してきた すごいPDCA
孫社長のむちゃぶりをすべて解決してきた すごいPDCA―――終わらない仕事がすっきり片づく超スピード仕事術
- 作者: 三木雄信
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/02/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
孫社長の右腕としてソフトバンクを成長させた元社長室長の三木雄信氏が、会社の急成長を支えるために従来のPDCAに独自のエッセンスを取り入れてより高速にPDCAが回せるように取り組んだ手法をまとめた書籍です。著者はこの手法を「高速PDCA」と呼んでいます。
高速PDCAとは
まず冒頭で、著者がずっと見てきた孫社長の仕事のやり方と比較して、普通の人の仕事が滞るのは次のような原因があると述べています。
仕事を滞らせる6つの原因
- 計画に完璧さを求めること
- 一球入魂主義
- 期限の甘さ
- 数値で設定されていない曖昧なゴール
- 検証の中途半端さ
- 自前主義
これらは全て「高速PDCA」を回すことで解決できるとしています。
ソフトバンク3原則
ソフトバンクで高速PDCAを実践している背景として、最も大事にしている次の3つの原則が紹介されています。
- 思いついた計画は、可能な限りすべて同時に実行する
- 1日ごとの目標を決め、結果を毎日チェックして改善する
- 目標も結果も、数字で管理する
この3原則を満たす仕事のやり方が「高速PDCA」です。
高速PDCAを回すことで身につく力
- 自分で考える力
- 数字を使う力
- ムダがなくなる
- 高いモチベーション
- 失敗を恐れない力
高速PDCAの8ステップ
高速PDCAは次の8つのステップで実践します。
- 大きな目標を立てる（週、月単位など）
- 小さな目標を立てる（1日が原則）
- 目標達成に有効な方法をリストアップする
- 期間を決めて、すべての方法を同時に試していく
- 毎日、目標と結果の違いを検証する
- 検証をもとに、毎日改善する
- 一番優れた方法を明らかにする
- 一番優れた方法を磨き上げる
高速PDCAを支える数字へのこだわり
ソフトバンクのような会社の成長スピードを支えている背景として「高速PDCA」が非常に重要な役割を担っていたことは確かによくわかります。ただ、個人的に本当に重要なのは本書の中盤に書かれている高速PDCAを実践するための数字へのこだわりの部分だと感じました。ただ闇雲にPDCAを高速で実践すれば良いわけではなく、PDCAを高速に回すためどのように数字を切り取り、目標を設定し、日々検証するかが「高速PDCA」にとって一番重要な部分なのです。ただ、本書ではテクニックの一部が紹介されているだけです。あとは自分で考えて実践せよという事だろうと思います。
月間、週間ではなく「毎日」の目標を設定する
ソフトバンクではまずは「実行ありき」で、Planではなく「目標＋実行」から全てが始まります。
- 大きな目標は「ナンバーワン」を基準に決める
- ナンバーワンは人、情報、金が集まってくる
- 小さな目標は「毎日できること」で定義する
毎日の目標を定義する流れは以下の通り。
- 仕事をプロセスに分ける
- 「大きな目標へつながる毎日の行動」を見つける
- 目標を達成する「具体的なアクション」を設定する
ここがソフトバンクが実践する「高速PDCA」の一つの肝だと思います。「ナンバーワン」と「毎日できること」は目標を立てる上でとてもシンプルな基準です。目標を立てる時にそれが実現可能か？を深く考えるまでもなく答えが出せるからです。だからこそ「目標＋実行」が可能なのです。
高速PDCAを回すために数字を扱う
高速PDCAを回すためのテクニックがいくつか紹介されています。このあたりは少しテクニカルな話で、様々なところから情報の入手が可能だと思います。
多変量解析
T字勘定
可視化の手段としてT字勘定の考え方を応用することで「入ってきた数」と「出ていった数」が日々追跡できて良いという話でした。
高速PDCAを実践する
後半は「高速PDCA」を実践するためのヒントとしていくつかのノウハウが紹介されています。
6:3:1の法則
一番良い方法を6割、次に良い方法を3割、新しい方法を1割にして仕事をすることで以下のような3つのメリットが得られます。
- 成果を確保しつつ、さらに上をめざしていける
- 不足の事態、世の中の変化に柔軟に対応できる
- 新しく試した方法が失敗しても、大きな痛手にならない
まぁしゃん理論
本番の前から準備を重ね、相手が自分から望んで寄ってくるような状況をつくる
「鯉とりまぁしゃん」という鯉とり名人の話で、「イエス」を引き出す手法として紹介されています。事前に栄養をとってしっかり準備して体温を温かくして水中に入ると人肌の温かさで鯉が集まってくるので、あとは腕の中にそっと受け止めるだけで鯉がとれるという話です。
人を動かすには見える化
3つのポイント
- その方法を実行した場合に問題になりそうなことをすべて洗い出す
- 問題の洗い出しは、関係者全員で行う
- うまくいかなかった場合の代替案を提示する
マウンテンガイド理論
高速PDCAを回すためには何でも自分でできるわけではなく、人の力を借りることも重要だとされています。
初めて挑む山に最短ルートで登るには、その山を知り尽くしたガイドを雇うのが確実
人の力を借りる3つのコツ
- 話を聞く前に、本を読んでおく
- 良い質問を用意しておく
- ビジョンを語る
おわりに
「常にナンバーワンを目指して高速PDCAを回すことでソフトバンクは成長を続けてきた」というのが本書の締めくくりです。ここからどういう共感や教訓を得るかは人それぞれですが、高速PDCAはそういう概念的なものであり実装は人それぞれなのだろうと思いました。PDCAを高速に回すためにどういう数字を使うかを徹底的に考え、それを高速に実践するためにありとあらゆる様々なアクションを起こすことで、高速PDCAが実現されるのです。
