Posts for: #Issue Tracking System

ダブル掃除

0時に寝て3時に起きてちょっとネットみたりしてまた寝て7時に起きた。

今日の筋トレは腹筋:10x2,スクワット20x1をした。

ストレッチ

筋トレの疲労がたまっているのかもしれないが、今日も太ももの後ろの筋がかなり張っていた。胸筋もやや張りがあったように感じた。トレーナーさんによると、筋トレした後に使ったところはストレッチして伸ばした方がよいという。今日の開脚幅は開始前153cmで、ストレッチ後156cmだった。先週とほぼ同じ。

筋トレを継続できているのでトレーナーさんにいろいろ聞いてみた。

  • 筋トレメニューに慣れてきたら強度をあげる?回数を増やす?
    • 回数を増やした方がよい
    • 負荷をかけてしんどくなるとフォームが崩れて適切なトレーニングではなくなる懸念がある
  • 種別をもう1つ増やすなら何がよいか?
    • 背筋がいいんじゃないか
  • 筋トレを毎日やるのはどうか?
    • 大きな筋肉を使うトレーニングは2-3日休みを入れながらやった方がよい
    • 小さな筋肉なら毎日でも構わない
    • 私がやっている筋トレは10分でできるようなレベルなので毎日でよいだろう

電子帳簿保存法対応の事務処理規定と運用ガイドラインの策定

税理士さんに 電子帳簿保存法対応の事務処理規定の叩き台 をレビューしていただいた内容を規定に反映した。念のため、再レビューしてもらうが、これで完了とする予定。規定から実際の運用のためにガイドラインを作る。運用ガイドラインは notion にまとめる。

あまり notion を使う気になれないのは、課題管理システムをメインに使っているから wiki もそこにセットで付いていてほしいという願望がある。うちは jira cloud を使っているので本当は atlassian の wiki プロダクトを使いたいところだが confluence が使いにくいから使っていない。atlassian は confluence とは別にもっと軽量でシンプルな wiki プロダクトを別途提供すればよいのでないかとすら思う。一方で esa や notion のような、wiki 単体のサービスを活用するのは課題管理システムとの連携において不便なように思えた。だから notion は最近プロジェクト管理の方に手を広げているのかもしれない。 github や gitlab のように、課題管理システムと wiki はとても相性がよいのでツールセットで提供するのがよいと思う。今後のプロダクト構想の中で wiki を考えていなかったけれど、アプリケーション間連携という視点から考察してもよいかもしれない。

sns などで電子帳簿保存法対応がすごく大変といったメッセージをたまにみかける。この法律は電子取り引き (請求書や領収書を pdf ベースでやり取りするサービスなど) に対応するもので紙の請求書や領収書でやり取りしている事業者には影響はない。しかし、昨今取り引きが電子化されていく流れでもあるため、電子取り引きはまったくないという事業者もあまり存在しないのではないかと思う。そして、これまではそういった事業者が取り引きの証拠となる電子データを消失してしまっても法律から言及できないという状態だった。電子取り引きはデータしかその取り引きがあったことを証明する証拠がないのにそのデータを消失して OK なわけないよね?というのが本来の電子帳簿保存法の目的になる。

おそらくパソコンやシステムでデータ管理していない事業者にとっては取引データ保存の仕組みや運用を新規構築する必要があってコスト増になって大変なのだと推測する。しかし、私のような、最初から大半の取り引きは電子取り引きであり、そのデータもすべてクラウドストレージに整理した上で保存している事業者にとってはほとんど運用に影響を与えない。もちろん現行の運用にあうようにするには事務処理規定を策定しないといけない。ここで影響があるのは訂正・削除の運用時に記録を残すという点ぐらいしか、既存の運用と変わることはない。そして、過去の電子取り引きの訂正・削除が発生したことは私の記憶にないぐらい稀にしか発生しないと推測される。

低辺 sier のひどい労働環境や多重請負契約の構造を it 業界の代表的なもののように揶揄されるのと同様、いかに世の中のできない人たちが自分たちのスキル不足や知識不足を大騒ぎしてその内容が正当であるかのように喧伝しているのかが伺える。まともにシステムを使っている会社は電子帳簿保存法で大きな影響を受けない。多少の運用手順が変わったり、システムの開発が必要になったりする程度だと思われる。これはインボイス対応もそう。うちのようなマイクロ法人でもインボイス対応は新規の取引先を登録していく作業が増えたぐらいで日々の会計処理にほとんど影響を受けていない。世の中のニュースと実際の実務運用に大きな乖離がある。そして、実際にやったこともないような人たちが「弱者いじめ」だと党派性をもって大騒ぎする。

モニター変更

これまで27インチと24インチのダブルディスプレイを使ってきた。実家 (コワーキングスペース) に27インチのモニターを持って帰ろうと思って、24インチのモニターをもう1つ買ってその入れ替えをしていた。24インチ x 2 のダブルディスプレイに変更した。27インチ x 2 は有効視野を考えると幅が広過ぎて私にはあわない。首振りが疲れる。1台でもっと大きいモニターを使うという選択肢もあるかもしれない。しかし、私はなんとなく2台のディスプレイで1つをコードを書くメイン、もう1つをブラウザで調べたものを表示させておくためのサブという使い方を気に入っている。ただの習慣かもしれない。

人間の視野は左右の眼を合わせると180度以上あります。 片眼の視野は鼻側に約60度、耳側に約100度、上方向に約60度、下方向に約70度と言われています。その中で、標識の文字を読むなど、モノのカタチや色などがキチンと認識できる範囲を中心視と言い、わずか1~2度ほど。中心視のまわりの必要なものを識別できる範囲、有効視野は左右に35度ほど。その外側である周辺視野では、カタチや色などをハッキリと認識することはできません。

中心視と周辺視野

オフィス掃除

モニターを入れ替えしたら埃っぽくなったのでついでにオフィスも掃除した。掃除機は sharp の EC-CT12-C を使っている。サイクロンだからパワーもあるし、ゴミ捨ても紙パックいらないから簡単。コンパクトで数ヶ月に1回ぐらいしか使わない私の用途にちょうどよい。普段は箱にしまってある。

箱から掃除機を取り出して、終わったら片付けるときに箱にしまい方も書いてある。他の掃除機はどうなのか知らないけど、たまにしか使わない家電で使ったらまた箱にしまうよねと気の利いたこの絵が嬉しい。掃除機を作ることに一生懸命だとこういう気遣いはできない。こういった配慮ができるのは会社の文化や組織や開発体制に「余白」があるからじゃないかと、私もマネジメントをしていて最近は思うようになってきた。この絵があるからこの掃除機を購入するわけではない。それでも、この掃除機を使っていて故障してもまた sharp の掃除機を買おうかなという気持ちにさせる。

部屋のレイアウト変更

マンションに帰って22時半から部屋のレイアウト変更を始めた。少し前に ホットクック を購入したものの、思いの外、大きくて置く場所がなくてそのための 置き台 をジモティーで購入していた。その置き台を台所の横に設置するには、本棚をどかす必要があって、それは重労働になるのでついつい先延ばししていた。こんな感じ。

設置して無線 LAN の接続や COCORO HOME に家電登録してアプリ間連携の設定をしていた。私のような Web 系の開発者からみると設定 UI やわかりにくさはひどいものだったが、家電メーカーの作るアプリはそんなものだろう。ホットクックの WiFi は 2.4GHz しかサポートしていない。うちの無線 LAN ルーターは 5GHz only で稼働させていたので 2.4GHz も有効化して接続した。私が購入したホットクック (KN-HW24G-W) は COCORO KITCHEN に非対応だった。COCORO KITCHEN は deprecated で今後は COCORO HOME になるのかな?COCORO KITCHEN で家電登録しようとしてうまくいかないとまごまごしていた。

資料作りの一日

23時に寝て何度か起きて6時に起きた。疲労も溜まっているのでなるべく早く寝るように努めている。旅行中ずっと早起きしていたから早起きするのは苦にならない。

今開発の大きなふりかえりの資料作り

ふりかえりのために課題管理システムの issue 情報から統計的な数値を取得する。

gitlab の cli ツールを使って issue 情報を取得して mongodb にインポートする。

$ glab api --paginate "groups/product%2Funicorncidm/issues?milestone=2023-09-05&not[labels]=Duplicate,Invalid,Wontfix" | jq -c '.[]' > 2023-09-05-issues.json
$ mongoimport --authenticationDatabase=admin --uri "mongodb://root:secret@localhost:27017" --db gitlab --collection issues 2023-09-05-issues.json

mongodb で aggregation (sql で言うところの group by 句に相当する) するときはパイプライン処理を実装する。例えば、最初にデータをフィルターして、次にグルーピングして、最後にソートするのは次のようなパラメーターになる。

$ mongosh --username root --password secret
test> use gitlab
gitlab> db.issues.aggregate([
  { $match: { $or: [ { "milestone.title": "2023-09-05" },{ "milestone.title": "2023-09-19" } ] } },
  { $group: { "_id": { milestone: "$milestone.title" , author: "$author.username" }, councount: { "$sum": 1 } } },
  { $sort: { _id: 1 } }
])

これで前回の開発のときに取得した数値と今回の開発の数値を比較してみると、いろいろわかることもあって、メンバーが成長していることも伺えて、課題管理をしながら開発を進めることのメリットを実感できる開発になったのではないかと思う。gitlab のアクティビティ図 (草生え図) をみても前回の開発よりも草がたくさん生えているので課題管理に習熟している様子が伺える。これをあと2-3年ぐらいすれば、課題管理を使いこなせる一般の開発者になるのではないかと思う。課題管理 + イテレーション開発でチームビルディングしていくところの、地盤のようなものはできたようにみえる。

この草生え図を匿名化して利用許可をもらって、うちの会社でいうところの課題管理ができるようになると、メンバーの働き方はこうなるというサンプルとして紹介させてもらうつもり。また来週メンバーにもその許諾を取ろうと思う。

次開発の要件打ち合わせの資料作り

今開発を始めるときに洗い出した要件の未対応のものと、今開発でやり残した非機能要件の開発課題を資料にまとめてたたき台とした。それだけでも3-4ヶ月分の開発課題になりそうだし、アーキテクチャとして大きな意思決定も1つある。私自身、7割型は決まっているが、考え方や要件によってはもう1つの案でいくのもよいかもしれない。機能要件は実際にお客さん先へ導入するときにもいくつか出てくるだろうけれど、非機能要件の運用に影響を与える懸念のところはなるべく早く改善しておきたい。次の開発期間にそこだけ対応すれば、一定の安心をもってお客さんへ提供できるようになると思う。

定例会議のプラクティスとプロダクト

昨日も1時過ぎまで飲んでいて3時に寝て8時に起きて午前中はだらだらしていてお昼からオフィスへ出掛けて行って調べものをしていた。

課題管理の雑談会へ向けての準備

先日の準備 の続き。

先日は私が関心をもっていることの資料を整理し直して先方に提示した。今日は コパイロツト さんのプロダクトの1つである SuperGoodMeetings にアカウント登録していろいろ触っていた。その過程で Project Sprint プラクティカルガイド を読んだりもしていた。

SuperGoodMeetings は Project Sprint という考え方で定例会議をうまくやるためのプロダクトにみえる。アプリケーションの完成度も高いしよく出来ていると思う。私からみたら課題管理システムのサブセットにみえる。会議のアジェンダが個々の issue に相当して詳細に管理できる。ui も最近の課題管理システムのそれに近い。一方でこのプロダクトは開発者向けのツールではないため、このツールだけでシステム開発を管理することは想定していないのではないか?と推測される。その辺りの話しも来週、出張したときに中の人に聞いてみようと思う。

ぼくのかんがえたさいきょうの定例会議

1時に寝て何度か起きて8時に起きた。昨日ブログを書き終えてほっとしたのか、珍しく寝坊した。

課題管理の定例会議の進め方

5月31日から 新しい開発がスタート していてイテレーションを2週間に、そして定例会議も同様に隔週とした。その狙いは先日の日記に書いてあるが、これまで毎週やっていた定例会議の進め方はあわないので新規に会議の進め方を刷新した。これまでふりかえりと定例会議を別にやっていたのを1つにした。またふりかえりの会議のときに、ふりかえり作業そのものもやっていたのを、定例までに事前にメンバーがそれぞれやってきて、結果を定例のときに共有しようというやり方に改めた。ネガティブなふりかえりは発生時点で課題管理システムに登録してフィルター可能というのがアピールポイント。いまチームのメンバーが3人なのでこれでも会議は1時間でおさまる見積もり。メンバーが増えたらふりかえりと定例は別の時間にわけてやるかな?会議時間が長くなるとダレるので1つの会議は1時間以内で締めるというのは徹底したい。

  1. 現マイルストーンのふりかえり (目安時間: 25分)
    1. fun/done/learn を使ったポジティブなふりかえり で共有
    2. ネガティブなふりかえりは課題管理システムに Postmortem ラベルを付与して issue 登録したものを共有
  2. 次マイルストーンでやることの確認 (目安時間: 25分)
    1. 課題管理システムにある次マイルストーンでフィルターした issue を共有
  3. issue になっていないもので聞きたいことや分からないことを聞く (目安時間: 10分)
    1. メンバーが自由に意見を表明
  4. 雑談 (余り時間)
    1. メンバーが自由に雑談

事前準備を済ましてから、スクラムでいうところの、レトロスペクティブとプランニングを同時にやるといったもの。実践としてうまくいくかどうか、今回の開発で試してみる。

sveltekit の ssr を理解した

2時に寝て7時に起きた。キングダムの新刊を読みながら寝てた。

sveltekit の初期プロジェクト

技術選定で svelte を採用した ので昨日から SvelteKit でアプリケーション開発に着手した。Project structure にもだいぶ慣れてきた。開発初期はディレクトリ構成に迷うのでドキュメントに標準的な階層構造を書いてくれているのは素晴らしい。Routing もキモいけど、ssr の場合は +page.svelte+page.server.ts を設けるのに慣れてきた。ssr で proxy 的に web api 呼び出しも簡単に実装した。知らないフレームワークで開発するのは学ぶところが多くて楽しい。区切りのよいところで初期開発の issue はクローズして明日は gitlab ci/cd でテスト環境にデプロイするのをやってみる。

課題管理の雑談

過去に働いていた会社の同僚と課題管理について雑談した。web3 系の会社で働いているのでブロックチェーンや dao 周りの話しも一緒にしたりしていた。一回りぐらい私より若いと思うけれど、私よりはるかに優秀な開発者だなぁと感じながら話しを聞いていた。いま一緒に働いても足手まといになるんじゃないかと思えて身が引き締まる。いくつか話題の中で学んだことを抜き出してみる。

  • 自分の知識やスキルを共有する手段の1つとしてペアワークをやる
    • ペアワークを通してメンバーとの信頼関係も構築していく
    • いまもっている知識やスキルには個人差はあるが、模倣の能力が低い人をみたことがない
  • 上位の意思決定者から低いレベルにあわせる (標準化など) ように指示がきたときは反発する
    • ユーザーファーストが第一ならレベルを下げるような指示はおかしい
    • 「誰を向いて仕事しているの?」と説得する
  • プロジェクトにおいて目的を明確化せずに始めてしまうのは本当によくない
    • 日本人は上意下達で行動するように教育されてきた弊害ではないか
    • 目的を明確化するのは意見を言うことと同じである
      • レイヤーが上がるほどエモい話しになって人生観や哲学の話しになっていく
      • チームのモチベーションを維持する上でも有効ではないか

私はコミュ障だから他人と一緒に作業しようという発想がそもそもなかった。こちらから一緒にやろうと声をかけて知識やスキルを共有する手段もあるのかと気付いた。これまでも何人もの人にいろんな話しを伺っている。他人のノウハウを聞くだけでもこの雑談をすることに意味はあると思えた。

出張前日の準備

1時に寝て8時に起きた。午前中は洗濯して普通にだらだらしてた。

課題管理勉強会の資料作り

12月から読み始めた Gergely Orosz 氏の記事 をベースに来週の勉強会の資料を作った。もう少し推敲はするが、スライドで全32枚になった。ブログ記事の内容を解説するスライドなので文字が多い。1時間の枠には十分に耐えそう。この資料と前回の勉強会の資料の2つを知人とオンライン飲み会するときの話しのつまみに使う。毎月、課題管理の文脈で勉強会を行う労力はそこそこあるけれど、コンテンツが溜まっていくのは未来への投資になるので困ることは何もない。課題管理の勉強会があるという機会そのものに感謝する。

フリーランス、40歳の壁

フリーランス、40歳の壁 の中盤を読んだ。

  • 「第5章 田中圭一 サラリーマンとマンガ家を両立させる男。」
  • 「第6章 『電脳マヴォ』と私の未来。」
  • 「第7章 FROGMAN アニメ界の革命児が直面した「30歳の壁」。」

平日はサラリーマンで営業として働き、休日を利用してマンガを描くという働き方を30年以上している田中圭一さんのインタビューがある。30年以上と聞くとすごいことでその実績は否定しようがないと素直に思う。一方でうちは兼業農家だったので平日はサラリーマン、休日に農業をするのは普通だった。父はその生活を42年間していた。またうつ病になった経緯のエピソードがある。ある会社に転職して最初のうちはうまくいったが、5年目ぐらいで行き詰まってしまった。技術系の会社でプログラミングを学ばないといけないという空気があったらしい。会社の仕事があわないと田中氏は思いつつも転職する自信をもてず、そのまま10年いてうつ病になってしまったとのこと。これが3ヶ月だったら大変だったんだなと思う。しかし、厳しい言い方だけど、行き詰まりは仕方ないとしても5年もなにも対策しなかったの?と私なら思ってしまう。ここだけ読むと未知のことやスキル不足を勉強しない人の典型例だと思えてしまった。本業で成果を出せていないのに転職できないから会社に残り続ける人たちを私も少なからずみてきた。助言や提案をしても、例外なく、そういう人たちはできない理由を熱心に説明し、自ら努力してスキルを習得しようとはしなかった。できる・できない以前にやろうともしなかったのをみてきた。

著者が運営している 電脳マヴォ という web マンガのサイトがある。たまたまリンクをみつけた 良い祖母と孫の話 を読んでみたら衝撃をうけた。こういう才能がたくさん埋もれているというのは理解できる。一方で漫画を描くことが以前よりも一般化したのだとも私は思う。どんな業界も人気が出たり市場規模が大きくなるにつれその創作者人口は増える。電脳マヴォを創刊したのが2012年だったらしく、奇しくもその頃が「ネットマンガ元年」と呼べるらしい。となりのヤングジャンプマンガボックス など、私が知っている web マンガのサービスも出てくる。

フリーランスの最大の営業は、仕事そのものです。 版元編集者は、そのフリーが実際に行った仕事を見て、次の仕事を発注するのです。向こうから来る仕事であれば、意に沿わない仕事は、断ることもできます。持ち込みだと、まさかこちらから断るわけにはいきません。

この考え方は私も同意する。取り引きをしている会社とのお仕事を高い品質で行うことがもっとも重要だと私も考えている。

FROGMAN さんという方を私はまったく知らなかったけれど、インターネットの黎明期 (2000年頃) に動画配信サービスをやろうとして FLASH アニメで一山当てた実業家らしい。その経歴も破天荒にみえる。もともと映画業界で働いていて、映画業界の没落とともに半ば強制的にフリーランス (リストラ) となり、業界としての先行きは不透明だった。島根の山奥に移住し、インターネットに動画を配信する仕事なら島根でもできるだろうと考えたとのこと。これを2000年頃に実施しているのだから素晴らしい先見性と言える。その延長でアニメ制作をするにいたったのも、奥さんが妊娠して出産費用が必要となり、1人で仕事を完遂できればコスト削減できるというアイディアでアニメ制作を始めたとのこと。実写は最低でも数人のスタッフを必要とするが、アニメなら1人でできるのではないか。実際に初期のインターネットの FLASH アニメを1人で作って人気を博して事業が軌道になったらしい。スポンサーを募らず、徹底したコスト意識から権利をスポンサーに渡さないことを意識していた。2006年頃に youtube が台頭したときも、他のアニメ会社が映像を勝手にあげられるのを嫌ったのに対して、FROGMAN さんの会社は自分たちが権利をもっているので自分たちの作品を率先して配信し、時流にも乗ったようにみえる。FROGMAN さんは絵もろくに描いたことがなく、アニメマニアでもないにも関わらず、まさにビジネスモデルの勝利と言える。また実写業界での経験があったから普通のアニメ会社が作るようなアニメとは異なる作品を作り、アニメ落語・アニメ漫才というジャンルそのものを作ってしまったという。きっかけは家賃を半年間滞納して出産費用を捻出するためという、ピンチをチャンスに変えた事例の1つとして、また製作委員会方式というアニメ業界のモデルとは異なるビジネスモデルを考案して実現してしまったところもサクセスストーリーとして痛快に読めた。

日本酒を嗜む

22時から寝て2時に起きて5時に起きて7時に起きた。久しぶりに吐き気もなくよく眠れた。

雑多な整理

本当はやりかけて途中の svelte 入門をしようとオフィスに来たものの、課題管理システムの整理や週明け2日間のお仕事の準備などをやっていた。あと毎年そうなんだけど、うちの会社は交際費として年間で30万円の予算を計上している。現時点で7万円しか使っていない。放っておくと私は交際費を使わない。交際費を使わないというのは情報収集を疎かにしていると同義である。これから3ヶ月かけて交際費を使いつつオンラインで雑談してくれる人を探していく。この調整作業そのものにも時間と意識をとられる。人とやり取りして予定を調整する作業だけは効率化できない。過去に話したことのある人が徐々に増えていくと、また毎年のアレやりましょうと言えるのでコミュニケーションコストは下がっていく。一方で新しい人とも話していかないと視野が狭くなっていくのでバランスをとっていく必要がある。

忘年会のお酒選び

カフーツさんの忘年会 へ参加するときにもっていく飲みものを探してきた。ビールは用意してあるということなので灘五郷の日本酒をもっていくことにした。以前 灘五郷酒所 へ行ったときに飲んだ琥泉というお酒がおいしかったからそれを購入しようと調べていたら、同じ 泉酒造 では仙介という有名なお酒もある。実は2019年に近所の公園で灘の酒フェスティバルをやっていてそのときに仙介を飲んでおいしかったと記憶に残っていた。仙介は山田錦を100%使っていて琥泉が国産米となっていてこの素材の差が主な価格差 (720mlで2,050円と1,500円) になっていると推測される。イベントにもっていくならブランディング的に上等な方がよいかなと考えて仙介を忘年会に、琥泉を実家へもって帰ることにした。それぞれ次のお酒を購入した。どちらも生酒を選んだ。

おりがらみ とは、にごり酒の一種とみなすこともできるそうで「おり」と呼ばれる、米のかけらや酵母などの細かな固形物を少し残した日本酒を言うらしい。それによる風味の違いを楽しむといったものにみえる。たまたま灘五郷酒所で飲んだのがおりがらみだったので同じものを選択してみた。

初夏に 開発合宿 (ワーケーション) へ行く前のレンタカー運転リハーサル白鶴酒造資料館 へ行ったときにお土産に Hakutsuru Blanc を購入した。そのときにいくらか飲んでその後ずっと冷蔵庫に残っていたお酒を飲み終えた。灘五郷を学ぶよい機会だと思うのでこれから飲んだ灘五郷の酒造のお酒を課題管理してそれぞれの特徴や所感を溜めていこうと思う。

エピック名は BE KOBE にした。なんかうまくはまった。

課題管理の話題で発散

0時に寝て何度か起きて7時に起きた。だいぶ眠れるようになってきた。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。来年やりたいことというテーマだった。来年の抱負というほど堅苦しいわけではないが、それぞれの参加者別にやりたいことをわーっと話すようなイベントだった。私は課題管理について軽く話し始めたらいとうさんが深堀りしてくれて、参加者からも共感を得られてそれなりに盛り上がった。自分が参加したイベントの録画を見返すことを私は滅多にしないのだけど、今回は話した内容を整理するために見返した。

課題管理という分野の体系化、ならびにプラクティスの整備をしたい

ざっくり話した内容はこんな感じ。

  • 課題管理を追求していくにはメンバーに強制・指示できるだけの権限が必要となる

    • ボトムアップで課題管理を実践するのは難しい
    • 課題管理の実践のために人の運用を変えないといけない場面が出てくる
  • 私は it 業界のプロダクト開発における課題管理のノウハウしかない

    • 複数の組織・チームで働く過程で課題管理ができていない、または課題管理システムを使いこなせていない開発者やチームがたくさんあることを知ったのが背景になる
  • 本質的には、課題管理自体は業界・業種を問わない分野だと思うので広く応用できるプラクティスとして体系化したい

  • 課題管理とは、ハウツー本を読んだり、ツールを導入すれば解決する類のものではない

    • それぞれの目的のためにメンバーが日々の業務において運用していく必要がある
    • メンバー全員が運用しなかったら効果もその度合いに応じて減っていく
      • 権限が必要というのは、やらない人に対してある程度はやってもらう必要があるから
  • 課題管理をうまくやろうとすると、組織論や組織の文化、マネジメントの分野とも密接に紐づく

  • 課題管理と密接な分野の1つに情報共有がある

    • 情報の一元管理は組織において重要なのに疎かになっている組織やチームは多い
      • 一元管理できると情報共有のためのコミュニケーションコストを削減できる
      • このためには組織レベルで使うツールや情報共有のやり方を統一しないといけない
        • 自分の好きなツールを使って自由に情報共有するといったものをいくらか制限する必要がある
  • 課題管理において重要なことの1つに文章を書けない人たちが一定数いることを受け入れないといけない

    • 情報共有の文脈で言えば、テキスト化は検索できるという大きなメリットをもたらす
    • 一定数の文章を書けない人たちをどう対応するかは難しい課題の1つ
      • 文章を書くための練習をすればよいのではないか
        • 新人やキャリアの浅いメンバーには有効となる
      • 文章を書かなくても情報共有できる手段と組み合わせるとよいのではないか
        • it 業界ではスクラム開発という開発方法論が流行っている
          • 大雑把に言えば、対話を重視して会議をたくさん設けることで情報共有を密にする開発方法論と言える
            • 文章を書けない人であっても話せない人はほぼいない
            • 対話を促されれば話すことで情報共有できる
          • デメリットとしてはコミュニケーションコストがとても高い
            • このコミュニケーションコストは開発における生産性とトレードオフになる
  • 課題管理において重要なことのもう1つに文章を読めない人たちも一定数いる

    • 日本人の1/3は日本語が読めない?PIAAC (国際成人力調査) の調査結果
    • 文章を書いてメンバーに読んでおいてと伝えても1/3は理解できていない可能性を示唆している
      • 情報共有において文章を書いても伝わっていない可能性を考慮して対策する必要がある
  • 仮に情報共有できていない状態でメンバー「わからない」と言えることはすごく重要になる

    • この文脈で心理的安全性が重要になる
    • 「わからない」と声をあげてくれることで文章や伝え方を改善していける可能性がある
  • 実は一昔前と比べて、いまの方がメンバー間の情報共有を疎遠にしている背景がある

    • いまは情報共有にクラウドサービスを使う組織が増えている
      • 基本的にクラウドサービスはユーザー単位/従量制で課金される
        • あまりサービスを使わないユーザーアカウントを減らすことでコストダウンできるインセンティブが働く
          • 情報共有という視点からコストダウンしてはいけないコストを削ってしまっている
            • 例) 課題管理システムのアカウントは開発者しかもっていないとか
      • 中小規模の会社ほどクラウドサービスを多用するのでこの傾向がある
    • 昔はオンプレで社内システムを管理していたため、システムのユーザーを減らすインセンティブはなかった
      • 要否に関わらず、社員は全員アカウントをもっていることが当たり前だった
    • 念のため、クラウドサービスのアカウントをメンバー全員がもつことは目的ではない
      • アカウントをもった上でそのメンバーがそのサービスを使うように運用を変えていく必要がある
      • システム投資とメンバーの運用を変える取り組みがセットでないとうまくいかない
  • コワーキングスペースは課題が持ち込まれるところではある

    • 課題管理のプラクティスが応用できるなら使いたい
    • 課題をどう整理して、優先順位を付け、情報共有していくかは難しい
    • 様々なメンバー、様々なツール、様々な課題を同じツールで一元管理することは非常に難しい
      • どうやって情報の一元管理をするかはコワーキングスペースの運営において難しい課題でもある
        • 複数のサービスを連携するサービスなどを使って一元管理する方法もある
      • 海外ではコワーキングスペース向けの sns も含めたプラットフォームサービスなども出始めている
        • 日本ではまだまだあまりシステム化されておらず、導入もされていないのではないか
  • コワーキングの分野では女性がとても活躍しているように、いとうさんから見えている

    • 今後もこの分野を盛り上げていくのは女性ではないか?
      • 男性は変なプライドが邪魔して行動力を抑制してしまうところがあるのではないか
      • 女性は損得勘定から行動力を発揮しているのではないか
        • 男性の方が感情的な動機でコワーキングをしているようにみえる?
  • コワーキングに課題管理の理論やシステム化はあってよいのではないかと、いとうさんはみている

キックオフのマイルストーン

2時に寝て5時に起きて7時に起きた。いろいろ余裕ない。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

フロントエンドの開発は monorepo が主流といった話題になって本来の monorepo はビッグテックが全社レベルで展開している巨大リポジトリのことを指していたんじゃないかという話しになった。どちらが正しいという話しでもない気はするけど、プロダクトやサービスレベルの monorepo と開発者が数万人いるような会社で開発しているものを1つのリポジトリにすべて管理する monorepo では、議論していて噛み合わないと確認した。どちらも monorepo と呼ぶからどちらかの名前を変えるべきなのかもしれない。そう言えば facebook が自社のソースコード管理システムを oss で公開していたニュースを最近みかけていた。

11月のマイルストーンをほぼ終えた

開発スケジュールの期間を表す単位を次の3つの用語で管理する。

  • 1週間を1つのイテレーション
  • 4イテレーションを1つのマイルストーン
  • マイルストーンを複数集めたものを1つのロードマップ

11月のマイルストーンの締め切り日を11月29日としている。あと月曜日だけなので11月のマイルストーンをほぼ終えたと言える。このマイルストーンの目的は要件定義を確定させることに置いていた。というのは、開発体制が大きく変わり、新規参加者が私も含めて3人いる。前任者からの引き継ぎ、開発対象の再定義など、曖昧な要件の部分を私がすべて洗い出して初期の開発目標の言語化を狙いとしていた。概ね狙い通りには進捗して可もなく不可もなくという認識。プロジェクトのキックオフの初月としては十分とみなすこともできる。

開発メンバーが課題管理システム (gitlab) に慣れていて、私の指示や意図をすぐに把握して行動してくれているので課題管理はとてもやりやすい。前月に手伝っていた sier の開発者とは格段にレベルが違う。大雑把に言えば、開発メンバーが優秀だからちゃんとマネジメントすれば成果を出せる見通しが立っている。

Go Test Comments の学び直し

Go Code Review Comments の勉強会 を前半・後半の2週にわけて読み終えたのでその次に Go Test Comments を読んだ。ちょうど Gopher塾のテスト会 に参加した後だったのもあり、書いてある内容のいくつかは重複していて、記憶に新しかった。開発メンバーがいま書いている単体テストに有効なアドバイスもいくつかあって参考にになったように思う。wiki に書いてあることにすべて従う必要はないものの、簡単にできて役に立ちそうなものはどんどん導入すればよいと私は考えている。

寝ることとお仕事の選び方

20時過ぎに寝て0時に起きて、何度か寝たり起きたりしながら7時に起きた。神戸マラソン のスタート地点が近所なので朝から神戸マラソンのアナウンスが聞こえてきた。

睡眠時間と仕事始め

後藤達也 note の掲示板 (たぶんメンバーしかみれない) に後藤さんがいつ寝ているのかという質問への回答を書かれていた。

よくある睡眠パターンは21:30ごろ~4:30とかだと思います。これだと7時間寝ているので十分です。

後藤さんも早寝早起き派らしい。私はだいたい0-6時が平均的なパターンだと思うけど、ちゃんと眠れないので6時間も寝ていない。体調の悪いときは横になっているものの1-2時間しか寝ていないときもある。7時半までには家を出てオフィスに向かい8時までにはお仕事を始める。開発が佳境に入ってきて集中力が上がっていれば仕事始めが6時半から7時ぐらいになる。開発のピークにそういう時期をもっていくように調整しながら働くときもある。最近は働き方改革でそういった密度の高い開発を要求されることも少なくはなりつつあるけど。

仕事を受ける判断

後藤さんはすごいなーと読んでいたら睡眠時間の投稿が思いの外盛り上がったらしく、第2段として仕事の選び方について投稿されていた。

そのなかで仕事を受ける判断として大事にしているのが、「発見があるか」「広がりがあるか」です。

これも私にとって共感のある内容でその投稿を読み入ってしまった。これまでも日記のあちこちに断片的には書いてきている。私も2021年1月31日に会社として引き受けないお仕事の基準を設けた。次の項目に該当したら基本的に引き受けない。

  • 自分の目指すキャリアの延長上にない
  • 自分がもっている知識や経験だけでできる
  • すでにあるものを維持していく、手伝うだけ
  • そこそこの開発メンバーがいて人手が足りないのを補うだけ
  • 権限委譲がなくてイニシアティブを取れない

どういうお仕事を受けて、どういう働き方をするかを課題管理し、その後も継続的にずっと考えていてまだ答えは出ていない。もう2-3年かければより明確になりそうな気はしている。やりたいことよりもやりたくないことを定義する方がずっと簡単で具体的と言える。

jira の epic 運用にもの思い

jira に特化した話だけど、チケットの整理をしていて自分の中での結論を言語化できたので書いてみる。前からずっと思っていたことではある。twitter に書いた通りだけど、epic のサブタスクはあまり使わない運用がよいのではないかと思うようになった。そもそも epic という単位が story よりも大きな機能のグルーピングを表す概念なのだから epic チケットはシステム上の制約で存在しているだけでそれを通常のチケットのように扱わなくてもよいのではないかと思う。epic に限らず、チケットを束ねるだけのハブチケットまたは親チケットに通常のチケット機能を設けない方がユーザーにとってわかりやすいようにも考えている。ハブチケットや親チケットに特化した要件や振る舞いはあるはずで、多くの課題管理システムはそれを追求していないようにもみえる。

課題の洗い出し

20時に寝て0時に起きて、3時に起きて6時に起きた。春先のような、なぜかたくさん眠れる状態になった。

ソースコードを読むマネージャー

アリエルをやめてから複数の組織で働いてきたけれど、以降ソースコードを読むマネージャーを1人もみたことがない。アリエルなんか cto が日々の開発のソースコードを読んでいたぐらいなのに。もしかしたらテックリードというマネジメントはしないが、開発のリーダー役のポジションができたせいかもしれない。そしてエンジニアリングマネージャーがソースコードを読んでいるのも見たことがない。いま私はプロダクト開発のマネージャーとしてお手伝いしているわけだけど、毎日変わるソースコードを読みながら、私が懸念に思ったコードについて issue 登録したり、技術的な課題であれば改善提案したりしている。もし開発リソースが足りそうになければ、私も開発に参戦しようと虎視眈々と狙っているのもある。

まだ初期開発フェーズなので粗いところが多々あるから読みがいがある (提案しやすい) というのもあるかもしれない。ソースコードも読めない (読まない) マネージャーが開発の進捗を正しく検査できると私は考えていない。その姿勢でプロジェクトマネジメントがどのように進捗して、どのような結果になるのか、これから私が実践して自分なりの考えをまとめたい。