patorashのブログ

方向性はまだない

「こじつけKPI」を脱する、開発マネージャーのための制約理論

まず結論

目標があり、それを具体的な指標にしたものがKGIであり、KGIを達成するために取り組むべきことがCSFであり、CSFを見つけるために重要な考え方が制約理論であり、CSFの取組ができているかどうかの指標が、KPIである。

では、うちの部署であったことを交えて、詳しく説明していく。

キッカケ

管理職として、部門目標や部下の個人目標の設定のサポートをするに当たって、KPIの考え方がいまいち腑に落ちていなかったため、こじつけのようなKGI、KPIを設定するようなことがあったので、ちゃんと理解したいと思って、こちらの本を読んだ。

この本を読もうと思ったキッカケは、PIVOTのYouTubeで著者の中尾さんの動画を見たからだった。 KPIマネジメントについて、制約理論に基づいた話をされていて、もっと詳しく知りたいと思った。


www.youtube.com

まずは制約理論

制約理論に基づいて考えるという話がすごく腑に落ちた。

制約理論は、すごく簡単にいうと、業務プロセスのボトルネックを見つけて、ボトルネックを解消するように動いて、ボトルネックが移動したら、次のボトルネックを解消しようということだ。集中の5段階がある。

  1. 制約を見つける
  2. 制約を徹底活用する
  3. 制約に従属させる
  4. 制約の能力を高める
  5. 次の制約に移る

ボトルネックがあるとしたら、すぐに4の制約の能力を高めるを考えてしまいがちだし、そもそも2と3と4の違いについて、ちゃんと理解できていなかった。

そして、今までの目標設定は、1の制約を見つけるという点がなかった。もちろん、関連していることはなにかしらの施策でやろうとはしていたが、明確に「業務プロセスのボトルネックを解消しよう!」という意図はなかった。

前回の失敗

前回は、制約理論に基づいた考え方を取り入れていないから、KGIに関連してそうなアクションとして、AとBとCをやろう!という感じで、やることを多く設定してしまっていた。そのため、目標となるKPIが複数設定される。A、B、Cは、あまり関連がなく、KPIとしてはそれなりに普通に見えるのだが、目標に対する重要度として、Aは40、Bは30、Cは20、残り10はその他、のようになっているため、暗黙の優先度が決まってしまい、Aのほうが重要なので、Aを達成するためにCをやらないのは仕方のないことだ、ということになり、結果、Cがあまり進まないということが起きていた。

1on1をする中でも、確かにAを達成するためにはCは後回しになってしまうよなぁと話しつつも、いつまでも放置されるC。どこかで取り組んでほしいと伝えても、「でもAがあるんで…」と言われ、とはいえ指導する立場でもあるし、個人目標を立てたのは本人なので、しっかりやってほしいという気はしていた。

失敗を踏まえて

今回は、今一度、業務プロセスを分解して考えることにした。システム開発チームなので、以下のようにした。

  1. 要件定義・要望確認・問い合わせ
  2. 設計・設計レビュー
  3. 実装・不具合対応
  4. 実装レビュー
  5. リリース前検証・不具合対応
  6. リリース

ちゃんとボトルネックを計測したわけではないが、皆が抱えている不満点や改善したい点について確認を取りたかったので、アンケートを作成し、メンバーに回答してもらった。ミーティングで聞くと、よく喋る人の意見のみになってしまうのと、他の人の意見の影響を受けてしまうと考えたため。

1. 制約を見つける

様々な意見はあって、どのプロセスでも課題はあったのだが、根本的なところは設計・設計レビューにありそうだった。

もっというと、『設計・設計レビューができる人が忙しい』ということだ。

突発的な問い合わせや、リリース前の不具合の発覚等で緊急の対応を迫られることが多いため、設計・設計レビューに時間を割くことが難しく、設計完了が遅れるため、開発に着手できない、という点。

2. 制約を徹底活用する

制約を徹底活用するというのは、新たな投資をせずに、今あるものを利用するということだ。

  1. 設計者が集中できる時間を増やすため、会議を減らす
  2. 設計レビュー待ちを放置しないようにする

みたいなところかなと思う。

3. 制約に従属させる

制約に従属させるというのは、制約以外のプロセスを、制約のために協力するということ。制約理論は、つまり全体最適化の話になるので、各プロセスの1つの生産性が高かったとしても、最も生産性の低いプロセスがその業務プロセスの生産性を決めてしまうので、過剰生産になっているところはその生産の手を緩めて、最も生産性の低いプロセスの生産性を高めることに協力すると、全体としての生産性は向上するということになる。

  1. 設計者への割り込みを減らすため、問い合わせ対応は設計者以外が行う
  2. 突発的な不具合対応を減らすため、テストをしっかり行ってからリリース前検証に移行する
4. 制約の能力を高める

これは制約から判断すると「設計できる人を増やす」ということになるのだが、これに関しては一朝一夕にはできない。ましてや、短期で教育するとなると、設計者が育成に関わらないといけないので、設計者が更に忙しくなってしまうので、取り組めない。

ただ、中長期目標としてはこれに取り組まないとボトルネックの解消は行えないので、若手に設計知識・業務知識を習得してもらう必要がある。

  1. 若手に設計知識・業務知識を付けてもらうために、定期的に勉強会・読書会を行う

CSFの定義が大事!

先に制約理論の話をしてしまったのだが、マジでこれが抜けていた。CSFとはCritical Success Factor(最重要成功因子)の略で、KGIを達成するために最も重要な取組のことを指す。KPIが迷子になっていたのは、CSFを定義することを知らなかったからだと思った。そして、本の中で、KPIはCSFが上手くいっているかの指標ということだった。

目標があり、それを具体的な指標にしたものがKGIであり、KGIを達成するために取り組むべきことがCSFであり、CSFを見つけるために重要な考え方が制約理論であり、CSFの取組ができているかどうかの指標が、KPIである。

目標・KGIについては詳しく書きすぎるとアレなので、一般的によくある形として書くと、

  • 目標:機能開発してよりよい製品にする
  • KGI:予定機能をスケジュール通りに提供
  • CSF:(制約理論に基づいて)設計のリードタイムを短縮する
  • KPI:制約を徹底活用、制約に従属させる、制約の能力を高める、に従ったKPIの設定を行う

となるかなと思う。

KPIは信号である

この、KPIは信号であるという考え方によって、ようやく腑に落ちた。これは、つまりAPMやRUMと同じなのだ。アプリの応答速度が遅くなっていたり、CPU負荷やメモリ使用量が上限を迎えそうになっていたら、なにかしらのアクションが求められる。それと一緒なのだ。

こういう分類があるかどうかは分からなくて、私がAIと壁打ちしているときに定義したのだが、KPIには大きく2種類ある。累積型と監視型だ。監視型は更に3つに分類できる。期限型、達成率型、在庫型。

  • 累積型KPI
    • 売上 3,000万
    • 訪問件数 100件
  • 監視型KPI
    • 期限型:いついつまでに〜する
    • 達成率型:◯◯を50%対応する
    • 在庫型:◯◯を5件以下にする

これらはそれぞれ独立しているわけでなくて、組み合わせて使うことが殆ど(主に期限型と)。

  • 期限型+達成率型:3ヶ月以内に◯◯を50%対応する
  • 期限型+在庫型:問い合わせに関する回答を3日以内に0件にする
  • 期限型+累積型:1ヶ月以内に訪問件数25件

累積型KPIは開発組織と相性が悪い

世の中でよく見かけるKPIの例が営業系のものばかりだからという言い訳をさせてもらうのだが(このKPIの本でもそうだったが…)、累積型KPIの例が殆どで、あまり監視型のイメージはなかった。そのため、累積型のようなKPIが設定されがちだった。こういうの、身に覚えはないだろうか?

  • PRをN件行う
  • 問い合わせ対応をN件行う
  • ドキュメントをN件整備する

システム運用もやっているから、重篤トラブル0件のようなKPIはあったが、それも累積型の亜種。

上記の問題は、PRの数なんて数えてもあまり意味がないし、問い合わせ対応N件は問い合わせの数が外部依存になってしまうので、そもそも問い合わせが少ないと達成できないこともあり得るし、逆にいっぱいあったとしたら簡単に達成できる目標と言われかねない、ドキュメントについても整備すべきドキュメントが少なければどうしようもない。

監視型KPIは開発組織と相性がいい(はず)

先ほどの制約理論に基づいたCSFに対するKPIを定義すればいい。

2. 制約を徹底活用する、に対するKPI
  • 設計レビュー待ちを3日以内に0件にする
3. 制約に従属させる、に対するKPI
  • 問い合わせに対して一次対応者で完結:50%
    • 設計者を二次対応者として定義し、設計者を保護する
  • 実装後に正常系と簡易的な異常系のE2Eテストを開発側で実施:100%
    • リリース前検証で不具合発生率を下げて、設計者を保護する

あくまでもKPIは信号であって、目標ではないので、100%とするのは別に悪くない

KPIが悪化したときのアクションを定義する

これもまた、信号だからそりゃそうだよなと思った。黄色信号や赤信号になってから、どうすればいいのか考えるのでは遅すぎる。 活動量が少ないのか、やり方が悪いのか等を見定める必要がある。

監視型KPIによって、正しい状態が定義されるので、信号が緑になるように取り組もうと言える。 そこの打ち手については、適宜ミーティングでKPIを確認して、黄色や赤になっているものについて、どうすればいいかを考えることができれば、良い方向に向かうはず。

まとめ

大事なことなので、再掲。

目標があり、それを具体的な指標にしたものがKGIであり、KGIを達成するために取り組むべきことがCSFであり、CSFを見つけるために重要な考え方が制約理論であり、CSFの取組ができているかどうかの指標が、KPIである。

その上で、開発組織では、累積型KPIは相性がよくないので、監視型KPIを導入し、KPIをスプリントのふりかえりで確認することで、次の打ち手を考えていくことができれば、きっと素晴らしいKPIマネジメントになるんじゃないか!?と思い至った次第です。

実は、まだこれらのKPIで実際に運用したわけではないのですが、個人的にはめちゃめちゃいい落とし所になったなと思っているので、どういうふうに考えてここに至ったかを残しておきたいという気持ちで、これを書きました。

悩めるシステム開発・運用の現場の管理職の方にこの記事を読んでいただけたら幸いです。

子供に空けられた壁の大きな穴を修理した

知的障害の長男のために家の中にブランコを設置しているのですが、長男が成長するにつれ、壁を蹴って勢いをつけるようになってきたのですが、だいぶベコベコになっていました。明らかに中の石膏ボードが割れてるなぁ…と思っていたのですが、先月、3年目にして遂に大きな穴が空いてしまいました…。

長男に空けられた穴

この大きさになると、リペアプレートで塞ぐことができないから、ひとまず段ボールで塞いでたのですが、長男が違和感があって気になるのか、すぐに剥がされてしまってました。

ここにきて夏休みに入って、妻と子供たちが帰省したので、ようやくこの穴を塞ぐ時間が取れました。正直、穴があまりにデカいので、業者に直してもらうのも考えたのですが、Geminiに聞いたら多分8万円位するよと言われたので、Switch2が買えてしまうやないか!ということで、自分でやることを決意。

石膏ボードで穴を塞いでみる

まず、表面の壁紙を剥がしにかかりました。破れた場所以上に石膏ボードがボロボロになっていて、かなりの大きさが必要だと思ったので、30cm * 30cmの石膏ボードをAmazonで注文。届いたら、石膏ボードを壁に当てて線を引き、塞げそうか確認。見た感じは、いけそう。

まず、石膏ボードを当てて線を引いた

その後、引いた線に沿ってカッターナイフで切り込みを入れ、ひたすら切りました。石膏ボード用のカッターがあるらしいけれど、普通のカッターでも頑張れば切れます。そして、空けて気づいたのですが、穴の下のほうはもっと石膏ボードが割れていて、30cm * 30cmでは全然足りなかった…。一旦、継続。

30cm * 30cmで空けた穴

次に、石膏ボードを嵌める前に、下地としての板が必要になるので、それを付けました。端材はホームセンターに行って木材を買わないといけないかと思ってたのですが、工作コーナーのあるホームセンターで余った端材を格安で売っているのがあったので、それを買ってきました。これは1つ100円だった端材。恐らく、ベンチ用の材料だったもの。

下地用の端材。ホームセンターで100円で購入

両面テープで石膏ボードに貼り付けた後、木ネジで固定しました。ネジ固定する写真撮り忘れてたけれど、これは両面テープで貼り付けたところ。

端材を下地として固定

そして、この穴に石膏ボードを嵌め込み、木ネジで固定。ここで、なんかやけに段差があることに気づく…。そう、石膏ボードは厚さ9.5mmと12.5mmのものがあるらしい…。この嵌めたボードは9.5mm。大きさだけで発注してしまっていたため、周囲から2〜3mmの段差が…。そして、見た目はもう直っているように見えるのですが、今回嵌めたボードのさらに下のほうは裏側の石膏がボロボロで壁がベコベコです。こんなのまた長男に蹴られてすぐに穴が空く…。

石膏ボードを嵌めたところ

更に石膏ボードを追加

追加で、A4サイズの石膏ボードを注文。横方向はほぼ30cmに近い29.7cm。早速、この石膏ボードに沿って線を引きました。

A4サイズに線を引いたところ

そして、再びこの線に沿ってカッターで石膏ボードを切る作業。大変過ぎて、石膏ボード用のカッターを買ったほうがよかったのでは?と思い始める…。でもこれが最後だからと頑張って切りました。

A4サイズに空けられた穴

また下地の板が必要になったので、再びホームセンターに行って端材を漁って、丁度良いサイズのものを購入。石膏ボードと石膏ボードの間も補強材が欲しくなったので併せて購入。2つで150円くらい。端材が安くて助かる。

再び端材を下地の板として設置

そして、A4サイズの石膏ボードを嵌めて木ネジで固定。今回は12.5mmの厚さにしたので、ジャストサイズ。逆に9.5mmのほうがだいぶ凹んでいるので、Geminiに相談したら、厚塗りのパテを塗ればいいと言われました。

A4の石膏ボードを嵌めたところ

石膏ボードの境界に、壁穴補修用のテーブを貼ってから、パテを塗っていたのですが、簡易補修用のパテだと30cm * 30cm * 3mmの厚さを埋める量としては全然足りないので、途方にくれました。今からでも12.5mmの石膏ボードを買うべきか?と考えたのですが、30cm * 30cm * 12.5mmの板がすぐには見つからなかったので、もう厚塗り用のパテを買って塞ぐことを決意。

パテが足りなくて段差が…

大容量のパテを購入

どれくらいのパテが必要になるのか、皆目検討がつかなかったので、足りないくらいなら多いほうがいいということで、大きめの缶に入ったパテをAmazonで注文。粉タイプではなく、すぐに取り出して少し水を足して練れば塗れるタイプ。めっちゃ業務用の見た目をしている…。

業務用の見た目をしているパテ

いつぞやピクニックに行ったときに使った余りの紙皿にパテを取り出して練り、3mmの段差に塗り込んでいきました。この時点で1回目なので、きれいに塗るのは意識せず、段差が少し残るくらいに塗って乾くのを待ちました。

厚塗りのパテを塗ったところ

乾いたら、2回目のパテ塗り。厚めに塗って、定規ではみ出た部分を削ぎ落としてから、まだ凹んでいる部分にはパテを足して、また定規で削ぎ…を何度かやってから、パテを均していきました。多少の凸凹はどうせヤスリで削るからOK。

2度目のパテ塗り完了

いよいよ壁紙を貼る

パテが乾いたので、紙やすりで削っていきました。紙やすりは粗めのやつで適当に。紙やすりをつけるようの端材を買ってたので、これに両面テープで紙やすりをくっつけて黒板消しのようにパテの上を擦って段差を均していきました。まぁプロではないので、大体の仕上がりで良かろうと割り切ってます。

そして、補修用の壁紙を探したのですが、もともと貼ってあった壁紙の余りが家の壁紙ストックにありませんでした。家を建てた際に、「残った壁紙は補修のときに使えるので取っておいてください」と施工業者に言われていたので残してあったのですが、まさかの事態。仕方ないので別の白い壁紙を使うことにしました。一旦、既存の壁紙を全剥がし。

固まったパテを紙やすりで均して壁紙を剥いだところ

そして、壁紙を大きめに切って、壁紙用の糊をローラーで塗っていきました。前に壁に空けられた穴をリペアプレートで修復した際に買っていたものが使えたのでよかったです。とりあえず糊が乾かないように折り返しながら塗り、全部塗ってから5分ほど乾かして、それから壁に貼り付けました(糊の使い方に書いてあったので、それに倣いました)。

刷毛(はけ)で壁紙の中に空気が残らないように空気を追い出し、壁の端っこまで貼り付けてから、金属プレートを当てながらカッターで壁紙を切って、接着をしっかり確認して…を繰り返しながら作業しました。そして、完成!!よく見たら(見なくても)、明らかに補修した穴のところがわかるのですが、まぁ塞がっているし、これで十分でしょう。

壁紙を交換して修理が完了した壁

そして、四隅の処理がちょっと甘くなってしまって、うまくいかなかったんですが、まぁこれも御愛嬌ということで…。難しかったんですが、いい経験になりました。

隅っこの壁紙の貼り付けが難しい…

正直、そこまでDIYに興味があるわけではないのですが、長男に壁を壊されるので、半強制的にDIYをせざるを得ない…。YouTubeで、壁の補修の動画や、壁紙を貼る動画などを見て参考にしながら、なんとか素人ながら直すことができたのでよかったです。こんだけ苦労したので、備忘録としてブログ記事にできてよかったかなと思います。

ホットクックの本を買ったら野菜消費量が増えた

ここのところ、基本的にホットクックでおかずを作る生活が長続きしており、非常に健康的…な気がする。

野菜のつくりおきの本を買った

煮浸しばかり作っていたので、ワンパターンで飽きてきた。付属の本についているレシピは手間がかかるものが多そうだったので、野菜を使ったレシピに特化した本を買ってみた。

こちらの本は副菜レシピしかないので、めちゃめちゃ使える。ブロッコリーやキノコ等、今まであまり使ってこなかった材料のレシピが豊富にある。しかも大体何日くらい日持ちするのか?についても書いてくれているのがありがたい。

この本のお陰でメイン副菜(きんぴらごぼう等)を常備しつつ、サブ副菜を切り替えながら食事を楽しめるようになった。ホットクックを買う前はとりあえず肉を買いがちだったのだが、最近は肉を買う量は結構減ったと思う。代わりに厚揚げを買うことが増えた。煮浸しと厚揚げの相性が良すぎて、大体の野菜と合うし、なにより満足感が得られる。油で上げてあるので脂質はあるが、糖質は少なめだから糖質制限に向いているってGeminiが言ってた。

家族が気に入っているのが、キノコ系の料理。エリンギや舞茸をベーコンと一緒に調理すると、ベーコンの塩味と風味がキノコに移って美味しい。あとニンニクとの相性がよい。あまり野菜を食べたがらない子供が舞茸とベーコンを食べてくれてよかった。

家で満足度の高い料理が食べられるようになったので、結果的に外食が減っていて、節約につながっているんではないかなと思う。お金と時間の節約に繋がるから、ホットクックは投資対象としてすごくいいんじゃないかなと思う。

肉・魚の本を買った

野菜の本のレシピがよかったので、シリーズものの肉・魚の本も買ってみた。

こちらの本はまだ買っただけで作れてはいないのだけれど、魚を調理する機会があまりなかったので、この本を参考に魚料理のレパートリーを増やして、子供に魚を食べさせる機会を作っていきたい。

ホットクックで煮浸し生活を送っている

洗濯機を買い換えたことで、今年はNISAではなく家電に投資して生活を豊かにしていくことにシフトしようということで、ようやくホットクックを購入した。買ったのは『KN-HW24G-R』。

旧型を購入

5年前の世代が古い機種ではあるけれど、新型よりも1万円くらい安いので、違いをGeminiに確認したら、ほとんど変わらないけど新型のほうがメニューが多くてメンテナンス性が少し優れていると言われた。

正直、定番メニューしか作らないだろう、ということで、妻と相談したうえで安い方を購入。赤い機種は旧世代しかないんだけれど、赤は不人気なのか、旧世代の中でも一番安い!

そして更にAmazonで安くなっていたのを見つけたので早速購入。そして届いた。

ホットクック KN-HW24G-R
届いたホットクック!

設置

結構でかいという話は聞いていたけれど、確かにでかい。5合炊きの炊飯器より一回りでかいくらい。向きが大事で、開くボタンを正面にするとかなりの横幅を取るので、蓋を開けた時に壁にぶつからない程度の隙間を空けて、横向きに設置したらスッキリと置けた。

ホットクックをキッチンに設置

クッキング開始

最初に作ったのはカレー

まぁ最初は定番メニューということでカレーを作ってみた。2.4Lなので、10皿分を作ろうと思えば作れるけれど、6皿分にしておくほうが妥当に思った。普通の鍋のときと違って、作り過ぎたら鍋ごと冷蔵庫に入れることができないので、作りすぎないほうが賢明。タッパーに移すのであればいいかと思うけれど。

うちは子供が塊肉を食べるのがまだ苦手なので、ミンチ肉のカレーなのだが、結構ダマになってしまっていた。かき混ぜユニットを信頼しすぎた。野菜にはちゃんと火が通っていて大丈夫ではあったが、圧力鍋で作るカレーのほうが美味しいかなと思った。悪くはないんだけども。

次にきんぴらごぼう

きんぴらごぼうは、自動メニューにもあって、本当にお手軽にできる。材料を千切りにするのだけが面倒だが、めちゃめちゃ美味しくできる!!買ったときに付属していたメニュー本に調味料の割合が書いてあるが、それをガン無視して、キッコーマンの『濃いだし本つゆ』を使っているんだが、これ一本で味が決まってめちゃめちゃ旨い。

ホットクックで作ったきんぴらごぼう

茄子の煮浸し

茄子の煮浸しは自動メニューにはなかったと思うが、手動メニューで10分煮込むようにするとOK。10分は沸騰してから10分になるので、実際の調理時間はそこそこかかるけれど、文字通り放っておけばいいので、めちゃ楽。こちらも味付けはキッコーマンの『濃いだし本つゆ』。長茄子3本で作っているのだが、茄子6本分くらい作ってもいける。調理後に液に浸けておけばすごく美味しくなる。

ホットクックで作った茄子の煮浸し

これは茄子だけで作った写真なのだが、茄子と厚揚げの組み合わせが滅茶苦茶美味しいのでお勧め。

小松菜の煮浸し

他にも煮浸しいけるのでは?と思って、小松菜と油揚げの煮浸しも同様に作ってみた。味付けは同じでキッコーマンの『濃いだし本つゆ』。量を調整すればいいくらいで、手動メニューで3〜5分煮込み用にすればOK。青菜を食べる機会がめっきり減っていたので、お手軽で非常に嬉しい。

普通に煮浸しを作るとなると調味料の量や、ちゃんと煮浸たせているかが気になってしまうのだが、ホットクックだったら密閉された状態で火を通すことができるのでその後にだし汁に浸けておけばちゃんと味が染みて美味しくなるのがよい。

常備菜作りが捗って楽しい

これらの料理を作るのがめちゃめちゃ楽になったので、常備菜として作っておくことで食事のバランスがよくなった気がする。なくなっても簡単なのですぐに作ることができるのがありがたい。ホットクックのおかげで料理が楽しくなるという不思議。料理してくれるのはホットクックだけど。

煮浸しばっかり作っているので、そろそろ違う料理も作りたいところだが、常備菜は欠かさずホットクックで作っていきたい所存。

WSLが起動しなくなったのでOS上書きインストールを余儀なくされた

先々週くらいだったかと思うけれど、突然WSLが起動しなくなって1日を潰してしまったので備忘録として残しておく。

結論から先に書く

  • PowerShellでwsl --list等の状態を確認するコマンドは動くのに、wsl -dをするとファイルがないと言われる
  • WSLの再インストールやWindowsの仮想化設定の無効化⇒有効化などをしたが、状況変わらず…
  • 最終的にWindowsの「上書きインストール」を実施したら直った
  • 似たようなことになっている人の記事を後で見かけた

note.com

起きたこと

まず、Docker Desktopが起動しなくなった。WSL Integerationを有効にしているからだろうと思ったので、WSLを再起動してみたんだけれど、そもそもWSL上のUbuntuが起動してくれなくなったので、PCを再起動した。

流石にPCを再起動したらいつも通り起動するだろうと思ったら、症状がまったく改善されず…。

試したこと

MS CopilotやGoogle Geminiと相談しながら試してみた。

  • PC再起動
  • WSLのイメージのバックアップを試みるも、ファイルがないと言われるのでvhdxファイル自体を一旦バックアップ
  • vhdxファイルをインポートして登録後、wsl --listでイメージを確認後、そのイメージを起動しようとすると、ファイルがないと言われる…
  • WSLサービスの再起動をしてみたが、効果なし
  • WSLをupdateしてみたが、効果なし
  • Windowsの仮想化設定や仮想化プラットフォームの無効化⇒再有効化等を実施してみたが、効果なし
  • BIOSを確認してみたが、仮装化設定は有効になっていた
  • PowerShellからWindowsの修復等を試みるも、時間がかかるだけで意味なし
  • 最終手段として『上書きインストール』をお薦めされたので、上書きインストールを実行しても悪影響がなさそうなことを情報収集したのち、実施
  • 深夜になってしまっていたので、そのまま放置して朝に確認
  • WSLが起動した🎉
  • Windows Terminalで今まで通り動作するよう設定

ついでにやったこと

いろいろと試す中で、wsl --unregisterもやっていたので、Windows Terminalで起動するべきUbuntuのイメージが見つからなくなっていたため、バックアップしていたUbuntuのvhdxファイルからインポートし直して、その後、無事に起動したのだが、ユーザーがrootになっていたため、今まで通りに戻したかった…。

指定したユーザーでWSLにログインするには?

WSLの設定ファイルを作ってデフォルトでログインするユーザーを指定しといた。

[boot]
systemd=true

[user]
default=patorash

後は、Windows Terminalで起動する際の設定について、新しいプロファイルを作って、今までと同じような設定を行った。

感想

WSLとの接続が切れたという感じだったので、まぁ再起動すれば直るやろ、と高を括っていたら、復旧にほぼ丸一日かかって大変だった。急ぎの作業が発生してなかったタイミングだったのでなんとかなったけれど、障害が発生したときにこの症状がもし起きたらと思うとゾッとする。突然起きたし、こうなった理由がよく分からないままだったのだが、多分、Windows Updateだったのかなぁと思った。

縦型洗濯乾燥機が優秀すぎて感動した

1ヶ月前くらいに、洗濯機を買い替える話を書いてた。

patorash.hatenablog.com

なかなか出荷されない中で、2026年モデルが出るというニュースが出て、「もしかしたら2026年モデルが出るから出荷されずに自動キャンセルになるのでは…」と考え始めるくらいには待っていたのだが(2週間くらい)、突如メールで設置の日を返信してくださいと送られてきて一安心。コインランドリー生活も結構長くなってしまい、お金と時間がかかって大変だった😰

そして、いよいよ設置の日を迎えた。エディオンのネットショップで購入していたのだが、元々あったパナソニックのドラム式洗濯機を引き取ってもらい、東芝のZABOONの、AW-10VP4を新たに設置。

東芝の洗濯機 ZABOON AW-10VP4
東芝の洗濯機 ZABOON AW-10VP4

ネットショップと言っても、普通に配達・設置に来てくださる方はエディオンの作業員さんなので、作業は丁寧かつ、洗濯機の使い方の説明も丁寧だった。今回の洗濯機は洗剤や柔軟剤の自動投入機能を搭載しているので、それを使った際の洗剤量の設定方法や、時間経過でこびりついた洗剤の残りを洗う方法等も教えてもらった。

使い方の説明で気になったところ

洗剤自動投入機能、メンテナンスが大変

洗剤自動投入機能は便利そうだが、メンテが大変だから使わなくなる人も結構いるとのこと。洗剤タンクを2~3か月に一度洗う必要があるのと、自動投入のタンクから洗剤を送り出すチューブの掃除も同じくらいの頻度で必要らしい。その話を聞いてしまったせいもあるのだが、我が家ではまだ使っていない。というのも、ドラム式の頃に使っていた洗剤がまだあって、それがドラム式専用のやつだったから。せっかくの便利機能なので、洗剤を全部使いきったら使ってみたいところ。

ゴミ取りフィルターの掃除が毎回必要

これはドラム式に慣れていて忘れていたのだが、たしかに縦型洗濯機の際には洗濯が終わるたびにフィルターの掃除が必要になる。ただ、この機種の糸くずフィルターは糸で出来たネットではなく、分解が簡単なプラスチック製のネットでめっちゃ掃除が簡単!

また、縦型とはいえ、乾燥機能付きなので、乾燥機能を使った際の乾燥フィルターも別途掃除が必要。これもめっちゃ掃除しやすかった。前のドラム式のフィルタは掃除しにくくて困っていたのだが(多分、現代のドラム式の乾燥フィルターは掃除しやすいはず)、今回のはパカッと開けてゴミを取るだけだったので楽勝👍

むしろ、ドラム式のフィルタ掃除は毎回じゃないからサボりがちだったので、こっちのほうがいいかもと思う。

実際に使用しての感想

では、とりあえず1ヶ月くらい経過したので、感想を…。

脱水能力がすごい

まぁ買い替える決め手になったところだから、当たり前なんだろうけれど、改めて縦型の脱水能力はすごい。洗濯後の衣類からめっちゃ水が抜けてて感動した。干すときに軽いから干しやすい。

洗濯後の衣類が取りやすい

あと、脱水が凄いからという理由と縦型だから衣類を取り上げるときに上から取るからというせいもあると思うのだが、洗濯後の衣類が凄く取りやすい。ドラム式は、かがんで取らないといけないので、地味に面倒。洗面所で干し姫さまを使っているからというのもあるが、その場で室内干しをしているから、この取りやすさは干す作業の効率に非常に直結する。

スピード洗いが便利

うちは長男が知的障害だからというのもあるけれど、小さいお子さんがいるご家庭や、老人のいる家庭ならあり得る、お漏らしした衣類の扱い…。これに困ってて、以前はとりあえず洗面所で手で水洗いして絞ってから洗濯してたけれど、臭いが取り切れてなかったりして他の衣服に臭いが移ることがあったので、それだけを別途洗濯してたんだけれど、往年のドラム式洗濯機は脱水機能もバカになっててどんなに少量でもなかなか成功しないし、洗いから任せたい場合でも洗濯物の量を測る機能が完全にバカになっていて、どれだけの量でも0.9を示すようになっていたため、水の無駄も多いし、時間もかかるし、大変だった。

そういうちょっと汚い衣類を、別で水でいいから洗っておきたいときに凄く重宝する。まず、10分ちょいくらいで終わる。そして、水の量も制御できるけれど、自動でも大丈夫だし、なにより先ほど書いた脱水能力が凄いので、おしっこの残り香がほぼなくなってて、安心して他の衣類と一緒に洗濯ができる。

縦型だけど乾燥機能、問題なし

洗濯物の量は気を付けないといけないと思うが、やや少なめの状態で洗濯・乾燥を一気にやってみたのだけれど、普通にフワフワに乾いていた。正直、乾燥機能のためにドラム式を選ぶ人は多いと思うし、自分も昔はそうだった。 また、縦型の乾燥機能は弱いから別途で専用乾燥機を使っていますという意見もネット上でよく見かけた。でも、本当にこれだけでええやん!と思うくらいには使い勝手がいい。専用乾燥機はちゃんと乾燥するけれど、一度洗濯機から乾燥機に移し替える作業が必要になるが、これはその必要もないし(それはドラム式も同じだが)。うちもまだ数回しか試してないから、今後は弱っていく可能性はあるのかもしれないけれど、今のところ、全く問題ない。

総括

今回買った東芝の洗濯機 ZABOON AW-10VP4は、乾燥機能もあるし容量も10kgなので縦型の中では高価格(13~15万)ではあるけれど、ドラム式の価格帯(18~30万)と比べると安いし、なによりパワフルかつ高機能でメンテナンス性も高い。

子供達が学校から帰ってきたときに、荷物に汚れた衣類があっても「まぁ我が家には脱水能力の優れた洗濯乾燥機があるからな」という気持ちでいられるのでストレスが激減!

妻とも話してたけれど、もうドラム式に戻ることはなさそう。縦型洗濯乾燥機、お薦めです。

チケット駆動開発を読んだ

翔泳社のショップのセールでポイント還元セールしていたときに『チケット駆動開発』を買って読んだ。

うちではRedmineでチケット駆動開発をしているんだけれど、なんかいまいちしっくりきていなかった。20代の頃に、この本の著者の小川さんのブログをよく読んでいて、チケット駆動開発の考え方にめちゃめちゃ感銘を受けて、それをやるようにしていた。自分の中では非常にしっくりきていたので、チームのメンバーが少なくて自分の裁量がかなりあるようなケースだと全然問題なくできてたんだけれど、今のチームになってから、形骸化した『なんちゃってスクラム』になっていたから、それを打破するためにカンバンに変えたりとか、色々としていた。

カンバンに変えたチームはそれはそれでうまくいくようになったからよかったかなと思うんだけれど、新製品を作るほうのチームではちゃんとスクラムできるんじゃないか?と思ってやろうとしてみたけれど、全然ダメで、結果、なんちゃってスクラムになっていた。ただ、メンバーが経験を積んできて成長してきたり、スクラムに対する理解が深まってきたことで、だいぶ良くなっている。良くなっているんだけれど、Redmineの運用の仕方が悪いのか、今でもそこまでうまくいってないと思う。単に、俺のプロジェクト管理能力が低いとも言えるが…。

最近、Geminiと相談しながら、Redmineの綺麗な運用方法を模索していたのだけれど、そこである程度クリアにすることができた。 ただ、その中でもカテゴリやバージョンの使い方、カスタムフィールドの使い方等、非常に悩んでいたので、他所がどういうふうに使っているのかを知りたかったし、自分の考えの正しさを確認したいという気持ちがあった。

バージョンの扱い方

最初、バージョンの使い方が下手過ぎた。開発フェーズとして使ってしまっていた。一次開発、二次開発のように…。 一次開発なんて、開発するものが大量にあるからRedmine上でWBSを上手くつくることができないのと大量のチケットのせいでクエリが重すぎて開けなくなったりしていた。 そのせいで、一次開発のリリースは済んでいるのに、対応されていないチケットがゾンビのように残っていた。

自分も、自身のタスクに追われてしまって、あるいはそれを言い訳に、プロジェクト全体を見る余裕がなかった。 ほぼ誰も過去のバージョンを整理することもなく、二次開発・三次開発と進んでいて、綱渡りでやっているような状態で、そんな状態だから結局タスクに追われて余裕がなくなるというスパイラルだった。 過去のチケット棚卸も時々やっているが、そんなに活かせてない。

本を読んでいるうちに、バージョンをどう扱うかというところが載っていて、リリース予定バージョン、ベースライン、イテレーション、マイルストーン、ビジネス要求として考えるというのがあった。

特別なバージョン

この中で、イテレーションのところにて、いつやるか分からない課題系を扱う特別なバージョンを用意しているという話があり、これは即採用させてもらった。

  • 35期3Q_課題一覧
  • 35期3Q_バグ一覧

を作った。本では、内部課題というバージョンを作っておいて、イテレーションが変わるタイミングで、そのイテレーションのバージョンにチケットを付け替えるのであろうけれど、うちの部署ではアジャイルプラグインを使っていて、イテレーションはそちらで管理しているため、バージョンは使わない。ただ、四半期毎にどれくらいの課題に対応したか、どれくらいのバグを対応したかを見える化できるやん!ということで採用。3Qで終わらなかったチケットは35期4Q_課題一覧などのほうに送られる。

昔のバージョンに紐づいたままのゾンビチケットについて、メンバーに確認をとりながら課題一覧のほうに移動させて、スプリントプランニングの対象にさせていったり、整地日(リファクタリング等を行う日)に対応してもらうなどで、ゾンビチケットを撃退していきたい。

マイルストーンとして考える

読んでいて一番しっくりくるのが、これだった。この機能をいつ頃までに確認できるようにしたい、という話があるのに、複数の機能開発が二次開発という大きなバージョンで括られている、かつ、各機能の予定日を入力する習慣がなかったものだから、全然見える化できていなかった。

この考え方を意識してバージョンを定義してチケットの関連付けをしっかり行ったら、そこそこ綺麗なガントチャートが出来上がって感動した。 もっと細かくマイルストーンを定義して、進捗を管理すべきだったと痛感しているところだが、余裕がなかったので仕方がない。未来でちゃんとしていけるようにしたい。

カスタムクエリを使ってシステム連携する

チケット一覧のところで、検索条件を保存することができるのだが、そこまで使いこなしてなかった。だが、これはめちゃめちゃ使える!!本を読むまでは、できることはもちろん知っていたんだけれど、そこまで活かせてなかった。 特に、RSSフィード(Atomフィード)でチケットを購読することができるのがでかい。

他のチームからの作業依頼のチケットを見るためのカスタムクエリを作って、それのRSSフィードをMicrosoftのPowerAutomateで購読して、チケットが登録されたらTeamsにメンションを送るようにした。Redmineでも担当者に登録されたらメールが送られてくるのだが、もうコミュニケーションがTeams等のチャットツールが主戦場でメールはあまり見ないので、これでだいぶ良くなった。

昔のチケット駆動開発と今のチケット駆動開発の違和感の正体

本を読んでいるときに思ったのだが、この本を読んでいると「チケットの情報が集まってくる」と書いてあったのだが、現代はなかなかそうなっていない。その原因はさきほども書いたが、コミュニケーションの主戦場がメールではなくチャットツールになっているからだ。

昔は、チケットに情報を書いて、1つ1つのチケットが掲示板のように扱われて、そこで議論が深まっていっていたのだが、今は議論は基本的にチャットツールでやる。なので、決まったことがチャットツールに残っているせいで、チケットに反映されないことが多くなってきた。 何故、小規模なチームの時はそこそこうまくいってたかと考えたんだが、議論に自分が参加しているから、決まったことをチケットに転記していた。しかし、今は参加しないこともあるから、それがそのままになったり、忙しさのせいで転記するのを忘れることがあった。

コミュニケーションツールの変化が、チケット駆動開発に影響を与えているということに気付けたので、今後は決まったことはチケットに転記するように伝えた。

とはいえ、チケット上だけでもやりとりできるんじゃないか?と考えて試してみたが、ダメだった。みんな、ほとんどRedmineからのメール見てない。結局、Teamsで「このチケットについてなんですが~」ってことになった。結局、そこのやりとりを転記した。

感想

チケット駆動開発に関する本だから、いろんな障害管理ツールの話が出てきて、それも学びがあったし、チケット駆動開発自体の概念や発展形の話、アンチパターンに関すること等があり、今の自分にとっては凄く発見が多くてよかった。この本の前に、Redmineによるタスクマネジメント実践技法という本が出ているらしくて、「詳しくはそちらを見てほしい」という書かれ方をしていたのでそちらも買ってみたが、まだ読めていない。テスト管理ツールとの連携の話があるみたいだったので、そちらも現代に合わせる形で調査してみたいと考えている。