万葉帰社日に「万葉積み重ね」という発表をしました

20141010 万葉帰社日発表 万葉積み重ね from tatsuo sakurai

内容

チーム積み重ねっていう前に公開したものと似てる、チーム開発とか社内での工夫とか、あいかわらず僕の好きそうな内容。

なんとなく万葉で中の人達がやってることを小出しにしたいなって思っていたんだけど、どこでやろうかなあ…みたいなのが思いつかなくて、社内で発表した。

万葉は僕にとって働きやすい環境で、なんでかっていうと、自分達で会社の制度や仕組みなどをリファクタリングしたり、機能追加したりしてるからかなあって思う。 もっと効率を良くする仕組みを、効率よく採用できる。（や、まあ、普通にどこでもそうしてますよね…^^;）

その理由として、社長が現役プログラマーというのは大きいと思う。（実際社内でも一番書いてるくらい書いてる。っていうのを意外と知らない人がいるって話をちょいちょい聞くのでスライドにもいれてみた。もちろん量だけじゃなくて 質や価値もすごい）（判断の早さや的確さとかもものすごいので、そのあたりも大きい） 誰かがこういう制度とかモノとかあるといいな〜って言ってから、話し合って導入されるまで、すごく早くてとてもいい感じ。

なんとなくコントローラブルな感じって思ってる。 僕にとって、コントローラブルっていうのは、働きやすさにとても関係してると思う。 一部の人だけがコントローラブルだと、全体で非効率になりやすいので、いろんなことを考えて設計して、やってみて改善していく感じが好き。

スライド内で紹介したハックは、書きやすそうなものだけ3つくらい書いて、あとは列挙もできてないないやつを思い出した順に足しては update してる感じ。でももっとふつうにやってることたくさんありそう。

MTGの効率をよくする

スライドに書いてなかったけど、万葉はチャット文化が強くてみんなそっちに慣れている。ビデオチャットは相手の反応もわかりやすくてよいんだけど、どうしても参加者それぞれのネット環境などに影響されて困ることが多い。反応や状態がわかるくらいチャットスキルがあがる（なくてもふつうにすぐ慣れる）と、そっちの方が効率がいい。あとから見返すことができるし、参加してなかった人もみれるし、後々重要になるそうなった経緯なども wiki などに貼ることができる。

GoogleDocs を使った[アジェンダ＋リアルタイム議事録]は、帰社日の全体会議のときや、ビデオチャットのときなどに使ってる。だいぶ効率良くなったと思う。誰かが1人で議事録書かなくて済むし、漏れとかもないし。事前に作って作りながらやるっていうのがすごく好き。

職人性・属人性を低くする

これは @redfit や @upinetree や @hyoshihara や @publichtml や @chobishiba や @ohtsuka_t たちのチームがやってて、いいなあって思ったもの。巻き込みやすい仕組みでとてもいいと思う。

◯◯さんじゃないとできない、っていうのはなるべく減らしたい。そのほうが長い目で見て効率がいい。情報をシェアしたり、教育したりなどのコストはかかるけど、それを考えても、誰か1人に負荷が集中したり、作業が進まなくなったり、知見が増えないことを考えると、かける価値はあると思う。価値があるからやるんだけど、まあ、ふつうにやりたい、や、やってる。シェアする技術や仕組みも改善していけるし。

僕は昔、10〜20人くらいのオペレーションを上手く回るようにするお仕事をしていたせいか、自分が動けなくなったときに、他の人達の作業が止まる、みたいな状態にできるかぎりしないようにしたいと考える。自分が何をしてたか、とか、どんなことを考えてるか、みたいなことをなるべくシェアしながら仕事をしたい。日報とかね。共有のコストはかかるけど、長い目でみて効率はいいと思う。もしもいきなり僕が死んでも、誰かがかわりに続きをやってくれると思う。（や、だいたい誰かがかわりにやることになると思うので、なるべく続きやりやすい方がうれしいよね？）死なないようにもなるべく気をつけてる。

日報にはかならずどうでもいいようなこと、今日の一言的なのを書いてる。こういうのが一番読みたいし、一番効果がある気がしてる。雑談。雑談って一見無駄だけど、チームの効率をよくするものになることがよくある。

言葉遣いに気をつける

万葉は、言葉や気持ちを大切に扱ってると思う。日本語についての指摘は結構したりされたりする。相手のことを考えたり、わかりやすいキレイな日本語を使うことは、やっぱり長い目でみて効率がいい。言い方が気になるなど、余計な感情によって思考のリソースが食われてしまわないようにしたい。

僕は過去に、自分がコワかったり、コワい先輩に教わったりしたことがあるんだけど、やっぱりコワくない方が圧倒的に効率がいい。コワいと質問とか話しかけるのためらうから、もっと自分の理解力を高めてから聞こうとか、もっと自分で調べてから聞こうとかなってしまって、そもそも必要ないことやって怒られたりっていう悪循環になりやすい。これって教わる側だけの問題じゃないなって、どっちも体験したことあるのでわかる。わかっちゃう。でもコワくない＝なあなあとかっていうんじゃない。ナメたりナメられたりっていうのも効率悪いので…。（なんていうかコードレビューでボコボコにしたった、みたいなのもあんまり好きじゃなくて、文脈が伝わらないまま、ボコボコにするのが目的になっちゃう人とかでてきたりすると効率悪いなって思う。レビューはレビューなので普通に指摘して、よくしてったらいいと思う。まあ、コメント数が多い＝ボコボコなんだとは思いますし、僕もボコボコにしたったみたいなこと言ってたことあるような気もしますmm）

コワいかコワくないかっていうのは相対的っぽい感じだと思うので、相手がコワいって思っちゃったらコワいんじゃないかなって思う。お互い半歩ずつ歩み寄るのがいいのかもだけど、アジャストしやすい方が動くのが効率がいいと思う。コワいかコワくないかはひょっとしたらどうでもよくって、一番効率のよい状態を考えればいいのかもしれない。会社で、チームで、ペアでどうするか考える。経験値の高いと思われる方がハンドルを握る時間が長くなりがちになるので、それが本当に効率よくなるのか考えながらやりたい。

感想

久しぶりに発表した しばらくずっとちょっとずつ作ってた別の発表もあったり、忙しかったりしたので数ヶ月してなかったけど、もっと低コストな感じのちょっとしたやつを発表するのがよさそう

ちょっとなんかタイトルが中途半端で、無理に積み重ねつけない方がよかったなって思った。

僕らの今やってるやり方が一番いいとかは思ってなくて、会社の数だけチームの数だけ良いやり方があると思うし、もっと改善していきたい。同じ日にあった @upinetree のカンバンを改善したっていう発表で、正しい看板とかはなくてチームの数だけカンバンがあるみたいなこと言ってて好きな感じだった。

たのしい開発

僕がたのしく開発したいとか、効率よく開発したいと思うのは、一番貴重なモチベーションを上げやすく下げにくいようにしたいってことなのかな〜って思う。まあ、相互に関係してるし、卵が先か鶏が先かって感じもする。動きやすいようによい状態・状況にしておきたい。

これはとても非効率的な文章になっていて、なんとも味わい深い。一見非効率だけど、思いや感情が入っている方が長期的に見て効率がいいなって思う。