0時に寝て5時半頃に起きて6時半に起きた。

リーン思考

スクラムのふりかえりをしていて、スクラムマスターがふとスクラムっぽいものとスクラムとの違いの1つとしてリーン思考の有無をあげた。私がリーン思考というのを知らなかったので軽く調べてみた。

• リーン思考とモジュラー化を実現するための3ステップ

リーン思考とは？

リーンという考え方は、ムダを最小限に抑えつつ、顧客価値を最大化することです。そのためには、ムダを削除・削減させるような構造化された「働き方」と、それを継続的に改善し続けることが必要です。つまり、リーンな組織というのは顧客が何に価値を感じているのかを理解しており、継続的な価値向上に繋がるプロセスに注力するものです。繰り返しとなりますが、究極の目標は、ムダゼロな完璧なプロセスを通して、顧客に最大限の価値を提供することです。

引用しておいてなんだが、「リーン思考とは」と節を書いているのに直接な定義を最初に書かない文章は読みにくい。要約すると、リーンという概念を組織として理解していて実践していく考え方や心の動きをリーン思考と呼ぶのだろうか？スクラムマスターがリーン思考が足りないとか言っていたけど、あまりピンとこない。というのは、スクラムマスターは基本的に言うだけで実践はすべて現場に丸投げ。リーン思考が足りないというだけなら誰でも言えるが、日々の具体的な活動や実践にどう落とし込むのかを示さないので現場のメンバーにはあまり響かない。リーダーシップにもいろんなタイプがあると思うが、実践は実践力をみせつけてフォロワーがついてくる。とくに抽象的なよくわからない概念をビジョナリーが提唱するだけではなにも変わらない。

私自身がリーン思考を意識したことはないが、課題管理に関して開発のワークフローを最適化するというのはある種のリーン思考とも言える。チケットのワークフローが洗練すれば洗練するほど効率がよくなってイテレーションのサイクルが多くまわり、結果として価値が速くユーザーに届いたり、試行錯誤の改善が早くなる。キーワードとして一応は覚えておく。

0時に寝て4時半に起きた。6時から金朝ツメトギを聞きながら途中で寝てしまって7時過ぎに起きた。

コミュニケーションについての記事を書く

以前 コミュニケーションコストに考えたこと をベースに、3ヶ月フィードバック の一節としてお手伝い先の社内 wiki に書いた。コミュニケーション一般の話なので私の考えを伝えられるよう、社外秘の部分を削除してブログにまとめておくことにした。ちょっと書き始めたところ、また週末にでも時間があるときに少しずつ推敲したり、洗練させて自身の考えを整理していく。現状でも悪い内容ではないけれど、まだしっくり来ていないところもあって、そのもやもやも見直していきたい。

課題管理の特性

課題管理システムにチケットを作成すると fix しない限り、そのチケットは永遠に残り続ける。未着手の状態でずっと放置することもできるが、それは対応を先送りしているだけで完了するわけでもない。チケットの対応方法として wontfix という選択肢が非常に重要になる。問題があることはわかっていたとしても様々な理由で対応しないという判断はありえる。誰がどういう理由でその判断を下したかという背景や意図さえわかれば、仮に将来的にその問題が看過できない状態になったとしても、過去の判断から新たな対応方法を検討したり、その判断の是非をふりかえることができる。これはチケットを作らずに見てみぬふりをして将来同じことが起きるのとは全く異なる知見が積み重なるので非常に重要な意思決定であると私は考えている。

閑話休題。話しがズレた。ここで fix せずにずっと放置するメンバーもいたりする。様々な理由で課題管理に非協力的な姿勢をとるメンバーがいる。少なからずいる。そういう人を放置すると、真面目に課題管理をやっている人たちが腐ってしまうので、課題管理の専門家を自称する私としては看過できない状況と言える。最初のうちは非協力的なメンバーにお願いしてやってもらうわけだけど、やってくれない人はずっとやってくれない。それを言い続けるのも嫌になるので別の対応方法が求められる。私の経験則では若い人に非協力的なメンバーはほぼいない。いまの若い人は優秀なので上司や先輩のやり方をみて勝手にやる人もいるし、ちゃんと教えれば教えた通りにやってくれる。非協力的なメンバーは往々にしてそれなりの経験をもっている中堅以上の社会人に多い。実はお仕事をさぼっていてあまり作業していないとか、課題管理に馴染みがなければ、それまでの自分の仕事のやり方をアンラーニングできないという人もいるかもしれない。理由はともかく、お願いしてもやってくれない人のチケットが課題管理プロセスの中で浮いてみえてくる。他のメンバーが腐る前に対応しないといけない。私の経験則ではこれはすごく難しい問題であるし、非協力的なメンバーそれぞれの理由にあわせて対応する必要があるので工数もかかる。

課題管理をしたくないというメンバーの中には何らかの理由で自律的に働きたくないという人もいる。課題管理というプロセスにおいては、そういった人たちをあぶり出してしまうため、状況によってはとても難しい人間関係の問題へと発展してしまう。

1時に寝て3時過ぎに起きて6時半に起きた。

ふりかえり

今日はスクラムのふりかえりとプランニングの日。1週間が終わり始まる。ふりかえりをしていて、2週連続でスプリントゴールが未達になって、原因を追求する空気になって、最終的にはリーダーを糾弾するみたいな雰囲気になった。昔の私だったら論理的に問題を掘り起こそうとがんばったかもしれないけど、いまはもう歳をとってスラムダンクの安西先生みたいになったのか、もしくは外部パートナーとしてのお手伝いだから真剣ではないのか、その両方かもしれないが、一歩引いたところからできなかったもんしゃーないんちゃう？みたいな心境で見守っていた。うまくできない人や状況に「なぜできなかった？」みたいに迫ると「努力が足りなかった」とか「もっとがんばります」みたいなやり取りしかならないので不毛にみえる。経営者のくせにこんなことを言うと怒られるかもしれないが、仕事なんてやりたい人やできる人が楽しめるように好き勝手やって、そうじゃない人は最低限やるとか、邪魔しないように配慮するとか、もうそれでいいんじゃないとか思ったりもしている。もう人類は会社の半分ぐらいの社員が遊んでても暮らしていけるぐらいの生産性を手に入れたと思うよ。半分は言い過ぎか。いずれにしても私はもう無理なく自分のペースで働きたいと思うようになった感じ。

backlog の管理者権限

お手伝い先で backlog を課題管理システムに使っている。私は課題管理システムのスペシャリストとして、ああしたい、こうしたいといくつも注文を付けて、チームの開発やワークフローを改善している。これまでは管理者権限がなかったのでもっている人に依頼するしかなかったけど、そろそろ私の相手をするのが面倒くさくなってきたのか、私にも backlog の設定を変更する管理者権限をもらえた。さっそくカスタム属性をいくつか作って実験的な検証をしていた。カスタム属性は backlog のフリープランでは使えない機能なので、お手伝い先の実地で用途や振る舞いを検証するしかない。同じプロジェクトでも種別ごとにカスタム属性の設定有無を切り分けられる機能があって、この機能は他の課題管理システムでみたことがない実用的で珍しい機能だと思った。チケットに PR とコミットのカスタム属性を追加して、github actions でコミットや PR のタイミングでそれらの属性に URL を追加すれば github 連携もできそうな気がしてきたところ。週末に時間があったら作ってみる。

22時に寝て0時に起きて5時に起きて7時に起きた。なんか体調が微妙。

リファクタリングのチケット作成

これまでは業務に関係しないところの機能拡張をしていたので新規にコードを書くことが多かった。いま業務の開発にも着手し始め、その過程で既存のコードを読むことも多くなった。私からみたらコードの品質が著しく低くて、ただ動いているだけで堅牢でもないし、設計の意図も伝わらないコードが多い。そういうのを自分が変更するときに少しずつ出来る範囲でリファクタリングしたりしている。今日もコードを読んでいて enum の扱いについてチケットを作成した。

前に手伝っていた会社の契約を終了するときに java のコードレビューだけなんらかの契約で依頼できないかという話しはあった。そのときは別件のお仕事が火の車だったので断ってしまった。いまお手伝いしている java のコードをみても、java に慣れていない開発者の書く java のコードはたいていひどい。なぜひどくなるかというと、java は言語仕様が複雑で難しいからだと思う。java の経験が少ないと Effective Java を読んでも理解できないぐらいには java の設計は難しい。その結果として java で開発しているのに設計を練っておらず「動けばいい」コードが散見される。java で開発するなら「これ以外に動かない」コードを書いた方がよいと私は考えている。その意図が伝わるからドキュメントなんか読まなくても「動かすにはこう書けばいい」とわかる。さらにインターフェースが明確であれば、責務や拡張方法も明示的になる。

前から考えてはいたけど、sier や内製始めたばかりの事業会社向けに java のコードレビューのサービスを提供することも考えている。私1人だとたくさん受けられないし、コードレビューサービスのようなものは会社の信頼関係の方が重要なのでビジネスにするのはちょっと難しいかもなぁ。

見積もりのまとめ

先日 見積もりについて考察した 。もともとは社内向けに書こうと書き始めたが、内容の大半は社内に閉じたものではなかったので一般論の記事として書き直した。最終的には1万文字ぐらい書いた。

• 見積もりをがんばらない

23時に寝て8時半に起きた。夜中に胃酸が逆流してむせてしんどかった。

ストレッチ

先週の日曜日に自転車でこけて胸を強打してまだ治りきっていない。トレーナーさんに伝えたら主に足のストレッチを重点にしてくれた。今週は2日間ストレッチをやったんだけど、今日の開脚幅は開始前166cmで、ストレッチ後169cmだった。先週と同じなので現状維持といったところ。悪くない数字ではある。今日は左のお尻の後ろの筋肉の張りと右太ももの後ろの筋肉の張りが強かった。

見積もりとは

昨日の バーンダウンしないチャート に関連して「見積もりとはなにか」というタイトルでつらつらと書き始めたら6000文字ほど書いてた。当初はお手伝い先の wiki に書こうと思って書き始めたものの、アウトラインと言いたいことをまとめたら、とくに機密情報はほとんどないことに気付いて、自分のブログのどこかにまとめ直そうと思った。社内向けに書こうとすると、実務の具体例をベースにして自分の論理や考察を展開し、最終的には提案の説得力を高めようと構成する。一方で社外向けに書こうとすると、社内の関係者に対してハラスメントにならないように配慮して書くのをやめた内容を一般論という立て付けで構成できる。文章を書くときに誰向けに書くかは、内容が同じでも話の展開や構成に影響を与えるということにふと気付いた。また数日以内にはどこかのブログに書き直す。

0時に寝て4時半に起きてドラクエタクトを1時間ほどやって寝て7時半に起きた。

課題管理の情熱

先日、行った 3ヶ月フィードバック はスクラムマスターには好評だったらしく、他にも3人ほど読んでくれた人たちがいたようだ。いま課題管理のボードの整理をしたり、wiki のドキュメント階層を整理したり、情報共有や書く文化の重要性を説いたり、チームに私のやり方を見本のように示している。チームにも、私のチケットはコメントの量が大幅に違うということは認識され、それを見様見真似でやり始める開発者も現れ始めている。誰もが最初はお手本を模倣しながら学ぶ。いままで課題管理と情報共有というコンテキストで見本を示せる開発者がいなかっただけという話だ。

ふと、なぜ私はここまで課題管理やドキュメントなどを整理したがるのか、自分で考えてもよくわからない。強いて言うと、自分が働く環境やツールに関心をもっていて、それをいまよりもより良く改善したいという気持ちが他人よりも強いのかもしれない。働くからにはよいものを作りたい、ひいてはよい環境があればよいものを作れる、よい環境を作るための投資は惜しまないという姿勢から、課題管理のワークフローと情報共有の最適化を常に考えながら実践している気がする。もっと端的には言えば、仕事がどうこうというのは全く関係なく、日々の活動に関心をもっていると言えるのかもしれないなと思ったりした。採用における特性をみるときの1つの指標として生きていることに関心をもっているか、どういう行動を取っているかとかをヒアリングしてもおもしろいのかもしれない。

0時半に寝て6時半に起きた。

課題管理システムの使い方指南

いまお手伝いしているお仕事はスクラム開発をしている。課題管理システムに backlog を使っている。アリエルを退職後、この10年、私より課題管理システムを使いこなす開発者をみたことがない。0-9段階で言うと、師範代として私のレベルが8だとすると、他のメンバーは0から2ぐらいのレベルしかない。このぐらいの差がある。0というのはほとんど使っていないという意味。情報共有とは、メンバー全員がいつでもどこでも同じ情報を取得できる仕組みを確立した上で、情報の提供側ではなく、その情報を必要とする受け手が常に最新の情報を取得し続ける運用ができて初めて成り立つ。情報共有を成功させるには受け手の意識の問題が大きい。まずメンバー全員がやっていない時点で情報共有の価値が大きく毀損する上に、受け手が自律的に検索して最新の情報を取得するようにならなけば実務において生産性を向上させることにもつながらない。

役に立つ情報がないから検索しない、検索しないから役に立つ情報を書かないは表裏一体だ。まず役に立つ情報を溜め、受け手が検索して情報収集するようになり、検索の精度をあげるためにカテゴリやタグでラベリングし、業務に活かすために最新情報を更新するようになる。これをチーム全員でやるようになるのは一朝一夕ではできない。

そのため、私は課題管理システムの運用に関して特異な開発者である (言うてもアリエルなら普通) という前置きをした上で、チームの開発者も非開発者も課題管理システムをうまく使えていない。私が課題管理システムをどう使っているのかをみて、開発者が真似して同じように使い始める。そして、非開発者向けにはどう使えばよいかというプラクティスを機をみて提案したり啓蒙したりしている。これは半年から1年かかる作業だと見積もっている。というのは、私が半年ぐらい働いて実践的な課題管理システムの使い方をみせないと多くの人は学べない。半年ぐらい経って、普段私がやっている価値はどういうものかを実際の実務で理解した後、模倣者がやり始めて慣れてくるのに半年ぐらいはかかる。お手本をみせるのに半年、模倣するのに半年で1年かかる。いろんなチームを指導してきたのでチームがどのような学習曲線を辿るかは概ね推測がつく。これをコンテンツにしてビジネスしようといまは考えているので、こういう実践的な機会にコンテンツとしてのノウハウも溜めていこうと考えている。

みかん

実家からみかんが送られてきた。実家で作っているみかんなのかな？なんか微妙に腐り始めようとしている雰囲気もある。お正月に帰ったときから実家に置いてあったやつだろうと思う。段ボール箱の空きスペースを埋めるために入ってた 「りんちょこ」 というお菓子を初めてみた。冬季限定らしい。軽く食べてみると思いの外おいしい。えびせんべいをチョコレートでコーティングしていてチョコフレークの食感に近い。チョコフレークが好きな人にはうけると思う。お土産にもよさそう。

会員制バー

オフィスの郵便受けに KOBE SALON S という会員制バーのチラシが入っていた。新規会員を募集しているらしい。個人だったら全く興味はないけど、経営していると接待する機会がたまにある。前に顧問さんに経営コンサルティングを受けたときに交際費が少な過ぎるという指摘を受けた。交際費は5年後10年後のお仕事をとるための先行投資もしくは調査費用のようなものだという。そこで今期は交際費の予算に30万円を見積もっているが、現時点で46,971円しか使っていない。4月までにあと2-3件は飲みに行くあてはあるけど、このままいくと30万円は消化できない。コロナ禍というのもあるけど、何もしないと私は交際費を使わないので積極的に使っていく仕組みを作らないといけない。その一環として会員制バーは接待にいいかもしれない。すぐ退会するかもしれないけど、チラシをみた縁で入会してみる。