# 奮い立つ どうも、日々エンジニアリングに奮闘している前田です。 さて、今日は古いたつというテーマで話していきます。 ヤバンナアジャイルという本を読みました。 その感想を話していこうと思います。 もちろん、僕の経験も添えて。 この本は、サイボーズという会社の天野さんという方が、 その会社、サイボーズにいかにして、そのアジャイルを浸透させていくか、 ということを書かれた本になります。 なので、本当に現場で起きた課題感とかが、そのまま書いてあるので、 僕はすごく楽しく読めましたね。 他のエンジニアっていうんですかね、他の組織というか、 世の中にいるエンジニアが、皆さん頑張ってはいると思うんですけども、 そのうちのより具体を知ることができて、すごく嬉しいというか、楽しい気持ちになりました。 この本を読んで、いくつか話したいなって思ったことがあります。 何個あるのかな。いっぱいあるので、先に何個とは言えないんですが、 まず1個目なんですが、なぜを問えない開発現場。 これ天野さんが書かれていました。 これが天野さんは一番苦しかった、かなり苦しかったと書かれています。 もうそのまま一旦読むんですけども、その前に確認させてください。 この機能の目的は何ですか。どのユーザーのどんな課題を解決するんですか。 狙いを理解しから見積もりたいのですが。 と聞いたところ、この開発計画で事業戦略の承認をもらっているので、大きな方針転換はできません。 細かい仕様の調整は可能ですが、機能の追加、削除については既に決まっています。 でも、もし方向性が間違っていたら、承認プロセスをやり直すと、リリースが数ヶ月遅れます。 この方針で進めましょう。このような感じのやりとりがあったと書かれています。 サイボーズはチームワークあふれる会社をつくるという理念があるんですが、チームワークとはと疑問を持ったというようなことも書かれていました。 このなぜお問い合いが一番つらいということを言ってました。 これ、僕自身の経験に重ねて考えてみると、こういうことをエンジニアとして働いていればよくあることだと思います。 何か追加の機能、変更があったときに、何でこれをつくるんだろう、何でこれを変えるんだろうって考えることはあるし、 また、この理由がよくわからないと納得できないで開発が進むということもあると思います。 僕はあるタイミングのときから、あんまり納得ができないときっていうのは、ちゃんと自分の意見があるので、 そのときは疑問を投げかけたり、またこういうふうにしていったほうがもっとよくならないですかっていうことをちゃんと伝えるようにしています。 ただ、これね、開発者全員がこの変更の方針に納得感を持つっていうのは、それは組織としては結構難しいことでもあると思っています。 全員が納得してからじゃないと開発が進まないってなったら、一個に進まないので、 これは、最終的に責任を持つ人がこれでいくと決めたのであれば、それはちゃんとやるというスタンスで僕は仕事をしています。 ただ、その疑問があればある、聞くし、ちゃんと自分の意見も伝えると。 Disagree but commitっていう言葉ですかね。これを僕はやっていますね。 ただ、なぜを問うことができないっていうのは、また別の話でやっぱりしんどいなって思いますね。 これが一個思ったことになります。天野さんの考えというか、経験に結構共感をすることが今まであったなという話です。 2つ目なんですけども、ソフトウェア開発の問題は技術よりも人と組織にあるっていうふうに本に書かれているんですね。 正直ここ、なんとなく僕も分かるんですけども、ここ解像度弱いです。 天野さんは、これはPeopleWareっていう本、書籍を読んでガツンときたっていうような描写がありました。 僕は、天野さんがガツンときたこのPeopleWareっていう本が気になって、そのうち買って読もうかなって思ってます。 なんでここの解像度浅いんですけど、とりあえずドックイヤーといいますか、気になる部分だったなと思います。 今の話の延長線上か、なんですけども、そうなってくると、組織のやり方とかに何か課題があるんじゃないか。 その課題やり方を作ったのは誰か人だから、その黒幕を天野さんは探し始めたんですね。 今の開発プロセス、誰が決めたんですか。何を参考にしたんですかと上司に聞きました。 誰かが決めたわけじゃないよ。問題が起きるたんびにみんなで考えてルールを追加してきた。その積み重ねだよ。 え、じゃあ正解だと思ってやっているわけじゃないんですか。正解かどうかはわからないけど、その時々でベストを尽くしてきたつもりだよ。 っていうようなね、会話やりとりが本の中にそのまま記載があります。 だから誰かが悪意を持って作ってきたプロセスじゃない。プロセスも生き物だっていうことを言っているんですよね。 今あるルールが当たり前だと思わずに、毎回毎回本当に必要なのか、これを問い直すことが大切なんだよってことを言っていると。 あと3つ目か、そうなってくると。今のが2つ目でした。3つ目なんですけども、これね、あえてデジタルで管理できるのに、あえてアナログな看板を使う。 ここから結構流れが変わったっていうのを天野さんは言っていました。 サイボーズって会社なんで、Kintoneっていうアプリがあると思うんですけど、これでタスク管理をしているんですけども、自社で使っている、自社の展開しているサービスですよね。 Kintoneでタスク管理をしているけども、あえて物理的な看板を作ったらしいんですよね。 これ一見すると二重管理で無駄な作業なんだけども、ここから開発フロアの景色が変わり始めたと言っています。 二重管理っていうのも天野さんも本の中で言っていますね。 だけども、この物理的な看板を置く効果がやっぱりあるということを言っていると。 僕、これ何の本だったか忘れちゃったんですけども、他のアジャイル開発の本とかを読んだときにも、看板を置くの効果あるっていうのを聞いていて、読んだりしていて、やっぱ実物は強いのかなって思いましたね。 本の中では、実物の看板があることで自然とタスクが目に入り、会話が生まれると。 これが重要なんだっていうようなところになったので、すごく気になっています。 ただ、僕の会社今、週一でのエンジニア出社になるんですよね。 僕はほぼ毎日行っているので、管理することはできるんですけれども、その場合でも意味あるのかなとかってことはちょっと思っちゃってますね。 正直、やりたいはやりたいんだけども、今の所属している企業でパフォーマンス高いかっていったら、業態効果が高いかっていったら、ちょっとわからないなって思っちゃってますね。 あともう一つ、最後の方にですね。チームギーク、もしくはアジャイル侍からの引用があった文章を持って、天野さん頑張って踏ん張ったみたいな話なんですけども、この一文めちゃめちゃかっこいいんで、一旦読みます。 正しいことをして、解雇されるのを待とう。私はGoogleと世界にとって正しいことをしている。あとは座って解雇されるのを待つだけだ。解雇されなければ正しいことができたことになる。 解雇されたら雇用主を間違えたのだ。いずれにしても私が正しいことをしている。これチームギークからの引用です。もう一個、アジャイル侍の方からなんですが、そうおっしゃるのならそうなのでしょう。 でも結局のところ、君の働き方や仕事の質を選んでいるのは、他の誰でもない君自身なのです。現実は厳しい。その通りです。でもやるんだよ。それが君の成すべきことなんだとしたらねと。この二つの文章、めちゃめちゃかっこいいなって思っています。 まさにこの言葉を天野さんは実践してきているんだなというのを思いました。僕もこう生きていきたいと思いましたね。今日はこんなところですかね。本当に刺激を受けたから、さらに本も読みたくなりました。 あの野蛮なアジャイルの中で天野さんが刺激を受けた本が、今僕が紹介してきたようにいくつかあります。アジャイル侍、チームギーク、あとはピープルウェアか。ピープルウェアに関しては初めて僕本を聞いたんですけど、そもそもエンジニアリングの本なのかな。 まあ本屋行って調べようかなと思っています。で、読みたいなと思っています。はい、この本を読んで三つね、次の読みたい本が出てきたというところです。今日はこんなところです。野蛮なアジャイルを読んで震い立たされたという話です。 はい、こんな感じで僕の考えたこととかをコミットログとして残していっているのがこのチャンネルになります。良ければフォローしてまた次回も聞きに来てください。今日は以上になります。