00:08
どうもどうも。
え、何それ?
そういう張り方。
なんか漫才っぽかったけど。
いや、いるでしょ、こういうの。重要でしょ。
で、今日は何話します?
いや、今日ね、あのー
全英オープンやってんすけど
テニスコリー
テニスコリー対フェデラー戦
っていうなんか結構
面白そうなカードがあるので
早く終わらせて帰りたい。
まあ確かにね。
俺は初戦で負けちゃいましたもんね。
そうなんすよ。
ちょっとね、最近調子悪いっすね、みたいな。
これ以上広がるかな、これ。
広がんないからね。
よし。
で、
こんな感じでしょ?
こんな感じなんだっけ?
こんな感じなんだっけ?
えっと、今日は
今日は須貝さんが
走ってたらやりますけど
はい。
はい。
これポッドガスの目って今回初めてじゃないですか?
決まったのに。
前回決まってなかったからね。
え、なんて名前?
これはもうもちろん、皆さんご存知
やる気ないAFMですよね。
なんでちょっと自信なさそうなの?
いやいや、自信はありますよね。
自信しかない。
いやなんか結構あれっすよね、こう
万情一致で決まったよね。
そうね。
終わって聞き返してみて
なんだこのやる気のなさ。
愕然としたよね、あれ。
いやいや、これしかできなかった。
結構頑張ったんだから。
やる気ない感じしかできなかったっていうところじゃない?
やっぱり、結局。
はい。
第2回のやる気のなさ。
やっていきましょう。
なんとかペイ
なんとかペイ使ってます?
私は全然バリバリ使ってますね。
セブンペイ?
だから、
セブンペイアカウント作れなかったんですよ。
乗り遅れちゃった。
私はLINEペイユーザーで
あ、そうなの?
LINEペイレジで。
LINEペイ何がいいんすか?
使いやすい?
でもLINEペイ
店舗でも使えて、かつ
一応個人換送機もできますよね。
あ、そうなんですね。
そこがいい。
でも、やめましたね。
やめちゃったんだ。
今は何ペイなの?
アリペイ?
アリペイも使ってないです。
どうやって買い物してるんですか?
クレジットです。
普通にカード?
昔現金だったよね?
その話しますよ。
昔、
衝撃だったんですけど
MacBookだっけ?
MacBook Airですね。
一回の帰りに
MacBook Air買うか!
03:00
買うわ!
新宿の淀橋行って
その前にATMで現金下ろして
レジで
パチン!
全然普通に置いただけなんすよ。
めちゃくちゃな力んですね。
あの頃から変わってないっすよね。
大物感みたいな。
さすがですね。
そんなんはいいっすよ。
菅井さんは使ってんすか?
クレカですね。
クレカみたいなものですよね。
裏側クレカなんで。
どこでも使えますよね。
だいたい
イオン行くとクイックペイ使えるんで
最強っすね。
僕は前
ペイペイポイント還元
レイズオフとか
ビッグカメラの
それでまだ
8000ポイントくらいあるね。
マジっすか?
やっぱりスイカとIDがあれば
なんとかペイ
なんとかペイ
ペイペイのポイント
使い終わったら
一旦お休みみたいな。
なんかあれっすよね。
なんとかペイ乱立してるし。
なんなんすかね。
やっぱりシステム開発の会社が
各社に営業を
かけてるから
あんな乱立するんすかね。
今ならこんだけお安くなって
こんなメリットがありますよね。
どうなんすかね。
それ本当にそうだとしたら
その慣れの果てが
セブンペイみたいな。
慣れの果てがそうなりますね。
後発でペペって
どうしてこうなったみたいな。
でもだって
そもそもコンビニって
IDとかクレカ使えるから
なんで自社でシステム組むの
いまいちわからない。
7個あるよね。
そうなんすよね。
僕セブンイレブン大好き人間なんで
7個使いまくってたんすけど
ポイントが
100円で1ポイントか
200円で1ポイント
だからもうスイカに
浮気しちゃいました。
結局スイカみたいな。
セブンペイ反する?
したい?
一番したいんじゃないすか。
でもなんか。
手役がついてる。
今回の件で
いろんな切り口でみんながしゃべるじゃないですか。
楽天の三木谷さんも
食い込んでたし
技術的な部分でもあるし
日本企業の
体制的な部分で
上司ストーンみたいな部分に行って
みんなが
使ってるもんだから
余計そんな事件が大きくなった
っていう。
三木谷さんって何言ってたんすか。
決済系で
二段階認証やらないのは
言えない的な。
二段階認証ね。
知ってる?
二段階認証知ってる。
皆さん二段階認証使ってる?
06:01
出来るサービスなら
可能な限り使ってますね。
意識高いですね。
出来る限り。
僕はもうめんどくせーって
普通にメールアドレスとパスワード
組み合わせで
そこまで強制されないんですかね。
今は選択肢がある。
それをずっとやってる感じで。
なんかGitHubとかも
二段階認証とかあるじゃないですか。
二要素認証。
やってないとやってないみたいなの
出るじゃん。GitHubもやってない。
そうだねって。
そうだねって。
堅くなに避けてんのなんなんすか。
なんすかね。
セキュリティを高める
イコールめんどくさい
っていうのが自分の中にあるから
やりたくない。
わからんくもない。
二段階認証は本当に
やばそうなサービスは
使ってますね。
あとはAWSとか
会社のやつは
二段階認証はしてる。
そういえばこのマイク買った時に
クレジットカードで決済したんですけど
動きが
ちょっと怪しかったっていうか
サウンドハウス
言っちゃうよ。
なんか
入力欄に
誕生日とか入れないといけなくて
そんなのありましたね。
あったあったあった。
最初会社のカードで
通そうとしたら
会社のカードに誕生日も
何も入れてないから
認証通らなくて
それで個人のカードで
決済したんですけど
そうやってですね
情報を求められたの。
で、なんかちょっと
動きも雑貫
って感じ。
経由してる感じ。
多分
本当はちゃんとしてると思うんですけど
なんとなく
パスワードとかを
そのままデータベースに
格納してそうな雰囲気を
感じた。
完全に僕の妄想なんで
事実無根なんで
あれなんですけど
そういう
ちょっとユーザーを不安にさせる
インターフェースでした。
でもなんか
俺PayPalで買っちゃったのかな。
PayPal使えたから
PayPal使って買っちゃいましたね。
でもPayPalも
日本は二段階認証ないんですよ。
アメリカのサービスは
アメリカのPayPalはあれらしいんですけど。
日本のPayPalは
二段階認証が無くて
ちょっと使うのヒヤヒヤしますね。
一応使ってますけど。
これまた前回の
WWDCの時と同じような
前半ぐらいの
前半ぐらいの
前半だいたいグダグダになってますね。
でもまあ
言えるのはなんかSI的な感じで
話
ううってなる
企業だったなっていうのと
日本代表する
09:01
通りの企業なのに
こんな感じなのか
ガッカリ感があるっていう
まあ
一時企業がヘマこいちゃう
部分に関しては正直僕は
何も言わないんですけど
正直こう
日本の文化というか
って言うと語弊があるかもしれないですけど
連帯責任になっちゃうんですよ。
結局他の何々Payとか
にも影響が出て
お国から指令が出たりとか
セキュリティ強固にしろとかみたいな
なんか一人がヘマこいちゃったから
みんな連帯責任で
何かしなくちゃいけないという状況が
多分今後起きる
そこだけは結構辛そうだな
っていう感じはあります。
誰かがヘマこいちゃうと
お国から指令が出たりするので
ああいうサービスはやっぱり
辛いなって
前だから仮想通貨の時とかもそんな感じでしたよね
そうですね
仮想通貨の時も同じような流れでしたね
はい
次行きますか
今日本当はチームの悩み相談
開発の悩み相談
みたいな話やろうとしたんですけど
この間僕
一級.comの会社説明会
行ってきて
伊藤直哉さんが
出てきて直接
話すっていうのがあったので
行ってきたんですよ
会社説明会って旧人的な感じ?
もう完全そうですね
エンジニア向けの
会社説明会みたいな
やってて
僕は転職する気はそんなにないんですけど
別に
そういう人じゃなくても
来ていいよみたいな感じだったんで
エンジニアであれば
ウェブ系のエンジニアであれば
ウェルカムだみたいな
そうですそうです
そこで久しぶりに
直哉伊藤の話を
直接聞いて
僕は大好きなんで
伊藤直哉さんの会をよく行ってたんですけど
感動しましたね
帰ってきたっていう
気持ちがすごいありましたね
ちょうどなんか
ポジションとかも
自分が終わってきて
伊藤直哉さんの言ってることがさらに
染みる的な感じだった
僕がですか?
別にマネジメントとか
そっち側の人じゃなくても
聞いて響くものが
あったんじゃないかなって思いますけどね
事前にここにいる人たちには
メモを共有したんですけど
マクさん読んだ?
ざっくり
響いたのは
一級はあくまで事業の会社だと
ホテル予約事業とか
レストラン事業の会社であって
ソフトウェアの開発じゃないよって
そこをすごい強調してて
なので
そこまでビジネスがメインだ
開発はそのビジネスを
止めないというか
そこのビジネス的なロードマップを
引っ張らないっていうのが
大事だよ
12:01
確かに
この話って前から
言ってたのかな
言い方違うけど
目的を手段化しない
逆か
手段を目的に
話と似てるのか
前から言ってたことと
変わってないんですけど
2年経って忘れてたんで
久しぶりに聞けてよかった
ついついこういうのって
テクニックなことや
技術的なことにばっかりフォーカスしちゃうけど
本当は何やりたいんだっけっていうのは
確かに時々思い出さないと
いけない
あとは
相変わらずイシューから始めようという話をして
大事ですよね
また読もうかな
前のリビルド聞いて
俺もいい兄貴問題について考えよう
いい兄貴問題
いい兄貴問題
スターバント型
リード型
確かにね
僕は逆にあんまり
スタートアップにいることが長いんで
やっぱ授業をメインとした
考え方に親しみがあるんで
割と見てみて
なるほど同じこと言ってるなって感じ
確かにそうじゃない
特にところにいるエンジニアとかは
やっぱ技術に
フォーカスしちゃう人っていうのは
やっぱ多方いると思うんで
そこに対して
そういう人たちに対してああいう話っていうのは
割と響くものがあるんじゃないかなっていう感じはしますね
はい
そうですね
こんな感じ
そのまま採用面接進んだり
全然そこまではなかったです
どのくらいのキャパ
でも50人とか
分かんないですけど
あんまちゃんと数えてないんですけど
儲かってるんですかね
多分儲かってると思います
途中で確かヤフーでしたっけ
かどっかに買われて
そこから先の業績
多分オープンになってないと思うんですけど
そうですね
多分官報とか見れば
利益がいくら出てるとかは
多分情報としては出てると思うんですけど
決算とかは細かい情報が出てない
なんか具体的な数字は
教えてはくれなかったんですけど
止まりたいっていう
何かがないと
移行しないような気がして
そのきっかけが何なんだろうっていうか
どっからお客さんを
呼び込んでるんですかね
普通に検索とか
でも流入はそうかもしれないですね
SEOの話とかもしてたんで
でも今
Googleから予約とかできるじゃないですか
はい
あれはどうなんですかね
他の同業他社というか
同じサービスをやってる人たちからしたら
おいおいおいおい
勘弁してくれよって感じなんだよね
そうですね
どの業界にも限らず
昔からあるじゃないですか
Googleが参入したらどうするんだみたいな話
飲食店とか地図が
検索の最初のところに
3件くらい表示されて
そこからの流入がすごいことになって
15:01
へー
そこの検索に
マップの検索に
引っかかるように
最適化するっていうのがあります
あー
Googleの規約違反で
例えば
店名に飲み放題
入れる
そういうことをやってる
店が
そういう業者
コンサル的な業者がいて
どういうアドバイスをして
お客さんを呼び込むみたいなことを
やってます
でも確かにここ最近
例えば前とかだと
食べログとかレッティを見ることが多かったんですけど
ここ最近やっぱお店
選ぶときほぼほぼGoogleマップ
を見て決めてるんで
そういう意味だとだいぶ
シフトした人はいるんじゃないかなって感じ
うん
なんか今現在地から
お店を見つけたいとか
行き先を見つけたいってなると
まず地図ありきじゃない
地図のところで
お店も調べられるってなると
もうそれが一番最短ルート
食べログとかレッティ開かなくなりました
確かに
僕不動産のサービスやってるんで
Googleとかやってきたらどうしよっかなって
不動産なんです
そうそうそう
不動産がかなり
いろんなサービスの中で
結果しづらいって言われてますよね
そうらしいですね
でもFAXがバンバン
第一線で飛び交うような業界いたら
そうらしいですね
僕はそんなあんまり言えないですけど
いろいろ
言えないことが多いんですけど
そういうこと聞きますね
だからその情報を
持ってる人
まだその人に情報が
集約されてるというか
人ありきな業界
あんまりその
物件の流動性は
高くないし
相場もあってないようなもの
相場も一応ありますけど
そこまでコンピューターで
ポンポンと弾き出して
買いますっていう市場
ではないのかな
そうですね
ただ僕のサービスに近すぎる話なんで
次行きましょうか
話本筋戻して
今回チームの悩みとか
開発の悩み相談っていう
テーマでやろうってことなんで
その辺のことやっていこうかなと思ってて
事前にいろいろ質問見ながら
質問というか相談悩んでること
みたいなの出してもらったんですけど
この間スラックとかでも話したんですけど
岡野さんの
複数の開発チームのタスクや
状況っていう
そこから行ってみますか
いきなりハードなやつから
だいたいハードだと思うんですけど
一番これがソフトな
気がする
会社で開発チームは
タスク管理
今そもそもうちのノートっていう
サービスの開発体制って
今1か2か3かって
18:01
チームが分かれてまして
それ以外にもMLとか
アプリのチームがあるんですけど
基本のメインで走っている
ノートのウェブサービスの方の
チームが1か2か
3かっていうのがあって
それぞれのタスク管理は
割とそれぞれのチームごととか
その中のさらにプロジェクトごと
とかに割と
任せていて
例えばうちで採用しているのと
トレロとGitHub Issueと
ZenHub
GitHubのプラグイン
GitHubにプラグインみたいなのをかませた
ZenHubっていうのと
あとは何を使っているかな
それぐらいか
基本的には2つか3つぐらいで
管理していて
ただ他にうちの会社と
ディレクターっていう職種があったりとか
あとはバックオフィス系のチームがあったりとか
あとはカスタムサポートのチームが
あったりして
割とそれぞれのチームでいろんな
部署をまたいだりとか
しているときに
それぞれが別々のツールを使っていると
今後結構辛いんじゃないかなっていう話をして
かつそれぞれが何の仕事を
しているのかわからないとか
今バックオフィス系だと
Romeとかは1人なんですけど
例えばこれが2,3人になったときに
どうやってタスク管理するのか
あんまりマネージャー層がないんで
各部署に
マネージャー層がついたときに
マネージャーはどうやって個々のタスクの
可視化をするかとか
っていう課題がいくつかあるかなと思っていて
ここに対して
どうアプローチしていこうかな
っていうのを今
Zackバランに話しているっていうか
考えているっていう際に
何かいい作ねえかなと思って
スラックでゴジョゴジョ相談している
あとはプロジェクトによっては
各部署がまたいたりするんですよね
例えば会計の話であれば
エンジニアと
会計の
バックオフィス系の人たちが
入ってくるとかもあるんで
それぞれのプロジェクトにアサインされるごとに
エンジニアのない人が
それぞれのツールを使う
このプロジェクトはトレロです
このプロジェクトは全ハブです
ってなるとツールを覚えるのが大変
プロジェクト行ったり来たりするときに
プロジェクトのためのツールを覚えるのが
大変で
統一したツールとして
ジラみたいなのを導入しようかな
って話をしてるんですけど
どうしようかなっていう感じですね
これでも僕は
最近ジラしか使ってないんで
ジラでいいんじゃないかな
ただ
ジラでいいんじゃないかなっていう雰囲気は
ありつつも
ツールの選択肢として比較対象は欲しいんですよね
候補は欲しいんですよね
一択だけっていうのは
結構辛くて
でもジラ以外だと
何があるんですかね
あんまり思いつかない
チケット切る系のやつですか
チケット切る系のやつですか
そうです
マークさんのところは何使ってるんですか
うちはGitHub Issueを使っているところと
ビズサイドは
21:01
いろいろで
トレロ使ってたり
アサナ使ってたりしてますけど
全社的に
これっていうのはないってことですか
そうなんですよね
チームごとに使いたいものをやるみたいな
じゃあそれって
横断的なやつだと
どうしてるんですか
横断的なのは知らない
多分トレロじゃない
横断的なんだと
トレロに追いつくような気もしなくもない
やっぱなんかね
みんなトレロのUIが好きなのか
ボコボコ入れて
すごい分かりやすいじゃない
溜まってるみたいな
担当もきちっと作れるし
無駄な機能がないし
確かに
トレロは確かに
エンジニアがない人にも
使いやすいというか
僕
奥さん出産するときに
トレロでタスク管理やってましたね
奥さんに対しては
トレロぐらいがちょうどいい
いきなりだってそれで
奥さんにジラ使ってくれって
言えなくない
ジラは辛い
有料じゃないしかも
個人で使うもんじゃない
そうだよね
今やってるプロジェクトとか
カスマサポートのチームと一緒にやってるんですけど
そのうちのカスマサポートチームの
人たちは
逆にトレロが使いにくいって言って
全ハブを使ってますね
トレロが使いにくいって何でなんすか
分かんないです
全ハブの方がよくて
あとプロジェクトが
今やってるプロジェクトの中でも
複数
さらに大きい試作のラインが
3つぐらいあるんで
それをエピックを作ってフィルダリングしたりとか
っていうので考えると
割と全ハブの方が使いやすかった
なるほど
マイルストーンは結構大事で
今週
来週マイルストーンだけで
ちゃんと絞れるとか
あんまりトレロだとできるんですけど
トレロだとあんまり
そういうこと使い方しない
ライトな使い方だったら
トレロの方がハマるし
もうちょっと複雑なことを
しようとしたらそれじゃやりにくいというか
もうちょっと
高機能というか
の方がいいんですかね
ちなみにジラって
どういう感じで使ってます?
タスクボードとかできると思うんですけど
ああいうのって使ってやってます?
うちでもそこまで
ちゃんと使えてなくて
基本的に僕はチケット切って
あとバックログで見てるみたいな
スイムレーンとか使ってなくて
いわゆる看板みたいなやつ
本当は使いたいんですけどね
割と看板的に
使っているプロジェクトがやっぱあるんで
全ハブを
なんでジラにした時も
それと同じようなものは伝えたいかな
って考えていて
他ジラじゃなくてもいいんですけど
でもなんかジラの
英語のサイト見た時に
アジャイルっていう単語がすでにあって
24:01
だいぶそっちに寄ったんだな
っていう感じが
そうですね
だからアジャイルの失踪みたいな
体現したツールみたいな感じが
結構ありますよね
ジラって
話を戻すとジラとの
比較対象というか
もうちょっと他の
検討するツールみたいなの欲しい
欲しいですね
タスク管理とかどうだったんですか
僕のところは
前者的にバックログ
ですね
それプラス
個人の
スプレッドシートで
看板みたいに
スプレッドシートで看板
そうですね
だから
マイルストーンとか
設定せずに
長くてもひとつ
終わるような案件が
おってなので
バックログでチケットを立てて
そこで
エンジニアとか
ディレクターの人とかがやり取りします
そのチケットを
僕が今抱えてるよ
っていうのをスプレッドシートにペタペタ
マネージャーは
その個人のスプレッドシートを
リンク一覧
持ってる
スプレッドシートのシートに
コーダーとかエンジニア
みたいなのが
その人が抱えてる
案件を
個人がペタペタペタペタ
コッペしていくっていう
なるほどね
割と
クラシックな
古き良き感じ
そうですね
その方が割と柔軟に
やれるし
新しく入ったメンバー
でもそんなに
学習コストなく始められるので
あと今いる
僕が今いるところは
そんなにエンジニアの会社じゃないので
ITリテラシーが
高くない人もいたりするわけです
はい
なのでそういう人が使える
っていうことを考えると
スプレッドシートっていうのは
そこまで実は
悪くない
どうですかスプレッドシート
ちょっと厳しいですね
あとは単純に
大げさなことを言うと
例えば今組織はだいたい50人ぐらいですけど
この先
規模100人200人とか
例えば500人1000人になった時にも
なんとなくでもいいから
耐えられるツールが欲しくて
そうなってくると
やっぱかなりツールが絞られるというか
そういう規模で使っている
ものって時代以外に
あまり聞かないな
っていう感じもあったりして
確かに
対抗馬がパッと思いつかない
サービスの一つですか
例えば
リポジトリだったら
GitHubか
BitBucketか
27:01
GitLabかありますけど
管理ってジラと
それに類するぐらいのものが
あんま思いつかないですけど
あとは1000人規模で
そもそも統一したツールを使っていない
っていう可能性の方が高い
なるほどね
そこを難易ポイントで
本当にツール一本化できるかっていうと
それは正直無理だと思ってるんですよ
ツールのせいで
みんなの精査成果が下がっても仕方ないんで
ある程度
ジラにまとまりつつも
個々のプロジェクトとかチームごとに
全ハブ使ったりとかトレードがあったりっていうのは
正直最悪良くて
ただシンクできる状態だと
ありがたいっていうのはあって
って考えると
例えばトレードと連携するとか
GitHubと連携するって考えると
ジラだったらできるんじゃないかな
とかも考えたりして
ていうので色々悩んでいる
最中
じゃあジラで
じゃあジラで
ってなっちゃうんですよね
うちもジラが一応全社的に導入している
ツールではあるんですけど
うちだと
営業の人はトレード使ったりとか
してるらしいんで
それで回ってるんで良いのかなって気がしますけどね
そんなに強制してもね
多分タスク管理ツールって
理想のものって
出ないと思うんですよ
なので最終的には内製化
じゃないかなっていう気がします
それつまりスプレッドシートってことですね
スプレッドシートは
内製化ってことなんですけど
色んなサービスを
色んな部署が
使ってるとしたら
各サービスの
API使って
それをアプリケーションを作るとか
良いと思う
色んなサービスを
横断的に視覚化できる
ツールとかがあると
良いのかなっていう気がします
それなんかアップスクリプト書いて
スプレッドシートで
あれね
10件20件とかだったら
良いんですけど10件超えると
ダメですね
やっぱり無料のサービスなんで
すごく重いし
実行途中に
落ちたら
エラー出ずに
しれっと最後の結果だけ返す
謎の仕様なので
本格的なものを作るのは
Google
アップスクリプトはお勧めできない
じゃあ岡野さん
これ悩み解決できた?
僕たちはこんな
ぬるい回答で
解決
そのうち解決するかもしれないんで
今後に来たいと
導入したら教えてください
結局これにしたかったよね
ジラって何が良いんですか
ジラが何が良い
何でもできるとこです
高機能すぎてちょっと
使いこなせる感はあんまないですけどね
何かしようと思うと
何とかなるっていう
確かにホームページ見ると
30:01
いろんなのあるんですよね
ジラコアとか
JQLみたいな
あるよね
ジラのチケット服を
探すためのクエリみたいな
独自のやつが
結構大きい会社だと思う
JQL職人みたいのが
いたりするんですよね
なんか聞いたの
使ったことない
じゃあ今度個人で契約してもらってね
家族で
家買うときとかに
一大プロジェクト
次行くか
次マークさんの
順番なんです
なるほど
私の悩みっていうのは
多分いろんなプロジェクトで
開発フローっていろいろ
持ってるじゃないですか
チームリーダーによって
今ってもうアジャイル一択みたいな感じで
やってるけど
アジャイルをやってるところって
あんま見ないのかな
アジャイルって
新規に作るとか
一番01で
やるときって向いてないのかな
とか保守メンテフェーズで
ちゃんとやるの
はいいのかなと思う
どうなんですか
スケジュールとかって
例えば
ここの機能を
何日までに取ろうみたいな
営業サイト
ここまでにWBSじゃない
ワークフローっていうか
ガンドチャードが
欲しくなったりするじゃないですか
アジャイルってそういうのって
ちゃんとやったことある
スプリントで2週間ベースで回すっていう
ぐるぐる回すっていうイメージしかないから
やれるところまで
しかやらないみたいな
2週間でできるところまでしかやらない
っていう感じで見積もりで
作ってて
冷凍してこうみたいな
そうなのかな
新規に作る場合って
これはここまでなきゃいけない
みたいなのがある
例えば
ちょっと抽象的なんだよ
例えば決済機能とかを
つけたいって
2週間後までは
この画面しかできてませんだと
営業の人が怒るみたいな
そんな感じです
見た目もできてないし裏側の仕組みも
できてない
それはアジャイルと関係ないんだけど
この機能とこの機能とこの機能は
ここまでにできてないといけない
みたいな
それ
2ヶ月後には
これしかできないとダメって
それをブレイク
ダウンしていけばいい
でもそもそも
締め切りが結構
かっちり決まってるってことなんですか
そういうことですよね
新機関数でもそんな感じじゃない
01ですよ
機能を今既存のシステムに
付け足すんじゃなくて
システムを1から作る
その場合
33:01
インフラはこの時になきゃいけない
環境を作って
デプロイもここまで
ある
そういった場合ってアジャイルでどうなのかな
みたいな
やってるところもあるんですけど
どういう
操作は
なんで向かない
やることは
2週間の中で
何をやるかっていうのが
明確になってて
それをやっていけば
自然的に
できるんじゃないかな
って感じするんですけど
マークさんの中で
1ヶ月のゴールを持って
2週間単位でやるべきことを
ずっとフォーカス
スケジュールがきついんですよ
それはあると
アジャイルの問題とは別に
スケジュールがきつい
見積もりの中で
作業量的に
そのスケジュールがちょっと難しいから
あれは調整しないと
アジャイルでやったら終わらなくね
ってなるのでそこは
無理をするか
エンジニアが頑張るか
調整して
どう思うか
この話の回答としては
僕は
ここ最近半年ぐらい
半年じゃないか
半年ぐらい
新規のプロジェクトを
持ってるんで
基本僕はアジャイルでやってます
0.1ってわけではないですけど
昨日としては0.1の
開発なんで
基本的に僕はアジャイルがいいと思ったんで
アジャイルを使って
今マークさんが疑問に思ってることは
大体アジャイルサムライを読めば
全て解決すると思うんで
ぜひ一度読んでみてください
っていうのは
うちの会社も今のノートの開発も
アジャイルを知っていれば
知らない人もいたんで
社内で読書会やったんですよ
アジャイルサムライ読書会
やったらかなりそこら辺
スッキリしました
読書会ってどういう風に全て行ったんですか
普通に最初20分ぐらい
書く章を読んで
あとは感想を言って
あとは僕が章を
もう一回みんなに眺みながら
補足をしていく
ここはこういうことでああいうことでとか
それ読むっていうのは目読ですか
目読ですもん
で例えばさっき言ったような
脳機みたいな問題は
アジャイルの定義として
アジャイルの定義っていうわけじゃないですけど
例えばアジャイルサムライに書いてあることは
何を
何を犠牲にするかというか
色々あるわけじゃないですか
要は時間とかお金とか
例えばクオリティとか
っていうのがあると思ってて
そういうトレードオフの
どこを変化させるかによって
要は最終的に
アウトプットを決めるんで
例えば脳機が決まっているんであれば
機能を変えるしかないとか
っていうとこなんで
どれにトレードオフを置くかなんです
36:01
全部トレードオフこうっていうのは
まず失敗するプロジェクト
そもそも脳機が決まっているんであれば
そこに対して
それ以外の要素を
トレードオフしていきますか
ってことを計画した上でアジャイルを回す
スプリントを回す
でやっていくと
取れないにうまくいく
よく話出ているのは
結局じゃあ例えば
営業とエンジニアの間で
できないじゃないかとか
っていうのはちゃんと
スプリントを合わせなくちゃいけないんですよね
脳機がここであればここまでの機能しか作れませんよ
とか
期待値を合わせないからこそ起きる問題であって
期待値を合わせた上で
スプリントごとに結果をちゃんと
見せていれば
そういう話にはならないと思うんで
そういうところの話も大事ですよっていうのが
いろいろアジャイルサムに書いてあるんで
ぜひ一度読んでいただければいいと思います
なるほど
期待値調整で
そうですね
トレードオフが効かない場合ってどうすれば
効かないって
それはもうなんか
転職です
効かないか
効かなくはないけど
明確に
こっち側を作らないとこっちも作れないみたいな
因果関係あるじゃないですか
依存関係
なんか難しいんですよね
全部中途半端に見えちゃう
嘘でもいいか
側だけ
側だけ
UIしか見てないからね
どういうフローですか
うちもアジャイルなんですけど
うちはシュハリーで言うと
リーみたいな感じなんで
かなり
そんなカッチしたやつじゃないです
最初はシュだった
最初からリーです
一応2週間で1スプリントなんですけど
別にスプリント中に
普通に新しいタフ積んだりとかするんで
だいたい普通に
最初にスプリント始まるように
プランニングして
その2週間これやっていこうみたいな感じだと思うんですけど
うちはもっと柔軟にやってますね
僕がやるプロジェクトは
基本的に1週間スプリントで
短いですね
アジャイルといっても流派があるというか
アジャイルの考え
原則自体を守っている
っていう開発といった方が
正しくて
例えばスクラムとかリーンとか
いろいろあると思うんですけど
そういうのはやっていなくて
アジャイルの流儀を守った開発をやっている
っていう表現が多分一番正しい
要は隠し事がないですよとか
計画が変わるなったら変更しますよ
っていう
基本的な原則を守って
開発するっていうとこが多くて
例えば
デイリースクラムやったりとか
1週間例えば金曜日ですけど
金曜日に振り返りをやったり
スプリントプランニングとか回してやる
っていうのはありますけど
特に決まった型で言えるわけではないし
かといってアジャイルで
やってますって
言うのにはちょっと違和感が
39:01
あるかもしれない
基本的にみんなそんなもんだと思うんですよ
あまりガッチリ例えばスクラムとか
やっていない人達とすると
やっぱアジャイルって結局
原則として守らなきゃいけない
というか考え方っていうところが
一番大事だと思う
どんなスタイルでもいいかなっていう感じはしますね
対話ですよ対話
最終的には対話
アジャイルの原則は対話
いろいろあるんですけど
あんまり型にこだわりすぎても
感じはありますけど
逆にWBS引いてるんですか
引いてないですけど
タスクがあるじゃないですか
バーって
2週間ごとにまとめても
意味あんのかなみたいな
最終的なゴールのタスクは100として
2週間ごとに
20、20みたいな感じで
分割して進めることに
やるのと
WBSで引いて
じゃあここまで
終わらせようみたいなやり方と
どう違うのかな
何がいいんじゃない
アジャイルのいいとこって
横ありのタスクとかを2週間でやれば
計画プランを
再リプランニングできるよね
っていうのが
やり方によりますね
やり方によりますね
そこは
チームとか業務の人によって
臨機応変に変えていこうみたいな
そうですね
関わる人によっても
臨機応変に変えなくちゃ
一旦アジャイルサムライ読む
って言って
読んでなかったらぜひ読んだほうが
途中まで読んでやめちゃったね
変な絵が多いかな
変な絵が多い
変な絵が多いし
海外の技術書にありがちな
変な絵だなみたいな
抽象的なんだけど
あるよね
オライリーのヘッドファーストシリーズとかも
謎の絵いっぱいあって
なんだこれみたいな
アジャイルの話を
体系的に聞きたければ
思いやりFMを聞くと
いいと思います
最近あんまり更新してない?
あんまり更新してないですけど
アジャイルの話をいっぱいしてるんで
勉強していきましょう
次、駿河さん
大丈夫ですか?
僕は何を悩んでいるんだろうね
哲学的な話になってきてるけど
さっき岡野さんが言ってたように
専門領域が異なる分野の人
エンジニアだったり
人が認識を一致させるっていうのは
すごい大事で
そこさえ一致していれば
割とスムーズにいくのかな
っていう気はしてて
でも
それが結構できないんですよ
エンジニアって
専門職だから
42:00
専門的なことをやってるわけだから
なかなかその専門的なことを
相手に伝えるのは難しかったり
エンジニアも
そんなに
他の仕事に対して
明るいわけじゃないし
営業の人とかも
そんなに
ソースコード見たら
ジンマシンが出るような人もいたりして
なかなかそこが
難しいなと
情報の
非対称性っていうのが
プロジェクトの問題というか
そこを無くせば
割と上手くいくんじゃないかなっていう気が
ぼんやりとしている
っていうよくわかんない
もうちょっと具体的に言うと
どういうシチュエーションがあったりするのか
シチュエーションですか
例えば
ウェブサイトを
更新しますと
ディレクターさんから
これをこうしてくださいっていう指示が来ますと
わかりました
あれ?でもこれ
ここ変えると
全部
変わっちゃうんですけど
って相談しに行くと
ディレクターさんはHTML全くわからない人
なので
これちょっとやると
すごい
全然30分じゃ終わらないんですけど
って言っても
それが理解してくれない
で困る
いやちょっとできないんです
基本的に
その仕事ってお客さんがいるわけです
他の会社の
お客さんにそれを説明しないといけないけど
それができない
だから
難しいらしいです
説明しかできず
お客さんもそうなんですね
わかりました
じゃあ今日はいいです明日までにお願いします
って言って
もやっとしたまま
進むっていうことですね
難しいな
それも直接なんか
説明するとか
だからそうなってくると
もう間に立つ
ディレクターっていう存在がいらないな
っていう話になって
だったらもう
僕が全部説明すればいいじゃん
って感じになっちゃうので
難しいです
理解してもらえばいいですか?
そうですね
もうちょっと
エンジニアもそうだけど
他の分野に対して
いろんな人がいろんな分野のことを
片足突っ込めた方が
仕事ってのは
スムーズにいくかなって思います
確かに
例えば交通費の生産とか
すっげーめんどくさいじゃないですか
だから僕とか
すごい締め切りとか
守れないタイプなんですけど
ケイリーの仕事をもしやってたとしては
これ
守らないと
こんなことになるんだ
大変なことになるねっていう理解があって
じゃあ技術通りに提出しようって
思えるかもしれない
45:00
うん
詳細まで
細かく分かってもらってなくても
いいと思うんですけど
要点は
把握してほしいなみたいな
そうですね
理解できてない最たる例が
セブンペイ
モドピーじゃん
あれはちょっとね
よろしくないですよね
2段階認証が何かぐらいは
トップが
知ってた方が
いろいろな
案件の進行はうまくいく
特に
ああいうシステム開発の
やり方だと
いろんな会社が
上流の会社がいて
中流下流みたいな感じで
設計があって
実装
会社が全然違ったりして
そうなってくると
気軽に聞けないんですよね
この仕様って本当にこれでいいんですか
とか
そういうことが非常に聞きづらい
情報が
しかも上から下にしか流れなくて
下から上に情報を流すって
すごくやりづらい環境だと思うので
確かに
個人的には
プロジェクトは
進まないんじゃないかなっていう
そういう意味ではアジャイル的な発想を
どんどん取り入れた方が
プロジェクトは進む
あれしかしセブンペイは結構
セブンペイの話しちゃいますけど
仕様がもうおかしい
いいじゃないですか
そこをたぶん作ってる人は
気づいてたと思うんですよね
これおかしくねっていう
そうですね
だから実装フェーズとか
試験をする人とかは
これバンバン他人の
他人のやつ
使い放題じゃない
っていうのは気づいたけど
でもそれが言えないとか
もしくは言っても
どこかで揉み消されるとか
そういうのが
あるんじゃないのかなとか
なんとなく想像しちゃいますよね
このマークさんが書いてある
その後にたぶん話がある
心理的安全性みたいな話にも
関わってくるところで
例えばセキュリティの問題が
これあるんじゃないかとか
あれなんかおかしいんじゃないか
って思ったときに
言える環境と言えない環境って
やっぱあって
言えない環境は確かにさっき言ったみたいに
思ったとしても別に言わない
なんか言うと逆に
言われそうだなみたいな
っていうのはやばいと思ってるんで
僕とかは正直
遠慮なく
言う派です
僕がもし間違っていたとしても
遠慮なく言う
そこで間違ってたらすいませんって言えばいい話なんで
ただね
心理的安全性の
話もあると思うんですけど
仮にこう言ったとしても
特に何も変わらなそうな
48:00
匂いも感じますよね
それはあると思うんです
事業会社内政化してると
岡田さんの場合だったら
ここで俺が言わないことによって
1年後会社が
なくなってるかもしれないと
考えるわけじゃないですか
だからそれを言うことが直接的な
自分のメリットにつながる
まあそうじゃないでしょうね
そうですね
そういう構造になってないですね
だからそういう構造になっていない
ソフトウェアプロジェクトを
作ってしまっている時点で
まあちょっとそもそも
どうなのっていうのはありつつも
まあ難しいと思うんですよね
大規模というか規模が違うと思うんで
僕たちがやってるサービスとか
そうですね
ちょっと想像ができないくらい規模がでかいんだと思いますけど
ただ規模がでかかったとしても
何か対策は
確実に取れるはずなので
まあ
ただそういうこと
そういうものを開発している人たちは
多分そういう経験とか
あの
考え方っていうのはあまりないのかな
っていう印象は勝手ながらある
ので難しいですね
そうですね
僕はやっぱりそういう
あんまりでかい規模のやつやったことないんですけど
だから一回行ってみたいですね
そういうの
ちょっと行ってみようかな
セブンペイの二段階燃焼
そうそう
なんか火消しみたいな感じ
死ぬかもしれないです
現場は盛り上がってるかもしれない
帰りうちにやるかもしれない
実際でも現場の人大変ですよね
あと一個
仕事を誰も見つけられない
はい
いわゆる座組みの問題なんですけど
このメンバーで
これをやっていきましょう
ってプロジェクトが進んだときに
例えばデザインの
知見がある人がいなかったら
デザインについて
考えなきゃいけないことが
ごそっと抜け落ちたまま
プロジェクトが進んでしまう
っていうようなことなんですけど
だからどうすればいいんですかね
デザイナーをアサインするしかないんじゃない
そうですね
で、なんだろうな
そもそも
デザイナーが必要だね
っていうことが
分かっていない人が
プロマネだったりする
それは
それは逃げたほうがいいんじゃないですか
逃げる
デザイナーっていうのは極端な例ですけど
そうだな
例えば
想定していたスキルセットが
その人にない
例えばデザイナー
入れたけどデザインできないみたい
極端な話
エンジニア入れたけど
コード書けないみたいな
エンジニア入れたから
大丈夫だろうって思ったけど
なんだろう
JavaScriptは書けるけど
CSSは全然書けない
51:00
それはありそうですね
保管するしかないんじゃないですか
そうですね
なんかいい案あります
デザイナーってどういうタイミング
2Cのサービスだったら絶対必要だ
うちの会社だと
デザイナーってあんまり
俺の事業部がいないだけで
他の事業部はいるかもしれないけど
2Cの
プロジェクトだと絶対いる
1人はいるみたいな感じだ
そうなんですかね
マークさんって
広告の管理画面
管理画面なんで
2Bなんで
基本的にデザインっていうか
使いやすさっていう観点はあるんですけど
デザインっていう意味では
あんまりなくて
デザイナー投稿っていうのは
あんまりしたことなくて
他の現場ではあるんですけど
いまいち
どういうタイミングで
絶対必要なものなのか
UI UXの
400とは違う領域ですもんね
デザインっていうのは
難しいですね
そこまで見るデザイナーももちろんいるし
逆になんか
僕は2Cのサービスをやってるんで
デザイナーいるのが
普通だと思うんですけど
マークさんの
デザイナーいないってなると
UIとかどうやって
決まってくるんですか
UIとか
他社サービスを見て
こういう
動線だと作りやすいよねとか
なんかオペレーションが
間違いないよねっていう観点はあるんですけど
このボタンの色が
気に食わない的なのは
ないんですよね
ブートストラップみたいな感じじゃないですか
ほぼほぼ
デザイン的な
エラーだったら基本的なものがあるじゃないですか
ああいうのに沿った感じで
やってるみたいな
部品を使うみたいな
部品以外のものを
スクラッチで作るって感じは
ないです
デザイナーさんって
部品を作るっていうか
パーツパーツとか
全体の構成を考える
ことの方が
いいとは思いますけどね
それ誰がやってるんですか
みんなです
みんなでこれの方がいいんじゃないみたいな
エンジニアの規制
ほぼほぼエンジニア
別サイズの人も
見てもらって
使いにくいとか
見た目にしてほしいみたいな
ここにこの情報が
欲しい的なアプローチはあるんですけど
このデザインがどうこうっていうのは
それより使いやすさ
デザイナーって多分
なんでこのデザインにしたのか
っていうのを説明できる人が
デザイナーだと
そういう人はいない
多分ここにこの情報が
あった方がいいとか
ボタンを追加したいとか
そういうことを
集積していって作る
基本的にデザイン
54:00
この多分
2Bなんで
どれだけオペレーションしやすくと
間違いがない
っていうのを重視されているから
別にそこの
変なとこに
ボタンがあるとこれ間違って押しちゃうよね
っていうのはあると思うんですけど
このボタンが
ちょっとグレーアウトだから分かりにくい
そこはあると思うんですけど
星マークが入ってて欲しい
みたいな極端な例ですけど
そういうのはない
裏返すとマークさんがデザイナーみたいなもんですよね
そうですね
デザイン領域をやって
だからデザイン的な
業界長い人とかが
今まで使ってみて
これ使いづらいとか
でやってるみたいな
まっせんしたんですけど
無知の無知ですよね
例えば僕は一人で
サービスを作ろうと思っても
マーケティングとか全然知識がないから
そもそもマーケティングが
必要だっていうところまで
至らない
そこに気づかない
サービスをスタートさせて
セイラにこける
そういうのですよね
あるあるです
気づかないじゃないですか
うーん
本当に周りに誰もいなければ
仕方ないと思うんですけど
今の僕がやってる案件とかは
カスタマーサポートの案件で
カスタマーサポートのチームが
社内にいるんで
エンジン屋だけで作るのはまず危ねえぞ
っていうニーシーは分かってるんで
巻き込むっていうところですね
知ってる人がもし
いるんであれば
自分たちの考えだけで作るんじゃなくて
巻き込むっていうところが
いなければ仕方ない
いなければそもそも巻き込むっていうのも
できないんで
ドメインエキスパートがいたら
一緒に作っていくとね
なるべくそういう人を
チームに
来てもらう
みたいなことをやる
だから社内で
例えばここのドメインは誰が
ここのドメイン知識は誰が持ってるとか
こういうことは誰が得意か
っていうのは結構
知っておくと正直便利だと思います
そういう時にすごい役立つ
例えばこの人ってあれ得意だったな
あこの人知ってたな
みたいなのは知ってると聞けるんで
そういうことさえ知らないと
知らないまま進めちゃう
答え出ましたか?
そうですねそもそも問いが何か
分からない
分かりました
これまたじゃあ岡本さん
これまた僕に思われますね
これすげえ難しいなって思ったんですけど
そうですねこれさっきの
アジャイル的な話で
プロジェクトを
立ち上げましたっていう時に
例えば
アジャイル的な考え方というか
スクラム的な考え方とかで
スプリントを回しましょうってなった時に
スプリントは1週間でも2週間でも
何週間でもいいんですけど
1スプリント目で何していいかな
57:01
何するとすげえ効果が
その後の効果が良くなるかなってことは
ここ最近結構考えてて
どうしたもんかな
何かいいアイデアありますかね
っていうのを聞いてみたい感じはあるんですけど
教科書的にはどんな
回答なんですか
そもそも
難しいこともあって
例えば1スプリント
そもそもスプリントが始まる前に
例えば
マークさんが言ったみたいな
新プロダクトの開発だったら
そもそも1スプリント前に
例えばアジャイルサムライで出てくるようなことだと
えーと
なんだろうな
そもそもユーザーストーリーを作りますとか
インセプションデッキをやるとか
っていうところを
そもそもスプリントが
走る前にやるのかっていうのと
そもそもスプリントで
そもそも
最初のスプリントでそれをやるのかみたいな
ここは分かれるとは思うんですけど
それ以外の観点で
何かやっておくと
いいことあるかな
っていうのは迷ってるんです
教科書的にはあるんです
いつもだとどんな感じなんですか?
いつもだと
そもそも
アジャイルの原則っぽいものを
知っていればいいんですけど
そもそも知らないことが
うちの会社だとやっぱ
チームを組んだ時に多くて
IGの方はよく知ってる方がいるんですけど
例えば僕がやってる今
カスワソコンのチームと絡むと
そもそも知らないんで
アジャイルってこういうものだよ
デイリースクラムはこういうことだよ
で
繰り返りをするのはこういうことだよ
それぞれにやることと
やる意味っていうのを
ちゃんと説明してあげて
こういうことだからやるよとか
あとはアジャイルの原則みたいなことを
ちゃんと言ってあげて
こうやって開発するのはこういう理由だよ
っていうのを結構1スプリント目で
ちゃんと
言ってあげるってことを
結構重視してるとこありますね
あとは1スプリント目で
それ以降のスプリントのタスクを
結構最初洗い出す
その先々のやつを洗い出して
じゃあこれ
どこら辺でできそうですかねとか
っていうのも結構1スプリント目で
やるかなっていうイメージがある
なるほど
なんでそこからモブプロになったの
なんか
尊すぎるでしょ
みんなスキルセットが
バラバラなときに
エンジニアだけの
世界の話をすると
開発環境も
それぞれ始めちゃうだろうし
そこで一旦
みんなでやって鳴らすってことなの
あんまり
もっと開発よりも前の段階
って感じですよね
今に関して
このやり方は
インプット
全体の知識レベルを
鳴らすみたいな
インプットに費やす
のパターンが僕は
1:00:01
結構多いかなっていう感じはします
僕はアジャイル
やってないんですけど
準備が
すごい大事なっていうのはあって
例えばすごい時間ないと
とりあえずサーバーだけ立てて
手動デプロイでいいやってたら
デプロイするのは
もうひたすら
手動でデプロイし続けなきゃいけない
みたいなためになるので
ちゃんとサーバー立てて
CIの環境を作ってとか
そういう準備が
すごく大事だな
っていうのは
この前痛感しました
デプロイおじさん
僕はいないと
誰もデプロイできないから
そういう
ちゃんと
プッシュしたら
アジャイルできるみたいな
そこは整えるとか
そういうやっぱり
地ならしですよね
みんなにアジャイルは
こういうもんだよっていう
共通の認識も大事だし
そういう環境の整備も
大事だし
そういうところが整っていれば
あとはみんな
人間なんだから
ちゃんと自分でやれると
そこが
何を頑張ればいいのか
わかんないし
頑張ったところで
その頑張りが実はそれって
頑張らなくていいことを頑張ってたり
そういうこともするじゃないですか
あとは
僕はやったことないんですけど
いわゆるデザインスプリントみたいな
あの辺ってやったりとかしてますか
デザインスプリントはやってないですね
全く
それはあんまり興味がない
デザインスプリントは
ちょっと
やったことがない分
ありつつも
デザインスプリントがはまるところじゃないかな
っていうことが多くて
はやってないですね
僕やったことないんで
何とも言えないんですけど
あれがはまるのってどういうパターンなんですか
デザインスプリントがはまるパターンは
僕もわかんないですね
どこではまるんですか
ググって
1スプリント目で何するといいかな
毎回1スプリント目になって悩む
デザインスプリントとは
デザインスプリントとはわずか5日間で
価値のあるプロダクトを開発するためのフレームワークです
新機能開発
に入る前の
なんか
ビジビリ的な
イメージが
決裁権のある人を含めてチーム全員が参加する
作業時間を守る
職種や等級に関係なくフラットに話す
不定的な発言をしない
スマートフォンやパソコンの使用は禁止
適度にリラックスした状態で
行う
個人作業によるアイデアの発想
共同作業による意思決定
投票による意思決定
なるほど
なんかそういう頭の中でやって
チームリップを
知らなかった
1:03:01
別の会社の他のプロダクトではデザインスプリントがあるらしい
詳細は知らないの
えーなんで
最初何したらいいかなって
一応インセプションデックやって
重要な項目だけ
大体知っておかなくちゃいけない
決めておかなくちゃいけない
項目だけ
インセプションデッキをやってます
例えば夜も眠れない問題とか
絶対知っておきたいんで
プロジェクトマネージャーとして
個人が何が起きると
本当に眠れなくなるのか
っていう問題は大事なんで
そういう話とか
やってるんですけど
1スプリント目でやってるかどうか
わかんないんですけど
リンキャンバスとかは作ったりして
リンキャンバスか
割と大きめの機能開発のときは
リンキャンバス
1時間経ったね
最初の話が長かった
これはこんなんでいいっす
次いく?
じゃあマークさん
チームの適切な人数
適切な
チームの人数
どうやって算出すればいいんですか
これそもそも
なんでそれが知りたいのかな
プロジェクトやると
人が欲しいって言われたときに
それは欲しいじゃないですか
それは頭数多いほうがいいじゃないですか
でも実際は
そんな必要ないんじゃないかな
っていう
チーム内で上手くワークすれば
終わる感じの仕事なのに
頭数増やそうと
してんのかっていう
自分の中の葛藤があって
どうやって算出するか
今何人くらいだったんですか
今は5人くらい
これって途中から
アサインするときの話なのか
最初から始めるときの話なのか
途中から
途中から
途中からか
途中からは基本的に参加させない
基本的にはあまり参加
人増やすのは
ちょっとあれですよね
逆にコミュニケーションコストが増えて
途中からなんか急に100人じゃあ
追加でアサインするわと
言われたらさ
いらないっしょ
やっぱり1人でも増やすと
そこに対して
教育コストかかっちゃうから
生産性は確実にそこで
一瞬ガクっと下がるので
リカバリして
生産性が上がってきた
期間がどれだけ
長いかっていうので結構計算で
あとプロジェクトの状態にも
よりますね
どういうタイミングで人に増やそうか
っていうのが
デカい開発がありそう
ってなったら人増やして
それがなくなったらミニマム
減らしましょうか
流動的になるもん
そもそもそんな流動的に
人をアサインできるんであれば
そっちの考え方でやったほうがいいような
気もしますけど普通だとそんな
流動的に
人をアサインできないほうが多いのかな
っていう気持ちは僕は今しましたね
1:06:01
そんなに簡単に
人をアサインしてくれるとこって
そんなにないんじゃないかな
潤沢にエンジニアがいたりとか
しないよね
逆に言うと
今いる人数でできる範囲の
ことをやろうねみたいな
うーん
そっちに近いかな
あとは結局
人が多ければ
多いでいいわけじゃなくて
結局
作るものって何が大事かって言うと
価値があるものを
作らなきゃいけない
100人いて
10人だけは価値あるものを作ってて
あとの90人は価値ないものを作っててもしょうがないんで
あとの90人はいらないんですよ
って考えると
そもそも価値あるものに対してどれだけ必要か
って考えるほうが僕は
好きかなって感じ
仕事のための仕事みたいなのは
楽ステみたいな
なんで
あんまり人が居すぎても
別にそんなに
って感じするときは
多々あります
今のチームで人欲しいって言われたら
どうします?
いらないって言いますね
いらないです
アサインされてもそれ以上価値あるものを
作れないんで
だからそこは
チームで
考えると思うし
一人で考えちゃいけないとこっていうのは
ありますね
プロジェクトマネージャーが
欲しいって言われたときに
一人で考えるのはまず危ない
なんか入ってきて
チームで考えるといらないんだけど
みたいなことになりがちなんですよね
なるほど
ただ状況によっては今のチームで
欲しいって言う場合も
パターンとしてはあると思います
だいたい主張が固まっていて
あとは
開発するだけで
かつ既存でいるエンジニアと新しくアサイン
するエンジニアの実装するとこに
依存性がなければ
二人いた方が早いとは思うんで
かつ
ちゃんとドキュメントをまとめているんで
なんでこのプロジェクトやってるのかとか
っていう話はちゃんとまとめているんで
それ読んでもらえばだいたい方向性は分かると思うんで
だったら
じゃあ欲しいですってなるかもしれないですね
なぜこの
プロジェクトをやるのかっていうドキュメントは
誰が書いてるの?
僕が書いてます
なんでこの機能を作るのかっていうのは
ちゃんとこういう課題があるから
こういうところが足りないから
こういうことを補うこういうものを
ちゃんと作るんですよっていう話は
ある程度僕が最初でまとめますね
それは
会社的にやってるんじゃなくて
僕が勝手にやってるだけ
素晴らしいですね
じゃないとやっぱり方向性がぶれるんで
かつ今やってるプロジェクトとかって
1週間2週間で終わるものじゃなくて
1ヶ月2ヶ月
またいで
運用していくものなんで
そういう時って
軸がないと確実にぶれるんですよね
なんか変なこと言う人が出てきたりとか
1:09:01
上から変なこと言われないとか
っていうのを
突っ跳ねるためにも
ちゃんとドキュメントとしてこういうことをやるんですよ
ってことを置いてある
フィロソフィー哲学的な
そうそうそう哲学的な
詩をちゃんと書いてありますね
あとは
個人的には
例えばタスクの
優先度というか
僕優先度って言うの嫌いなんですよ
優先度って
項が2つあった時には
この順番めちゃくちゃなんですよ
項が2つあったとか中が2つあったとか
小が3つあった時にも
順番がめちゃくちゃで
なので基本的に僕が優先度っていう時は
絶対優先順位っていうの
1からつけてください
で1から
上からやっていくんです
優先度とは絶対言わない
優先順位
みんな項をつけたがる
みんな項とか中とかつけたがる
中3つあるけどこれどれからやるのみたいな話になっちゃう
連番で振るって
順位で振ってるってやるんですね
話はそれましたけど
チームの人数の話に戻すと
僕の場合は
うち
レーザーアプリケーション作ってる
チームの人数が今3人で
さっきマークさんが言ってたように
モブプロをやってるんですね
モブプロって
ペアプロじゃないんでペアは2人で
3人からはモブになるんですけど
3人いれば最小単位なんですけど
例えば僕が
ミーティングで抜けたりすると
モブプロじゃなくなっちゃうんですよね
だからもう1人欲しいなって
常に思ってますね
3人いれば動くんで
そうですね
仕事量っていうよりも
仕事量っていうのは進め方的に
モブプロ優先みたいな
最低限3人いれば
逆にだからパラでは
走らせなくて
3人いれば動いてくる
どうなんでしょうね
仕事量チームって
どういう単位で
切り分けのやっぱここにある
スーピッダチームで
切り分けて
分散した人たちで
できる量をやらせる
チームの作り方とか
プロダクトごとに
多分最初は
割と
こじんまりとしたチームで
スタートして
上手くいったら
人を増やしてどんどん新しい機能を
追加するために人を増やす
みたいないい循環の時
の話をすると
多分10人を超えた
時ぐらいから
みんなを見れなくなってる
っていう時が来ると
その時になって
チーム分けるかみたいな感じ
になるんじゃないかなと
だから
何が作りたい何をやりたいか
とりあえず置いといて
5,6人とか
7,8人ぐらいまでだったら一つのチームとして
ワークする
っていうのが
1:12:01
経験的に分かってるから
7,8人ぐらいまでだったら
増やしたければ増やす
っていう
そこから増やす必要
どうしてもこの機能を追加するには
人が必要だってなったら
ちょっと考える
だからどんどん人ください人ください
ってスタンスでいいんじゃないですかね
なるほど
マネージャーがハンドリングがきかなくなるまで
人を増やせ
そうですね
そうすれば
突発的なタスクが
バッと増えたとしても
良しなに
増やす人っていうのは外部から来る
内部
内部で
人を増やそう
社内
それだと新たに人を雇う
みたいな
採用みたいなイメージ
人を
こっちのチームから
花市モンベ的な感じじゃなくて
新規みたいな
そうしたら結構コストがかかる
まあ結構
エンジニアの
スキルって
すごい差があるじゃないですか
すごいできる人もいれば
何しに来たみたいな人もいるし
確かに
そういう意味でも
どんどん人を入れて
この人すごい
いい
この人できるけどこのチームに合わないなとか
そういう相性の問題もある
そういう意味ではどんどん
人を入れといた方が
リスクを
逆に減らせるんじゃないか
体力があるんだったら
採用コストで
いい人を見つける
あとはあんまり人が
入れ替わり立ち替わりだと
流れちゃうし
教育コストもかかるし
僕の好きな小さなチーム
大きな人っていう
ギリギリまで雇うなっていう
ギリギリまで雇うなっていうのがある
GEかどっかの社長が
誰かが
辞めたら
問題が起きるまで雇うな
なくても回るんだったら
いいだろう
優秀な人が
現場にいればいいほど
問題が顕在化しにくい
例えば医療の現場とかで
優秀な人がいると
そのマンパワーでカバーしちゃうから
実は潜在的には
すごいリスク抱えてる
単一障害点になってる
っていう問題があるので
確かにコスト的には
人数を少ない方が
いいっていう経営的な
視点はあると思うんですけど
実はそれでうまくいっていると見せかけて
おきながら実はいってないっていう
可能性もあるので
でもまあその人がやめて
問題が顕在化したんだったら
代わりの人を雇えばいい
そういう話なんです
そうですね
そんな優秀な人すぐ雇えないんですけどね
そうですね
1:15:01
そんな簡単には雇えない
これもう1時間半
経ってんすけど
どうしますか
これ切る?一旦
どうする?
アフターショー的な話
マジっすか?
マジかちょっと
一旦間に合わないから
そういうこと?
すみません
一旦切ります
じゃあそんな感じで
ありがとうございました
