00:03
はい、7月30日ですね。地獄は浅草城もありました。今日の東京語は、割といい電気でございます。はい、おはようございます。ユメミのkeethこと桑原です。
では本日も朝活を始めていきたいとおもいまして、ついでにこれをツイートしたほうがいいんだろうな。
えー、インバイトビア、違う、コピーア、シェアビア、シェアビア、どうやってツイッターにツイートしますかね。
みたいな感じでツイートすればいいのかな? はい。
OK、じゃあ、えーと、朝活ですね。で、本日読むものは、まあタイトルはある通りの記事ですけど、今回は2つですね、記事読んでいこうと思います。
読み終わりかどうかちょっとわからないですけど、まあまあ、だらだらーと読んでいくのでお付き合いいただければと思います。で、今日は2つ。
えー、お使いするとあんまり技術的な話じゃないんですけど、えーと、1つはトレードオフインディシジョンメイキングで、まあ意思決定にするときに、えーと、トレードオフの考え方とかですね、っていうところが1つです。
で、もう1個は、えーと、7 Shipping Principles で、まあ要はデプロイするときの7つの、えーと、観点とか考えるべきことみたいなところですね、のお話をしていこうかなと思っております。
はい、というわけで、じゃあまあ早速1つ目の、1つ目のほうの記事から読んでいきたいと思います。えー、トレードオフインディシジョンメイキングですね。はい。
まあざっくり概要的にいくと、えー、意思決定において様々な選択肢を考慮するためにはトレードオフを理解することがまあ重要ですよってことを、えー、
いろんな観点でお話をされていこうかなっていうところだと思います。じゃあ、えーと、本文に入っていきましょう。えー、我々は皆、えー、毎日たくさんの決断をしておりますと。はい。
で、その毎日たくさんの決断をしているというところにまた別の記事のリンクが貼られてますね。はい、まあその辺も見てみてください。これだそうです。で、そのほとんどは無意識のうちに行われるものですと。はい。
で、その無意識ってところをまた記事のリンクが貼られてますね。はい。えーと、Tシャツにするかジャンパーにするかというような間小さくて些細なこともあります。
また頻度は低くてもより重要な意味を持つものもあります。個人的なレベルでは家を買うかどうかを決めることかもしれませんし、ビジネスでは優先順位の決定から会社の場所に至るまで、まあ様々なことは考えられますと。
まあそうですね。意思決定って言われるとまあいろんなものがありますよね。小さなものから大きなものまで。はい。
えー、ねむさんですね。おはようございます。ご参加ありがとうございます。毎日毎日参加いただいてすごく嬉しいです。で、今日はタイトルある通りですけど、えーと、まあトレードオフのお話と、えーと、
なんだっけ、デプロイに関する7つの考え方みたいなところですね。読んでますと。で、最初はその意思決定におけるトレードオフの方を読んでますという感じです。
で、また我々はですね、できるだけ頻繁に良い決断をしたいものですと。はい。良い決断とは望ましい結果につながる決断のことです。
はい。例えば2回目のデートの機会を増やすためですね。増やすために最初のデートでどの服を着るか悩むかもしれません。はい。あるいはビジネスの目標を達成するためにまあ最適な優先順位を見つけようとするかもしれませんと。
そうですね。まあ確かに良い決断、良い意思決定をするってのは良いことですし、僕らの人生ってのは基本的にその決断とか意思決定の詰め重ねが今の僕らですからね。はい。
03:05
そりゃ決断は良い方がいいっていうのはそりゃそうでしょうって話ですね。で、良い決断をするための最初のステップは望む結果を明確にすることですと。
我々は明確に出された一つの結果を目指したいのですよというふうに言ってます。まあまあ、はい。明確な目標ないのに確かに良い意思決定とか決断ができるわけはないですよね。はい。
目標が決まったら次は当然解決策の方法を探しますと。そうですよね。多くの場合目標を達成のために取るべき道っていうのは一つではありません。我々の仕事はどれが最も成功する確率が高いかっていうのを判断するわけですね。
そのためにはトレード法を見極める必要がありますというのが本記事の主題的なところですね。はい。
続いていきます。The Tale of RedBubble's Hiring Processだと。
レッドバブルの採用プロセスの物語をちょっと出してみましょうと。はい。ケーススタディーとして、現在テック企業にとって最も愛されたテーマである採用についてお話ししましょう。
現在じゃなくて昔も今も、未来もですね、採用というテーマはずっとビジネス課題であり経営課題でもあるので、今だけじゃないと思いますけど、まあまあはいはい。それは余談でした。
そして世の中の多くの組織と同じように私たちもエンジニアリングやデザインまでかなりの数の職務を募集していますと。これはこの人の職場も同じようなことなのかなと思いましたね。はい。
ついでにそのLooking for Quite a Few Rolesというところで、リンクが貼られていますね。レッドバブルの採用の記事のリンクが貼られているので、そこを見てくださいということでした。
そもそも今回の記事の筆者の方がそのレッドバブルの中の人ですね。はい。今猿でした。
で、遅れを取らないようにするために私たちは定期的に採用プロセスの見直しています。その中で募集職種の多さとそれが人材チームにあたる負荷に問題があることがわかりました。
そこで私たちは新たな成果を目指すことにしました。それは人材チームの管理関節費を削減することです。
はい。まあみんな同じことを思いますよね。はい。 ちょっと余談ですけど弊社でも最近そうですね。あの関節工数をいかに削減してでもバリューを発揮するか
みたいな、かつ社内の改善ができないかみたいな結構無茶なテーマをでも真面目に考えてみてどうなるかっていうのを今
アクションしてますけどやっぱりどの会社ですか大きい会社であろうと小さい会社だとやっぱり同じことは思うんですね。
はい。 その最初の一歩はまあとりあえずまずまずの成果が出たらしいです。
まあそして目指す成果を明確にしていきましたというところですね。 その目指す成果って何でだよってところなんですけど
採用には様々ニュアンスがありますけどハイレベルのアプローチは少ないものです。 あ、なるほど。そこに関しては語られないんです。
はい。で私はそのうちの2つですねプーリング戦略バーサス個々の役割について考えてみました。
プーリング戦略っていうのがあるんですね。初めて知りました。 はい。で個々の役割ですね。はい。説明のために多くのチームにまたがる
06:01
10人のエンジニアを募集するシナリオをちょっと想像してみましょうと。はいはい。 チーム横断をする10人のエンジニアを募集するシナリオを想像してみましょうと。
それができれば本当にいいですよね。いわゆるスーパーエンジニアを雇うってことだと思うんで、それができればもちろんいいんですけど、
まあとりあえず10人採用することを考えてみます。 プールではすべてを一つの広告に求めますけど個別のアプローチでは各チームに別々の役割を持たせます。
はいはいはい。 というところですね。でででで
次のセクションに行くんですけど、はい。 まあとりあえずそういう風な戦略を考えた時に2つの戦略が出てきましたと。
まあ選択肢が増えたことは素晴らしいです。でも次どうしよう、どうしましょうかというところですね。 どちらも実現可能であり予想通り一定の無理とデメリットはあるでしょうと。
そこで十分な情報を得た上で決断するために私たちは2つのオプションのトレードフを明らかにすることから始めましたと。
はい。前者のプーリングアプローチという方はセットアップとプロセスを簡素化しましたと。 プロセスを管理する人が少なくなり面接官のグループも一つで済むからです。
そりゃそうね。しかし候補者がどのチームに所属するかはプロセスの中では明らかにはなりませんと。 そのため人材を募集しているチームの具体的な側面に候補者を興奮させることは難しくなりますと。
確かにね、アトラクトはかなりハードル逆に上がっちゃいますよね、こうやってしまうと。 かつどのチームにっていうところに魅力づけをさせるかってところですね。
その人がどういうところの能力があってどのチームへの貢献ができるかというか、バリューを発揮するかみたいなのが、そういう側面は見づらくなる可能性もありますね。
逆に個別アプローチですね。 の方では候補者にとっては誰と一緒に仕事をするのか、もしくはプロジェクトはどのようになるかとかをより明確に理解することができます。
また企業側としてもより詳細に職務内容を説明し売り込むこともできますと。 要はさっきのと真逆のことができる。
しかし役割を分担した採用担当者や面接側はもっと増やす必要があります。 結局間接コストは増えるよねってことですね。
で、例えば体験を上げるって意味ですね。 採用体験を上げるんだったらもちろん後者の方が絶対に良いでしょうと思いますけど、そこがいわゆるコストの話ですね。
経営戦略的に採用費に対してどれだけ人件費をかけるかっていうところが経営課題の話になると思いますね。
予算をどこまで当て込むかとかありますね。 われわれには目標があります。選択肢はトレード方があります。あとは決断するのみですって言ってます。
私たちはすでに全てのハードワークを入れているのでこのステップは簡単になりました。 管理上のオーバーヘッドを減らすという目的から私たちはまさかのプーリングアプローチを採用しました。
それをプーリングアプローチを採用した上でさらに コスト削減をできるだけやってきてという話が次に聞けるのになったら嬉しいなと思いますけど。
次のセクションですね。トレードオフとバイインですね。
09:00
トレードオフは意思決定の別の側面でも役立ちます。それはコミュニケーションとバイインですよというふうに言ってます。
意思決定に関するコミュニケーション不足っていうのは大きなフラストレーションの原因となります。
誰かがあなたまたはあなたのチームや部署のところに来て決定を提示した時ですね。
あなたはその理由を理解したいと思うでしょう。 正当な理由のない決定ほど悪いものありません。
まあそういう意思決定をする人たちもしくは指示を出すようなポジションにいる人たちは説明責任が必要ですので、
それは説明とかが正当な理由がない話をされても下の人は納得いかないし、それはフラストレーションがたまりますよね。
意思決定に関わるコミュニケーションを円滑にするための重要な要素っていうのはその背後にある理由を共有することです。
そのチームの管理負荷を軽減するためにプーリング方式に移行しますと。
もしその理由が共有されていなければ人々は不満に思うでしょう。
しかし私たちが検討した選択肢やトレードフについて少し共有するだけでもっとうまくいくはずです。
そうすればなぜどのようにしてその決定がなされたのか、そのグループの理解をより深めることができます。
そうすることで全面的な賛同を得られる可能性は高まりますというふうに言ってますね。
要は人は感情で動くというところだと僕も思っていて、それは皆さんも同じだと思います。
仕事の場では感情とかを排除するというか、感情を持ち込むなみたいな指導を受けることもあると思います。
僕も結構あったんですけど、とはいえ人は納得しない限りは動くことはできるけど、それはストレスが溜まるしっていうところで結局チームの仲が良くならない気がするので、
そういう感情を意識してちゃんと説明することは説明するっていう、そこにコストをかけるというのは重要だと思いますね。
プロジェクトのスタートのところに時間をかけることも一緒ですし、タスクを振るときのフレーミングをするときもそうですし、とにかくその背景とかも説明して本人が本当に心からよしやりますというふうになってくれるところがやっぱり最高なスタートだと思いますね。
まあ問題はやっぱりコストはかかるんですけど。
すみません、余談でした。
で、最後ですね。トレードオフは良い決断をするために不可欠でありますよと言っています。
常に良い決断を下すというのはやっぱり難しいことですけど、また良い決断が良い結果がつながるという保証もありますね。
しかししっかりとしたプロセスを踏むことで良い決断をし良い結果を得る可能性が高まりますと。
達成したい結果を明確にしましょうと。もしくは潜在的な選択肢の間のトレードオフを明確にしましょうと。
最後に意思決定の内容を伝えて納得をしてもらいましょうと。
この3つですね。
トレードオフというのはこのプロセスで重要な役割を果たしますね。
トレードオフを明確にしない限り私たちの決断はほとんど当てずっぽうになってしまいますよというところで、
このブログは締めくられていますね。というところでした。
今回の記事の話としては、トレードオフというのはコミュニケーションの場合にも役割、
大きな付加価値が上がったというところは結構個人的にはやっぱり印象的かなと思いましたね。
12:04
なるほどです。まあでもそうですね。選択肢のトレードオフっていうのはやっぱりしっかり見ていくことは重要で、
それをしないで全部やろうとしたらそれは多分きついと思いますし、多分それは不可能だと思うんですよね。
だいたい相反する話が出てくると思いますので、はい。
そのためやっぱりまずもうご協力で明確にして選択肢とか道筋、手順というのを考えていって、
その中でトレードオフをどんどん考えていくってところですね。
その後意思決定したときに、それを実行してもらう人たちにはちゃんと説明責任を果たしましょうというところが付加価値としてついに付加価値ですね。
一緒についてくるよっていうお話でしたね。
はい、というので一旦この記事は以上になります。
結構読みやすかったし、いいなと思いましたね。
ただ、そんなに新しいことがあったってそういうわけではないですけど、
まあでも大切なことはしっかり語られたっていうところでいいなというふうに思いましたし、
改めてこの辺は意識しようと思いました。
はい、というわけで次の記事読んでいきましょう。
次の記事ですね。
セブンシッピングプリンシップルですね。
いわゆるデプロイ周りに関する7つの大事な考え方というか、まさしくプリンシップルですね。
というところを読んでいきたいと思います。
はい、じゃあ行きましょう。
We only ship good workですね。
まあ良い作品というか良い仕事にしか出荷しないというところですね。
はい、というところがまず一つ目です。
はい、まあこれは自明のことに聞こえるかもしれませんけど、
実際には平凡なもしくはあるいはあやふやな仕事をシッピング、
まあ出荷することにつながるというのはあらゆる種類の圧力がありますと。
私たちはその機能を約束しました。
多くの時間を費やしたんだと。
まあひどい敵ではありません。
ユーザーの視点に立てばまあまあ敵じゃないかみたいな話はあるんですけど、
まあこれらの言い訳っていうのはこの37signalsっていう、
これこのブログのドメインなんですけど、
この37signalsで良い仕事以外を出荷する適切な理由にはなりませんと。
はい、まあさっき言ったいい訳ですね。
多くの時間を費やしましたとか、
ひどい敵じゃないんだけどとか、
ユーザーの視点に立てばいいよ、これぐらいの敵だったらまあいいんじゃないのみたいな、
曖昧なあやふやな言い訳ですね。
っていうのは出荷する理由にはなりませんと。
デザインもプログラミングもCSSもJavaScriptもRubyも運用もしっかりした実装をすることですと。
9ヶ月後に溜息もつかずに見成すことができるような喜んできる仕事ですと言ってます。
まあなぜ9ヶ月後かちょっとよくわからないですけども、はい。
私たちが37signalsで取り組んでいることのほとんどっていうのはインターネットがなくなるまで続くものです。
まあですから短期的な利益やともかく短期的な利益を得るためには、
再びそれに取り組む必要がありますと。結局はそうなるんですけどって話です。
これは現在や将来の生産性だけでなく仕事に対する誇りの問題でもあります。
きちんと作り込まれたコードやデザインを使うことで得られる喜び、
15:01
それに具体的な価格をつけるのは難しいですけどそれがもたらす笑顔を認識するのは簡単ですよねっていうふうには言ってます。
というところでした。
で最後に、1つ目のやつと最後に、これは何でもかんでも金メッキをすればいいというものでありませんと。
シェイプアップのサイクルでは2週間、2週間分の仕事に2ヶ月を費やしてしまうことがないよう意図的に自制しています。
すべての作業が10点満点であるわけではありません。しかし10分の8以下の作品であればおそらく外に出すべきではないでしょう。
10分の7以下の作品であれば緊急パッチとしてすぐにクリーンアップに戻る以外、外に出すべきではないでしょうと。
結構この会社はわりと基準が高いですね。10分の9以上で初めて出荷に値すると。
良い作品を出荷するには規律と犠牲がもちろん必要になりますと。私たちはその両方手に入れることができるので、と言っています。
以上1つ目がWe Want Reciprocate Workでした。続きまして、
ちょっと翻訳が時間かかってますが、記事が長い。本文長いですね本当に。
めっちゃ長い。僕の家の多分ネットワークが重いから翻訳が長いんですけど。はい来ました。
続いてですねWe Ship When We Are Confidentですね。自信を持って出荷するというところが次のプリンシップです。
我々が自動テストや探索的テストを行うのはそれが大きな問題を引き起こさないという確信を持って作品を出荷できるようにするためです。
しかし具体的にどの程度の自信が必要かというのはチームと問題の重要性の両方に依存します。
標準化されたプロセスにむやみに委ねるのではなくて、作業の具体的な内容との関連で測るべき尺度なんだよというふうに言っています。
クリティカリティーの低い小さな変更であればクリティカリティーの高い大きな変更と同じように
デューデリジェンスってなんだ。僕がわからない英単語でした。デューデリジェンスを行う必要はないのですと。
時間かかるけど威圧しちゃいますかね。デューデリジェンスとは何ですか。
しかもデューデリジェンスってワードが見つからないですね。出てこないので次に行きましょう。
クリティカリティーの高い変更と同じようにデューデリジェンスは行わない必要はないです。
これは当たり前のことに思いますけど、よくあるプロセスを実行するだけでその特殊性に合っているかどうかをチェックすることを忘れてしまいがちですというふうに言っています。
小さい変更であれば確かにそういう特殊性に合っているかどうかをチェックし忘れるっていうのは確かにやりがちかもしれないですね。
いったんプロセスを流すだけでそんなに大きなインパクトがないものだからまあいいでしょうみたいな。確かになりがちですね。
クリティカリティーの高い作業にはデータを変異させたりとか加工したりするものが割と含まれます。
データを失う可能性がある場合はもさにクリティカリティー高いですよねという話です。
18:01
また既存の機能や大きな機能に大きな変更を加えるものもクリティカリティーが高いんですよねというふうになります。
ベースキャンプのToDoの仕組みを書き換える場合、全ての項目を2度3度チェックしたことを確認した方が良いでしょう。
クリティカリティーの高い作業でバグが本番稼働してしまったらそれは大変なことになります。
クリティカリティーの低い仕事とは既存のデータの表示を変えるだけのもの、もしくは全く新しいデータセンターを使うもの、
もしくはクリティカルパスから外れた画面や機能を扱うものです。
なのでクリティカルパスの低い作業でバグが発生しても大した問題にならない。
修正して次に進めばいいよというところですね。
自分たちが取り組んでいるものがクリティカリティーが高いのか低いのかあるいはその中間なのかを判断するのはそのチーム次第になります。
また誰が取り組むかにもよりますねと。
その分野に精通している人とか10年以上の経験を持つリーダーとか、
最近始めたばかりの人よりもクリティカリティーが低いと判断することが多いでしょうと。
これは自然なことであれ正しいことでもあります。
もし自分の仕事がクリティカリティーに見合うほどしっかりしていると確信するためにはQAによる探索的テストが必要であったりとかそれを行うべきでしょうと。
例えばそれが出荷できるようになるまで少し待つことを意味するようになったとしてもやった方がいいよと言ってますね。
もしそのワークだったり作品というのが危機に非にしているようなクリティカリティに対して十分に良いものである可能性が高いと確信できるのであればそのまま出して問題に対処するために近くにいて前進するべきでしょうと言ってます。
自分の自信を確かめ疑問があればそのもっと上の人に確認するのです。
プロセスとかツールテストというのは自信を深めるためにあるのです。
出荷する時期が来たらどうかを判断するためのものではないということですね。
あくまで自分たちの自信を深めるためにプロセスとかツールとかテストはありますよというところでした。
出荷する時期って結構ビジネス的なところでいいやって決めるものという感じも確かにしますけどね。
はいというところでした。
今のが2つ目のプリンシップです。
では次ですね3つ目です。
3つ目は意外と短いですね。
逆に言うとさっきのがかなり重要だったということですね。
we ship when we are confidentということですね。
自分たちが自信を持てるとか自信を持てた時に出荷しましょうということですね。
はいじゃあ3つ目です。
3つ目はwe ship when the works is finished。
まあこれもそのままですね。
作業が完了したら出荷しましょう。
まあそのままの気がしますね。
基本的に完成している仕事を機能フラグの後ろに長く置いていくことはここでは滅多にありません。
私たちは高度に自作的なプロジェクトはあまり始めないんです。
もしプロジェクトが開発されたならばそれは私たちがそれを必要と判断したからであり、
それはつまり調理されたらキッチンを出ていくということですね。
つまり何か不思議なことが起こるまでもしかしたらというプロジェクトの在庫を大量に抱え込んで機能フラグの後ろに滞留させるようなことはしないんですよと。
私たちは新しい仕事に取り掛かるためにデッキをクリアにします。
はいそのためたまにこれはちょっとみたいなプロジェクトを出荷してしまうリスクももちろんあります。
21:03
でもそれでもいいんですと。
もしそれが十分に悪いものであればその時点で修正するはずです。
私たちは何十億人ものユーザーを抱えているわけでももちろんありません。
最初から別の方法でやっていればもっと良くなっていたかもしれないものを私たちが発売したからといってユーザーが大量に死んだり離れたりすることもないでしょうと。
良いものを出荷していく勢いにはそれだけで質がありますと。
よっぽどのことはない限りその勢いを止めないし、だらだらと自分を責めるようなこともしませんと。
ショーは続けなければならないですよというふうに言ってますね。
というところでした。
早く出して改善サイクルするというところも裏にありそうな気がしましたね。
とにかく仕事が完成したらどんどん出していきましょうというところですね。
面白いですね。
仕事が終わって出荷する準備ができましたけど、いろんな判断で大量させておくと、いわゆるそれは在庫を持っていることと他ならないということなんですね。
僕らでいうとデプロイブランチが何種類かあったらいいんですけど、時期をまだ逃しているからとか、今までビジネス的戦略で出さないみたいなのがあるけど、それは確かに在庫と言われたらそうかもしれないですね。
いやー面白いな。デプロイブランチを在庫っていう例え方をするのは面白いと思いました。
この人たちがデプロイブランチの話をしているかはちょっとわかんないですけどね。
多分ソフトウェアの仕事だから同じ業界だと思います。
そもそもベースキャンプって書いてますしね。
では続いて4つ目だっけ?5つ目だっけ?忘れましたけど。
続いてのプリンシップルですけど、We own the issues after we ship.
出荷後の問題は私たちが所有しましょう。しっかり自分たちでやったことは自分たちでオーナーシップを持って解決していきましょうという話だと思いますね。
もし問題を起こしてしまったら、もちろん自分たち、もしくは自分で解決してください。
発売後のしばらくの間はエラートラッカーにしっかり注意を払いましょう。
顧客からフィードバックを受けたときサポートへの最初の連絡先となることになること。
あなたが仕事をしたのならばあなたには文脈があるんですが曲がっていたらまっすぐにすることですよというふうに言ってます。
これは時に新しいことを始めたのに古いことを修正するために引き離されることを意味します。
実質的な問題であればそれは仕方のないことでもあります。
古いものを直している間に新しいものは保留にするのです。
まあ仕方ないですねそれは。
しかし本質的な問題とは何でしょうか?
その線引きをしなければ、我々はその線引きをまずしなければなりません。
私たちが出荷する製品のほとんどに様々なフィードバックがあります。
どんなに完璧な作品を作ったとしても人々はより多くのもの、もしくはあるいはより少ない、あるいは異なる、あるいはより良いものを求めることになります。
ほんの小さな変更であっても気を許せば永遠に改良とし直しに費やすことができます。
しかし私たちはそうしませんよということですね。
そもそも完璧な製品なんてないと思いますし、誰にとっての完璧かっていうと
多分自分たちが完璧って言ってる気がするので、本当にユーザーにとっての完璧かどうかはユーザーが答えをくれるものですからね。
まあそれもあるから早く出してしまうっていうのは本当にいい話だと思いますけど。
はい。
だからあなたはそれを正しく、意図した通りに動作させる責任があります。
24:02
しかしそれ以上のフィードバックは他のすべてのアイディアや時間に対する要求を照らし合わせて検討するために提出されます。
はい。
とにかく出荷し、修理、改善し、忘れていきましょうというところです。
はい。
以上、今のが4つ目でした。
続いて5つ目ですね。
はい。
次のプリンシップルは、We don't ship if it isn't right ですね。
時間もちょうどそろそろ迫ってきたので、ちょっと急ぎますかね。
はい。正しくなければ出荷しないっていうところですね、次は。
ある問題や洞察が明らかになったために、作業が11時間目に中断されるとイライラすることがあります。
11時間目。
まあでも確かに書いてますね。
11th hourって書いてますからね。
うーん。
なぜ3週間前に言ってくれなかったんだと。
しかし多くの場合それは不可能です。
なぜなら問題や洞察が明らかになるのは本番の時だからです。
そのような時は自分の直感を確かめるのと真実がこぼれるものでなりますと。
はいはいはい。
まあ自分の直感を確かめると真実がこぼれるのはそうかもしれないですね。
はい。
なおかつやっぱり本当に問題とか洞察っていうのは本番の時ですよね。
まあユーザーが使い始めて初めて見えることはたくさんありますからね。
はい。
しかし直感が落ち着くまで一時停止するのはやっぱりもどかしいんですけども、
番人にとって正しくないものを出荷するのはもっともどかしいですと。
一度用に出た作品ってなかなか元の箱には戻せません。
そりゃそうね。
社会的に楽だから誰も困らないからみたいな理由で出荷するよりも、
出荷するものが根本的に正しいかどうかが重要なんですと。
しかし現実はそのような機会を与えてくれませんので、
私たちは正しいものでない場合は行動を引いて列車を止めましょうと。
はい。
世の中に出るものが楽しいか良いかという2つの問いを簡単にクリアしなければなりませんと言ってます。
はい。
最後の最後に難しいことを言いますね、ほんとに。
はい、じゃあ続いていきましょう。
次はちょっと長いので割と大事な話かもしれないですね。
別に7つのプリンシップに強弱とか上下はないと思いますけど。
はい。
続いて、We ship our collective best defaultですね。
はい。
ベストを尽くして出荷しましょうということですね。
はい。
実装だったり設計だったりコンセプトの品質問題を発見することは最終的には全員の領域です。
だからといって出荷を停止するほど重要な問題かどうかっていうのを、
あるいは対応すべき問題かどうかをここで働く全員が判断できるわけではもちろんありませんと。
しかしその作品を見た全員が疑問や改善のアイディアを出すことはできますと言ってます。
で、不備があると指摘されると少し身構えてしまうのは自然なことです。
その気持ちと戦わずにそのままにしておきましょうと。
あ、そうなんや。
身構えるその気持ちはとりあえず置いておいて、
その気持ちを利用して賛成派と反対派、両方の立場からその問題を問い出してみましょうと。
すべての異論を受け入れる必要もありませんけど、
検討する余地は全然ありますよって話ですね。
うん、いい話。
で、また自分より年上の人からフィードバックがあった場合は、
その人の言うことも一理あると考えた方が良いでしょう。
なぜなら彼らはより多くのことを見てより多くのことを行っているからです。
それが彼らが先輩である理由ですと。
27:01
はい、これはすごいブーメなんですね。
教訓しておきます。
僕らの持っている経験値とか、見てきたものとか観点が、
僕らが先輩である理由だというところですね。
はい、OKです。
常に正しいとは限りませんが、そうである確率は高く、
初心者のスタンスで臨んだ方がより早く学ぶことができますと。
はい、まあそれもそうですよね。
スタンスは初心者のスタンスで臨んだ方が、もちろん学びは早いですよね。
はい。
で、また自分より後輩からフィードバックがあった場合ですね。
提案を省略することを選択すれば、それを教育の場にすることができますと。
あー、はいはいはい。
提案を省略することを選択すると、それを教育の場にすることができますと。
ふーん。
なぜ、今すぐ対応することが適切でないのか、正しいのか、比例しないのかと。
そして、もしその提案が採用されたら一緒に運用しましょうと。
えー、ちょっとこれ多分翻訳が、ちょっとニュアンス間違った翻訳になっている気がするんで、
ちょっと理解苦しむな。
なぜ、今すぐ対応することが適切でないのか、正しいのか、比例しないのかみたいな、
比較をしないのかみたいな問いを投げて、どんどんどんどんフィードバックしますと。
で、その提案が逆に言うと採用されたら一緒に運用しましょうと。
はい。まあ後輩からのフィードバックですからね。
はい。
ところです。まあ確かにそれは、そういう問いを投げることで教育の場にすることも確かにできますね。
ふーん。
はい、というわけです。
続いていきます。
で、洞察がどこから生まれたかに関わらず、生まれたかには関わらず、
最終的にハードルを設定するのはより高い必須なんですよと言ってますね。
で、もし私たちが取り組んでいることがよりよく、よりシンプルに、より早くできるのであれば、
それを実現するための時間がたくさんあるのであれば、それを実行に移すので、と言ってます。
はい。
というところでした。
はい。ベストを尽くして出荷するっていうプリンシップでしたね。
はい。で、ラストですね。
ラスト。はい。ちょっと30分になったんですけど、まあラストなので、走り切っていきたいと思いますね。
ラストは、
WeShipToOurAppetiteですね。
私たちは食欲に合わせて出荷しますと。
食欲って英単語ですね、これは。
アプリじゃなくてアップタイトですね。
失礼しました。アップタイトですね。
はい。食欲に合わせて出荷しますと。
うーん、なんかちょっと言い回しが難しいですね。
読んでいきましょう。
シェイプアップの重要なコンセプトの一つに食欲ってのがありますと、
プロジェクトは2週間、4週間、または6週間以内に良いバージョンのピッチを完成させることができる場合のみ、
行う価値があるという前提でキックオフされます。
この人たちはそういう基準でやってるんですね。
行う価値があるという前提で、そうですね。
偉大な企業が崩壊な値段でひどい株になることがあるように、素晴らしいピッチも食欲を遥かに超えて追求されれば失敗を得ることもあります。
食欲によって課された時間的制約というのはトレードオフと情報を強いるためのものです。
完璧を求めるあまり更なるアイディア、あらゆるアイディアを永遠に引きずるようなプロジェクトにしてしまう野心を抑制するためにあります。
30:00
時間的な制約があると、ほとんどの場合、より多くのアイディア、より小さな問題、より多くの磨きをかけることになります。
その瞬間はもどかしく感じるかもしれません。
あと2週間あれば、みたいに思うかもしれません。
しかし、もしあと2週間あったらそれに応じて野心を広げ、最後にはそれに加えてもう2週間欲しいと思うかもしれません。
まあ、絶対ありますね。
これは僕もよく経験値がありますけど、
いろんな事情があって、お客さんが後から出してきた要件とか出てきたりとか、
スケジュールを後ろ出しとか、リリースを先延ばししますという話は結構あるんですけど、
実際に先延ばしになった原因を解決するためにその先延ばしの時間を使うんですけど、
なぜかしらお客さんは、リリース伸びたし時間ができたので、この要件もぶっ込んでくれないみたいなことをちょいちょい言われるんですよね。
なんでその発想になるかはよくわからないんですけど、
理由があって伸ばしているのにその理由にさらに新しいものを乗っけようとしてくるんですよね。
野心が広がるなら構わないですけど、できるかどうかは別の話なんだよなというのは思いますね。
はい、というところでした。ちょっと経験値を喋りたくなりました。
で、続きます。
制約があると私たちは選択を迫られ、ANDではなくてORなら何がいいかという順位づけをさせられます。
他のステークホルダーに可能性の芸術を受け入れさせる客観的な方法として機能するのです。
可能性の芸術っていうワードがちょっと面白いですね。
このブログを書いた人、本当ワードのチョイス面白いな。
もっと欲しいものは誰でも思いつきますけど、両方が手に入らない場合、もしも何が欲しいかを決めるのはずっと難しいんですよと言ってますね。
通常必要なのは追加ではなくて代用なのですと言ってます。
はいはいはいはい。
なるほどね。
で、フィーチャークリープや見積もり漏れなど業界の標準です。
私たちのスタンダードは与えられた時間内に最高の仕事をすることであり、そのために妥協に胸を張ることですと言ってます。
はい、というところでした。
もちろんベストを尽くすのは構わないですし、ベストを尽くせるのはそれに尽きますけども、ただベストを尽くすことでより大きな課題だったり、また時間を制約されたり、新しい食欲が発生するとか確かにいろんな問題があるので、
追加ではなくて代用に振り切って、妥協に胸を張ることって結構面白いなと思いました。
ただ、このセブンプリンスプルズの他のやつとバッティングする意見な気がしますね。
妥協っていうワードを使うと、あれ違うんじゃないこれはっていうふうに思ったりもしますけど、
先ほどの記事もありましたけどトレードフと一緒な気がしますね。やはりビジネスやってるのでね、というところだと思いました。
以上ちょっと難しい記事だったというのと、翻訳が微妙にニュアンスが違ったりして読みづらかった感はあるので、
後ほどこの記事自体をツイートしますので、皆さん自身でまた読んで解釈していただくのがいいと思います。
大体のコンセプトはわかったと思いますし、タイトルがほぼ物語っている感じはありますので、その辺を見てもらえればいいんじゃないかなと思います。
というわけで、35分になりましたので、今日の朝活はこちらで以上にしたいかなと思います。
33:01
7月最後の土曜日ですね。皆さんゆっくりお休みいただければと思いますし、
また明日も日曜日ですね。ゆるーっと読んでいきますので、またご参加いただければ嬉しいなと思います。
明日はもうちょっと技術的に記事を読めるように、ちょっと記事を探してみます。
でも僕が今興味を持っている記事を読むことになるので、大体フロントエンド周りだと思います。
興味ある方はご参加いただけるとありがたいなと思います。
では今日の朝活は以上にしたいと思います。良い休日をお過ごしください。ではでは。
