タノラマタウン

エンジニアリング、スタートアップ、仮想通貨..etc

SOFT SKILL読んでみた

エンジニアとして、どう生きていくべきか転職を機に色々考えていて、そんな時に出会ったSOFT SKILLの本を読んでみた

https://www.amazon.co.jp/dp/B01GDS0994/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

感想としては全体的には広く、浅く(結構本人のエンジニア観とアメリカの文化に寄っている)で「ふーん」という感じだったが こういう体系化された本が現状意外となくて、ブログ頼みというところの現状からすると、結構貴重なこと言っているのではないかと思う。 全体的に浅くためになる感想だがその中で、結構響いた表現として

「達成感は、やったタスクではなく、集中した時間によって得られる」

という言葉(ちょっと自分の解釈が入っているかも)

マネージャーとかやっていて、1日で色々決定して、いっぱいMTG出ていても、どこか夜20時くらいになると「今日何をやったけ。。。?」 という感覚に追われる 主観的にも、客観的にも仕事はやっているにも関わらず襲われるこの感覚。それを言語化したのが上記だなと 結局集中して主体的に取り組もうとしない、単独で完結するのであればゾーンに入る努力をしなければ、個としての充実感は得ることはできないのだなと痛感 その具体的なテクニックとしてポモドーロテクニック(25分で時間で区切ってタスクに取り組む)があり、これは自分の中でも取り組みたいなと思いました。

1日の最後に充実したという感覚を得るためにはタスク量でも質でもなく、「集中した時間をどれだけ1日の中で確保できるかが重要」ということが気づけただけで とても広いこの本のなかの自分に響く部分を汲み取れたかなと思います。

プロダクトオーナー研修 2日目感想

昨日に引き続きプロダクトオーナー研修2日目 色々良かったが、中でも勘違いしていた部分を正すことができて、有意義だった

これまでしていた勘違い

アジャイル開発は仕様は最低限しか決めない。INVESTを満たすユーザーストーリーだけを決めて、どういう画面、機能で実現するかは開発者に任せられている。ドキュメントはあくまで最低限で不明点は会話で解決する。プロダクトバックログの役割の一つとしても会話を自然に促すというものがある

正しいこと

スプリントバックログに入ってREADY状態(エンジニアが着手可能)になるものはデザイン含んだ仕様、受け入れ条件、完了条件が明記されている。 ここにあるストーリー、タスクはPOと意思疎通なしで進められることが理想でもし会話が必要になったら、それはPO、チームのリファインメントが甘かったということ

勘違いの原因

プロダクトバックログとスプリントバックログを混同していた。確かにあいまいな状態で会話により進めていくのはあっているが、それはスプリント対象外のタスクにおいてのみ 「仕様が全部決まらないと作れないとか、これだとウォーターフォールじゃん」と思うかもしれないが、アジャイルの真髄は全体像が決まりきっていなくても、ビジョンを分解して部分的に進めて積み上げられるところにある

POのセンス

アジャイルの真髄はビジョンの分解と積み上げ。分解してどうやって積み上げてプロダクトを作っていくかがPOのセンスが問われると思った

  • ユーザーにとって最も価値のある機能、MVPは何か
  • フィーチャー、エピック、ストーリーは構造的にユーザーストーリーマッピングで整理されているか
  • インターフェイスを意識して、各機能の依存は十分に考えられているか

内容のサマリー

プロダクトバックログ、スプリントバックログ、READYの定義は上でも書いたとおり あと細かいが - チームにデザイナーがいる場合:デザイン完了してREADY状態 - ミドルウェアサードパーティ何使うかの選定:Howの部分なのでチームメンバーがやる

あとPOの手前に事業としてマネタイズ、KPIどうするというプロセスがあるが、そこはビジネスアナリストが専門でやる。誰がスクラム的に担当になるかわかっていなかったのでスッキリした。

dailyScrumはとりあえず進捗が見えづらい時、意思疎通で問題が起きている時のカンフル剤、あととりあえずアジャイルだしやってみるかというのでこれまでやってきたが、理想的なのはオールブラックスのハカ。士気を上げてチームでゴールに突進するという意思を統一すること。これまでdaily割とのそのそやること多かったのでここは反省。。。

プランニングポーカーやる時にPOは加わってはいけない、あくまで仕様、要件を説明する係。あと細かすぎる資料、ドキュメントが増えるとポイントは上がる傾向にあるので注意

ユーザーストーリーマッピングスクラムの最初にやるもの

  • プロダクトビジョン
  • コンポーネントゴール
  • フィーチャー
  • エピック
  • ストーリー

の順に分解されていく。直近の部分は細くして、未来の部分は割と適当にビジョンだけだったりする。 またスクラムの最初でとりあえずざっくりエピックにポイントをPOの独断でふってポイントの全量を出す。 大体わかると思うが、超あてずっぽう。とはいえ仮説でも出すことが重要 大体3イテレーションくらいやるとズレがわかってくる。そこで再度見直しを行って、正確なバーンダウンチャートが見えてくる。

アジャイルウォーターフォールの違いは色々あるがしっくりきた表現は計画に対する誠実さ。ウォータフォールはあたかも未来が正確に見積もれているふりをする。 ただスクラムが全面的にいいというわけではなく、結構組織を選ぶ。導入が大変というのもあるし、スクラムに必要な正直、誠実、透明、イノベーションへの意思を持っていないとうまくいかない。

内容はかなり満足 ただプロダクトを考えてチームでユーザーストーリーマッピングしてみようという割と大きめのワークがあったが正直微妙だった

  • 時間短いし、6人とかで遠慮しながらマッピングしても全然スピード感でない
  • プロダクト考えるというところで、本質とは違う奇抜なアイデア出し的な方にそれてしまうことがある

参考

研修のスライドの中で紹介があって、ただただ最高だった

プロダクトオーナー研修 1日目感想

Sierでなんちゃってアジャイルやったり、スタートアップにアジャイルプロセス導入したり、アジャイルサムライ一通り読んでみたり スクラムとは結構3年くらい付き合ってきたものの、どちらかというと現場の叩き上げで学んできたので一度整理したかった。

というわけでこれ行ってきた

https://scrum.esm.co.jp/

先に前提としてPO,SMの役割について

プロダクトオーナーとは

プロダクトのWhatを扱うもの。Howには決して言及しない。チームメンバーに任せる。 半分の時間は顧客、ステークホルダーと過ごして、半分の時間はチームと一緒に過ごす。 プロダクトマネージャーとの違いは諸説あるが、Scrum Inc曰く本質は同じで、より「プロダクトの全責任はあなたにあるよ」というオーナーシップを意識してPOと呼ぶ

スクラムマスターとは

プロセスを管理する。チームの幸福度、ベロシティの向上が責務 プロダクトオーナーとは基本的に対立する立場となる。POの機能要求をスクラムマスターは管理しなくてはいけない

内容のサマリー

序盤はアジャイル語る上で欠かせないウォーターフォール叩きから入る。計画から逸脱しない前提でやってるけど現実そんなことはおきないという感じ。 新しかったのは化学工場の例え。「工場で行っている化学反応はリアルタイムで微妙に調整しないとコントロールできない。失敗すると爆発してしまう。最初から全部予測なんて無理だろ」と妙に説得力あった。

アジャイル行う上で重要なものは

  • 勇気
  • 集中
  • コミット
  • 尊敬
  • 公開

の5つ。 中でも難しい(特に日本では)のは勇気と公開。 これは日本人の謙虚さ、礼儀という性質の副作用。プロセスの透明性、検査によってアジャイルは実現されるが、上記を欠くと遅延、成果物の品質問題を正直にレポートできない、チームの自己組織化が損なわれる あと日本は根回ししすぎ、これはPOが責任取る覚悟が足りていないから。全部決めて、責任取るべき。別に失敗してもクビにならないんだから、もっとリスクを取るべきと

あと大切なのはスクラムスクラムするという考え方、いわゆるカイゼンというやつ。スクラムやる以上ベロシティを上げるために全力を尽くさなくてはいけない。具体的には以下が有効

  • カイゼン:振り返りをして改善できるポイントは次のスプリントの再優先事項として扱う
  • やり方:集中というやつ。マルチタスク状態にならないように
  • 幸福度:メンバー全員が役割、チームに幸せを感じて働けるように

違和感感じた部分

違和感感じた部分は大体共通していて、いわゆる理想と現実のギャップというやつ

  • PO,SMの役割分担:メンバーとは明確に必要なスキルが分かれているものの、ぶっちゃけ優秀なメンバーを経験してPOになるケースがほとんどだと思う。POがシニアエンジニア、メンバーは新卒とかの構図も普通に多いはず。PO的にはHowに言及したいし、組織としてもPOにSM的役割、またメンバーのマネジメントを求めている時にどうすればいいのか

  • ベロシティの向上:ソフトウェア開発は労働集約なので、基本メンバーが最初から十分なスキルを持っている前提であれば、ベロシティがそんな劇的に上がるイメージはない。上げるとすれば時間か人を増やす。ベロシティはものさしでこなせるタスクの量を決めるもの。SMが使うチームを守るための指標で、それをどういうやり取りで上げていくのかイメージできない

  • メンバーの意識:アカデミックなスクラムではメンバーにタスクがアサインされることはない。メンバーはバックログから勝手に必要なタスクを取っていく。ただ実際には期限、アサインを明確にしないと進まないということからSM権限、あるいは合議でアサインが決まっている。メンバーにそこまでアグレッシブさを求めるのもなと。。。

総じて - 役割全員が十分なスキル、スクラム知識を持っている - なおかつチームに対するビジネス側の圧力がほとんどない(POが十分なスキルを持っているということかもしれないが) - メンバー全員のモチベーションがメチャクチャ高い。労働時間が完全に固定されているか、眼中にない。

という現実にはなかなか揃わない条件が揃った時に成立する部分に違和感を感じた。 ただ仮にこれらが実現できなくても、スクラムのメリットは十分だと思う

保活の話

これは何

最近会社で保活(=保育園を探す主に母親の活動)の問題解決するプロダクトを企画中で保活の何が問題なのか調査したのでそのレポート

保活の背景

ニュースにもなっているように、今はとにかく保育園に入れない。保育園はまず大きく認可、認可外の2種類に分かれていて 認可外の中に東京都の独自制度の認証があるという構図。 例外はあるものの、基本的にサービス、質ともに認可>認証>認可外の関係が成り立っていて(なぜなら国から補助金が出て、それがサービスの質向上、利用者の費用減にダイレクトに使われているから) より環境のいい保育園を目指して子供が生まれる前から熾烈な戦いが繰り広げられている。

スケジュール

保育園に入るのは一応年中できるが、基本的には4月が一番枠が多くて狙いやすい。一般的なスケジュールは

  • 5-7月 情報収集、保育園見学など
  • 7-10月 本年度の認可保育園申し込み状況や、新設園情報の確認
  • 10-12月 4月入園の1次申し込み
  • 1-2月 1次申し込み結果通知
  • 2-3月 2次申し込み結果通知
  • 4月 入園、慣らし保育

保育園は誰でも入れるというわけではなく、生まれた後8週間後という制約がある。よって早生まれ(特に2,3月)の場合は 1番チャンスの4月入園は極めて難しい。このあたりが早生まれ不利とよばれる理由 0歳時入園を逃すと、1歳時入園とかは基本繰り上げ枠に専有されるのでさらに難しくなる

保活の闇

「保育園落ちた、日本死ね」とか色々なニュースからもわかるが、保活はとにかく闇が深い。保育園、保育士不足ばかりにフォーカスされるが、 それは構造的な問題の一角であり、問題が全部解決されるわけではない

  • 保育園の情報が色々と散らばっている。おまけに一番信用できる市役所のページは相当使いづらい。
  • 区役所に行かないと点数(=偏差値みたいなもので自分がどの保育園に入れるか)がわからないところがある
  • 区役所に行かないと申し込みなどの手続きができない
  • 見学会の予約の電話とか全然つながらない。保育士側も大変
  • 各種書類や手続きが区ごと、認可かどうかによって微妙に違っている、かつ複雑すぎる
  • 全体的に役所のみが把握している情報、役所しかできない手続きが多すぎる。また公開のやり方が悪く、解決しようとしてもそこがボトルネックになり参入しづらい

まとめると子供を産む直前、生まれた後で肉体的にも精神的にも大変な時に

  • 点数計算を筆頭に保活のルールが超絶複雑
  • 調べたり申し込んだり作業量が多いし、いちいち負荷がかかる
  • このIT化全盛の世の中で情報取得、手続きのためにわざわざ1時間待ちとかがザラの役所に行かないといけない

が待ち受けているということである。しかもこれを全部やったとしても保育園入れるとは限らない(2017年の目黒区では4人に1人が入れていない)

これ、どうすんの?

まず保活において親のストレス、作業負荷がかかっている部分を効率化していく(行政依存の部分は一旦後回し)、同時に保育園、点数計算の部分を 最初はどんなに非効率なやり方でもいいので、集めていきプラットフォームとして圧倒的な地位を確立する。 そこから行政にアプローチして、足りない情報、手続きの機能を埋めていく イメージとしてはマネーフォワードとかの戦略に似ている。あれもAPIとかない旧態依然の金融業界で情報を集約するのをやろうとして、 最初はとてもアナログな方法でやってたけど、圧倒的に便利なのでプラットフォームとしての価値を確立。金融機関も無視できなくなって 次第にAPI化の流れが進んでいる。

スタートアップにアジャイル開発プロセス導入してみた

1月はとあるスタートアップにフルコミットでJoinしてエンジニアリング全般(ディレクション、コーディング、採用、コーチングetc)を見ていました。 スタートアップの状態としては

という状態でした。

結構カルチャーショックだったのが、仕様決定とそれを開発する人が完全に分離していたこと そして、フルコミットの比率から圧倒的にビジネスサイドの力が強かったこと

1つ目のアプリも全部外注で作って、しかも外注先のエンジニアが割とフルスタックでAWSの用意からコーディングから全部1人でやっちゃってリリースできたということもあり 成功体験としてそのやり方が強く残ってしまっていたんですね。

ただそんな再現性のない方法でいつまでもやってられないというのと、内製化をしたいという代表の意向、アプリの性質を考えても仕様決めて外注というよりは ビジネスとエンジニアリングの距離を近づけて、仕様ではなくユーザーストーリーベースでスクラップ&ビルドしたほうがよさそうだと判断したので アジャイル開発布教をやってみました。

詳細に関しては下記の記事に

イケてる開発チームを作るために、アジャイル開発プロセスを導入した話 https://www.wantedly.com/companies/reactcorp/post_articles/107077

pythonでブロックチェーン作ってみた

3週間くらい前にQitaの週間1位取ったこの記事に触発されて作ってみた。

https://qiita.com/hidehiro98/items/841ece65d896aeaa8a2a?utm_source=Qiita%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9&utm_campaign=68f4ff2c4a-Qiita_newsletter_295_01_24_2018&utm_medium=email&utm_term=0_e44feaa081-68f4ff2c4a-33816713

というので割と舐めていったら、予想外に難しかった

まずはpythonほぼ初めて触ったということもあり、実行するまでが結構長かった 笑 versionが2x,3xと2つあってpyenvとか使わないといけないし、インデントで処理の意味が変わるとか、java,ruby,jsにない要素が色々勉強になった

あとはブロックチェーンの概念自体がまだ咀嚼しきれてないのに躓いた - トランザクションが溜まって、マイニング処理によってこれらをまとめたブロックが作られる - ブロックを作るのはProof of workの原理使って、前のブロックの情報使って計算処理 - 各ブロックには1つ前のブロックのオブジェクトをhashにした値を持っている

この辺りが大変だったな。。。あとコンセンサスアルゴリズムは概念だけで、中身は割と適当 他のノードの情報取ってきて、blockの数と各ブロックの中身を比較して、ブロックの中身が全部一致していて、一番長いやつの情報を上書きするという仕組み

問題は、マイニング結果がビットコインとかだと確か最初に計算終わらした1ノードだけに保存されて、次のマイニングは10分後とかになるから、その間に他のノードが更新されて整合性が保たれるけど、そこら辺の仕組みがないから、各ノードが個別にマイニングできちゃって、それをされると成立しないという。いや、同じ条件でマイニングしたら、同じブロックが追加されるから整合性は保たれるのか?? このあたり、理論はあるものの、実運用をしていないからこれで回るのか不明。。。 あと本格的にアプリのロジックにブロックチェーンが使われるようになったら、開発どうするんだっていうのはある。これまでもマルチスレッド時の不具合を再現させるとか結構難しかったけど、その比じゃない。。。ブロックチェーンやってるスタートアップとかは開発環境どうしているんだろう

モチベーション革命読んでみた

How Google Worksを読んだ後、結構超大作で疲れたので、次は軽めのと思い前から気になっていたので読んでみた。 思えば、昔中学生、高校生くらい?父親から「中国やインドの子供はハングリー精神を持って勉強している、お前にも今の日本の若者全体を見てもハングリーさが足りない」と言われて、確かにそうだなーっと それから10年くらい何回か野心的にハングリーになろうとしたものの、正直モチベーションが続くことはなくて、誰かが言った「自分を変えようと思った時一番無意味なのは決意を新たにすること」というのを本当に名言だなと噛みしめる日々でした。 この本はまさかの予想外でそんなモヤモヤの理由、アクションが言語化されていて、作者には失礼ですけど、予想外の収穫でした 笑

ハングリーさが足りない現代の若者をミレニアル世代と定義し、かつて活躍していた世代とはもはや価値観が違う異なる人種だというところから始まり、その世代が活躍するためのマインド、また一緒に働くためのマインドをきれいに言語化していたなと

特にミレニアル世代が重視するのは意味付けという定義から、最近のバズった事象の分析は鋭かったなと思います。 とはいえちょうど自分はタイミングが良くて、読んでいる中で同意する部分が多かったのですが、業界や働き方によっては「何を綺麗事を」、「フワフワしてるな」といった感想を持つ層も少なくないと思うので(多分半年前はこう思った)、ミレニアル世代といってももうちょっと細分化できるのかなというのは思うところ