カイゼン・ジャーニーを読んだ
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/15
- メディア: Kindle版
- この商品を含むブログを見る
カイゼン・ジャーニーを読んだ。展開が熱くて2日くらいで一気に読んで、この熱量を伝えたくて会社の人に布教してしまった。
江島という主人公のストリーに沿ってスクラム・アジャイルについて学べる
この本のいいところはタイトルにあるように「たった１人からはじめて」というところだと思う。現場に対して不満や変えたいことがあったとしても、それをいきなり理想形の形に持っていくのはとてもむずかしい。いきなり理想形にもっていくのは現場の社員１人では無理だと思う。それでも１人からはじめて、仲間をどのように作っていくか、そこから書かれている点がとても良いなと思った。
立ち向かう問題がなかなかリアル
自分はスクラムの経験が沢山あるわけではないけれど、それでもあーこういうことあったなぁーという問題が本書のなかでも沢山起こっていて、とてもリアルだった。個人的にはデザイナーとの協業のところは、過去に似たような経験があったのでとても学びが大きかった。当時は自分の馬力で何とかした(なってなかった説もある)けど、こういうやり方で進めればよかったなーと思うことが沢山ある。
インセプションデッキを定期的に見直す、とか「向き直り」をする、とかこれまでやったことのないアプローチもあったので真似していきたい。
いちいちセリフが熱い
「みんな、隣の芝生は青く見えている。行ってみると、実は芝生は前にいた場所から続いていて、大して変わらないことに気づくんだ」
「それで、あなたは何をしている人なんですか？」
「僕が取り組むより、部のみんなに展開したほうが良いかもしれない。…といって、また自分からは始めないのが、これまでの僕だ。」
WEB系にいる今でも震えたので、SIerにいたときなら涙がでちゃったかもしれない。
専門家はいない。私たちしかいないんだ。
これは先日あったRuby 25周年イベントのときに何かのスライドで、またエラスティックリーダーシップという本でも出てきたフレーズだ。カイゼンジャーニーに出てくるフレーズではないんだけど、サブタイトルにもなっている「越境」するチームというのは、こういうマインドを持ったチームなんじゃないかと読んでいて思った。
まとめ
現場を変えたいと思っている人にとっては、手法が参考になるのは勿論のこと、やっていこうという熱量を貰える本だと思う。オススメです！
ティール組織を読んだ
Twitterでよく見かけたので、ティール組織を読んだ。
- 作者: フレデリック・ラルー,嘉村賢州,鈴木立哉
- 出版社/メーカー: 英治出版
- 発売日: 2018/01/24
- メディア: 単行本
- この商品を含むブログ (1件) を見る
ティール組織と呼ばれる、従来の組織形態の常識からは考えられないルールで運営され成果を出している組織形態についての話だった。ホラクラシーというと馴染みがあるかもしれない。(ホラクラシーはティール組織の形態の１つみたいな紹介のされ方がされている。)
ティール組織は以下の3つの特徴があるらしい
- セルフマネジメント (自主経営)
- ホールネス (全体性)
- 存在目的
コレだけ見ると、セルフマネジメント以外はなんとなくトンデモ理論に見えるけど、読み進めていくと確かにと思うことが多かった。 1章目は若干スピリチュアルな話(にこの時点では感じること)が入ってるんだけど、2章目からは実際にティール組織で運営が行わている企業の話が続いていくので1章目は我慢して読んでいってほしい。
以下読んでいて自分が思ったこと。
性善説な組織
セルフマネジメントな組織では、従業員は基本的に善良であるという前提にたって組織運営がされている。本書で紹介されている会社では、元々備品の貸出にマネージャーの承認が必要だったり、事細かにタイムカードを付けなければいけなかったものを一切取りやめるだけでなく、目標設定や決済まで各チームに任されて運営がされていた。従業員が基本的に善良であるという前提にたつと冗長なルールや面倒な手続きのほとんどをなくすことができるようだ(だからこのような組織ではオフィス機能にあたる人の数が極端に少ない)。
個人的にも性善説にたっていない組織では、無駄なルールやとりあえずマネージャーに承認をもらうみたいなフローが多くなるという気はしていたので、これは納得だった。
こうなると気になるのは「何か不正が起こったらどうするのか？」ということだけど、本の事例だと以下のパターンだった。
- 罪を犯した人は解雇になり社内にも統制を求めるような声があがったが、社長が中心になりセルフマネジメントで性善説にたった文化を守った
- これまでこのような組織運営に寛容だった取締役陣が、統制を求め始めてセルフマネジメントの文化が失われてしまった
こういう文化を守っていくには、経営層にそれなりの覚悟がいりそうだなと思った。
なぜ最近のオフィスはアットホームな雰囲気のものが多いのか
これはホールネス(全体性)にかかってくる部分。そもそもホールネスってなんだよって感じだけど、本書を読んでいくと職場でも「自分らしくいられるか」ということだということが分かる。職場で「自分らしくいられる」ということの意味は、多分「自分を必要以上に大きく見せ」たり、「必要以上に卑下して見せ」る必要が無く、普段に家や友人と過ごすような気持ちで職場で過ごせるかということなんだと思う。 最近できたオフィスってカフェスペースがあったり、小上がりがあったりするのが多いのって、社員が自然体でいられるようにという狙いもあったりするのかなーと思った。
ティール組織になるとどのようなことが起こるのか
オランダのビュートゾルフというヘルスケアの非営利組織の話が特に面白い。もともとオランダの地域看護師を束ねる組織では、1看護師あたりの生産性を上げるために細かく全ての医療行為に標準時間を設定して内容を指示し、それをモニタリングするために各家庭の玄関ドアにバーコードを付けて医療行為にかかった時間を調べ、遠隔地から監視・モニタリングするということをしていた。(これだけ聞くと結構利にかなっていると思ってしまう。)
一方ビュートゾルフではこういった管理をせず、10〜12人のチームでケアサービスや、患者の受け入れ、スケジュール管理、さらには採用まで受け持つ形態を取っている。しかし結果として、ビュートゾルフの方が他の組織よりも1顧客あたりに費やした介護時間は40%近く少ない(要は効率よく医療行為ができている)というデータが出ているらしい。2006年に10人だった組織が2013年には7000人になっているという成長スピードも凄まじい。
いまの組織をティール組織にするにはどうしたらいいのか
これは結構身も蓋も無いことが書いてあって、正直だいぶ厳しい。
- CEOがティール組織のアイディアについて個人的に素晴らしいと思ってくれているか
- 取締役会もティール組織について理解し、支持しているか
CEOが乗り気でない場合には、自分の権力や時間を注ぐことはそれほど意味がないとまで言われてしまっている。厳しい。
まとめ
最近生産性を上げるにはもっと性善説に立たないといけないと思っていたので、どうやってセルフマネジメントな組織が実現されているのかは納得する部分が多かった。 既存の組織を末端の社員からティール組織に変革していくのは無理ゲーと書かれているわけだけど、組織がどのように変わっていくかの話など勉強になる内容が多かったし、変革までいかなくても改善していける部分もありそう。というかあってくれ頼む。
メルカリやSmartHRはかなりこのあたりうまくやってる印象あるけど、どうなんやろうか。 blog.shojimiyata.com
実践ドメイン駆動設計を読んだ
実践ドメイン駆動設計を読んだ
会社でレガシーシステムのリニューアルをやっていて、それのコアとなるAPIサーバをDDDで作りたいと思い購入した。
エバンス本は既に一度読んでいたのだけれど、いざ実務になるとこれはどこに置いた方がいいんだ？とか、どう実装するべきなんだ？みたいなのは本当によく迷う。
この本で、そのあたりクリアになるんじゃないかなという期待を持っていた。
以下、感想
自分がやっていたのは軽量DDDだった
本書ではDDDの思想を理解せずに、そのアーキテクチャの実装だけを真似ることを軽量DDDと呼んでいて、あまりオススメしないと言っている。
実際、自分もやって見て思ったんだけど、ドメインとは何だろう？という問いにちゃんと答えられないとレイヤー分けが結構難しくなってくる気がする。
ビジネスロジックはドメインなんでしょ？みたいな意識だけだと、複数人の開発で意識合わせていくの辛くなるんじゃないかなと漠然と思ってたので納得。
DDDとは特定の技術的なアーキテクチャのことではない
これはよく公開されているスライド見ててもよく誤用されてるし実際自分も DDDでやってますみたいなこと言っちゃうんだけど、レイヤードアーキテクチャ= DDDではないという話。
特定の技術に依存するものではない、でもヘキサゴナルアーキテクチャがオススメとは本書に書かれていた
エンティティとは？バリューオブジェクトとは？アプリケーションサービスとは？ドメインサービスとは？
このあたりは、概念としては分かっているつもりでも、いざ実装するとこれでいいんだっけ…ってなりがち。本書ではこれらについて具体的なコード例もつけて解説してくれているので、かなり参考になる。また理想的にはこうだけど、パフォーマンス要件とかで難しい場合もあるよねーといった現実的な話もしてくれるのが良かった。
でもこれもやはり、技術的なテクニックというだけの話ではなく、ドメインから導いていくということが大切だなとおもった。(特にアプリケーションサービス、ドメインサービスは単純にビジネスロジック置き場みたいな気持ちだとごちゃごちゃになっていきそう)
全てをバリューオブジェクトにする必要はない
例えばBooleanの値であったり自己完結した数値だったりする場合など、その値自体で意味のある全体を成している場合にはバリューオブジェクトにする必要が無いということは書いてあった。
なんとなくDDDガチ勢の人って全てをバリューオブジェクトでラップする印象があったのでちょっと意外だった。(よく考えたらそりゃそうだという話ではあるけど)
一方でIDみたいなものはどんどんバリューオブジェクト化した方が良さそうなので、自分もやって行こうと思う。
まとめ
おもっていたよりも読みやすい本だった。表紙で損してる気がするw
これを呼んでエバンス本の方をまた読み返し、またこの本を読むみたいなことをすると、理解が深まりそう。
作者が公開しているリポジトリも参考になるのでおススメです。
Netflixでデビルマンを見た
深夜に調べ物をしていてそのお供に見た。ながら見だったんだけど、割とトラウマになった。。。どれくらいかというと、ぼーっとしてるとその辛いシーンが思い出されて陰鬱な気分になるレベル。 ただ本当に傑作だと思った。
以下激しくネタバレ含みます。
続きを読む2017年の振り返り
2017年は上半期で振り返ってた suzan2go.hatenablog.com
2017年の下半期振り返り
11月に転してた。
7月
7月の最初には関わっていた決済回りの機能追加プロジェクトが無事リリース。かなりリファクタリングもしたし、決して単純な機能ではなかったが大きなバグも起こさずにいけたのは安心したし自信になった。
7月の後半からマネージャーから打診を受けてリーダー的な役割をやることになった。この時点で退職を考えていたというか既に内定が出ていたのでリーダー的な役割を引き受けるか迷ったけど、正直に話したところそれでもやってみてほしいということだったので頑張ることに。
8月
リーダー的な立場になり数値を追っていくことや、ビズデブ的な人たちとの関わりなどこれまで以上にやることになったが、１つ視座が上がった感じで割と楽しめた。
KARTEというツールを導入して、キャンペーンとかサイト内プロモーションをエンジニア無しに大体できるようになったのが自分のやった仕事としては大きいと思う。導入までは結構頑張ってその後の運用は優秀な新卒氏に任せたんだけど、ガンガン使い込んでいてとても頼もしかった。半分冗談でKARTE大臣！と呼んで任せていたら本当にめちゃくちゃ詳しくなっていって、名をつけて任せるって大事だなーと実感した。 karte.io
今も活用されているようで嬉しい。 qiita.com
9月
転職後に触ることになりそうなKotlin + Spring Bootの勉強をプライベートで始めていた。
9月後半からは社内でScalaも始まってたので、Kotlinで勉強していたことやSpringでのレイヤーわけは地味に役に立った。
10月
サービスの運用負荷を下げるためのサポートの人向け機能開発とか、自分が過去に開発に関わったサービスのリアーキテクチャとか、自分が rails new したサービスの面倒を見ていた。サービスのリアーキテクチャは、完全に自分が(期間的に)やりきれない案件だったので、自分の理想を押し付ける形にならないように、実際に手を動かす人と認識を合わせることを意識した。その後どうなったかは聞けていないんだけど、頑張って欲しい…すみません…
このタイミングで祖母が亡くなったりしてめちゃくちゃドタバタしたものの、サポートの人にお願いされていた管理系の機能は全てリリースできたのでよかった。
そして10月の後半は2年半在籍したスタートアップ?の最終出社日だった。2度目の転職。何で転職したかというと主に理由は二つ。
- 条件面
- 技術的に今と違うことがやりたくなった
会社の公式エンジニアブログに何故か退職エントリーを書きました…
11月
今思うとツールだけの問題ではないんだけど、前職で当たり前に使っていたツールが使えないので転職してすぐは結構テンションが下がっていた。
単純に慣れなんだとは思うけど、当たり前に使っていたツールやサービスが使えなくなると思ったよりテンション下がるんだな
— すーさん二号 (@suusan2go) 2017年11月3日
あと入社してしばらくお腹こわしていたんだけど、今思うとこれ明らかにストレスだな…
無限に胃でガスが生成されてる感じで凄く辛い
— すーさん二号 (@suusan2go) 2017年11月9日
破裂しそう
この辺のお気持ちは以下で表明している。 suzan2go.hatenablog.com
仕事内容的な話でいうとgRPC + Spring Boot + Rails(これはこれから) + Nuxt.js なプロジェクトをほぼほぼ１人で回している。当初はgRPCやるつもりなかったんだけど、ちょっと触ってみると思ったよりも良いものだった。
DDDを実践するためにこういう本を買って読んでいるんだけど、自分がやっているのはレイヤードアーキテクチャ(or オニオンアーキテクチャ or クリーンアーキテクチャ)なだけで所謂 軽量DDD の域を出ていないなぁと思う。大分ドメインの知識がついてきたので、今年はドメインエキスパートと話して諸々すり合わせをしていきたい。
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
12月
Slackが使いたすぎて、Slackを入れたいという話をして資料を作って、偉い人に持っていったら何やかんやあって導入が決まった。過去の経緯とか聞いてると、色んな人の下準備が色々あったので、自分の提案で通ったって感じっぽい。
他のチャットツールをディスるわけではないけど、現時点でやっぱり開発用のチャットとしてはSlackが最強だなーと。GitHub(会社ではGitLabだけど…)の通知を垂れ流すだけでも情報共有という意味ではかなり価値があるし、セキュリティや言語、FW関連の情報をRSSで流せるのもいい。
あと振り返り・プランニングの習慣を他チームに広めたりしていた。振り返りでとりあえずKPTやってみたんだけど、めちゃくちゃいろんな意見が出て他チームながらとても有意義だった。Problemとしてとても重い課題(組織構造的な話)がでたんだけど、それでも「XXと話す場を作って相談してみる」という具体的なTryが出て実行されたのはとても良かった。
まとめ
11月の転職が大きな出来事でした。前職は不満が１つもないといったら嘘になるけど、エンジニアとして働く環境という意味ではとても良い会社だったなーと改めて気付かされました。そして、自分が当たり前に享受していた諸々は決して当たり前ではなかったなーというのを実感して、感謝の気持ちでいっぱいです。
現職はポジティブに捉えると改善しがいがあることが沢山あるし、色んなことを任せてもらっているので、メインのプロジェクトと平行して頑張っていきたい。とはいえ段々と手が足りなくなってきた感はあるので手伝いたい人ご連絡ください。
改善しがいがあることが多い(しかも自分の経験が役に立ちそう)というのはとても嬉しいことなんだけど、一方でそれをやるために転職したわけではない…という思いは正直ある。知り合いから「組織を変えるには、それなりの立場、権限、報酬がセットじゃないと消耗するだけで得るものがない」とも言われているので、かかる労力や期間がどれくらいかというのはぶっちゃけ結構シビアに考えている。
2017年下半期の抱負の進捗
機械学習
進捗ダメです
アプリ
Spring Boot + Kotlin + gRPCの勉強に消えていきました・・・
2018年の抱負
力尽きたのでまた週末に…
自分が仕事で使うツールやサービスは割とモチベーションに影響するのだなーという話
※あくまで自分にはそうだったという話
所謂スタートアップと言われる会社から、それなりの規模の会社に転職してもうすぐ2ヶ月くらいになる。
今の会社に転職してくるときに、開発に使っているツールについては説明を受けていたし、当然それを知った上で入社したのだけれど、実際に使ってみると思ったよりもテンションが下がった自分がいた。
特に以下のようなソフトウェアエンジニアとして日常的に使うツールのグレードが下がると(正確には必ずしもグレードが下がったとはいえないものもあるんだけど)、辛かった。
- チャット
- ソースコード管理
- ドキュメント管理
こういう周辺のツールにモチベーションが左右されてしまうのはどうなんだろうと思っていたし、転職で会社を選ぶ時にも割と軽視していたのだけれど、自分には重要な要素だったようだ。
正直な話、入社して最初の週末は人事の方や誘ってくれた人に頭下げて辞めさせてもらおうか…という考えが頭をよぎる程度にはテンション下がっていた(今思うと単純にツール・サービスだけの話しではなく、環境が変わったとか複合的な要素が絡んで必要以上にナーバスになっていたのだけれど)。
ただ「今いる環境を良くしていくことが出来なければ同じことをどこに行っても繰り返すことになるのでは？」と思い直し、「もっとこうしたい」ということを発信してみると、賛同してくれる人がそれなりにいることがわかった。
そういった声をいわゆる偉い人達も後押ししてくれていたり、他にもXXを改善したい！と手を上げる人が出てきたりして、今は色々と良い方向に改善していきつつあると感じる。
またおこがましい言い方なんだけど、自分がそういう流れを作れた気がしていてそれがちょっと嬉しい。
全くまとまりのない文章だけど、Slack導入が承認されたのでその記念に。
Slack導入のトロフィー解除したぞ！
— すーさん二号 (@suusan2go) 2017年12月19日
grpc-gatewayでMetadataに詰めたエラーの内容をJSONに詰めてRESTクライアントに返したい
引き続きgRPCの話。
gRPCでエラーをクライアントに返したい場合、通常だとステータスコードとエラーメッセージしか返せない。例えばアプリケーションレベルのバリデーションエラーみたいなものを返したい時、メルカリさんの資料によるとMetadataに詰めて送ると良いらしい、
gRPCがクライアントのときは詰めたMetadataを読み出せばいいんだけど、grpc-gatewayでRESTのクライアントに返す時にはどうしたらよいか調べた。
grpc-gatewayのエラーハンドリングをカスタマイズする
実はGitHubのwikiに How to customize your gateway というのがあって、そこに結構色々と書かれている。
How to customize your gateway · grpc-ecosystem/grpc-gateway Wiki · GitHub
で、Wikiから辿った先にあるブログに実際に結構丁寧にエラーレスポンスのカスタマイズ方法が乗ってるので、それを参考にすればよい。
fun run() error { runtime.HTTPError = CustomHTTPError // 省略 } type errorBody struct { Error string `json:”error"` ErrorDetails []ErrorDetail `json:”errorDetails”` } type errorDetails struct { Field string `json:”field”` Message string `json:”message”` } // おもにgRPCのMetadataをerrorBodyのような構造に変換し、クライアントに返すためのカスタムハンドラー func CustomHTTPError(ctx context.Context, _ *runtime.ServeMux, marshaler runtime.Marshaler, w http.ResponseWriter, _ *http.Request, err error) { const fallback = `{"error": "failed to marshal error message"}` w.Header().Set("Content-type", marshaler.ContentType()) w.WriteHeader(runtime.HTTPStatusFromCode(grpc.Code(err))) eb := errorBody{ Err: grpc.ErrorDesc(err), } md, _ := runtime.ServerMetadataFromContext(ctx) for k, v := range md.TrailerMD { eb.ErrorDetails = append(eb.ErrorDetails, errorDetail{ Field: strings.TrimSuffix(k, "-bin"), // バイナリで帰ってくる文字列は-binのprefixがつくので、クライアントが扱いやすいよう消す Message: v[0], // サーバー側では文字列としてしか入れていないが、何故かArrayで入ってくるの最初のものだけ取得する }) } jErr := json.NewEncoder(w).Encode(eb) if jErr != nil { w.Write([]byte(fallback)) } }
Go書くの久しぶりすぎてこんな感じでよかったか全然自信ないけど、一応やりたいことは実現できた。
