blog.nishimu.land 呼びかけられたような気がする(?)ので、思っていることを素朴に書いてみます。 まず一番大事なこととして「成果を出せているのか？」があると思っています。 「ユニコーン企業ではスクラムなんかやってない」ことが注目されるのも、ユニコーン企業だからこそです。 なので、成果を出せているのならスクラムじゃなくても何でも良いと思っています。 以前勤めていた会社はトップダウンの会社でアジャイル的な思想とは真逆だった気がしますが、天才プロダクトマネージャーの差配で回ってました。 回ってる内は、別にそれでいいと思います。 scrapbox.io これは、自然状態から成果を最大化するための課題に向き合っていくとこういう変遷を経るケースが多いんじゃ無いか、という僕の予想です。 この予想では、アジャイルソフトウェア開発に行き着くことになっています。 ただ実際は、例えば先ほど挙げた

SNSを見ていたり人の話を聞いたりしていると、「職場で攻撃的な物言いをしてくる人に困っている」ということがある。 攻撃的な物言いをされる側は気分が落ち込んで生産性が下がったり、最悪退職してしまう。 そして攻撃的な物言いをする側は、いくら指摘しても態度を改めない、というもの。 割と長期間に渡ってそういう話を見聞きしてきて自分なりに思うことがあったので、書いておく。 攻撃的な物言いをするメリットはほぼ無いはず 言われる側の心構え 攻撃的な物言いをするメリットはほぼ無いはず 何かを指摘する際の目的は何なのかと考えてみると、指摘をすること自体は目的ではなくて、大体は相手に素早く正しく動いてもらうことが目的だと思う。 その観点で最適な指摘の仕方を考えてみたときに、本当に攻撃的な物言いが最適だと思えるならそうしたらいい。 けど、多くの場合は相手の反発感情を煽って咀嚼に余計なエネルギーを要したり、最悪怒

アジャイルとは、トライアンドエラーを効果的に行うための知識群、だと思う トライアンドエラーするのはどういうときかというと、やってみないと分からないとき やってみないと分からないときはどういうときかというと、その時点での能力を超えた仕事をするとき 能力を超えた仕事をするとき、成功が目的であることに変わりは無いけど、計画と実行よりも学習と軌道修正が重要になる 最初に立てた計画は間違っているため プロダクト開発の領域は大雑把には、ディスカバリーとデリバリーに分けられる ディスカバリーにおいて十分な能力を有している=つくるべき正しいものを見極められている場合、ディスカバリーにおいてアジャイルである必要は無さそう 例えば、受託開発のような場合はつくればお金がもらえるということになっているので、アジャイルになろうというモチベーションは低そう デリバリーにおいて十分な能力を有している=やるべき正しいつく

必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす

引き続きリモートワークに関心があるので関連書籍を読んでみています。前作「小さなチーム、大きな仕事」は未読です。 強いチームはオフィスを捨てる 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン発売日: 2014/04/01メディア: Kindle版 どこにいても世界中の人と簡単にコミュニケーションできるのに、なぜオフィスが必要?人生の大切な時間を通勤に費やすのはナンセンス!優秀な人材と一緒に働きたければ、物理的距離なんて関係ない!前作『小さなチーム、大きな仕事』で圧倒的な支持を集めたカリスマ経営者たちが、今回取り上げたのは「リモートワーク」。世界に散らばる36人の社員を率いて、数百万人ものユーザーにふさわしい働き方を伝授する。会社や組織にまつわる固定観念が、根底からくつがえる! リモートワークを取り入れることで生産性が上がり、生活の質も上がる。リモートワークを取り入れるとき

ありがちな話なのでこのことについてふと考えることが多い。 最初に断っておくと特に結論はなく、ケースバイケースで考慮するべきというのが僕の考え。 それを踏まえて、先ずは良い点について考えてみる。 一番もっともらしい理由は、他のエンジニアが納得しやすいこと。一番戦闘力の高いエンジニアがエンジニア長になって皆を束ねていくという世界観。若く猛ったエンジニアも従ってくれるけど、石器時代っぽい。 次点として、システムの実装を把握しているのであまり滅茶苦茶なことにはなりづらく、安心して任せられるということ。 それ以外にありがちなものとしては、人的コストの圧縮も考えられる。人件費もそうだけど、頭数が1つ増えるだけでコミュニケーションパスは爆発的に増加していくのでコミュニケーションコストの削減にも繋がる。 次に悪い点について考えてみる。 これはまさにピーターの法則そのもので、組織の構造的な欠陥を示している。