Posts for: #Scrum

今期の予算づくり

#founding  #issue management  #scrum  #business  #exercise  #food 

今日の運動は腹筋ローラー,散歩,バスケットボールをした。統計を 運動の記録 にまとめる。

隔週の雑談

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

  • 税理士さんの変更に伴ういろいろな共有
  • 第6期の予算共有
  • 課題管理の働き方についての認定証を個人に与えるなにか
  • (時間があれば) 社宅の契約のいろいろ

まだ本格的にスタートするのは半年ほど先になる予定だが、先月から顧問を1人増やしている。はらさんは ui/ux の専門家であり、1人で20年以上会社を経営してきた個人経営の専門家としても私は評価していて、うちのようなマイクロ法人の経営についてアドバイスしてもらうのは最適だと考えている。先月に追加した顧問はさらに技術寄りの、一般的に言えば技術顧問に相当する。その方はある sier の cto を何年も務めているので実績も十分にある。本格的に始動するのがもう少し先なのはよいとして、技術顧問から課題管理ビジネスについて、いまから準備してやっていけることもあるのではないか？という意見が出た。

それは正しくはあるのだけど、私の時間がないというのが現状になる。

課題管理に関する情報収集も、現実の開発における poc も、この3-4年ずっとやってきたことの累積があるから十分にインプットを蓄積できている。これからやらないといけないのは、そういった溜め込んだ1次情報を見直し、整理し、体系化し、会社の戦略として練り直せないといけない。資料を読み、考え、フィードバックを得て洗練させる。地道で時間のかかる作業が必要になる。この時間が私にはいまない。体重を減らすために運動に時間を費やしているのもある。もう一つ、いまのお手伝い先の受託開発で私が開発の実務もやってしまっているというのがある。開発の実務をやると途端に時間がなくなる。なぜならば、プログラミングというのは製造業における設計に相当する業務なので、開発に終わりはないし、無限に品質を上げるための取り組みに注力してしまえるから。お手伝い先の受託開発で実務から離れない限りは課題管理のビジネス作りに時間を割く余裕がないというのが現状になる。

スクラムという開発方法論について調査した issue はいくつもある。そして、たとえば「スクラムのよくないところ」といった話題ではらさんと軽く話し始めたら20分は議論が尽きない。この話題で私はいくらでも話せるが、やらないといけないことは、そこからさらに洗練させて言語化しないといけない。そういったノウハウや概念の体系化や整理には得てして時間がかかる。

今期の予算を策定して現時点ではざっと500万円弱の赤字を見込む。今期から投資フェーズへ移行したいと考えている。役員報酬はすべて役員借入金にして会社のキャッシュアウトをなくせば、ほぼとんとんで会社は維持できる見込みで想定している。他社の実務は受けないけど、付加価値の高いコンサル案件なら多少は受けて赤字を減らすための施策はできないか？と思ったりもするけれど、なかなか難しいかなとも考えている。

バスケットボール

近所にある みなとのもり公園 でバスケットボールをしてきた。先日購入したバスケットボール をもって行った。幸いコートが1つ空いていて自由にドリブルやシュートの練習をしてみた。個別に自由練習できるからボールを2個買っておいてよかった。2人で練習していたら、途中から3人グループがやってきて、混ざって練習していた。私は別に独占する意図はないから人数少なかったらこうやって一緒に混ざって練習するのもいいかもなと思えた。それなら3つのコートが空いていなくても、人数の少ないコートに行って入れてもらってもよいかもしれない。もしくはミニゲームを申し込んでやってもよいのかもしれない。

1時間ほど練習したり1on1したりした。相手がわざわざ西明石から出てきてくれたので晩ご飯も食べにいった。夜に行ったことのない ISOGAMI餃子バル TOMAKO へ行ってみた。お客さんよく入っているし、お店の雰囲気もおしゃれだし、女性客も多い。よいところなのだろう？と勝手に思っていたけれど、実際に行ってみるとそれほど特別とも感じなかった。もちろん個々の単品はおいしかったし、十分に平均以上のお店ではあるのだけど、なにか小さくまとまった感があって、前を通る度に外からみて人気店なのだろうと上がっていた私の期待値に応えるほどではなかった。でも、軽く晩ご飯を食べて1-2時間ですぐ帰るといった用途にはよさそうに思えた。

言語化能力と仕事のパフォーマンス

#blog  #recipe  #event  #scrum  #issue management 

1時に寝て5時前に起きて6時半に起きた。起きてからホットクックで玄米を炊いてみた。2合で40分前後といったところ。

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

社内版テックブログを読む会の2回目

新しい取り組みの2回目。前回の所感はここ 。淡々と始めて淡々と終えた。これはそういうイベント。一方でマネージャーの視点からメンバーの取り組みをみていて1つ気付いたことがある。読解力、文章力、言語化力に個人差がある。そんなことは当たり前だが、たまたま最近ある動画をみた。8分20秒ぐらいからみてほしい。

この先輩が後輩に指導している中で日経新聞を題材に、情報処理能力を鍛えることの重要性を説明している。言語化能力を鍛えるために新聞を読む、映画をみる、日記も書く、文章能力を上げなさいと指導している。本当にこの通り。私が働いてきた組織では開発者で半分ぐらいの人しか文章を書けず、ビジネスの人に限ってはもっと多くの割合の人たちが書けない。そして若い人よりも年配の人たちの方ができない割合が多かった。それではビジネスで勝てないよという話し。テックブログを読む会はこの視点からも言語化能力を養うよい練習になるように思えた。

野菜スープのレシピ改改

先日つくった野菜スープ のさらなる改善。前回のレシピをさらにアレンジして今日のレシピはこれ。

  • にんじん x 1
  • 新玉ねぎ x 1
  • かぼちゃ 1/4切れ
  • ミディアムトマト x 8
  • セロリ x 1 の葉っぱ部分
  • しめじ 1袋
  • えのき 1袋
  • 鶏肉
  • ローリエ 1枚
  • 塩コショウ 適当
  • コンソメ (小さじ4杯)
  • 水 600cc

調理のワークフローもだいぶわかってきて、食材を切って内鍋へ入れるのも次の順番がよいように思う。

  1. 水を 600cc を入れる
  2. コンソメを小さじ4杯入れる
  3. ローリエを入れる
  4. 塩コショウを少々入れる
  5. にんじんをさいの目に切って入れる
  6. 新玉ねぎを細目にくし切りして入れる
  7. かぼちゃをさいの目に切って入れる
  8. しめじの石づきを切り落として、個々の房を分解しながら入れる
  9. えのきの石づきを切り落として、半分のところで切って、ばらかしながら入れる
  10. ミディアムトマトを洗って入れる (出来たては熱過ぎて火傷するから半分に切った方がよいかも？)
  11. 鶏肉の身と皮を分離して、それぞれをさいの目のサイズに小さく切って入れる
  12. セロリの葉っぱ部分を切って、適当なサイズで入れる

これで内鍋の水位 MAX の線がちょっと隠れるぐらい。ちょうどいっぱいになる。あとはホットクックの調理ボタンを押すだけ。だいたい40分程度。

スクラムマスターという功罪

QAエンジニアがスクラムマスターに憧れてしくじった話 に参加した。

失敗経験の共有をするという意味で発表そのものはおもしろかった。regional scrum gathering tokyo (rsgt) 2024 の発表の再演だったみたい。開発経験の浅い人がスクラムに馴染んでいない会社に転職していきなりスクラムマスターに挑戦してみて、全然うまくいきませんでしたといった失敗談の共有。その会社では、その後、組織改編されてスクラム導入も断念して、その発表者も結果的に退職してしまったとのこと。いろいろ悲しい。スクラムマスターは組織のライン上もチームの役割としても、実務に対しての責任を負っていない (建前上はチームの成功にコミットとあるけど、スクラムの運営をうまくやるための支援をするといった活動がメインになる) ため、若い人がいきなりスクラムマスターをやるというのは難しいのではないかと感じた。スクラムマスターの役割の1つにファシリテーションをうまくやってチームを誘導するみたいな風潮がある。しかし、私の感覚的には、ファシリテーションをうまくやっただけで開発がうまくいくわけないだろと自分の経験則からの反発もある。

私からみたら、この例は経験不足／実力不足の人が開発のマネジメントに影響力を及ぼそうとして、しかも転職したばかりの組織も開発もよくわかっていないチームで、そんなことそうそうできないってだけの話しにみえた。にもかかわらず、このイベントに参加している人たちはみんな優しくて、どうすればうまくいったか？を親身に相談にのってあげたり、その組織や会社の問題点をあげてフォローしたり、それはそれでやさしい世界ではあるけれど、社会人としての責任感といったところで私は相容れないものがあった。私自身、いろんな組織やチームで課題管理の価値を共有してきたけど、それも半年〜1年、私が実際に現実の開発の中で実践して、その価値が伝わっていく。こういった開発の運用を変えるというのをファシリテーションと啓蒙の (いわば) 口先介入だけで実現するのは相当のスキルや経験がいるのではないかとも思えた。

昼に寝て夜に考える

#life  #founding  #tax  #scrum  #project management  #issue management 

0時に寝て何度か起きて7時に起きた。昨日は晩ご飯食べてからだらだらしているうちにいつの間にか寝ていた。今日はオフィス暑くて14時から帰ってきてお昼寝して19時過ぎにまた戻った。

ストレッチ

先週末は実家や四国へ出掛けていたため、ストレッチをお休みしていた。2週間ぶりのストレッチとなる。右足がパンパンでひどいことになっていた。休んだことと出掛けていたことの疲労が重なったのか、右足のどこの部位も調子が悪くて歩くのもやや辛いと言える。相対的に左足が大丈夫なように聞こえるが、普通の感覚ではそれなりに張りがあるので左足も疲労している。あと腰も左右ともに負荷がかかっているように思えた。今日の開脚幅は開始前155cmで、ストレッチ後157cmだった。週末はちょっと休もうかと思ったぐらいの疲労度と体調の悪さを実感した。

工事業者の訪問

先日の 暑さ対策委員会 の続き。

ストレッチを終えてオフィスに向かうと、ちょうど同じエレベーターで工事業者さんと鉢合わせになった。いまから作業するところだったらしく、作業前にオフィスに入ってもらって通気口の状況を確認してもらった。いまの室温は30℃を少し上回ったところ。通気口からエアコンの風は出ているが、室内がまったく冷えないことを伝えた。そのときになにかの機器にガスを注入したという話しをしていた。これでダメなら (エアコンの？) メーカーの担当者と別の調査か対策を行うといった話しをされていた。何であれ、調査して原因の切り分けをして、次の作業へ進展している話しを聞いて安心した。但し、今日のところは、夜になっても室温の変化はみられなかった。まだ改善するかどうかはわからない。

遺産分割協議書の契印・割印の要否

弁護士さんから以前、作成した遺産分割協議書に割印をしていないことに気付き、税務署の手続きを進められない可能性があるから、もう一度、相続人全員の割印を取得してほしいと書類が届いた。すでに銀行・法務局の手続きは滞りなく終えている。こんな面倒なことを可能性があるという不確かな情報でやってられないと思って、本当に必要な手続きかどうかを税務署に確認してほしいと返信した。それと同時にググってみると、あるほうが改ざん防止になるので望ましいが、必須ではないという記事が多くみつかる。書類を作成するときに依頼されていれば応じるが、書類作成後になって大半の手続きも終えていて、相続税を払うためだけにそんなことやってられるかと思ってこのまま進めてほしいと押印せず書類も返送した。

もちろん税理士さんや税務署に裏付けをとる必要はあるが、ちょっと調べれば分かることをベテランの弁護士さんが調べずに顧客へ工数を転嫁することにがっかりした。

ストーリーポイント再考

少し前にみかけたポストで「ストーリーポイントは機能しない」というものがあった。

私もストーリーポイント否定派の1人だが、その投稿に発明者ですら謝罪していると書かれていた。それでずっと気になっていたので発明者の元記事を読んでみた。翻訳に近いが、日本語でも要約された記事もある。

これを読んでみて、発明者も言っていることは真っ当だと思う。ストーリーポイントがいかに誤用されているか、それによって意味のない時間を費やしているか。そもそも見積もりは現実のプロジェクトマネジメントにおいて必要とされるが、実際の開発においてまったく無意味であるといったことなどが書かれていて、ソフトウェア開発を見積もろうとする行為そのものがそもそも間違っていて、それをさらに相対化 (抽象化) させたストーリーポイントが役に立つわけがないとすら思えた。誤用されるなら、スプリントプランニングのためにストーリーポイントを使うのはまったくの無駄とまで言い切っている。

この記事を読んで不思議なことの1つに、実際にスクラムでストーリーポイントを使ってみれば意味のない指標であることに気付く開発者は多いと思う。スクラムガイドにおいても、見積もりより経験主義の重要性を説いているにも関わらず、なぜこんな誤ったメトリクスがスクラムとセットで導入されているのか、私には理解できない。プロジェクトマネジメントては別の、政治力学においてストーリーポイントが使われているのではないか？という気すらしてくる。

課題管理の文脈だと、見積もりは勘と経験でよいというのが私の解になる (ストーリーポイントを使ったところで出鱈目なんだから) 。課題管理と見積もりというテーマもなにかしらコンテツになりそうな気がした。

クレームへの階段

#founding  #scrum  #project management 

0時に寝て何度か起きて6時に起きた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週は多忙でお休みした。今日の議題はこれら。

たまたま X (twitter) でスクラム批判しているツィートを教えてもらってリンクにあるように Scrum is a cancer. というインパクトのある書き出しで聴衆を一気に掴んで盛り上がっていた。多少の誇張はあるものの、内容も真っ当で私が読んでみてもそんなに違和感がなかった。スクラムの懸念をうまく言語化したポストになっていたと思う。その延長で他にも、見積もり、フィードバック、ストーリーポイントにも言及していて、これらの話題についてはらさんと雑談してみた。はらさんとは1-2年前からスクラムの話題で何時間も話しているので、もうお互いに食傷気味ではある。ただ時事ネタなのと1年ぐらい経ったらアップデートもあるかな？という期待もあって話題に選択してみた。次のような意見が出た。

  • スクラムの開発プロジェクトをそんなに経験している開発者は少ないから主語が大きくなりがち
  • マネージャー入門としての、スクラムという開発方法論を評価してもよいのでないか？
  • 「スクラムにはマネージャーいない」と骨髄反射で返答をよくもらうがそれは理想論ではないか？
  • スクラムの失敗と事業／業務の失敗は違う
  • スクラムは毎日見積もり、デイリースクラムで確認できるというメリットがある
  • スクラムはチームの限定合理性を重視するため、個人の限定合理性を重視するメンバーを排除できる
  • スクラムの懸念の1つに全然できていないのに「できている」というメッセージを出し過ぎるのではないか？
  • ソフトウェア開発は前提として見積もりできないという認識をもつべき

お腹いっぱいなので詳細はあまり書かない。

オフィスの担当者との電話

先日の 暑さ対策委員会 の続き。

昨日、運営会社にその後の進捗を確認するために電話したらお休みだったので再度電話した。昨日もコールバックすると言いながら15時過ぎてもコールバックがなくて、もういい加減エスカレーションして偉い人に正式なクレームをあげようと考え始めていた。ようやく電話つながったと思ったら通話の音質が悪くて話しているうちに切断して、その後もつながらない。本当にイライラがつのる。2回目のコールバックで話していると、エアコンの工事によって隣のオフィスの人たちは問題ないと言っていたといったコメントが出てきた。

私のイライラが最高潮に達したのはこのとき。私はこれまでもずっと隣のオフィスの社員さんと暑さどうですか？という会話を何度かして先方も室内は暑いという話しを聞いていた。隣のオフィスの社員さんが問題ないなんて言うわけがないと思って、そのまま隣のオフィスへ言ってそこの社員さんにも電話に出てもらった。もちろん隣のオフィスの社員さんはこの件について一切やり取りしていない。社員さんも「(暑さについて) すぐ分かるから現場に来いっ！」って怒っていた。

ほんとその通りで7月の中旬からずっと伝えている。何もしていないわけではないのは理解するが、現地で確認したらこれまでの施策の効果がないことは一目瞭然である。一切確認せずに作業したから問題ないと判断して放置していたようにみえる。一連の対応が終わったときに正式なクレームとして運営会社にあげようと考えている。

  • 1ヶ月半の間に5回電話して一度もコールバックも進捗報告もなかった
  • 効果が出ていないことは報告しているにも関わらず、なんら施策を検討していない
  • 現地で確認すれば、ひどい暑さであることがすぐわかるのに1度も調べようとしなかった

台風の暴風雨にびびった

#remote work  #audio media  #issue management  #information exchange  #scrum  #go  #ldap 

台風が来るということだったので昨日は18時には家に戻ってきてゆっくりしていた。とくに何をしていたわけでもないけれど、なぜか眠れなくて3時ぐらいまでは起きていた気がする。あまりちゃんと眠れない中、7時に起きた。朝から外の暴風雨がすごくて人が飛ばされそうな勢いだった。さすがにオフィス行けないなと諦めて家でリモートワークしていた。お昼過ぎぐらいまで暴風雨が続いていたと思う。夕方になってから外に出たら普通の雨になっていてそれからオフィスに来た。

課題管理とプロジェクトマネージメントの話を熱く語る

理由があって先日 チェックした音声データ とは違う音声データを使って昨日の夜に公開された。週末働いてバテていたせいか、昨日は余裕なくて聞けなかったものの、深夜に聞き始めた。よいこと言っているなーと自画自賛しつついくつか間違ったことも話してしまっているけれど、私の話しにそこまで注意して聞く人はいないでしょう。

課題管理の話題になると、ついつい熱中して話してしまう。「熱く語る」と書かれてしまうのはこの分野に熱意をもっている人が稀だからかな。私はこの1-2年この分野をずっと調べているから、ここで話した10倍ぐらいのコンテンツをもっている。勉強会の資料も数個はあるし、スライドは200枚ぐらいある。そして、調べれば調べるほど私が分かっていないことも分かってきて、もっともっと調べたいことがある。しかし、いまいまはもう体力と気力がない。

エージェントアプリケーション開発

昨日の続き 。昨日レビューをしっかりしてもらってマージした。windows ad サーバーとの dirsync の通信のところを、一切動かさず、既存のコードをインターフェースにあうように作り直したものの、実際に動かしてみると非同期の制御が意図したデータフローでなかったり、windows ad サーバーの知らない仕様があったり、細かいバグもあったりで半日ほどかけてデバッグしながらバグ修正してた。単体レベルのテストでこのバグ数だと、qa レベルだとさらにバグありそうだなという感触だけ確かめた。その後 dirsync の検索も非同期になった方が嬉しいなと思ってちょっとリファクタリングして検証がてら提案してみた。特別なことをしなくても go-ldap の非同期検索を使ってそのまま動くことも確認できたのでこれはこれで役に立つと思う。

仕事始め

#founding  #scrum  #iterative and incremental development 

0時に寝て8時に起きた。夜に吐き気がしてやや苦しんだ。実家だと吐き気はなかったので寝方の問題なんやろか。今日からオフィスに出てお仕事を再開する。

名刺の発注

オフィスの住所を変更したので名刺を作り直さないといけない。オフィスの引っ越し作業の最後のタスクになる。名刺を配る機会そのものがないので優先度はかなり低いのだけど、一連の引っ越しタスクの親タスクを完了できないのも気持ち悪いので年末にやろうと考えていた。それが葬儀でなおざりになっていた。名刺データは Adobe Illustrator で管理されていて、その ai ファイルから編集した svg ファイルがある。この svg ファイルを inkscape というアプリケーションで読み込んでオフィスの住所が書かれたテキスト編集を行う。元データは有償フォントだったけれど、自分で編集できるよう、フォントも身近な M+ FONTS に置き換えている。

M+ FONTS のインストール方法。

$ unxz mplus-TESTFLIGHT-063a.tar.xz
$ tar xvf mplus-TESTFLIGHT-063a.tar
$ sudo mkdir /usr/share/fonts/truetype/mplus
$ sudo mv mplus-TESTFLIGHT-063a/*.ttf /usr/share/fonts/truetype/mplus/
$ fc-cache --verbose

ubuntu だったら inkscape は apt からインストールできる。

$ sudo apt install inkscape

inkspace で元の svg ファイルを読み込み、Ctrl + Shift + T でテキスト部分を編集して保存する。最後に次のバッチコマンドで svg を pdf に変換する。

$ inkscape --file=my-biz-card.svg --export-area-drawing --without-gui --export-pdf=my-biz-card.pdf

この pdf データを使って パプリ というサービスで名刺を発注した。

ビッグテックの技術系プロジェクトのマネジメント方法と興味深いスクラムの不採用

9月からずっと積ん読していて、本当は12月の課題管理勉強会で取り上げようと読み始めたものの、記事の文量が多いのでちゃんと精読してこれだけで1つの勉強会できそうと途中で読むのをやめて、1月の課題管理勉強会へと先送りしていた。

ローカルで deepl で機械翻訳しながらおかしな翻訳のところだけ精読して直したりしている。それでも数時間程度はかかった。すべて翻訳してからざっと読み返してみると、それほど特徴的なことを言っているわけでもなくて、もともと自分が知っていた内容にいくつか補足や背景があるといったものだった。記事の切り口が「ビッグテックはスクラムやってない」というキャッチャーなタイトルから掘り下げていて、もちろんビッグテックと他の企業との違い、そういう傾向がある背景も解説しているし、著者の経験や主観も展開されていておもしろい考察ではある。私もずっとスクラムよりもイテレーション開発の方がコミュニケーションコストが低い分、自由度が高くて開発者がオーナーシップや主導権を取りやすかったり、その結果として生産性を向上させられるといったことを考えていた。その自説を論理武装する内容もいくつか書いてあった。私にとって今後のコンテンツを書くときに役に立つ記事であることは間違いがない。これから勉強会の資料も作る。

全体を通しての要項をツィートにまとめてみた。

クリーンアーキテクチャを勉強し直したい

#design  #iterative and incremental development  #scrum  #founding 

0時に寝て5時前に起きたらサッカーやってて最後の10分ほどみた。まさかスペインに勝つと思ってなかったから驚いた。

アーキテクチャと設計

退職したメンバー がドメイン駆動開発 (DDD) とクリーンアーキテクチャから既存のアーキテクチャを構成したというドキュメントを残してくれた。そのドキュメントを読みながら、説明の粗いところや足りないところを私が補って加筆し、既存のコードを読みながら誤っているところなどをリファクタリングしたりしていた。あとアーキテクチャや設計のドキュメントを書く上で図がないのはよくない。現代の開発は分割統治の概念で設計されていて、そこで扱う本質的複雑さは依存関係になる。誤解を恐れずに言えば、現代の開発のアーキテクチャは依存関係をどう管理するかの基本的な考え方に過ぎない。依存関係の向きが分かるので図があった方が圧倒的にわかりやすい。一方で私自身もクリーンアーキテクチャにそう明るくない。もう少し勉強し直す必要があることは感じた。クリーンアーキテクチャ勉強会もやっていいようにも思う。

課題管理 + イテレーション開発とスクラム開発の勉強会

今週ずっと朝起きたら2-3時間かけて資料を作り続けてきた。前回は時間が余ったので今回は余らないよう、最終的には43枚のスライドになった。

  • スクラム事前知識
  • スクラムガイド
  • 課題管理+イテレーション開発とスクラム開発との比較
  • スクラムマスター
  • 会議体とツール
  • 分析・計測
  • スクラムの是非
  • まとめ

話してみたら1時間を10分ほどオーバーした。勉強会で1時間話すネタを調整をするのは難しい。毎月出張でオフィスへ行くときは課題管理に関する勉強会を行う。課題管理や開発方法論の話しを聞いてくれる人たちがいるというだけでありがたい。5日前から準備を始めて資料作りの時間が少なかったので細部の調査はあまりできていないし、構成も荒くて練れていない。もう2-3ヶ月かけて細部の調査や理論武装をしたらよいコンテンツになるかもしれない。イテレーション開発とスクラム開発を比較するときの叩き台として寝かしておく。

オフィスの引越しの荷造り

神戸に戻ってきて一旦家に帰って晩ご飯を食べて一息ついて、23時過ぎから引越しのための荷造りを始めた。大きい家電や電子機器は購入時の箱を置いておくと引越しのときの荷造りが楽になる。言うても一部屋の荷物なんで本気出せばすぐ終わる程度の量。3時間ほど荷造りやって8割ぐらいできたところで今日の作業は終えた。出張と移動で疲労は積み重なってきた。

1年間に渡ったお手伝いの最終日

#founding  #scrum  #communication 

2時に寝て7時に起きた。昨日は23時ぐらいまで送別会やっててまた寝るのが遅くなった。

隔週の雑談

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

昨日の送別会で、システムはいくらでも社員を監視して効率や最適化を要求できるけれど、そんな働き方は嫌だろうし、幸せじゃないだろうと私が話した。それに対して次のような反論がきた。

そんなことはなく誰か (何か) に管理されたいと考える人間の方が多数派だ

私はまったく同意しないのだけど、はらさんにも聞いてみた。リスクの多寡や有無ではないかと。リスクを取りたくない≒管理されたいと考える人が多いのではないかと答えてくれた。上司の言うことさえ聞いていれば自分は何も責任を負わなくてよいと考える人たちが一定数いることは私も理解できるが、そんな卑屈な人たちが多数派になるのかな？とやはり懐疑的に思えた。

プロジェクトの最終日

スプリントレビュー、送別会、今日のデイリースクラムと、今週は「最後なんで」の挨拶を3回ぐらいした。毎回話すことを用意しているわけでもなかったので即興で話すわけだけど、こういうところを私はもう少し準備してちゃんとした方がよいのかもしれないと反省もした。自己肯定感のセミナー でも書いたが、私は他人との比較をやめてから自分の尺度でしか生きていない。このプロジェクトで私が為したことはもちろん私の全力ではあるが、私がもてるスキルや知識のすべてを提供できたわけではない。それは組織の壁、業務の壁、伝えるスキルの稚拙さなど、様々な要因がある。一切の他責はなく、いまの成果物はすべて私の実力を反映しているものだけれども、その成果に自分自身では満足していない。10段階で言えば3ぐらいの成果だろう。自分では低い評価を下しているにも関わらず、他人からの賞賛を受け入れるのは難しい。辞めるときなので社交辞令もある。それも考慮して感謝の言葉をもらうときに、自分はそんな感謝を伝えられることをしていないというギャップに違和感を覚える。これは何を為しても満足できない、私が抱えている心の闇かもしれない。

それはともかくプロジェクトメンバーが オンライン寄せ書き にメッセージを書いて送ってくれた。オンラインの寄せ書きは無料だけど1年経つと削除されてしまう。メンバーが私のためにわざわざ時間をとって書いてくれた寄せ書きが消えてしまうというのはみんなに申し訳ない気持ちになって、プリントしてお届けを購入 (2,948円) することにした。情に訴えるビジネスモデルは抗いがたい。せっかくなので内容を秘匿して会社の宣伝にも使うかなぁ。

葬送のフリーレン で勇者ヒンメルは依頼人とあっさり別れるといったエピソードが出てくる。

旅をしてる以上また会うことだってあるだろう、また会った時恥ずかしいからね。

依頼人から報酬を受け取って貸し借りなし。それでお終い。この感覚は私にもあって、いまの時代、一緒に働いた同僚と離れても転職やなにかの縁でまた一緒に働くことは多々ある。あまり仰々しくしたくないと私も思う。送る側も良かれと思って気遣いしてくれている。それもわかるのでこういう価値観を伝えるのはなかなか難しい。

sql の group concat という組み込み関数

#postgresql  #scrum  #event 

2時に寝て7時に起きた。昨日の hannali dao が盛り上がった影響で夜更ししてた。

本番リリース後の緊急対応

昨日あるバッチ処理の本番リリースを行った。そのバッチ処理は本番環境のデータがないとテスト環境ではあまり有効な検証ができない。昨日は別のバグがあって実行できていなかったのを今日直して再実行したらまた別のバグを発見した。sql である集合を取得するときのグルーピングの条件が適切ではなかった。postgresql で mysql でいうところの group_concat に相当することをやりたい。How to Use string_agg() のチュートリアルをちょっとカスタマイズして引用する。次のようなデータがあると仮定する。

> select * from teams ;
  team_name  | team_member | num
-------------+-------------+-----
 Barcelona   | Messi       |   1
 Barcelona   | Piquet      |   2
 Barcelona   | (null)      |   3
 Real Madrid | Ronaldo     |   1
 Real Madrid | Benzema     |   2
 Real Madrid | Ramos       |   3
(6 行)

このときに team_name に対して team_member も集約して数値の合計を取りたいときがある。string_agg という組み込み関数を使うとできる。null があっても無視して数値の合計はしてくれる。

> select team_name, string_agg(team_member, ','), sum(num) from teams group by team_name;
  team_name  |      string_agg       | sum
-------------+-----------------------+-----
 Real Madrid | Ronaldo,Benzema,Ramos |   6
 Barcelona   | Messi,Piquet          |   6
(2 行)

送別会

プロジェクトの区切りの打ち上げと、私が今週末で契約終了となるので送別会を兼ねて催してくれた。感謝。実はこれまでプロジェクトの打ち上げに私は参加してこなかった。それは複数の意図があった。オンライン飲み会だと人数が多いほど話しにくいし、若い人たちだけの方が年長者に配慮しなくてたくさん話せていいんじゃないかと考えていた。私のような老い先短いメンバーがチームに馴染んでなくても日々の業務に変わりはないし、業務で発言しにくいといったこともないし、他に山ほど仕事の積み上げがあって他のことに時間を使えるならそれに越したこともない。過去に2-3回打ち上げしていたと思うけど、私は今回が最初で最後の参加となった。

都合のある人はばらばら抜けたりもしていたけど、9人ほどずっと参加していて20時から始めて23時過ぎまでやっていた。この人数だと、みんなが話せるというわけでもなくて、本当に2つのグループに分けて雑談した方がよかったのかもしれない。私は1-2割ぐらいの時間を話していたと思うけど、ほとんど聞いているだけで話さないメンバーも半分ぐらいはいたと思う。それは年長者がたくさん話せるように配慮して若い人たちが話しにくいというのは実際にあるのではないかなとも思えた。終わりの時間を決めておかないと延々話しが続いてしまう。チキンレースみたいになってしまって誰かが抜けると言わないと終わらない雰囲気になってしまった。それが23時過ぎで、ある人がそろそろ抜けますと宣言して「私も」「僕も」と続いて、じゃあお開きにしましょみたいなノリで解散となった。いろいろな話しができて楽しかった。

hannali dao に参加した

#scrum  #information exchange  #issue tracking system  #event  #dao 

23時に寝て1時に起きて2時間ほどだらだらしてて6時に起きた。

最後のふりかえりイベント

最終週なのでこのチームでのスプリントのふりかえりは今日が最後になる。メンバーが気を遣ってくれてこれまでの活動に感謝を伝えてくれた。いくつか出たコメントをあげる。

  • インフラを整備した
  • チケット駆動開発の基礎を伝えた
    • 課題管理のよさもわかってきた
    • メンバーが課題管理を行う習慣化につながった
  • 社内でもっとも backlog を使いこなしているチームになった

1年に渡って開発に参加して課題管理を見守ってきたので課題管理とは何ぞやの基礎をメンバーの大半は理解できるようになったと思う。(私からみて) ワークフローを洗練させるという視点で現状の運用は入門レベルではあるけれど、根っこの部分をちゃんと理解できているメンバーもちらほらみえてきたのであとは時間とともに上達していくのではないかと思う。このままもう2-3年取り組めばスクラムに頼らなくても高い生産性と迅速な情報共有ができるチームになるかもしれない。1年前はチームで課題管理がほとんどできていなかったのに、いまは大半のメンバーがやろうとするようになった。他のメンバーの行動を変えられたのが私としても嬉しい。いくつかの組織やチームで何度もやってきたことなので半年から1年あればできるというのは一定の信頼がおけて自信ももっている。今後の私の課題としてはこれを3ヶ月で達成する、1ヶ月で達成するための体系化やリーダーシップを作り上げていくことが考えられる。

hannali dao 始動

Hannali DAO に参加した。Metaアカウントへの移行(Workrooms向け) によると、2022年8月30日以降は meta アカウントではないと workrooms にアクセスできないらしい。ここ2-3ヶ月 workrooms を使っていなかったのでまとめてシステムのアップグレードや meta アカウントの移行なども行った。まったく難しくなくて手順通り作業を進めればアップグレード作業も含めて1時間もあれば完了するぐらいの作業量。当初は workrooms で開催する予定だったが、諸事情あって zoom 開催になった。とはいえ metamask の設定などをいろいろやっていたので結果的に zoom でよかった。

おがわさんが作った dao で利用できる PROG という名前のカスタムトークンをメンバーに配って受け取る。受け取る方も metamask で wallet と接続しないと受け取れない。polygonscan というサイトで自分のアドレスへの polygon ネットワークのトランザクションを次の uri で確認できる。PROG というカスタムトークンを 50 受領しているのがわかる。

これだけのことをやるのにまったく作業の勘どころが働かなくてみんな四苦八苦していた。たったこれだけを2時間ぐらい。その後、dao や世の中の事例について雑談。お互いの情報共有になっておもしろかった。私は web3 関連に技術体系には否定的なスタンスを取る方だけど、技術そのものを否定しているわけではなく、なにかしら価値はあると考えているのでどういった用途に使うのがよいのかを探りたいという思いがある。最後にそれぞれのメンバーがもっている PROG トークンの比率に応じて投票権をもつ。みんなの投票結果を使って次の開催日を決めてみた。本当の投票は手数料がかかるトークンを使ったアプリになるのだろうけど、このアプリは手数料なしで使えるらしい。

自分で自分を信用しない

#scrum  #event  #thought 

0時に寝て5時に起きた。朝から2時間ほどドラクエタクトしてた。

ふりかえりのフィードバック

先日 5日以上かけて非開発者向けのドキュメント を書き終えた。労力をかけてわかりやすいように書いたせいか、評判がよいという噂があり、ふりかえりのときにも先方の社内で共有されていて、他チームでも読まれているといったコメントをいただいた。それ自体は嬉しいことだ。一方で先方の社内に閉じている議論なのでドキュメントを書いた私には一切フィードバックはない。同じチームのメンバーからもほとんどない。

私はあまり自分自身を信用しない人間で、私が作った成果物はよいものだと考えていない。とくに初期のバージョンはすべてそう。誤り・勘違い・怠惰・抜け・漏れがいくつもあって3世代ぐらいのアップデートをこなさない限り、運用に耐えるものにはならないという考え方をする。書き終えたばかりのドキュメントを褒められても、自分の中ではそれはおかしいと思ってしまう。あんなものがよいはずがない。もっとよくするための取り組みがあるはずで、そのヒントを他者に期待しているところがある。単純に褒められるよりも「どこがわかりやすかった」「どこがわかりにくかった」「ここをもうちょっと詳しく」とか、そういったインタラクティブな議論を他者に求める傾向がある。それは自分自身が欠陥だらけだから。今回はふわっとした手応えで業務を終えることになる。

開発方法論を議論するのに飽きた

エンジニアリングマネージャーのしごと 読んでみたけど、質問ある？（答えられるとは言っていない に参加した。ちゃんとしたイベントじゃなくて、書籍を読んだ感想を discord で気軽に雑談するようなイベントだった。雑談と言っても話していたのは主催者のみで、他のメンバーはチャットにコメントして、それを主催者がみて話題として取り上げるといった進め方だった。悪いイベントではないのだけど、コミュニティの内輪感が強くて初めての人が参加するようなところではないなと思えた。

この1年、スクラムを実践しながらずっと開発方法論やマネジメント／リーダーシップについて考えてきた。考え抜いた (と言ってもたった1年だけど) 結論として開発方法論そのものはあまり重要ではないと結論づけた。重要なのは、自分たちの開発にとって障害や課題を認識したときに改善していけるか。そんなの当たり前だと思うかもしれない。改善するにあたって組織も含めて変えられるかというところが最も重要だと気付いた。スクラムにおいても、簡単な問題はすぐ解決しようとするのに、複雑で難しい問題はなぜ解決への試みすらやらないのだろう？とずっと不思議に思っていた。それは既存の組織や制度のなにかを変えないといけないとき、それらを改善の対象とみなすか・みなさないかという視点が人によって大きく異なることに気付いた。多くの人はそこまでやろうとしない。それは越権行為かもしれないし、思い付きで組織の決めごとを変えられても困るかもしれない。一方で私は頭がおかしくて組織や制度そのものも変えようとする。まず組織を変えようとするかどうかが最初の分水嶺になる。そして、実際に組織が変われるかという最大の課題もある。開発のためだけに組織を変えてくれと経営者にお願いして「わかった」という経営者は稀かもしれない。組織にも歴史や文化があり、会社には開発以外の様々な業務もある。大規模スクラムが提唱されるようになったのは組織を変えていくアプローチがスクラムには重要になってくるという証左かもしれない。

組織さえ変えられるのであれば開発はいくらでもよくなる可能性がある。これは小さい組織や若い組織にとってはとくに有利な点と言えるだろう。開発方法論に何を採用するか、初期のチームがうまく開発できないといったことは些事でしかない。自分たちの開発をより良くすることを本当にやろうとしているかどうかが重要だ。そのことに気付いてからゾンビスクラムをみかけたときも、これは組織のこういった課題から派生していると深堀りするようになってきた。