1ヶ月前になりますが、2025-01-22 D-Plus Osaka #1 開発生産性を高めたい！関西エンジニアのためのTips共有会 に参加＆LTさせてもらってきました。 次回、でぃーぷらすオオサカの2回目は 2025-03-19 に行われるようです。
募集ページをみた時は人数も少なくて、賑やかしLTくらいならできるかなーと思って申し込みました。 東京がメインのコミュニティの大阪初回ということや、知り合いが運営に関わっていると聞いて応援したいなーって気持ちから。 そしたらあっという間にLTも参加も埋まってしまい。「あーこれはやらかしたか……」とか思いつつ、まぁ気にしなくていいかなって。
LT（7分）に対してもりもり詰め込んだ資料となっているので、口頭ではほとんど読み上げもしなかったと思います。 また、灰色部分はスキップゾーン（言及すらせずページチラ見せするだけのやつ）ですが、投影＆公開資料には載っていないブラックゾーンなどもあったりします。
こんなの。他にxxページくらい。いやヘッダに「絶対収まらない」とか書くなら最初から作るなとね……。
LTと資料について
私の普段のセッションは会場の反応とか見ながら出し入れするものにしています。
今回はLTの定義もゆるふわな昨今の事情と、はじめてのコミュニティ＆少ない枠を取ってしまったと言うことで失敗率を下げようと、「どうとでも調整できるLT」を設計したらこうなりました。
去年10月の京アジャ のLTは我ながらひどかった
「LTらしいLT」は私のイメージで、勢いで押し切るやつです。ライトニングだし。個人的には五指に入る出来だったと自負しています。 他の人とトーンが違って浮いてなかったかなと心配にはなりましたが、懇親会で聞いた限りは大丈夫って言ってくれたからきっと大丈夫だったんでしょう。聞きながらも「この聞き方じゃ大丈夫じゃなくても大丈夫って言うしかないよなぁ」とか思ったりはしましたが、他に聞きようもないから仕方ない。大丈夫だった、うん。資料にも書いてるように計測は大事。観測者効果を気にするのは計測してからだ……ってのも書いたつもりだったのに入ってないな？削ったっけ？まぁいいや。
内容の下敷きは以前書いた「開発時間の内訳を眺めてみよう」です。
ピンとくる人も居た ようで。はい、このブログ投稿して 反応もらった あとにPSPの入門本とか読んだので色は濃くなってると思ふ。
原著は1997年、訳書も2001年と流石に古いですが、今でも役に立つエッセンスは結構あります。とは言えかなりの読み替えが必要なので、おすすめできるかっていうと、うーん。
他にも具体的なやり方の書いているPSP入門とは違って考え方系ですが、継続的デリバリーのソフトウェア工学にも通じるところがあります。
こっちはぜひ読みましょうなおすすめ本。 昨日の関ジャバ で増田さんのセッションでも紹介されていました。 特に「ソフトウェア工学？なんか堅苦しくて重々しくて現実だと使いづらいんじゃ？」とか思うような人。つまり読む前の私。
さて、話の内容については、スライドに書いています。というかLTで口頭で話したものの方が情報量が少ないくらいです。 私が「ふつう」にやっていること のうち、人におすすめしてもいいと思える程度に言語化と実績のあるプラクティスを抜粋した、取り組みやすいもののつもりです。
スライドだけで伝わる構成（普段はあまりしない）としていたこともあってか、思いの外RPやいいねが伸びてびっくりしました。
LT資料です / 自分ひとりから始められる生産性向上の取り組み #でぃーぷらすオオサカ https://t.co/NJNjtsMV7B
— irof (@irof) 2025年1月22日
あと、1ヶ月経とうかというころにすどうさんがnote書いてくれてました。
よくスライドだけでここまで汲み取れるなぁと感心しました。むしろ現地にいた人の方がLTのトーンに引きずられて内容にノイズかかってるまであるのではないだろうか……。
直後以外にも言及されるのっていいですね。
生産性について
「生産性」って言葉を現場で聞くのはネガティブな状況が多いと思います。良い時って気にもしないものだと思います。 そしてこの言葉を出すのはパワーバランス的に強者（少なくとも言われている方はそう感じる相手）なことも多く、「遅れてる！」とか言って責められるのとセットな感じ。まぁ「遅れ」なんてないんですが。
irof.hateblo.jp （7年前。間違ったことは書いてないつもりだけど、取り扱い注意ではあると思う。）
また「生産性」の話題は資料でも書いていますが、組織的な話になることが多いと思います。 だからと言って「組織任せ」のようなスタンスはちょっと違うと思うんです。ややもすれば生産性と個人の取り組みは関係がない、あっても誤差だと言われることすらあります。 ある面では統計などが示しているようですからそれは事実なのかもしれませんが、システム開発業界はコンピュータの力が借りられることもあってか「人による生産性の差はXX倍」なんて話もあります。 こちらも眉唾なもので全てのコンテキストで当てはまるものではありませんが、人によっては倍どころか「（時間など実務制約の元で）解決可能か不可能か」という比較すらできない差がある（0に何倍しても0だよねって話）のは動かし難い事実です。
……とかから話を広げると帰ってこれないので切り上げるとして。
複数人で開発する以上、最終的な生産性は組織に強く依存するのでそちらを外すことはできませんが、組織の生産性だけよくしようとしたところで、個人が応えられなければ厳しいと思います。 明確に言語化できているわけではないですが、私の脳内モデルでは組織の生産性は道路で、個人の生産性は走る車の小回りや加速力や最高速になります。 道路が狭く入り組んでいればいくら最高速が出せる車でも時間はかかりますし、道路が工事や災害で断絶していれば到達できなかったり徒歩になったりします。 かたや広く平坦な高速道路が整備されていても、速度が出せないなら宝の持ち腐れです。どちらも必要なのです。 そして個人の生産性は一朝一夕に上げられるものでもありません。「走れる状況で走れない」のようなのは私は嫌です。嫌だと思うなら備えるしかありませんし、備える以上は普段から使いたいものです。この辺りは「緊急時の規律」に通じます。
と言うことで、普段からやっていこ。です。先にあげたように『「遅れ」なんてない』と嘯くのであれば、それに見合う程度に無理筋じゃない言い訳ができる程度のことはやらねばなるまいって思います。 そしてひとりカンバンのように「普段から組織でやってるプラクティスを個人に縮小適用して鍛錬し、それを組織に逆適用しちゃえばいいじゃん」みたいな相互適用をバンバンしていけばいいかなって思ってます。良さげなプラクティスに取り組む際、「聞いただけ」じゃなく「（自分一人では）やったことある」だけでも全然違うものだったりします。てことでスライドの最後にもあるやつで締め。
