「ELASTIC LEADERSHIP」を読んだ
- 作者: Roy Osherove,島田浩二
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/05/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
最近急に意識が高まって本を読みまくっている。
この本は、色んな人が既に感想やまとめを書いていらっしゃるので個人的によかったところまとめる。
フェーズに応じてリーダーがとるべき振る舞いは違う
チームの状況に応じてリーダーがとるべき振る舞いは違うよねという話。本書ではチームの状態は以下のように説明されている。
- サバイバルフェーズ
- 学習フェーズ
- 自己組織化フェーズ
これからの時代はサーバント型のリーダーだ!みたいなことをよく聞くわけだけど、当然それはチームの状態によって異なるよねという話。サバイバルフェーズ(チームに余裕がない状態)では、指揮統制型でリーダーがチームの取るべき方向を示し引っ張っていくことが大切だとのこと。
また例えばチームが学習フェーズであっても、過ちを正すのに沢山の時間がかかる場合には指揮統制型で望むべきだともあった(例えば、「Gitととかよくわからないし、ファイルサーバで管理しましょう!」みたいなことをチームが言い出したとき、バージョン管理されてないがゆえのデータ削除なんかの間違いが起きてからリカバリするのはしんどいよね)。
こういうリーダーシップ論って極端な話が多い気がするんだけど、現実に即して振る舞いを変えるべきだということが書いてあってとても納得した。
コミットメント言語
これは 「XXを△△△までにやります」 ということをチームのメンバーにコミットしてもらうようにする、と言うものだ。これは他の方のブログでは結構炎上していたけど、意図がちゃんと伝わってないのではと思う。
このコミットメント言語には前提がある
- チームがサバイバルフェーズではない(チームに学習するだけの余裕があるといこと)
- コミットメント言語では制御下にあるものを対象とする(コントロールできないことはコミットメントしない)
- メンバーがコミットメントできない(コントロールできない)ことを言ったら、リーダーはコントロールできるものに変更するように依頼しなければならない。
コミットメントをするのは、メンバーに期日や約束を絶対に守らせるようにする!!といった精神論的な話ではなく、コミットメントをすることで、問題を可視化する ためだ。
「今週中にやろうと思ってるんですけど難しいかもしれませんねー」みたいなタスクがずっと宙ぶらりんになってしまった経験はないだろうか。今思うと、こういったタスクは振り返りでもあまり進捗が悪かった原因が話し合われない気がする。
コミットメントしようとしたときに、「XXまでに実施する」といった断定的なことが言いにくい場合には以下のような課題が見える。
- 実は他チームのタスクを抱えていてそれを実施する余裕がない
- タスクの粒度が荒すぎて / 難しすぎて、何から手を付けるべきか迷っている
コミットメント言語は上記のような課題を早めにあぶり出すためのものなのだと思う。
いい兄貴
この本には途中から日本人開発者のエッセイが収録されているんだけど、なかでも伊藤直也さんの話がよかった。チームを良くすることだけに集中して技術や事業の問題に向きあっていないと、本当に組織が困った時(事業が伸びない、プロダクトが使われない、技術的に困難な課題に躓いてしまった)に役に立たないリーダーになってしまうというようなことが書いてあった。
リーダーというとどうしても組織づくりみたいなところに目がいってしまうけど、文字通りチームを技術的に・プロダクト的に「リード」できる人間であり続ける必要があるんだなと再確認した(大変だな…)
まとめ
前に友人のエンジニアと飲んでたときに、「今後のキャリアを考えたときに、マネージメントか技術かどっちに進んだらいいんだろうなー」という話をしたことある。そのときに「suzan2goさんは、マネージメントっていうよりはリーダーシップとかプロジェクトを引っ張ってくとかそっちな気がするなー」ということを言われた。
当時はあまりピンと来てなかったんだけど、この本を読んでいくらかそれがどういうことなのかクリアになった気がする。相変わらず「マネージメントをする」と言われるとちょっと身構えてしまうけど、「リーダーをやる」ということにはこの本を読んで少し抵抗がなくなった感じがする(単純に言い方だけの話だと思うw)。
「リーン顧客開発」という本を読んだ
リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)
- 作者: シンディ・アルバレス ,堤孝志,飯野将人,エリック・リース,児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/04/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
積んでた本をちゃんと読んだ。 前回読んだときは、想像していた中身とちょっと違っていて、最初の数十ページ読んで積んでしまっていた。しかし、改めて読み直してみると現在会社でやっているユーザーインタビューに対してかなり知見を与えてくれそうな本だったので、一気に読んだ。
どんな本?
「顧客開発」というタイトルから、サービスのファンを如何につくるかみたいなマーケティング的な話を想像してしまっていたんだけど、中身はそういう感じではない(なので前回読んだときは途中でやめてしまった)。顧客と対話することで、どんな課題やニーズがあるのか、そもそもその顧客は作ろうとしているサービスのユーザーになってくれるのか、みたいなものを如何に見極めるかという話だった。
この本の殆どの部分は「ユーザーインタビューをどんな風に行ったらいいか」ということに割かれている。ユーザーインタビューで聞くべき質問から、インタビュー対象の見つけ方、どれくらいインタビューを重ねればいいかなど結構具体的だ、本のタイトルから自分はもっと心構えがどうといった抽象的な話が多いのかと思っていたので結構意外だった。
学び
「ユーザーの言うことをそのまま実装してもダメ。本当の課題が何か考えよう」みたいな話はよくあるし自分も思う所だけど、ユーザーとの対話を通して如何に課題を引き出すか・見つけるか、みたいな視点をあまり意識したことがなかったので新鮮だった。
自分はユーザーインタビューで得られた意見に対して「尤もな意見だけど少数派なのではないか」「不満は感じてないと言っているけど、システムに慣れてしまっただけなのではないか」みたいなことをよく思っていたし、どう判断すればいいのかよく分からないなと思っていたんだけれど、そこについてもこの本は色々書いてくれている。
結局は漫然とユーザーインタビューをしていても駄目で、「自分たちの持っている仮説を検証する」という心構えでインタビューの対象者選びをして繰り返しインタビューをしていかないと、得られるものも少なくなってしまうんだなと思った(これはどういう意図のユーザーインタビューだったかにも依るとは思うけど…)。
MVPについてはこの本のメインの部分ではないだろうけど、様々なパターンについて具体例を交えて書かれていて結構参考になる。「最終的な製品をどうするか決めて、MVPとして出すためにカットできる機能を検討する」は「よく耳にする起業家の間違い」とはっきり書いてあってアッ…ってなった。
まとめ
ユーザーインタビューにしてもMVPにしても、「どんな仮説を検証したいのか」ということがはっきりしていないと、それ自体が目的化してしまいそうなので気をつけたいと思った。リーンに開発していくぞ。
RubyエンジニアがGolangのどんなところに挫折して、どんな風に再挑戦したかという内容でLTをしてきた
LTしてきた
【Go言語LT大会! 「最近、Go言語始めました」の会】でLTしてきました go-beginners.connpass.com
内容について
大体内容は前にブログで書いたような話で、 これからGolangを触る人向けに自分はこういうところで挫折した / 再挑戦してうまくいったよって話をした。
要約すると以下のような感じ
- Golangで他のRuby(or 他のオブジェクト指向言語)のやり方を持ち込んでもうまくいかない事が多いよ
- Golangの色んな先人の知見(ブログやGitHubのソースコード)を参考にしたほうがいいよ
- 書く量を少なくするためのハックよりも愚直に書いた方がいいコードになる気がするよ(個人の感想です)
- 一度Golangの書き方に染まってみるときっと楽しくなってくるよ!
感想
- インフラエンジニアっぽい人が多くて、アプリケーションエンジニアはあんまりいなかった印象でした(実際どうだったかは分からない)
- Webアプリ作る時に参考にしたリンクが結構需要ありそうだったので、もうちょっとそっち方向でまとめればよかったなと思った。
- ゲスト講演者のtenntennさんの標準パッケージ紹介が普通に勉強になった。Golangちょっと分かった気でいたけど標準パッケージでも全然知らないことの方が多かった。
- 標準パッケージの内容読むの役に立つよって人が多かった。自分も読んでみようと思った。
- 一緒に行った同僚の前職の後輩の人がいてビビった。更にびびったのはその人が自分のことを知っていてブログも読んでいるという事実。いぇーいXXXさん見てるー!?
- 資料作っていると実は自分がよく分かっていないことが分かっていい。曖昧な知識で発表するのがアレだったので今回の発表内容は結構ふわっとした感じにしてしまったけど、次はもうちょっと突っ込んだ話をしていきたい。
現場からは以上です。
Railsでももっとカジュアルにapp/models配下にクラス作っていいんじゃないかなーと思っているんだけどどうなんでしょうか
Railsのプロジェクトやってると、app/models
には ActiveRecord
だけ、それ以外のオブジェクトは app/services
とか app/forms
層みたいなところに定義しないといけないと思っている人がそれなりに多い気がする。
個人的には app/models
配下に責務を分けたActiveRecordでないクラスを作っていくのはむしろ積極的にやるべきだと思っている。むしろそうしないとXX層みたいなものを導入したとしても、本来モデルの振る舞いとして表現されるべきものが手続き的に書かれてしまったり、新しく導入したXX層の処理がファットになっていってしまったりするのではなかろうか。(ActiveRecord
のクラスと、そうじゃないプレーンなRubyクラスが app/models
に交じるのが気持ち悪いという意見はまあ理解できるけど)
たとえば
たとえば以下のようなクラスがあったとする。
class User < ApplicationRecord def nanka_fukuzatu_na_shori if user.hoge? private_na_method_a private_na_method_c else private_na_method_b end end private def private_na_method_a # なんかの処理 end def private_na_method_b # なんかの処理 end def private_na_method_c # なんかの処理 end end
見るとnanka_fukuzatu_na_shori
と private_na_method_a~c
は明らかに関連をもつひとまとまりの処理なので、こいつらを実行する実態はUserクラスではないところにあっても良さそうな気がする。
これを User::NankaFukuzatsuNaShoriHandler
を作って、そちらに責務を分けてみる
# app/models/user/nanka_fukuzatu_na_shori.rb class User:: NankaFukuzatsuNaShoriHandler attr_reader :user def initialize(user:) @user = user end def perform if user.hoge? private_na_method_a private_na_method_c else private_na_method_b end end private def private_na_method_a # なんかの処理 end def private_na_method_b # なんかの処理 end def private_na_method_c # なんかの処理 end end
( nanka_fukuzatu_na_shori
とかいう適当な名前で書き始めてしまったので User::NanakaFukuzatuNaShoriHandler#perform
みたいにしちゃったけど、Handler
、 Perform
みたいな抽象的な名前は避けたほうが良さそう)
Userクラスはこんな感じになる。
class User < ApplicationRecord def nanka_fukuzatu_na_shori nanka_fukuzatu_na_shori_handler.perform end private def nanka_fukuzatu_na_shori_handler @nanka_fukuzatsu_na_shori_handler ||= User::NankaFukuzatsuNaShoriHandler.new(user: user) end end
基本的にはこんな感じで責務を分割していって、あるモデルの振る舞いとして定義するのが微妙なものだけそれこそXXX層みたいなの作ってやるのがいいんじゃないかと最近は思うんだけど、各社どうなっているんだろう。
- Rails Wayから外れるので止めたほうがよい
- Concern使えば?
みたいな意見はありそうかなと思っています。
参考文献
あなたが成功したいならプライドを飲み込み、外に出ていって、自分が馬鹿に見えるのを恐れないようにしなければならない
最近(もう一ヶ月くらい前)、今更ながらソフトスキルズという本を読んだ。
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
この本場が話題になったのは去年の前半くらいだったと思うんだけど、買った後ちょっと読んで、忙しくなって積んでしまっていた。 あらためて読んだんだけど、タイトルにもした一文が自分的にはいい話だったのでブログにしておく。
あなたが成功したいならプライドを飲み込み、外に出ていって、自分が馬鹿に見えるのを恐れないようにしなければならない
結構自分は「自分をよく見せようとしすぎる」ところがあるなーと思っていて、そういう気持ちが何となくイベントにでて発表したりといったところに億劫になっていた気がする(あんまり失敗したくない・・・恥かきたくない的な気持ち)。
自分は影響されやすいので、この本を再度読み始めた直後に会社にお誘いのあったイベントに登壇してみることにした。 (以下が資料) speakerdeck.com
上記の資料はまあ正直フロントエンドガチ勢の人からするとそんなに参考にならないないようだった気がするし、 反省会というタイトルに引っ張られすぎて辛い内容を盛り込み過ぎたなぁと反省するところも多い。 あと結構当日までビビってて行きたくねーと回りに言いまくっていたりしたw
でもイベント終わったあと色々情報交換したいということで話に来てくれる人がいたり、 他の勉強会とかでお会いしたときに話掛けてくれる人がいたりして、今は登壇してよかったなーと思っている。 (Wantedly経由のお話しませんか的なやつの数も気持ち増えた)
【再掲】あなたが成功したいならプライドを飲み込み、外に出ていって、自分が馬鹿に見えるのを恐れないようにしなければならない
自分が成功しているとはまだとても言えないけど、外に出ていってみることで、色々分かることとか、広がるチャンス的なものがあることはかなり実感できた。今後もイベントがあったら登壇していきたい。とりあえず来週は、最近はじめたGo言語のイベントに出てみることにする。
最近Golangを触っている話
今更ながら趣味でGolangを触り始めた。家庭内アプリ用のAPIサーバとしてGolangを絶賛書いている。アプリはReact Nativeで書いていて、それはまた別の機会に書くことにしよう。
実は一年前くらいにもちょっと触っていて以下のような本を読みつつ、簡単なアプリケーションを作ろうとしていた。
- 作者: Mat Ryer,鵜飼文敏,牧野聡
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/01/22
- メディア: 大型本
- この商品を含むブログ (2件) を見る
- 作者: 松尾愛賀
- 出版社/メーカー: 翔泳社
- 発売日: 2016/04/15
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (5件) を見る
が、ちょうど仕事が忙しくなる時期と重なってしまったり若干モチベーションが落ちてしまったので、最近まではRailsにずっぷりだった。
Golang楽しい
一年ぶりに触り直してるんだけどとても楽しい。前回多少学習していたという貯金が効いている説、この1年で自分が成長している説などあるけど、明らかに前回触ったときより楽しい。 具体的には以下の辺が。
- gofmt、golint… などで書き方をかなり強制されるので迷わず書ける。
- ので、どうロジックを書くかといった部分に集中できる。
- フルスタックなWAFのようなものはないので、自分で色々設計について考えられる(考えなければいけない)
- (これは完全に自分の個人的な感想)ちょっと書く行を減らすためのハックより、愚直に書くことが好ましい雰囲気があるきがしていて、愚直に書けばいいやーという気持ちになる
- 「それ標準パッケージでできるよ?」といったマッチョな思想があるきがしていて、ベストプラクティスを追い求めなくてよい(と、いいつつ、
echo
やgorm
を使っているけど…)
ここからは静的言語ならどれでもそうなんですが
- コンパイルが通れば、大体動くという安心感
- エディタ上で型、引き数が補完されるので、一々リファレンス眺めなくてよい
SIでJavaやってたときも同じメリットはあったはずなんだけど、全然思い出せないし楽しいと思ったことあんまりないな。なぜだ。
なぜ一年前はあんまり楽しくなれなかったのか
たぶんGolangでRubyっぽいことやろうとしていた。Golangにはクラスがなくて構造体しかない。で、構造体を利用して、オブジェクト志向っぽく書く方法はいくつかあるにはあるけど、Rubyと同じような作りで書けるわけではない。なのに一年前はRuby(というかRails)のような書き方をしようとして、色々調べた結果うまく書けずそこでやる気が失われてしまった部分はあると思う。
Goに入ればGoに従え
今回はアプリケーションを書き始める前に、GitHubでいくつかrepositoryを見てみたり、いくつかブログを読んだりして、みんなどんな書き方をしているのか見て回っていた。そのおかげで、Golangではどう書くのかーというところをある程度インップットできたと思う。GolangをGolangらしく書くことで、楽しくなったきた気がする。
Golangからの学び
Golangで今更ながら型の有り難みを噛みしめるようになった。エディタの型補完や、コンパイルが通ったときの安心感とか。 型のある言語からRuby/Railsに来た人が「型がないのが怖い」的なことを言う理由がちょっと分かった。自分がJava => Ruby に行った時には型がなくて怖いなんてことは思わなかったんだけど何で今更こんな感覚を持っているんだろうな・・・。Golangで書くようになって、インターフェース的なものを前より意識してプログラミング書くようになった気がする。
React NativeでJS書くときもflowをちゃんと使うようになった(前は使っていたけど面倒になってやめてしまった・・)。ライブラリの選定も「これくらいなら自分で書けばいいかー」という思想になってきた。
まとめ
お気づきの通り、Goに入ればGoに従え
を言いたかっただけの記事です
最近アプリケーションの設計するときに気をつけてること
最近、機能の設計をレビューしたり話し合ったりするときに、うん・・・?ってなることがあって、でも駄目な理由をうまく説明できなかったのでちゃんと言語化してみる。ちなみにRailsの話です。
DBには事実だけを記録するようにする
色々開発してきて思ったのは、テーブルに状態を持たせるようにするとあっという間に複雑度が増してしまうということ。 status
カラムや hoge_flag
みたいなカラムを持つこと自体は全然否定しないけど、本当にそれが最適なのかは慎重に考えた方がよいと思う。
これは例ですけど、会員申し込み => 何か審査 => 会員登録完了 みたいなフローのアプリケーションを作る時に、会員情報のテーブルを1つだけ作りstatus
、approved_at
みたいなカラムを突っ込んで、申し込み状態と申込み完了状態を
アプリ側で頑張って判定しようとしている例はまれによくある。
こうすると何が辛いかというと、他のレコードから関連を辿って参照しようとしたときに常にレコードのカラムの状態を気にしないといけなくなってしまう。それに申し込み時の情報と、会員登録後に必要になる情報は必ずしも一致しないはずなので、作ったときは同じだとしても後々拡張するときに辛くなってくる。また、会員情報にDB上のユニーク制約をかけたくなっても掛けられないのでアプリケーションでかけるしかなくなる。(そしてアプリケーションで掛けた制約は結構簡単にすり抜ける…)
こういうときは事実が何なのかに着目すると、きれいに設計ができると思う。今回でいうと申込み
というテーブルと 会員情報
というテーブル二つに分けてしまう。そうすれば上記にあげたような懸念はスッキリ解決する。
同じようなカラムが二つのテーブルに別れることを懸念するかもしれないけど、本来違うものを同じテーブルに押し込むことのデメリットの方が大きい。
同じような理由で論理削除もよく考えたほうがよいと最近は思っている。削除という状態を追加するよりも、素直にそのテーブルからデータは消してしまい、必要な情報だけ履歴的に別のテーブルにコピーしておいた方がアプリケーションをシンプルに保つ事ができるとおもう。
安易にHashを作らない
「Rubyはダックタイピングなのでそんなに厳密にやってもしょうがない」みたいな話は一定理解するし、そういうゆるさがRubyのいいところだと思いつつも、巨大なHashを作ってそれを色んな所に引き回したりするのは結構最悪だと思うようになった。Hashに何が入っているか、何のkeyを持つべきなのか実装を全部追わないと分からないからだ。
そしてHashが巨大化していくると、そのHashを操作するための実装がそのHashを引き回す側に出てきたりしてあっという間に良くない感じになっていく。
何かを作る場合も、ハッシュではなく、クラスを作ってそこに attr_accessor
を定義したほうがよいと思う。そうしておけば、クラスを見ればどんな値を持つべきなのかすぐに分かる。それに、値の中身を書き換えたり、デフォルト値を与えたり、変換したりといった処理をそのクラスに押し込めていくこともできる。
まとめ
最近考えたことをまとめてみた。定期的にこういうの考えて吐き出しておきたい。