カイゼンジャーニー たった1人からはじめて、「越境」するチームをつくるまで

昨日から読んでるがめっちゃいい話しなのでいまのうちに書いておく。 感想はまた後日。

この本は「いまの会社やめようかな…」と考えている人や「うまくチームが回ってないな」と感じている人向け。 どこかで聞いたことがあるようなどう改善していくのか、またその仕組みを取り入れる目的や目指す地点が丁寧に書かれている。

ストーリー仕立てで進行するため「あるある〜」という感じでスラスラ読めていく。 いまのチームや会社で働いている人に対してはないが組織やマネジメントなどで不満があるという人には是非一読してほしい。

そこから何を感じるか、どう動くかは個々人毎に違うだろうけども、その際の1つのガイドブックとしてカイゼンジャーニーはよい手助けをしてくれるだろう。 なお、↑ではアフィリエイトリンクを貼っているが現在出版元の翔泳社では電子書籍半額セールを行っている。

www.shoeisha.co.jp

期限が2/21までということなのでぼくの中では異例であるが読んでいる最中に書籍紹介をさせてもらった。 どうせならぼくのアフィリエイトリンクから購入してほしいがちょっと興味ある程度の本だからなーと躊躇しているかたは翔泳社さんの半額セールを利用するといいんじゃないかな! っていうか発売日に半額セール対象になるってどういうことだよ!!!

…失礼、電子書籍版を定価で買った負け犬の遠吠えでした。

ということを昨晩Twitterに #しがないラジオ のハッシュタグつきで連投してしまったのでブログに書いてます、はい。

とりあえずパーソナリティーのガミさんは買ってくれたらしいので、「よっしゃ!」という感じです。 きっと読み終わったらpodcast内で紹介してくれるやろー!とか雑な感想です。

RubyKaigi 2018のSuper Early Birdに申し込んだ

rubykaigi.org

多分日本で一番有名なカンファレンスなんじゃないかと思うが初RubyKaigiのSuper Early Bird枠が買えそうだったので思い切って買ってみた……ところ買えてしまった。 ということでよちよちRubistsだけど参加することになった、あったことある人やTwitterとかで知ってまっせ!というひと気軽に声かけてくだされ〜(知り合いがほぼいないので)

1月のやっていきログ

先月は中盤くらいまでいいペースだったけど後半に体調不良で一気にペースダウンしてしまった。優先順位の設定とかやろうかな…。

昨年末、やっていくぞ!という思いを新たにしたところ、さっそくフラグを回収してしまいました。 どうしてこうなった…。

やったこと:

やり残していること:

できなかった原因:

1月中旬くらいまでは遅れ気味だがそこそこのペース配分でいろいろ進められていたと思っている。 問題はそれ以降から月末まで体調を崩し気味だったこと。

早く治そうと早めに寝たりしていたのだが一向に回復しなかったせいでインプットに当てる時間やアウトプットに当てる時間がほぼなくなってしまった。 それどころか完全に体調を崩して熱がでて何日も寝込んでしまった。

これによって大幅に計画が狂った。

リカバリー:

とりあえずまずはRailsチュートリアルを最優先でやっている。 これは1月中旬まではインプットが順調だったため、2月は多少インプットを減らしても挽回できそうだなと思っているから。 なのでやり残していることを「Railsチュートリアル写経」→「Go言語でチャットアプリ作る」→「テスト駆動開発読む&写経」で考えている。

テスト駆動開発Rubyでやっていきたいと思っているがGo言語でもいいかもしれない。

最後に

ゼノブレイド2が全然終わってくれなくて非常に時間的制約が厳しい。

合議制の話しからプロジェクトマネージャーとプロダクトマネージャーの違いに思いを馳せてた

合議制は駄目なシステムか?

medium.com

製品開発の目的は社内の人を満足させることではない

とあってここ最近似たようなことを考える機会があったのでかなり得心がいった。 合議制はある種リスクの分散を目的としてる節があるとぼくは感じていて、 その結果リスクを分散する代わりにあなたの意見も取り込みますよというスタンスにみえる。

結果、合議制で出来上がったものはどこかでみたことのあるようなもの、あるいは劣化版ということになりがちだ。

少なくともスタートアップやベンチャーのような企業やチームであれば合議制で同意をとっていくのは悪手だと思う。 そんなコンセンサスをとってどこにでもあるなにかを作るくらいなら「これしか出来ないがこれだけはどこの製品よりも尖ってる」製品を作るほうが生産的であると感じる。

傲慢であればよい?

じゃあ意見を聞かない傲慢なマネージャーになればいいのか?というとそれは極端すぎる例だと思っていて、 1人が持ち得る視野の広さは有限であり、またバイアスがかかっている。 それはバイアスに関しては属人性が高いので良い面もあり悪い面もあるという感じだが視野の広さという点では個人が持ち得る視点はどうやっても限界がある。

全てを見通す神の眼でも持ってるなら別だが、人類にはレベルキャップ解放されていないので神の眼は装備できない。 つまり、人海戦術でマネージャーにとっての考慮外を潰すのがベターとなる。

大企業などであれば凡庸な製品を作っても問題ない部分が存在する。 大多数の人間を満足させ得るプロダクトを作るとなると合議制で決まったような平凡だが堅実な製品が好まれることもあるだろう。 ただそれはブルーオーシャンだから許されるとも思っている。 レッドオーシャンになったときに同じことをしていても他社だって同じようなものを作るだろうからそことの差別化を図らないと遠からず追い抜かれて、時代遅れの産物になってしまう。

おうさまとさいしょう、あるいはしょうぐんのはなし

閑話休題。 そうして考えていたときにふと「プロダクトマネージャーは製品の絶対的な決定権を持っている役割でその分多くのリスクも抱えた存在なのではないか?」と思い至った。 いままでプロジェクトマネージャーとプロダクトマネージャーの具体的な違いがいまいちピンとこなかったのだが以下のような理解をしたところ少しだけ靄が晴れたように感じた。 全体としてはまだまだ理解が甘いと思っているが少しだけ理解できた気分になっている、今は少なくともこれでいいのかなと思う。

つまりプロダクトマネージャーとは王様なのだ、そしてプロジェクトマネージャーは宰相や将軍という役割なのだ。

王様が「ここ最近税収さがってるから農業改革するぞ!」と号令をかける ↓ 宰相や将軍がそれを受けて「税収下がってるのは川が氾濫しているから。じゃあ農業改革して税収増やすには治水工事だ!」と道筋立てていく。 ↓ それを元に官僚たちが詳細を詰めていく

こんな感じの理解であってるのかわからないがそうすると確かに2つの役割は明確に違うし、同じにしてはいけないということがわかる。

プロダクトマネージャーはプロダクトの成否まで含む全てのリスクを負い、何故それが必要なのかを示しつつ、進むべき目標を定める。 プロジェクトマネージャーはそのプロジェクトが円滑に回るためのリスクを負い、そのために必要なものを揃えていく

こう考えたところ、自分のなかで妙にしっくりときた。

まとめ

両方とも略称がPMだったり、いままでプロダクトマネージャーとプロジェクトマネージャーが(少なくとも明示された)仕事をしたことがなかったのでいまいち理解できていないなと思っていたが少し理解が進んだように思う。

大きなリスクを負うからこそ彼ら、彼女らは大きな報酬を得ているわけなんだけども、たまーにそのリスクを背負わず(背負えず?)にその席についている人がいると不信任決議案を出したくなるという気持ちにもなり「マネジメントとか人の評価って本当に難しいなー」という雑な締めくくりで終えたいと思う。 ここから先は藪蛇というか生半可な知識で足を踏み入れるとものすごい数のマサカリが飛んできそうだなーと思うので自粛しておく。

しがないラジオ sp 14の補完・補足

紹介:

sp.14a【ゲスト: lucca0show】楽しいコミットメントの始め方

shiganai.org

sp.14b【ゲスト: lucca0show】楽しい積ん読カンバン術

shiganai.org

ゲスト出演しました! …がいくつか話していて説明不足であったり、うまく説明できていないなと感じることがあったので補足話を書いておこうと思います。

好きなことを仕事に!だけでは難しい:

よく「好きなことで食べていく!」とかキャッチフレーズみますよね? ぼくは割りと好きなことを仕事で生活できていると思っているんですがゲーム業界で働いていたときに「ゲームが好きってだけだとこの業界で働き続けるのは難しいなー」と実感したということが伝えたかった主題です。

実際にゲーム業界で働く前は「好きのレベルが低いんじゃない?」という疑念が頭の片隅にあったのですが業界で働く内にその幻想は木っ端微塵に砕け散りました。 主に悪い方向で。

podcast内で補足してもらえましたが好きにもいろんな形があって、ゲームを作るのが好きなのか、作ったゲームを遊んでもらうのが好きなのか、ゲームをプレイするのが好きなのか…それぞれいろんな形の「好き」があります。 アニメや漫画、ゲームなどのエンターテイメント系はこれらの境目が曖昧なことが問題の1つだとぼくは考えていて、 そのときに「好き」だけではなく「楽しめる」という軸がないとうまくいかないのだと実体験から結論を出しました。

なんというかこの2つはどちらが上とかではなく車輪の両輪のようなものだと思っているというのが正直なところです。 「好き」という原動力が「楽しむ」というエンジンで加速エネルギーを得ていく…とでもいうのでしょうか? どちらかだけでは疲弊してしまい、人によっては好きが反転してしまうこともある…ということを伝えたかったのです。 説明ベタで申し訳ない。

Write Code EveryDayを4ヶ月してみた:

podcast中で語ろうと思ったままついつい忘れてしまったのですが実はぼくはいま現在毎日コードを書いているわけではないです。 というのも自分の課題として基礎的な技術力が不足しているという思いがあります。 その基礎的な技術力を向上させるためにはまず質の良いインプットが重要だと考えました。 ところが毎日ある程度とはいえコードを書いているとなかなかまとまった質の良いインプットを行うのが困難であるということに気づきました。

そこで意図的にインプットの質と量を担保するためにそれまで継続して書いていたコードを毎日書くのではなく、書けるときにだけ書くという方針に変更しました。 これはGithubの草を生やすことが主題になってしまっているように感じていたことも1つの理由です。 「イシューからはじめよ」でいうところの「犬の道」に自分が陥っていると感じたからです。 これはpodcast内でブログをただ書くだけでは難しい…といった発言にも共通している思いです。

結果はまだまだついてきていませんが、目的の部分がブレているとはまだ思っていないのでそのうちまた毎日コードを書く日々に戻ってくると思っています。 いまは充電期間のようなものだと考えて、しっかりと質の高い、あるいは高くなるようにインプットに専念したりしています。

ブログ執筆の話し、書いてるだけではうまくならない問題が難しすぎる:

この問題は多分ぼくにとってある種の転換点を迎えたからこそ発生しているのだと思っています。 昨年、期せずしてElastic Leadershipという書籍を紹介したところ変な形でバズることとなってしまいました。 そのときに「伝えたいことがしっかり伝わらない」という思いをしました。

ここが転換点だったのだろうと思います。 その瞬間からぼくは「ぼくだけのブログ」から「読者に伝えたいブログ」に変化していったのだと思います。 いわゆるコンテキストを共有している人からは好意的なコメントをいただきました。 一方、コンテキストが共有できていないと感じる方からは「コミットメント言語は日本人の文化にあわない、圧迫されてしまう」というコメントを沢山いただきました。

コミットメント言語は手段であって、目的ではないのですがそこがしっかりと伝えきれなかったなと今にしては思います。 バズっていたときは「それはチームの問題でコミットメント言語自体の問題ではない」と思っていたのですが コミットメント言語を手段として用いるその目的や目標をたしかに明確にしていなかったなと最近は考えることがあります。

先程もちらっと書きましたがそのことに気づいたとき「ぼくのブログを書くのはただ「犬の道」になってやしないだろうか?」という思いが頭をよぎりました。 そういう思いや考えから件の発言元である「ただ書くだけで上達するわけではないので難しい」という主旨にたどり着きます。

自分のスキルに不安があるので転職迷う問題:

概ね自分の考えはpodcastで語った通りなのですが一点だけうまく伝えられなかったと聞き直していた際に感じたことがあったので補足しておきます。 ぼくがpodcast内で「フリーランスを意識するほうがよい」という主旨の言葉を使っていますがこれは実際には正しくなく「自分の価値を常に意識する、そのための方法として転職やフリーランスを常日頃から意識すると良い」というのがぼくが考えていた思いに一番近い回答となります。

フリーランスになることそのものが重要なのではなく、「自分の価値を自分で見極め、知る」ことが肝要ということが伝えたかった全てです。 podcast内でも語っていますがぼくは自分の副業先の給与を時給換算でいただいています。 そして副業をしているときにふと自分の価値を客観視し、「ぼくの技術力はたったこれだけの価値しかないのだろうか?」と感じる結果となりました。

実際問題、副業先のスタートアップはそこまでお給与を支払えるわけではなく(フリーランスの人のほうがコミットメント率が高く重要だったとかの理由はある)ボク自身も契約当初はどれくらいコミットできるかわからなかったこともあり、納得の上で給与を決めたのですがそこには「これだけ高い給与もらって結果が出せなかったら怖いので低く見積もろう」という心理がありました。

結果から言うとそれは大きな間違いでぼくは自分の価値をもっと真剣に査定すべきだったのだと思います。 いまだにぼくは自分の価値の適正値がわからないです、ですがそれは自分の価値と向き合わないということと等価ではないとも思っています。

ぼくらは自身が持つ自由な時間を労働して成果を出すことで会社から給与をもらっています。 もちろん諸々の経費などは差し引かれているでしょうが、そこにはそれだけの価値があると会社に認められているわけです。 自分の価値を低く見積もるというのは自分自身を卑下して貶めているようなものだと最近は考えるようになりました。 その行いは自分と、自分の価値を認めてくれるひとたちに対して不義理で、あまりに失礼な行為ではないかとも思っています。

とはいえ、スキルがないと自分の価値を認めにくいのも真理です。 だからこそフリーランスや転職のように他人から見た評価を参考にするのが良いとぼくは思っているのです。 いまの自分のスキルセットはどのくらいの市場価値なのか?を意識することは十分価値があるし、またもし転職することになった際にも話のネタになります。 転職するしないは関係なく、自分の給与が実力に対して適切に評価されていない場合1つの提示する資料にもなります。

転職サービス側からすると迷惑千万な行為だと思いますが、市場価値を知るために転職サービスに登録しておくのは割りとコストパフォーマンスのよい施策でないかなと思っています。

出演してどうだった?

概ねいいたいことは言えたかなと感じています。 ビブリオバトルについては語れなかったので次回出演するか、自分のpodcastでやろうと思ってます 反省すべき点は多々あるのですがパーソナリティのお二方に助けていただいて非常によい体験をすることが出来たと思っています。

どうしても対話というベースや技術系の話しではないため、議論的というか話しが盛り上がってしまい時間が長くなってしまったのがpodcastというものの難しさを改めて実感しました。

どうしても1人だとうまく掘り下げられない内容もパーソナリティーの方がいるといい感じにまとめてくれたり、思わぬ方向からの意見をいただいて改めて考えるきっかけになるなと感じました。

ぼくはネット弁慶の割に打たれ弱いので基本的にあまりエゴサをしないようにしているのですがついつい誘惑に負けてしまいTwitter上で検索してしまいました。 いろんな意見やぼくの意見の補足、共感、反論諸々読んでいて自分の発した一言が与える影響がこんなにあるのかと新鮮な驚きを得ています。 そして改めて自分のためのpodcastをやっていこうと思いを新たにしました。

いつになるかはわからないけども自分の中でこのくらいの時期に行いたいなという獏っとした思いがあるのでリリースしたらTwitterやブログで報告させてもらおうと思います。 あと、今回ヘッドフォンから自分の声が聞こえてきたり、思った以上に早口だったのでしがないラジオにリベンジしたいですね!

プロを目指す人のためのRuby入門

2017年中に読了する予定だったがゼノブレイド2やってたら諸々あって2週間遅れで読了した。

対象:

本著の冒頭でも語られている通りプログラミングの未経験者がこの本を読了するのはかなり根気がいることだろうと思う。 プログラミング初級者(初心者でない)が次のステップへ行こうとするときに読むべき本であると感じた。 一方で手元にあって困ることがない本だとも実感した。 他の言語である程度プログラムを書くことが出来る、あるいは最低限if文、for/while文、関数がわかる人が対象としてボリュームゾーンであるように思う。

感想:

結論からいってしまうと個人、というよりは業務でRubyを扱うことがあるなら1冊教育用途で置いていてよい書籍だ。

本著を手に取るきっかけとなったのが目次の例題が非常に適切なレベルで設定されているように感じたからだが結果振り返ってみるとそれは正しかったように思う。 4章の繰り返し制御や配列、ブロックなどの概念や使い方ハマりどころは以前Railsでアプリを作っていた際に「よくわかっていないがサンプルとして書かれている通りにかけば動く」というものを十分に解決してくれたし、5章のハッシュやシンボルを理解するも大いに不勉強な知識を補完してくれた。 ぼくの今までの主言語がPHPだったこともあり、なにがRubyとその他の言語で違うのか?が書かれているのは非常にわかりやすく、またハマりどころを事前に教えてもらえたと実感している。

クロージャーの振る舞いの違いやサンプルコードでなく実務でよく見かけるような書かれ方をしたコードの説明などがされており、まさしく入門として正しい1冊だと感じた。

カバーに「Railsをやる前に、Rubyを知ろう」という一語があるが自分が如何にRubyを知ることなく、極端な言い方をしてしまえば「舐めていた」かを直視することとなった。 まだまだyieldやProc、それにシンボル。 そしてなによりもクラスのPublic/Private/Protectedの概念はまだまだ自分のなかにしっかりと根づいていないと感じている。

そうそう、本著ではRubyらしいコードの書き方が乗っていることがある。 Rubyにはいくつもの書き方や実装の仕方があり、独学の初心者や初級者は相談する相手がいないことが多いため、どの実装を選択するのがベターかわからず戸惑うこともあると思う。 会社であれば先輩社員や詳しいひとにレビューをお願いすればいいが、独学ではなかなか難しい。 全体的な総量としては少ないが本著にはその点について言及されているところが何箇所かあり、そうすることの意図も非常に明確に書かれている。 今後迷ったときにどれを選べばいいのかの判断基準になりそうだと感じた。

もしあなたが他言語のプログラミング経験はあるが、Railsを覚えたいと思うのなら最初に手にとって読む1冊として最適だろう。 恐らく幾つかの内容についてRuby独特の解釈で戸惑うことや思考が追いつかないことがあると思うが、それがRubyという世界の流儀なのだろうと思う。 今後の目標としては以前挫折したRailsチュートリアルやPerfect Ruby on Railsなどを写経していわゆる「Rubyらしい」書き方を身に着けていこうと思っている。

2018年の抱負

今週のお題「2018年の抱負」

まだ第1週なのでセーフだろうという自分ルールを適用したい。

具体的には3つ。

英語のアウトプットをする

インプットは最悪1人でも出来るけど喋るのは1人じゃ無理なので英会話教室でも行ってみようと思ってる。 そこでまず苦手意識を克服することを目標、目的は外国人に喋りかけられてもネガティブに感じなくなるようにする。 流暢に喋れなくてもいいし、単語が出てこなくてもいいけど今のぼくは伝えることに対して非常に腰が引けている状態なのでまずはそこの意識改革が大事だと思う。

あと最近感じたことなのだけどアジア圏の人が英語で話しかけられても身構えることが少ない(ネイティブでなければ)のだけど白人黒人だと身構える事が多いのは多分意識の問題でここを乗り越えれることができたらある程度喋れるようになりそうだなと思ったりなんかした。

英語をやっていくぞ!

インプットの量と質を保つ

実質的には昨年末からだけど積ん読をカンバンで管理する、ということを行っている。 量に関してはこれで担保がほぼされているので質をどうやって保つか?が今年の課題だと考えている。 読むだけでは身につかないのでなにかしらの改善策が必要、そこを考えて是正していく。

欧米(イタリア)に旅行する

ぼくは小学生の頃にグアムにいったきり外国にいったことがない。 ところがイタリア、特にヴェネツイアには行きたいと常々思っていたが実行していないし結婚したりすることが今後あるかもしれない(特にいまそのような予定も相手もいないが) ということでやるぞ!と宣言することで自分を追い込もうと思う。 ちょうど?妹夫婦がドイツにいるのでついでに挨拶してこれたらいいなと思う。

できれば夏くらいが理想。

あれ?Podcastは???

これはすでにやることが決まっている決定事項なので抱負ではない。

以上。 とりあえず旅行はスケジュールやらパスポートやら事前に用意する必要があるので早め早めに対応していこうと思う。