下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・個人開発の瓦礫の記録

"1日でWEBサービスを作る"という取り組み

前の週末に"1日でWEBサービスを作る"という取り組みをしました!

f:id:yuzutas0:20171119210350p:plain

ルール

1.スタートは昼食後!

  • イデア出しから始めること。
  • 開始前にあれこれ考えないこと。
  • とにかく無心でリリースに漕ぎ着けること。

2.夕食までに本番環境にリリース!

  • それまでは断食すること。飲み物はOK。
  • 食事をしたければ、さっさとリリースすること。

何が何でも1日でリリースに漕ぎ着けるという強い意志と「やっていき」の精神。

当日の流れ

プランニング

とりあえずホワイトボードにお絵描き。

  • コンセプト(誰のどんな課題を解決するのか)
  • 開発要件(画面遷移、ER)

サービス名は和風な言葉から連想ゲームで決めました。和歌に出て来る「待ち人」です。 クリエイターの未来を決めるような「待ち人」との「マッチ」から「ビート」が生まれるということで、Match Beat(マッチビート)と命名しました。

ちなみに持ち歩いているホワイトボードはこいつです。

CANSAY nu board JABARAN (ヌーボード・ジャバラン) A4判 [MBR] NJA4CMBR08

CANSAY nu board JABARAN (ヌーボード・ジャバラン) A4判 [MBR] NJA4CMBR08

コーディング

システム構成はこんな感じです。

リリース

※誤解を招きそうなので補足すると、カフェは終業時間になっただけです。

ということで何とか無事に達成しました。

できたもの

クリエイターがテストユーザーを募集するWEBサービス「Match Beat」(マッチビート)
https://matchbeat.yuzutas0.com/

突貫工事なので、作り込みは浅いです。 「もっとこうした方がいいよ!」といったアドバイスをいただけると嬉しいです。

翌日以降に修正した内容

  • Bug: コメント投稿者のTwitterリンクが誤っていたのを修正
  • UI: テキスト内のURLをタップすればリンク先に飛べるように修正
  • UI: 投稿者のTwitterリンクをタップしたときに新しいブラウザタブを開くように修正
  • UI: 長文投稿しやすいように入力フォームの幅を縦長に修正
  • UI: 実機iPhoneMacでも入力フォームのスクロールバーを操作しやすいように修正
  • UI: SNSシェア時にデフォルトで企画タイトルを含むように修正
  • Cost: 金銭面の事情によりGCPからVPSにサーバを移管

なぜ作ったか

この取り組みとは別に「声だけでマッチングするアプリ」を作っています。 そのテストユーザーを募集するにあたって、専用サイトがあってもいいんじゃないか、と思ったのがきっかけです。 詳しくは募集ページをぜひご覧ください。

振り返り

よかったこと

1: タイムアタックで時間を意識したこと

時間が限られているので、効率の悪い作業・苦手な分野は、はっきりと可視化されます。 毎日コツコツと作業を行うだけでは気付きにくい1、自分の弱点と向き合うことになります。

逆に言えば、そこを効率化することで、次からはもっと早く作業ができるようになる、ということです。 個々の反省点(=改善余地)は後述します。

2: 1日リリースの実績を得たこと

クリエイターにとって最大の敵は「未完成」(エターナること)だと思うんですよ。 モチベーションが続かないとか、なかなか完成しないとか。

だけど、アイデアを言うだけではなく、実現するからこそのクリエイターです。 スコープを小さくするための方法を考えることもまた「企画」の醍醐味の1つでしょう。

15週間でクソゲーを20本作って得たもの - Qiita

RPGツクールでゲーム作ろうとしたけど30分で飽きてラスボス戦だけ作って放置したんだけど、今思えば「いきなりラスボス」ってタイトルで1作でっち上げても良かったのかもしれん

2017/10/02 16:41

前に拝見したこのコメント、いいなぁと思いました。 「企画力」という言葉はこういう発想のことを言うのだと思っています。

今回、1日でWEBサービスをリリースするという実績ができました。 次からは「ログイン機能も削っちゃっていいじゃん!」と、自分自身に対して強気で言えるようになったわけです。 「モチベーションが落ちる前に1日でリリースしようぜ!」という選択肢ができたのは心強いです。

3: 使ってもらえたこと

@seekgeeks_nyさんがPostterというサービスのテストユーザーを募集なされています。 「何か一言」と画像を合成してシュールな画像を作るサービスだそうです。 話題になっているハッシュタグをお題にして画像で大喜利できるとバズりやすいのではと思ったり。

画像と文字を合成してTwitterに投稿するサービスの改善案募集中! - Match Beat

ユーザーは1人も付かない想定だったのですが、こうして使ってもらえるのは、やっぱり嬉しいですね。 @seekgeeks_nyさんは「1日でWEBサービスを作る」企画を面白がってくださって、あちこちで宣伝いただきました。 せっかくですので、この機に一緒に何かできたらいいなと思いました。

反省点

What

コンセプトの尖り具合が足りなかったです。 例えば「Pythonで彼女を実装しました!」みたいなパワーワードが出て来ないと、この乱世は生き残れないですからね。

ゼロ・トゥ・ワン 君はゼロから何を生み出せるか

ゼロ・トゥ・ワン 君はゼロから何を生み出せるか

www.wantedly.com

これらの書籍や記事で書かれているように、

  • まずは少数に対して尖ったものを叩き込む
  • 熱狂してもらう
  • シェアを確立する
  • その上で、次の尖ったものを叩きつける
  • その繰り返しで非連続的に成長させる

このスタンスを意識できていなかったです。 薬にも毒にもならないものよりも、歓喜乱舞と罵詈雑言が飛び交うくらいの尖ったものにしたい。

Who

具体的に誰がどう使うかのペルソナを描けていなかったです。 リリースしたら「この人とこの人に声を掛けてマッチングさせよう」という企みが足りなかったです。

angel-base.com

上記リンクで言われているように、仮にサービスが伸びなくても「その2人に喜んでもらえた」だけでも成功と呼べるでしょう。 もしかしたら「最初の成功例が早くも生まれました!」とPRすることで、注目や初速が出たかもしれません。

そういった意味で、ユーザーになってくれるであろう自分以外の誰かにきちんと向き合えていなかったのは反省です。

Where

きちんとした作業場を確保すべきでした。

When

昼食〜夕食で試みたのですが、朝からやったほうが良かったのではと思います。 関連して、食事制限は設けずに適度に休憩すべきでした。さすがに身体に悪すぎる。

How

今回の作業ブロッカー・手戻りのリストは以下の通りです。

  • 異常系の動作確認パターン:複雑になるときは紙に書き出して整理すべきでした。
  • before_filterの無理な共通化:最初はベタ書きで進めて、別途リファクタリングの時間を設けるべきでした。
  • Asset Pipelineのエラー:久々で色々テンパりました。1度に多くの変更を加えると問題の切り分けが大変なので、小さく1つずつ動作確認すべきでした。
  • Production環境の設定エラー:本番サーバにいきなり上げたせいで原因特定に苦しみました。先にローカルでProductionビルドすべきでした。
  • GCPの想定外コストに気付いて別サービスのチューニングを始めてしまった。えらく時間を費やした。お陰で安くなりましたが。GAEは難しいですなぁ。

今後: 磨き込みのアイデア

実際に公開してみると、利用を促進するには工夫がいるなぁと思いました。

テストユーザー側のアクションを磨く

このサービスのアキレス腱は「テストユーザー側」の「アクション」だと思うんですよ。 フィードバックを求めるクリエイターはいるはずなので、最初の投稿はお願いできるかもしれない。 だけど、そこから伸びるためにはテストユーザー側の反応が不可欠です。

では、テストユーザーがあえてこのサイトを訪問するのはなぜでしょう。 このサイトで意見を交わすのはなぜでしょう。 そこを抑えることがポイントなのではと思います。

例えば

  • NewsPicksに経営者がコメントするように、デザイナーやエンジニアやQAが「このサービスはここを伸ばすと良さそうだね」「こういう点が難しいだろうな」「使ってみた!可能性を感じたよ!」と語る場
  • StackOverflowでエンジニアがQ&Aをするように、クリエイター同士が知見を共有しあうQ&Aサイト → 回答するとレベルが上がる、知識の整理になる、考える訓練になる
  • マイナーな仮想通貨で支援できるクラウドファンディングのような場(もしかしたら高騰するかもしれないくらいの期待感がインディーズっぽくて私は好きです)
  • Githubのように、エンジニア以外でもIssueを出したり「+1」できたり、ロードマップやコミット(更新履歴)やチケット進捗を追えたり、Wikiで使い方を確認できたり、STARで更新通知を受け取れるプラットフォーム
  • オフラインで「日曜グロースハック会」なるイベントを月次で開く → 参加者は当日までにMatchbeatにグロースのアイデアを書き込んで、当日はケーススタディ&ディスカッションしあう(=このサイトに書き込むことが勉強に繋がる)

こういったアイデアはどうでしょうか。 最後の案(日曜グロースハック会)はシステム改修なしで今すぐ実現できそうなので、試してみる価値はあるかもしれません。

テスター募集側のツールとして磨く

あるいは「テストユーザーを募集する側」の「ツール」として磨き込む作戦もあります。

  • WebAPI,SDK,コピペ用JSを提供してユーザーからのご意見箱を気軽に設置できるツール
  • LINEやFacebookメッセンジャーbotと連携して、ユーザーが好きなインターフェースで感想を送ることができるツール
  • SNSエゴサーチでご意見を自動収集してレポートしてくれるツール
  • いろんなSNSでバラバラに受けた意見を、どんどんInboxに蓄積すると、似たものを自動グルーピングしたり、チケット管理できるツール

このサービスだけではテストユーザーが見つからないかもしれない。 だけど、テストユーザーを探したり、意見を出してもらったり、出てきた意見が管理しやすくなる。 コミュニティとしての活性化ではなく、SaaSとしての実用性を磨き込む。

そういった作戦に切り替えることも考えられます。

最後に

長々と書きましたが。

イケてる(と思い込んでいる)アイデアをいつまでもリリースできない。 そんなイケてない自分とはサヨナラだ!という内容でした。

やろうと思えば初心者であっても、スコープを絞り込んで1日でリリースできるはずです。 ぜひチャレンジしてみてはいかがでしょうか。

あと、せっかくなので、これやりたいですね。

ちなみに

  • 声のマッチングアプリのテストユーザー募集はこちらです!ぜひよろしくお願い致します! → https://matchbeat.yuzutas0.com/plan/3
  • もし良かったら「日曜グロースハック会」(月次で集まって互いのサービスのグロース案を模索する会)を誰か一緒にやりませんか?


  1. WIP制限を1にすれば普段の作業でも同じ恩恵を受けることは可能なはず。参考: なぜWIPの制限が重要なのか | Ryuzee.com

開発運用チームを立て直した話

SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。

発表スライド

「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」

ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。

参加した感想

  • 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。
  • 一方で内容面については全体的に違和感を覚えました。もやもやです。
内容 思ったこ 補足事項
「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。
現場にメリットのない改善施策に意味はあるのか。
最後のパネルディスカッションで似たようなツッコミが出たので安心しました
1人1人の改善意識をいかに養うか → 打ち手として「教育」「評価」の話になりがち 普段からお互いに「お前はどう思う」を聞きあうだけで解決するのでは
参考:新入社員の自発的な課題発見・解決を促す
パネルディスカッションで似た話が1
「今回の取り組みをもとにXXX導入を社内全体に広げていきます」といった今後の方針 わざわざ広げる必要ないのではと思う内容が多々。
プラクティスには適用範囲があるので。1
文脈は違えどクロージングセッションのSoE/SoRの話が近いのかなと
テストコードやアジャイル手法を「やってみた」が多い WEBに山ほど上がっている各社事例で知見としては十分ではないか。
適用するプラクティスと生じる問題に業界の差は見受けられなかったので。1
単純に私の観測範囲がほかの参加者とズレていたのだと思いますが

個々の取り組みはどれも素晴らしいものだと思います。1つ1つの活動を否定する意図はありません。

ただ、趣旨が趣旨なので仕方ないのかもしれませんが、「改善」自体が目的化しているように感じる場面が多かったです。 どちらかというと「これから改善活動を担う人」向けのイベントだったということでしょうか。

「改善」から卒業しようと決めた

「プロセス改善」や「xx手法」といったものは、名前こそ大仰ですが、実際には高校生でもやっていることです。

  • どうやったら好きな人に喜んでもらえるか、ひとづてにリサーチしてみたり
  • どうやったらケンカした友達とまた一緒に遊べるようになるか悩んでみたり
  • どうやったら試合に勝てるか、スポーツの練習メニューを試行錯誤してみたり
  • どうやったら楽に良い点数が取れるか、効率の良いテスト勉強法を模索してみたり

そのなかで定石(問題と打ち手の組み合わせ)がパターン化されて名前が付けられるわけです。 「部署間のハレーション」と「子供同士のケンカ」の解消方法は、よく似ていると思いませんか。

結局は、目の前の出来事といかに向き合うか、が重要なのだと考えています。 付き合い始めのカップルのほうが、そこらの開発チームよりも高速にPDSサイクルを回しているとは思いませんか。

夜も眠れなくなるくらいの問題意識があれば、諦めたくない目標があれば、本気で熱中できるものがあれば、 「What」への強い関心があれば、必然的にその過程で「How」は磨かれていくでしょう。

今回に限らず、Howや改善に関するイベント・議論に対しては、以前から違和感を覚えていました。 「また同じ話か」と分類できるくらいには、私自身の見識が十分に育ったのだと解釈しています。1

ということで、なるべく「改善」という言葉は使わないようにします。 "こうやって工夫しました"(How)ではなく、"こういうことをやりました"(What)。 「おもしろいでしょ」と世の中に自慢するような、そんな動き方を大切にしたいなぁと思いました。

海からの贈物 (新潮文庫)

海からの贈物 (新潮文庫)


  1. 作業のリードタイムが短く、試行錯誤のサイクルを回しやすいソフトウェア担当者のほうが、ハードウェア担当者と比較したときに、現場発の改善活動に取り組みやすいように感じる、という某社の方の意見。つまるところ「いかに普段からPDSサイクルを回しているか」「いかに普段から自分の考えを言葉・行動に出せているか」「そういった空気を醸成できているか」だと解釈しています。

  2. この手の拡大議論は、既に1度なされているという認識でした。XPに端を発した2000年代のアジャイルブームの時の講演資料を漁ると、共通ルール化や組織内普及の事例が出てくるので。

  3. 何か新しい視点が得られたら良かったのですが。社内でtwadaさんやi2keyさんの取り組み・知見が展開されることもあり「うーん」というのが正直な感想。

  4. ここでは極めて個人的・主観的な物の見方をしています。

新入社員を現場で受け入れるプラクティス

私のところでは新入社員の受け入れ時期になりました。 思考の整理を兼ねて、過去に現場リーダーとしてやったことをまとめます。

スコープ

本稿では「新卒社員」かつ「現場での受け入れ」をスコープとします。

  • 新規参画者向けのTODOやフォロー体制は別途存在する。中途入社や異動があるので共通。
  • 会社横断でのTODOやフォロー体制は別途存在する。新人研修など。

なお「こいつは新入社員として扱かったらダメだろ」みたいな即戦力人材は対象外。

関係者の期待を確認する

関係者に期待事項をヒアリングするところから始めます。

  • 本人(変わりうるので都度確認する)
  • メンター
  • 研修時の上長・講師
  • 配属後の上長

配属意図、関心事項、伸ばしたいポイントについての認識を揃えます。 本来はメンターや上長が推進すべきですが、手が回っていないことが多いので、現場で巻き取るスタンスで。

関係者ごとに意見が異なる場合は、なるべく本人の意思を尊重します。

  • 人は「自分のやりたいことしかやらない」「自分の聞きたいことしか聞かない」ものだと割り切る。
  • 人は誰かが育てるものではなく、自ら育つものである点に注意する。
  • どんな相手であれ、ある側面では自分以上の介在価値を発揮する人材であることを念頭に置いて接する。

コテコテの新人育成メニューを押し付けるようなことは絶対にしないと決めています。 機を見て「こういう点を伸ばすと良いかもね」メッセージを織り込むくらいに留めます。

依頼する業務について

本人と話して案件を選んでもらいます。

制約条件は色々あるので配慮が必要となります。

  • 本人のケイパビリティに合致するもの
  • 推定工期が長すぎないもの
  • 緊急度は低いが重要度は高いもの
    • 緊急の仕事を押し付けるな
    • 重要でない仕事を押し付けるな → 「なぜ重要なのか」の背景を踏まえて依頼する
  • トラブルが起きること前提で、フォローできる範囲内に留める

主な方針は以下のどちらかになるはず。

  • 簡単な作業から徐々にステップアップするチュートリアルモード(人材育成の書籍や社内制度はこちらを前提としたものが多い)
  • 最初から高い目標を叩きつけるハードモード(急成長・表彰狙い)

最終的には同じところに着地するので、まぁどっちでもいいかと。

  • チュートリアルモードでもそのうち全工程を自ら推進してもらうようになる。
  • ハードモードでもやることは同じ:目的・制約の整理→作業分解→TODOリストを捌く→頻繁に軌道修正。

配属直後の登り方やコミュニケーションの取り方が若干変わるくらいですかね。 私はチュートリアルを突っぱねた派なので、同じような性格の人だと辛かろうということで方針を聞くようにしています。

「自走スキル」を身につけてもらう

一連のPDSサイクルを主体的に回すように促します。

  1. 自ら問題を見つける
  2. 自ら解決策を考える
  3. 自ら解決策を実行する
  4. 自ら実行結果をもとに振り返って次の手を打つ

自走さえできれば他のスキルは後から身につくので、この1つだけに絞ります。

スキル習得のために、ひたすら「あなたはどう思いますか?」を問い掛け続けます。

  • その上で、少しでも兆しが見えたら褒める。とにかく褒めまくる。メッセージング目的なので露骨で良い。
  • 内容の成否ではなく姿勢を評価する。成否はアンコントローラブルな部分があれど、姿勢は再現可能なので。
  • 褒めるときは、本人の前だけでなく、本人がいないところ、いろんな人が見ているところで褒める。

基本的にはミスを責めずに、サポートする方向で。

  • STEP1やSTEP2の筋が悪いのは経験や知識が足りないだけ。
  • 着手できないのはSTEP3のリードタイムが長いだけ。
  • アクションが失敗するのはSTEP4の一部。

というか自分自身も毎回スムーズにできるわけじゃないだろと自省しながら対峙する感じです。 逆に毎回スムーズなら、挑戦していないということなので、新入社員以下だという自覚を。

本人とのコミュニケーション

毎日30分の1on1を設ける → 少しずつ頻度を減らす。

  • 最初は個人タスクについて「やったこと」「よかったこと」「困っていること」を聞く。本人の抱える課題を検知する。
  • 徐々に、1on1で話した内容をチーム内にフィードバックするように促す。本人の困りごとは、本人がチーム内で相談して、チームでフォローしてもらう状態に持っていく。
  • チーム単位での動きに慣れてきたら「チームの状況」「何が1番の問題だと思うか」「どうしたらいいと思うか」を聞く。チーム内で介在価値を発揮してもらう。

注意点として「こういうところは良くなかった」の指摘は、他の人がいないところでやります。

  • 最初の方に1回だけ仕事のスタンス面について話すことがあるかないか。通過儀礼なので2度は言わないですが。
  • 去年の実例:影響範囲を考慮せず何となくのプルリク出す → 「これがそのままリリースされて顧客に届いたらどうなると思う?」
  • 軽微なミスはいちいち怒らない。ポカ避けをどう組み込むかが大事。上記の例も本来はシステムで防ぐのが望ましい。

基本方針は他メンバーとのコミュニケーションと同じで、気持ち丁寧に対応します。

関係者とのコミュニケーション

配属チームの他メンバーとも頻繁に会話します。

  • しつこいくらい何度でもフォローを依頼します。「大丈夫そうだった?」「困っていなかった?」を聞きまくる。
  • チームメンバーに対して「実は本人はこう思っているらしいよ」のフィードバックを繰り返す。特に若手メンバーは「全然気づかなかった」と返してくることが多い。
  • 新入社員を気にかけてもらうことでチームとしてフォローしやすくなる。リーダーや後輩指導の経験が少ない若手メンバー自身の成長にもつながる。逆にリーダーと新人の1対1の関係に終始すると、チームの成長機会を損ねてしまうので注意。

新入社員と仲が良いチーム外の先輩に、本人の相談相手になってもらいます。

  • チーム内のメンバーやリーダーでは引き出せない本音もあるだろうということで。同様に、男性ばかりのチームに女性が配属されたら、女性社員に声を掛けてもらう、といった観点もありますね。相性などもあるので色々配慮します。
  • 「相談相手で〜す」というより、それとなく話を聞く存在になってもらいます。内容をフィードバックするかどうかは相手の判断に任せます。私の言動を変える必要がある場合は、本人の代弁者として叱ってもらいます。
  • わざわざ依頼しなくても相談相手になっていることもあるし、余計なお世話だろ感があるが、念には念を。本人にとっては人生で初の仕事なので、最初のほうは多少お節介すぎるくらいでよかろうという思想。これが続くとうざい(というかキモい)ので、ある程度自走できるようになったら基本はノータッチ。

上長との1on1で報連相しておく。

  • 新人の担当業務と状況、私の新人に対するコミュニケーション内容について話します。
  • 進め方やコミュニケーションの取り方についての相談に乗ってもらいます。問題があれば指摘をいただきます。
  • 上長経由でコミュニケーションしたほうがいい場合などは依頼する。特に、偉い人が新入社員の仕事ぶりを直接見れない距離であれば「がんばっているらしいじゃん!いつも話を聞いているよ!」と一声掛けるだけで、心理的安全性が担保されることもあります。

連携が多い部署には挨拶しておく。

  • 受けられるサポートが多いに越したことはないので。
  • その業務で少しでも成果を出したら「配属1ヶ月でこんな成果を出せました!」的な感じで一緒に祝う → 「部署は違うけど手伝ってよかった」のポジティブサイクルに巻き込みます。

なお、リーダー(私)の観点から見て、最も大切なことは「私自身の言動が糞だったときに、新入社員が他のひとに相談して、私をぶっ刺せるルートを確保すること」だと思っています。

  • これがないと間違っていたときにフィードバックを受け取れない=改善できない。
  • 逆にこれさえ確保できていれば、多少のミスはどうにかなる。
  • 人と人の話なので正解はない → ノーミスは無理 → ミスを誰かがカバーする方向で備える。

まとめ

色々書いたけど、基本的には「なるべく自分事として受け止める」「1人で背負いこまない」というのを、丁寧に徹底しましょう、というだけの話です。 1人1人やり方は違うので正解はないかもしれませんが、最初のほうでコミュニケーションに手を抜くと、後々面倒になるのかなとは思います。

おわりに

あとあれですね、年度末の新入社員プレゼンで「このリーダーのもとで働けてよかった」的なことを言ってもらえると、結構嬉しかったりしますね。

部下育成の教科書

部下育成の教科書

XP祭りで開発高速化の話をしました #xpjug

概要

XP祭り2017に参加して「新米エンジニアがレガシーシステムを死に物狂いでグロースハックした話」というタイトルで発表しました。

イベントについて

アジャイル分野の方々が参加するイベントだそうです。 他の方々の発表は以下のページにまとまっています。

XP祭り2017

発表スライド

当日の資料は以下になります。

すでに新米ではないのですが、当時を振り返るとアジャイルプラクティスを(結果的に)適用していた!ということで、この機にケーススタディとしてまとめてみました。

CfP内容(一部抜粋)

グロースハックプロジェクトでの試行錯誤を共有します。

10年物のレガシーシステムにおいて、120の開発案件を捌き、 4ヶ月でユーザーアクション数を2.8倍にしました。

1つ1つボトルネックを愚直に解消していくことで、 気付いたらアジャイルのプラクティスが適用されている状態になりました。

http://xpjug.com/xp2017-session-a3-2/

ざっくり概要

  • ステークホルダー
    • 多様なステークホルダーからの五月雨の依頼に対して、結果的にスクラムのような開発プロセスで対応することになりました。
    • 1個流しで案件を捌き、その過程でリードタイムに影響を与える阻害要因(ボトルネック)を特定・排除することで、フロー効率の改善を図っています。
  • スキル
    • 新米状態から素早く一人前になるために、アーキテクト・プロダクトオーナー・リーダーのように振る舞いました。
    • 当然ながら上手くいかない→「何が足りないか」を把握できる→その差を埋める、を繰り返すことで、ハイスピードでスキルを向上させることができました。
  • システム
    • レガシーシステムに対して改善サイクルを回すために、まずはGit/Jenkins/SonarQubeといったツールを導入して、最低限の開発環境を整えました。
    • その上で、過剰な設計書フォーカスからソースコードフォーカスに移行したり、「よい設計」の共通認識を揃えながら徐々にシステムの複雑度を解消していきました。

ビブリオバトル

LT形式で書籍を紹介しあうコーナー。せっかくなので出てみました。

「システムは作って終わりではない」ということで、マラソンに関する科学がメタファー(あるいはアナロジー)として参考になるのではないか!と『マラソンの練習法がわかる本』をお勧めしました。

感想

  • 良い意味で変な人が多かったです。女装率が高い。LTは笑いすぎて腹が痛かった!w
  • 運営者の法被(?)が祭り感あって良いですねー。
  • 初めて来た人や遠くから来た人を優先して書籍プレゼントする、といった配慮が素敵だなぁと思いました。
  • 内容面で新しい発見は特になかったかなぁというのが正直なところです。プラクティスや原理原則はある程度固まっているように見受けられるので、パラフレーズのネタを増やすよりも、「いかにエンジニアの枠を超えたケーススタディを積むのか」が求められているのかもしれないと思いました。私が言えた話ではないのですが。

終わりに

運営者・発表者・参加者の皆様、本当にありがとうございました!

エクストリームプログラミング

エクストリームプログラミング

PyConJPでデータ分析基盤とチーム文化の話をしました #pyconjp

概要

PyCon JP 2017というカンファレンスに参加しました。 Day2の最終セッションにて「SREエンジニアがJupyter+BigQueryでデータ分析基盤をDev&Opsした話」というタイトルで発表しました。

f:id:yuzutas0:20170912194610j:plain

イベントについて

実施風景や発表内容

togetterや他の参加者のブログで良い感じにレポートされているので省略。 「こういう観点の感想もあるのかぁ」といった発見があり、読んでみると結構面白いです。

他の方の発表を聞いて

よかったです! 小学生並みの感想ですが!

  • 分析ネタ系・作ってみた系:やっぱり面白い。ニコニコ学会や自由研究に通じるものがある。こういうの大好き。
  • 足りない機能をハックする系・中身を読み解くぜ系:プログラミング言語を触るってこういうことだよなー、みたいな良さ。

あとLT聞いて思いついたんですけどPythonで実装した彼女とマッチングするWEBサービスを(略)

とまぁ、技術カンファレンスは今回が初参加で、最初はどうしたものかという感じでしたが、想像以上に楽しめました。

発表について

スライド

当日の資料は以下になります。

CfP内容(一部抜粋)

多様な部署・職種が関わる大企業において、どのような目的・用途・制約が与えられ、そのためにどのようなシステム・プロセスを採用したのか共有します。

プロダクト開発におけるデータ活用の指針・参考事例を持ち帰っていただきます。少しでも多くの開発現場がPythonという武器を手に、データを最大限に活用し、世の中に良いプロダクトを提供する助けになれたらと思っています。

https://pycon.jp/2017/ja/proposals/vote/159/

アジェンダ

  • 分析基盤をDev&Opsする
    • データ利用のユースケース
    • 分析基盤が必要となった背景
    • 設計ポリシー・技術選定
    • データフロー(収集>蓄積>加工>活用)
    • 構築プロセス
  • データ駆動文化をチームに装着する
    • Measure:効果測定と開発工程
    • Learn:顧客理解とSECIモデル

いただいたコメントなど

ありがたいことに色々とコメントをいただきました。

「タイトルだけ見てスルーしてた」

「文化の話いいね」

言われてみれば。 タイトルから中身を想像できないですね……。 どういうのが良かったんだろうなー。

「Jupyterはバッチ処理を試すのに相性が良い」

なるほど。 明文化できていませんでした。 確かにそういうことですね!

「朝の何時までにデータを疎通しなければいけない!みたいな話を伺いたい」

サービスレベルとオペレーションレベルを設計・運用しています。 詳しくは以下を参照いただければと。

yuzutas0.hatenablog.com

今回の質問であれば、バッチ処理の機能要件に該当するトピックとなりますね。 このあたりはいわゆるSREトピックとして、他のシステムと同じように運用・改善を行なっています。

SREやDev&Opsとタイトルに付けた割には、構築後の運用保守に対する言及が少なかったのはミスでした。 「それっぽいシステムを作るだけなら誰だってできるよ!大変なのはその先だろうが!」と言われたらそりゃそうだ、という感じです。

まさにGood Questionというやつですね。終了直後にわざわざ話し掛けてくださいました。

補足(蛇足?)

システム面

  • 話を聞いた人は「そこまで大したシステムではない」と思ったはずです。自分でもそう思います。ただ、大したシステムは必要ないと考えています。だからこそ簡単に書けて便利なPythonを技術選定しました。
  • 半年後には違う姿になっていると思います。システムは生き物と同じで日々変わるので。特にワークフローエンジンの運用保守については強い課題意識を持っています。むしろぜひ助言が欲しいくらいです。
  • 「大規模データだ」「他と比べて大変だ」と言うつもりはありません。たかだか数年程度の若いサービスなので。
    • 技術制約として「この規模のデータだとN/Wレイテンシがボトルネックになる」という話はしましたが。
    • 本当にヤバいやつは「みんな死ぬしかないじゃない!」状態だったりしますよね。未踏出身の先輩が20年物のシステムを数年掛けて少しずつ直すのを見て「こういう人たちには敵わないなぁ」と尊敬しております。

プロセス面

  • エンジニア向けなので「システムを直す優先順位が1番低い」と伝えました。実際にそう運用しています。ただ、ビジネスサイドには別の伝え方をすることもあるので悪しからず。「ボトルネック発生時は他作業を止めてシステムを直す」(その頻度は少なくない)という但し書きが伝わるかどうかで切り分けています。
  • 終わってから気付いたのですが、1番リードタイムを費やしたのは(着手前の)「工数確保のための根回し・調整・擦り合わせ」で、要するに社内政治でした。さらに泥臭い話になりますなぁ。そこまでやって初めて「業務」になるわけですからねぇ。
  • 改めて振り返ると「言うは易し行うは難し」だと思いました。今回の構想は、システムもプロセスも文化装着も、1時間のホワイトボードミーティングで描いた戦略がベースとなっているのですが、それを実現するのに半年以上を費やしております。

メイキング裏話

ひたすら試行錯誤

  • 100枚超えのスライドを5回丸々作り直した。
    • 伝わる構成にならなくて苦労した。
    • もともと扱うトピックが広すぎたというのはある。
  • 10回リハーサルした。あのザマでしたが。
  • 20人からフィードバックをもらって細部を修正した。
    • 例:「楽して」が「楽しい」に見えるので「ラクして」に書き直す。

準備面での振り返り

  • 【Keep】スライドが真っ白の時から毎日リハーサルしてフィードバックをもらい続けたこと。
  • 【Problem】スライドに全部書き出してから余計な箇所を削る方式で始めたこと。これは無理があった。物量が多いので修正がキツい。単純にバッチサイズの問題。
  • 【Try】結局は「30秒だったら何を話す?」から考え直して今の構成にした。「じゃあ1分だったら?」「3分だったら?」と広げていった。最初からこのやり方を採用すべきだった。

当日の反省など

反省点多し。マイクに声が入っていない、時間はオーバーする、余計なことを言うの三拍子。 そんな中で最後までお付き合いくださった方々、声を掛けてくださった方々には感謝の気持ちでいっぱいです。

最後に

ベストトークアワードで優秀賞という栄えある評価をいただけました。 私自身の拙い発表というよりは、チームの仕事が認めてもらえたのだと解釈しています。

何はともあれ、運営者・発表者・参加者の皆様、本当にありがとうございました!

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

スクラム開発チーム立ち上げの失敗談を話しました #GWD_Nulab

概要

Nulab様が主催する Geeks Who Drink in Tokyo - Agile Team という勉強会に参加しました。 なるべく具体的なケーススタディ(特に失敗談)を共有したかったので「スクラム開発チームの立ち上げでアンチパターンを踏みまくった話」という発表をしました。

イベントの様子

イベント風景や発表内容は、以下のブログでレポートされています。

モブプログラミング?アジャイル?自分たちに最適な開発手法を本気で考えてみた「Geeks Who Drink Agile Team Edition」をレポート! | ヌーラボ

会場の合いの手スキルがやたら高くて面白かったです。

発表資料

当日のスライドは以下になります。

PEXELSにラグビーの画像がなく、アメフトでごまかしたことについては、深く反省しております。

内容

かいつまんで説明します。 詳しくはスライドを見てもらえると嬉しいです。

この話の位置付け

  • とあるスクラムチームの立ち上げでアンチパターンを踏みまくった話を共有します!
  • 反省を活かして、それ以降のチーム立ち上げ時には、比較的スムーズに話を進められるようになりました!
  • 「失敗談」と「こうすべきだった」を共有することで、同じように困っている方のヒントになれたらと思います!

アジェンダ

  • チーム立ち上げの背景:モバイルアプリ開発チームを立ち上げました!
  • アンチパターン
    1. 改善とビジョン:目指すゴールの共通認識(=Good/Badの基準)がないと改善のやりようがありません!
    2. 課題とフォーカス:解決したい課題を明確にせずに「アジャイルっぽいやり方」をやろうとしても本末転倒です!
    3. 出荷とロール:下手に役割分担するのではなく、全員が優先順位の通りに行動することで、ボトルネックが可視化されます!
    4. 作業とストリーム:1つのチームで1つのプロダクトの1つのゴールに向かって作業しないと、綻びが生じてしまいます!
  • スクラム開発:「What」と「How」を見直す → 継続的な「課題発見」と「課題解決」による進化を支えるフレームワークだと解釈しています!

スライドの一部抜粋

f:id:yuzutas0:20170902200832j:plain

f:id:yuzutas0:20170902200848j:plain

f:id:yuzutas0:20170902200905j:plain

f:id:yuzutas0:20170902200919j:plain

f:id:yuzutas0:20170902200931j:plain

補足

誤解が生じないように補足すると「これがスクラムだ」と断言したり押し付ける意図はありません。 正直なところアジャイルスクラムという言葉を使う必要さえないと思っています。

あくまで位置づけとしては

  • ビジネス価値の最大化が目的である
  • その過程でチームビルディングが必要となる
  • 開発プロセスフレームワークとしてスクラムを採用する
  • 運営の過程で何かしらの問題は起きる(コンテキストによって違いはある → とはいえ類型もある)
  • なのでアンチパターンや失敗談を起点にして知識を整理した

という感じです。

ケーススタディとして含めなかった話

なぜスクラムを採用するのか

中長期のプロジェクト型開発(ウォーターフォール)は必要悪だと思っています。

  • 事前に定めたQCDS目標を達成するために、学習頻度を犠牲にしがちだからです。
  • 半年間のプロジェクトなら、半年もフィードバックを得られない(仮に得ても活かせない)ことになります。

可能な限りイテレーションを回せるプロセス設計が望ましいです。 そうなると、何らかのアジャイルプラクティスを(結果的にであれ意図的にであれ)適用することになるでしょう。

特にスクラムは型が明確で「最初にこれをやりましょう」の会話がしやすいです。 それゆえに意図の解釈や議論があちこちで起きてしまいがちなので、ビジョンの補完やフォーカスの徹底、ロールやストリームの考え方を装着することが必要になります。

また、スクラムデファクトスタンダードゆえの恩恵をもたらしてくれます。 困った時に参照できるリファレンスや知見が世の中に溢れているのです。 新規参画メンバーに話を通しやすい、別の場所に移っても学びを活かせる、といった利点もあります。

チーム立ち上げ時に使う資料

ホワイトボード

下の図を描きながら、スクラムとは「What」「How」の「問題発見」「問題解決」を繰り返すフレームワークだと伝えます。

f:id:yuzutas0:20170902200950j:plain

参考図書

最初に読んでもらう → 必要に応じて輪読会をします。

URL

いちおうチームに共有しておく → 結局自分で見ることが多いですが。

  • Scrum Guide:邪道ですが「スクラムガイドには書いてないので、自分たちでやりやすい方法でやってみたらどうかな!」と言うために参照することがしばしばあります。
  • Ryuzee.com:困ったときによく見ます。

アジャイル博士になることがチームの目的ではないので、提供する情報量は最小限に絞ります。 なるべく余計なことを考えずに、目の前の問題に集中してもらうことが大事だと繰り返します。

感想

自発的に継続進化できるチームの構築は、基本であり奥義でもあると改めて思いました。 顧客価値にコミットできる良いチームを作っていきたいです。

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

社内政治をリーンにやろうぜという話をしました

概要

某社の社内勉強会にて「エスカレを支える技術 - アジャイル報連相と情報流通」という発表をしました。 炎上現場を生き抜いた権謀術数(というか土下座テクニック)を共有しました。

スライド

ざっくり内容

「既存の業務フロー」と「ステークホルダーコミュニケーション」を無駄なく結びつけようぜ、という話です。

  • 偉い人に働きかけることで、必要な資源をスムーズに得ることができるぞ!
  • 報連相をより効果的にするには、リーン(トヨタ方式)が参考になるぞ!
  • 今回は「チャット」「レトロスペクティブ」「人事評価シート」「ちょっとした雑談」を利用したぞ!

1営業日あたり2件の障害が発生した中で編み出した技法たちになります。

チャット

ノイズを減らす&気軽に投稿する、を両立するために無駄を削減する。

  • 上位レイヤの前にまずは現場チームで課題意識の共有・解決を試みる。
    • #dev_times チャンネル:技術・仕様面でのハマリどころ。
    • #kpt チャンネル:チーム運営でのちょっとしたご相談。
  • 上位メンバとの1on1で話すことは事前に #times_{myname} チャンネルに投稿する。
    • 現場メンバから「これも忘れずに会話してくれ」リマインドが来たり。
    • 上位メンバが事前に目を通してスムーズに会話できる。

レトロスペクティブ(振り返り)

いろんな会議で同じ話をするのは無駄なので、情報流通フローを整理する。

  • メンバーは思い立ったタイミングで#kptチャンネルに上げる。
  • チームの振り返り会で#kptを見ながら大事なものをチョイス。
    • チーム内で解決できるならTryに繋げる。
    • チーム内で解決できないものは分ける。
  • マネジメント会議で、KPTのサマリーを上位層に伝える。、
    • チーム内で解決できない課題を受け渡す。

人事評価シート

目先の課題とは別に、攻めるための目標・進捗を管理して、なおかつ担当者は取り替え可能な状態にする。

  • 前提:人事評価シートの目標設定(xxxまでにxxxを達成するのだ!)をもとに、人事面談で攻めの目標についての認識合わせがなされる。
  • 課題:マネージャーとメンバーたちの1対nの関係になりがち → 各メンバーが受け持っている目標が開示されない → チームで進捗確認できない → 報連相が個人に任されて漏れが生じる → 色々こじれがち。
  • 打ち手:メンバー全員に同じ目標を設定する → 各目標の進捗管理を週次ミーティングで実施する → 進捗を妨げる問題があればチームとして検知 → ミーティング同席の上位陣にそのままご相談。

ちょっとした雑談

毎日の終業時刻に偉い人を10分弱ほど捕まえて、小さなバッチサイズで報連相を行う。

  • 「もうダメっすねぇ」→「xxxに困っているんですよ」→「xxxがあれば助かるのになぁ(チラッ」
  • 相談の中で課題が整理される。
  • 必要であればサポートを受ける。

名付けてデイリーエスカレ。

言いたかったこと

エッセンスとしては、「開発・運用の現場」から自然と「経営層」に情報を流せるように仕組みを作りましょう、ということを伝えたいです。

でないと、ある日突然偉い人から「xxはどうなっているのか」と言われて、現場は「な、なんだってーーー!」と混乱したり、ある日突然現場が「xxで困っています」と伝えて、偉い人は「な、なんだってーーー!」と混乱したり、とにかく碌なことにならないです。

しかるべき情報共有をするだけで、あっという間に解決できるような問題は山ほどあります。 だったら、わざわざ未解決のまま放置する理由もないでしょう。

情報の「流し方」の話になるので、滝(ウォーターフォール)のように一気にドバーッと流すよりも、無駄なく(リーンに)流した方がよかろう、という話です。

当たり前だけど難しいこと

悪い言い方をすると、ただの社内政治(の第一歩)にすぎません。 お粗末な言い方をすると「報連相をしっかりやりましょう」という話です。 また、制度・文化・コンテキストに強く依存するので、プラクティスは組織によって変わるはずです。

ただ、このあたり、ビジネスとシステムを繋ぐ立場の人なら、似たような問題意識を持っているのではないかと思っています。CTO、技術マネージャー、開発リーダー、プロジェクトマネージャーなど、呼び方は多々あれど。

特に、組織がスケールして三階層を超えたら、確実にこの手の問題が浮上します。トップがメンバー全員ときめ細やかにコミュニケーションできなくなるので、情報流通をきちんと設計しないと阿鼻叫喚です。

各プラクティスの考案タイミング

上記の取り組みは、最初からスマートに仕組み化できていたわけではありません。 あとから俯瞰したらこうなっていた、というだけです。 仮に、最初からやろうとしても、関係者には必要性が伝わらず、浸透しないと思います。

実際には、目の前の課題をチームで1つ1つ取り除いていただけです。 チーム内では解決できない問題も山ほどあるので、必然的に上位レイヤーに働きかけて、間接的に解決することになりました。 その中で、プロセスに無駄があれば地道に取り除いていき、結果的にこれらのプラクティスに辿り着きました。

大事なのは、可視化(透明性)を担保した上で、課題発見(検査)と課題解決(適応)を繰り返すことだと思っています。 結局はDevOpsというかスクラムというかアジャイルというかリーン的な話に繋がるのかなと。

あえて言わなかったこと

あまりLT受けする話ではなかった(というか完全に社畜養成講座になりそうだった)ので、あえて言わなかったのが後工程の話です。

階層化された大規模組織だと、エスカレ後に「ポケットの内側」と「ポケットの外側」で、次の行動が変わると解釈しています。

追加予算の獲得や他部署の協力が必要な場合だと、ステークホルダーを説得する必要があるのです。 説得ストーリーを描き、エビデンスを集めて、軽くジャブを打って反応を見て、といった営業チックな活動になります。 ここは現場と偉い人が力を合わせると比較的スムーズに進むはずです。

ただ、最初から細かい数字やエビデンスまで抑える必要はないかなと思っています。 確保済みの予算など「ポケットの内側」で済む場合は、それこそ臨機応変差配するためのポケットだと思うので、規模感だけ把握すれば問題ないはずです。

なお、組織の状況がどうなっているのか(特に予算と人員)を把握しておくと、何かとスムーズなのかなとは思います。 これも順番があって、こまめな報連相・サポート需給を通して上位レイヤーと信頼関係を構築することで、そのうち情報が開示される機会が巡ってくる、というのが妥当でしょうか。

まとめ

顧客への価値提供を主要な企業活動と捉えると、こうした社内の情報流通は本質的な部分ではありません。 だからこそ、無駄なく話を片付けるために、型化が大事なのかなと思っています。 過剰にこだわってしまうようだと本末転倒ですが、完全無視はもったいないです。

上手いことやっていきましょう。

リーン開発の本質

リーン開発の本質