Posts for: #2023/02

余裕がなさ過ぎる

#founding  #communication  #team building  #go  #design 

1時に寝て7時に起きた。タスクが溜まり過ぎてそろそろ辛くなってきているところ。この余裕の無さはよくないことなので、自分のダメさ加減というか、大いに反省しないといけない。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつもは打ち合わせの議題を2-3日前には共有するようにしている。だいたい水曜日前後に議題のリファレンスをはらさんに共有して金曜日の朝に話している。しかし、今週はリファクタリングに集中し過ぎていて前日の寝る前になって議題を共有していないことに気付いた。そして朝起きてから急ぎで議題を考えて共有していた。これはとてもよくない。準備ができていないので今日の議題は主に近況の話しをしていた。

ハドルの雑談

先日から 午前中はハドルに滞在 するようにしている。今週は木曜日にチーム外から勉強会についての相談が、今日はメンバーから気分転換に雑談にやってきてくれた。おそらく私がハドルにいなかったらゼロだったコミュニケーションの機会が、1週間に1-2回でもあることに私は嬉しく思ってしまう。フルリモートワークにおける、オフラインのような気軽な雑談の機会を提供する施策の1つとして意味なくハドルに入るのは悪くない気がしている。そのときにコミュニケーションを強制させるような押し付けが発生しないよう、運用ルールを徹底することが大事に思える。いまは相手がハドルに入ってくると 1on1 のような雰囲気になってしまうのでその次の挑戦としてはハドルに入っていても話さなくてよいといった運用ルールを設ければよいのではないかと思う。例えば、午前中はとりあえずハドルに入って気分が向いたときだけ話しかけるみたいな、ゆるいコミュニケーションの場になればいいなと思う。

ハドル雑談の運用ルールのアイディア

  • ハドルに入らなくても業務上の支障は一切おきない
  • ハドルにいる人には、用事があってもなくても、話しかけてよい
  • ハドルに入っていても話さず聞いているだけでもよい
  • 業務に集中していて忙しいときは話しかけられても後回しにしてもよい (ハドルから退出した方がわかりやすいかもしれない)

go の generics 勉強会

ちょうど先週からあちこち直したり、mongodb のクライアント周りをリファクタリングしたりしている。その過程で generics を使ってコードの共通化もしたりしている。私自身 generics で意図した通りにコンパイルできなくてはまってしまった事例もあるのでそういった失敗コードも共有した。go の generics はコードに対して静的な領域しか適用されず、コード中における動的な値の型は generics とは直行した概念だというところに初学者ははまるのではないかと思う。私がはまった。参加者におそらく1度はまるからはまったときに私が話していたことを思い出してとコードの解説をしていた。

余裕があったらスライドにまとめて後で資料として再利用できるようにしたかったものの、私の作業に余裕がなさ過ぎて次のリファレンスから引用しながら解説するといった勉強会になった。ただ私が読んでよいと思った他者のスライドやブログの記事のみを紹介している。それはそれで参考にはなるので勉強会の意図としては問題なかったんじゃないかとは思う。

mongodb を触ってみる

#refactoring  #design 

0時に寝て7時半に起きた。今日は1日中リファクタリングしてコードを書いていた。

リファクタリング

mongodb 周りのインフラ層のリファクタリングしている。過去に mongodb を触ったことがなかったので mongodb そのものの振る舞いや仕様なども理解しながらリファクタリングしている。その第一弾として差分が1500行以上のマージリクエストを作った。私の中ではまだ 1/3 ぐらいの進捗。動くレベルになったのでコードレビューを通じてメンバーと設計の考え方を共有していく。差分は多いけど、重要なところは一部だけ。やり過ぎだなと思えるのは、設計を見直すとテストコードを書き換える必要があって、その書き換えをやっていると時間が削られる。設計の部分だけ変更して、その後の作業をメンバーに引き継いでもらうといったやり方ならもっと早くできるかもしれないけど、テストコードを書き換える過程で私もユーザーの立場になって設計の良し悪しを検証するきっかけになるのでこの作業は自分でやることにも価値があると考えている。

設計がよくないところをどうやってメンバーに指導していくかはなかなか難しい。良し悪しは複数の設計を比較することで初めて気づくことも多い。私はその引き出しが多いので比較対象がたくさんあるだけでメンバーはその引き出しが少ないから悪い設計と認識できないでいる。その比較対象を私が提示してメンバーが考える機会にしてあげたい。理屈上はこれだけなんだけど、現実のコードと納期とのバランスを取るのが難しい。

いい加減マネージャーがリファクタリングに工数を使い過ぎだろうと私自身でも思うようになってきたので週末に残りのコードを書いて区切りのよいところでひと段落つけようと思う。

後世に残せるものを書く

#book  #database  #coworking  #community  #event 

0時に寝て4時に起きて6時半に起きた。今日は3つのイベントに参加して疲れた。そのうちの2つを紹介する。

データ指向アプリケーションデザインの紹介イベント

Data Engineering Study #18「データ指向アプリケーションデザイン」 に参加した。監訳者のさいとうさんのブログの 2022年を振り返って を読んだときにたまたまみつけて登録していた。

14:00 - 16:30 というちょっと変わった時間帯に設定されているのはさいとうさんが米国在住で時差によるものだと推測する。さいとうさんのいる場所では21時ぐらいと話されていたような気がする。2時間半分のお仕事を休んでもこのイベントは聞きたいなと思ったので取引先に連絡した上でその時間帯はイベントを聞いていた。

この本は人類の叡智といってよいと私は思う。 さいとうさんによると、2007-2017年の過去10年間の分散データシステムの教科書と紹介されていた。私はそれ以前の研究を知っているわけではないので、私のような初学者にとってはもっと長い期間のデータベース研究の歴史を学べるように感じた。 著者はこの本を書くのに4年を費やしたという。本を1冊書くのに4年とか、著者の偉大さが伺える年月でもある。

著者はデータベースの研究者であろうけれど、すべての研究を自分で行ったわけではないだろう。 他者の研究を調査した上でこういった書籍にまとめるというお仕事も非常に価値のあることだと本書を読んで実感した。私も課題管理の分野でそういうことができればいいなと思う。

さいとうさんの講演のタイトルは「30分でわかる〜」という接頭辞がついているものの、さいとうさんと同レベルの人にしかわかるわけはなくて、このイベントに参加しても本に書いてある全体像がわかるだけで、本の内容がわかることはほぼないと言える。私はこの本を精読したのでさいとうさんの話しを聞きながら、あの辺の書いてあった話しの紹介だなと記憶を辿りながら聞いていた。

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

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。今日の話題は 間借りコワーキング だった。実際にカフーツさんで間借りコワーキングを実践された方をゲストにお招きしてその体験談を話してもらってみんなで議論したりしていた。ここで言う間借りとは、コワーキングスペースの運営をメンバーにも体験してもらってそこから新たな価値を模索しようといったもの。インターンシップのようなものとも言えるし価値創造のための施策とも受け取れる。ただのアルバイトではないという意図で「間借り」という名前を付けている。最初に説明を聞いていて、あまり私にはピンと来なかった。それは it 業界は勉強会を個々に開くのが当たり前過ぎて、そんなのはわざわざコワーキングスペースの運営者にならなくてもすぐにできることのように思えたから。おそらくここは it 業界が先進的過ぎて、普通の組織や会社に勤めている人は、気軽に知人や不特定多数の人たちを呼んで勉強会 (イベント) をしたりしないのだと推測する。

それからコミュニティの話題で、強い紐帯と弱い紐帯の話しが出てきて、リンダ・グラットン 氏の著書に書いてあった言葉として「境界接続者」という用語を紹介されていた。私が軽くググってみてもその用語は出てこないのでおそらくは次の研究者の研究を紹介されている一節だったのではないかと推測する。

　アメリカの社会学者Ｍ・グラノヴェッターの「弱い紐帯の強さ」という有名な説をご存じの方は多いと思う。「紐帯（ちゅうたい）」とは文字どおり紐（ひも）や帯（おび）のことではあるが、転じて「二つのものをかたく結びつけるもの」また「 血縁・地縁・利害関係など、社会を形づくる結びつき」という意味がある。（「デジタル大辞泉」より）「弱い紐帯の強さ」とは『価値ある情報の伝達やイノベーションの伝播においては、家族や親友、同じ職場の仲間のような強いネットワーク（強い紐帯）よりも、「ちょっとした知り合い」や「知人の知人」のような弱いネットワーク（弱い紐帯）が重要である』という社会ネットワーク理論である。もう40年前に発表されたが、SNSが世の中を席巻するようになり再び注目をあびている。

会社内の「弱い紐帯（ちゅうたい）」

なにかの英語の言葉の訳語として「境界接続者」という用語をあてているのだと推測する。ここでいう境界とは、コミュニティとコミュニティをつなぐ役割をする人のことでそういった人がコミュニティにおいて大きな価値を提供しているというのが、弱い紐帯の強さで提案されている価値に相当するらしい。それを体験もしくは実践する機会として間借りコワーキングはうまく作用するのではないかという企画につながってくる。そこまで聞いて、単なるインターンシップではないことは理解できた。

私はどちらかと言うと弱い紐帯よりも強い紐帯のコミュニティの価値を認める方だと言える。その真逆の考え方は懸念もいくつかあるものの、普段は考えないことを考える機会としておもしろかったと言える。社会で生きていく上でどちらの要素もあることなので一方に固執しなくてもよいというのも正しいと思う。

個人の人生と会社の経営

#refactoring  #project management  #management  #life 

1時に寝て6時半に起きた。久しぶりに起きずに長時間眠れた気がする。1-2ヶ月に1回あるかどうかぐらいの感覚。

リファクタリング

ここ最近、私がバックエンドのリファクタリングを集中的にやっている。私からみたらバックエンドの設計にはいくつか改善の余地がある。動いているという視点では及第点ではあるし、メンバーは限られた時間の中で十分にうまく開発していると考えている。それでも、遊撃として余裕があるときにリファクタリングをしている。これから運用レベルの QA テストに入っていく。その前にがーっとリファクタリングしておくとテストで振る舞いを検証できるし、テストで別の不具合をみつけたときも保守コストが下がるように設計を洗練させておくことには一考の価値がある。実際にコードを書き始めると時間をどんどん取られて、マネジメントの業務から離れていってしまう。マネージャーがコードに集中し過ぎるのも問題だというのも理解できるようになってきた。本来はあまり深入りしない程度にメンバーに要点を伝えて改善したもらうのが正しいとは思う。いろいろプロジェクトの都合があるので必ずしも思い描いたようにはいかない。バランスをとってうまくやりたい。

余暇と経営と個人

1月以降は実家の法事のために私の余暇の半分程度の時間を取られている。先週末に49日を終えたので次の法事は初盆まで余裕がある。とはいえ、弁護士さんと実家と相続のやり取りがあってまだ何割か時間を取られている。この余暇の時間に、これまでは自社の業務や事務手続きをしている。その余暇が少なくなると、最終的には他のところにも皺寄せがいく。余暇に余裕がないと自分の会社を経営するのはなかなかしんどいところもあるかもしれない。

来季は実家の一部を自社のオフィスにしようと考えている。よくよく考えれば、神戸のオフィスでフルリモートワークをするのも、淡路島のオフィスでフルリモートワークをするのも、お客さんからみたら全く違いがない。いままでそうしてこなかったのは、神戸のオフィスでは業務に集中できるよう、私にとって最適な環境を構築し続けているからと言える。最も大きな違いは椅子だと思う。よい椅子でデスクワークしていると、あまり粗末な椅子でデスクワークしたくないというネガティブなモチベーションになってしまう。

メインオフィスと同じとはいかなくても準ずる程度のオフィス環境を実家に構築できれば実家に帰って1-2週間程度のフルリモートワークをしてもよいと考えている。その延長上で実家との行き来を出張扱いにして経費を使えるようにし、経営的にはそうすることで節税にもつながる。私個人の視点からも、親の介護という、私の人生設計上避けられない問題に対する解決策となる。個人の人生の問題と会社の経営を両立させることは、自分の会社であれば、十分に両立できると自信をもって言える。この話しも田舎から上京してその後のキャリアを考える上でのモデルケースの1つとして、いつかブログの記事として書きたい。

cookie の secure 属性と localhost

#security  #browser 

0時に寝て6時半に起きて7時半に起きて9時過ぎに起きた。普通は明け方に2度寝して起きるのになぜか3度寝して寝坊した。慌てて準備してオフィス行って業務開始が9時半をまわってしまった。年に1回ぐらい意味なく寝坊することもある。こういうことがあるから他人がなにか意図しない失敗しても寛容になれる。

以前たまたま Meety脆弱性 2022-11 をみたときに認証 cookie に secure 属性が使われていないという指摘をみかけた。http でログインするときに cookie にセッション情報を保存してしまうと、平文でセッション情報が流れてしまうのでセキュリティ的によくない。具体的な攻撃方法としては wifi の通信をパケットキャプチャするとか、ルーター (カフェの無料 wifi とか) で中間者攻撃 (man in the middle) などのセキュリティ上の懸念がある。その対策としては cookie の secure 属性を付けておくと、http のときはセッション情報をブラウザに保存しなくなるのでログインできなくなる代わりにそういった攻撃から守れるようになる。フロントエンドのセキュリティのお作法みたいなものにみえたので覚えていた。

ちょうど管理画面のログイン機能をメンバーに実装してもらったところなのでその対応をしているかどうかをメンバーに確認していた。メンバーもその認識はもっていて環境変数の設定で切り替えられるように実装していた。テスト環境にデプロイするときにその設定を有効にしてもらって、私が意図した振る舞いをしているかどうか、テスト環境にアクセスして検証していた。しかし、secure 属性が付いていることは確認したものの、http でもセッション情報がブラウザに保存されていて、あれー？って感じで検証していた。メンバーは保存されないという。

localhost は例外

ブラウザによっては localhost だと httpsの要件が無視されるとのことでした。

CookieのSameSite属性とSecure属性について

この記事によると localhost だと適用外になるブラウザがあるんだと気付いた。たまたま私が ssh の port-forwarding 経由でテスト環境にアクセスしていたので localhost 経由のアクセスになっていた。これは開発時は http でも動くようにすることで環境変数で切り替えるといった、それ自体がセキュリティインシデントになり得る設定をもたないようにするための、ブラウザベンダーの配慮だろう。chrome はそういう振る舞いをしていることを私は確認できた。

納骨

#life  #drive  #day off 

昨日から実家に帰ってた。0時に寝て5時に起きた。珍しく親が寝坊して5時半頃まで起きてこなかったものの、私の方が早めに起きてスマホをみながらだらだらしてた。朝から法要の準備をしたりしていた。

49日 (納骨)

この前は 35日 だった。

9時40分頃には参加者が全員集まっていた。今日の参加者は15人。10時からの予定だったものの、住職も10分前には到着されて全員揃っていたので予定時刻より少し早く始めた。いつも通りのお経を住職にあげていただく。30分ほど。その後に住職からの法話がある。今日は49日なのでその由来について話された。仏教では亡くなって49日目に亡くなった方が仏の元へ向かうとされている。なぜ49日なの？という由来にいくつか諸説があるといったお話をされた。

  • お釈迦様が瞑想して悟りを開いたのにかかった日数が49日だったとか
    • お釈迦様がそれを数えていたわけではなく、弟子が数えていたのでそれが正しいのか後世の創作なのかはわからない
  • 昔のインドは7進法が採用されていて7 * 7 = 49日が重要な意味をもったとか
    • 古くから1週間は7日とされている
    • 仏教に限らずキリスト教においても神は6日で世界を創造して7日目に休んだというので7という数字が意味をもつのだろう
  • 土葬の時代、土に埋めるものの、そのままだと土地を有効活用できないため、埋めて白骨化するのを待って掘り返すのが49日だったとか

その後、お墓へ移動して納骨になる。お墓の前で骨壺から納骨袋に骨を入れ替えてお墓の中に入れる。お墓がどんな構造をしているか、私が知らなかったので骨を入れるスペースとその開け方を学んだ。住職もお墓まで来てくれて納骨の作業をしている間はお経を唱えていただいた。感謝。

お墓から戻ってきて11時。随分と順調に予定を消化し過ぎて食事どころを12時で予約していたので少し待つことに。11時半から近所の食事どころへ移動して参加者でご飯を食べる。12時前から食事が始まって14時前にはお開きとなった。過去に父とも1-2度来たことがあるお店なので私にとってもやや懐かしかった。量は十分にあったし味もよかったと思う。 料理が出てくる合間がもう少し早くてもよかったと思うぐらいの改善点。料理を配膳するスタッフが2人しかいなかったので人手不足で大変なんだろうと推測できた。

祖父の法要をしていたときはこの倍は参加者がいたように思う。コロナ禍で葬儀が家族葬となり、親戚も近くの濃い人たちだけで行うようになった。参加者数が減ることで調整コストが下がって昔に比べたら簡素化できて楽にはなっている。

帰路

姪が神戸にある大学に通っているので帰りは車で一緒に帰ってきた。祖父の法要をしていた頃、大阪の親戚が車で淡路島に来られていて、私もよくその親戚の車に同乗して一緒に大阪まで帰っていた。その親戚も少し前に亡くなってしまったが、同じようなことを代替わりしてやっていることに気付いた。車なら早く帰れるはずが、運が悪くて月見山 - 湊川間で10分もあれば抜けられるところを1時間の渋滞につかまった。5台の玉突き事故があり1車線規制で渋滞していた。真ん中の2台の車がもっとも潰れていた。事故じゃなくても湊川付近は神戸の中心地なのでやや混雑しがちな印象がある。私が通ったときはまだ事故車があって警察が聴取をしていたので発生直後に近かったのかもしれない。ちょうど 湊川 ICの真横だったので降りるときの事故だったのかもしれない。

もしかしたら事前に渋滞情報を聞いていたら迂回路を選択できたかもしれない。高速バスは阪神高速の3号神戸線が渋滞していると北側の迂回路を使うことがある。だから迂回路の存在は知っていた。帰ってきてから迂回ルートを調べてみた。垂水JCTから神戸に入るには次の2通りの経路がある。

  • 垂水JCT - 名谷JCT - 月見山 - 若宮 - 湊川 - 柳原 - 京橋 - 生田川
  • 垂水JCT - 布施畑(ふせはた)JCT - 白川JCT - 箕谷(みのたに)JCT - (新神戸トンネル) - 布引(ぬのびき)JCT - 新神戸駅

垂水JCTの前で渋滞情報を取得できれば、北側の布施畑JCT経由のルートを選べばよい。今度ナビも操作しながら通ってみる。

合間の休養

#life  #issue management 

23時に寝て何度か起きて8時に起きた。疲れていたせいか、いつもよりよく眠れた。18時過ぎぐらいまで調べ物をしていて、それから実家へ車で帰った。初めて夜の高速道路を走ってみたらわりと道がわからなくて怖かった。昼間よりは速度を出せないので夜に帰るならゆっくり帰るのが安全にはよさそう。20時頃には実家について晩ご飯を食べ始めてた。

ストレッチ

今日の開脚幅は開始前156cmで、ストレッチ後160cmだった。出張帰りだったのもあって腰に張りはあってやや疲労が溜まっている感はあったものの、前月に比べたら全然ましだった。やはり前月が葬儀の後に事務手続きと出張が重なって特別に疲労していたことがわかった。トレーナーさんといつも通りの話をしていた。最近はサッカーの三笘選手が大活躍しているので毎週その話題が定番になっている。

こってり天津飯

天津飯は日本発祥！カニ玉との違いとは によると、天津飯は日本の中華料理屋さんが考えた料理らしい。麻婆春雨と同じ類の料理。

少し前に天下一品の新メニューでこってり天津飯ができた。天津飯は日本の中華料理屋さんならどこでも食べられる料理だが、こってり天津飯は「こってりスープ」がある天下一品でしか食べられない。天津飯というコモディティを、こってりスープという天下一品独自のプロダクトで再発見または再発明したような商品とみなせる。

課題管理という分野もそれ自体はどこにでもある概念やスキル体系でしかないが、うちの会社独自のプロダクトを作ったり、プラクティスを構築できれば、再発明できるんじゃないかとたまたま食べていて思った。いつか課題管理ビジネスが軌道にのってインタビューされるようなことがあったらこってり天津飯を食べていて気付きましたみたいな、カッコいい談話にしたい。

windows の調査を開始

#windows  #go  #issue management  #book 

1時に寝て7時過ぎに起きた。やや飲み過ぎて、2日酔いではないけど起きたときは気分が悪かった。

go-winio を触ってみた

windows 向けのモジュールを作り直すにあたり、有識者のサポートをお願いしているものの、私も最低限の知識はないとあかんやろと調査を開始した。microsoft/go-winio というライブラリが ms 社のリポジトリで公開されている。公式ならよいのだろうと安易に考えて触ってみたものの、ドキュメントがほとんどなくて、まず使い方がわからん。いまのところ、windows に詳しい人向けのライブラリみたい。ひとまずリポジトリにある pipe_test.go のテストコードを読みながら名前付きパイプを介したプロセス間通信をやってみた。一応は動いたのでここから内部の windows api の仕様や設定などをみていく。その過程で go-winio のチュートリアルがないのであれば、私がテックブログを書いてもよいのかもしれない。

チュートリアル的に書いてみたコードは次の通り。

課題管理勉強会

出張のときに毎月の課題管理勉強会。とくにネタが思いつかなかったので エンジニアリング組織論への招待 を題材にしてみた。資料はすでに作ってあった 。私にとっては課題管理をやる意義や価値の大半がこの書籍の中で解説されている。用語や考え方のところでとても参考になるし、いまメンタリングの技術の章を読み直したりもしている。昔はマネージャーやってなかったからその章は読み飛ばしてた。開発組織向けの組織論を解説した書籍でこれ以上のものは、いまのところ、私が読んだ本の中では知らない。4年前に読んだ本を、今回の勉強会を開く機会でまた読み直すきっかけにもなってよかった。本はコンテキストがきれいに構成されているので他の人の所感や意見を聞いたり雑談したりする題材としてもよさそうに思える。

リリースの前倒し

#project management  #team building  #communication 

23時に寝て何度か起きて5時半に起きた。

プロジェクトの進捗報告

出張したときの月例報告の3回目。前回の進捗報告はこちら 。1月はバックエンド開発を完了させてフロントエンド開発に着手した。当初は6ヶ月の開発期間を設けていたものの、1ヶ月前倒しの5ヶ月でフェーズ1の開発を完了させる見通しを報告した。管理画面も機能的にはすでに一通り実装できている。これから2月は使いやすさの ui を改善していくところや品質をあげるためのリファクタリングを行い、3月は運用レベルのテストをしてバグ修正を行う。ソースコードの品質も私がチェックしているので、どういう修正が必要かも予測できていて、十分に余裕のあるスケジュールだと私は考えている。油断も慢心もなく、いまできるだけの知識とスキルをつぎ込んで品質の高いプロダクトに仕上げるのに努める。

先月に宣言した通り、フェーズ1の開発はもう私の中では終わっていて次のフェーズ2への準備や計画をこれから考えていく。業務的に区切りがよいのでフェーズ1で契約終了する可能性もあったけれど、4月以降も開発のマネジメントをしてほしいとのこと。フェーズ1の開発と並行して、余裕をみてフェーズ2以降の計画も立てていく。フェーズ2以降に予定している、少なくともあと2つの機能開発に私は責任をもとうと契約の有無に関係なくもともと考えていた。それらを実装すれば大半のお客さんのニーズにあうプロダクトになるはずなのでそれ以降の開発は引き継いでいいかなと思う。言うても野心的に言えば3ヶ月強といったところか。チームも成長しているので3ヶ月前よりは開発速度が上がっている。

さらにいま私が担当しているプロジェクトとは別に、他にもやってほしいお仕事があるらしい。もしかしたらそれも含めて来季の半期以上のお手伝いになるのかもしれない。しばらく次のお仕事探しはしなくてよい状況にある。3月のリリースを終えたら会社の事例紹介を書きたい。今回は会社として初めてのプロジェクトマネジメントの実績になる。周りにも喧伝していきたい。

出張晩ご飯

たまたま1月末に課題管理についてチャットで議論していたら盛り上がったのでこみやさんと晩ご飯に行ってきた。ざっくばらんに近況やチームのマネジメントについて話してきて楽しかった。19時半過ぎから始めて23時過ぎまで飲んでた。帰路の途中で新宿駅構内で人身事故が発生して、電車が止まってしまい、復旧に1時間ぐらいかかるというのでタクシーで帰った。タクシー料金も region pay で「ただいま東京プラス」のクーポンが使えたので金銭的に損はしなかった。

こみやさんのチームの話しからは、対話重視のスクラムのイベントが si におけるメンバーの教育にもうまくいっているように聞こえた。メンバー間で質問し合うのを促していて、質問者と回答者の双方の理解度をあげることを狙いとしている。質問が現状をふりかえるよいきっかけになっているとのこと。

あとメンバーに自律的に勉強会をしてもらうにはどうしたらいいかという話題も盛り上がった。私もいま毎週勉強会をやっていて、これはよい開発文化を作る上で大事だと思っているものの、いずれメンバーが自律的にやるようになってほしい。いまは私がお手本をみせるという意図もあって勉強会の運営をやっているのだけど、それをどうやってメンバーもできるように巻き込んでいくかを考えている。こみやさんや私が勉強会をやると、一定の水準で運営してしまうから、それがメンバーにとって逆に気後れさせてしまわないかという視点も話したりしていた。勉強会は準備に工数がかかると発表者が大変になって続かなくなるので、毎週やろうと思ったら準備に工数をかけないという仕掛けは重要になる。もしくは情報共有やコミュニケーションの場としての勉強会を考えるならもっと身近な内容を話す場になってもよいのでは？という考え方もある。例えば、最近の時事ネタで関心をもったニュースや技術などを取り上げて雑談するのでもかまわない。

いずれにしても、うちらがやれと指示してしまうと、業務命令として業務だからやっているだけになってしまい、よい開発文化を作るという、結果的に業務に大きな価値をもたらすなにかとは違うものになってしまうのがこの問題の難しいところ。開発をよりよくしたい。技術を深めたい。品質をあげたい。なにかしら開発そのものに対して関心をもって自律的にそういう活動をする開発者を増やしていく。言葉にすればたったこれだけのこと。しかし、このことを教えるのは相当に難しい。まだ私がマネージャーとして働く時間はあるのでこれからも挑戦していきたい。

車で行きたい場所

#windows  #life 

23時に寝て5時に起きて7時半に起きた。軽く二度寝しようと思ったらちょっと寝坊した。

windows アプリケーション開発に関わる

ある windows モジュールの開発をやり直しことにしたのでその仕切り直しのキックオフに参加する。もう10年以上前の sier にいた頃は windows サーバーで oracle を動かしたり、vb6 のアプリケーション開発をやっていたりしたけれど、その後は windows アプリケーションの開発に関わったことはないのでまったく windows サーバーの知見はない。別チームから有識者に入ってもらって既存のモジュールを開発し直すことになった。私が実装するわけではないけれど、せっかくなので最近の windows の振る舞いを調べて仕組みを再確認する機会としたい。

ニッポンの絶景

たまたま帰ったときにテレビでやっていた 林修のニッポンドリル 学者が選ぶ！春に見るべきニッポンの絶景ベスト24 をみた。 コロナ禍がひと段落したらインバウンドも戻るのかなという話題にあう、日本で観光するとよいところを紹介していた。出てくる風景がすごいのもあって、死後の世界だとか、桃源郷だとか、たしかにこんな場所あるんやなと思えておもしろかった。

この中に 兵庫県朝来市の竹田城跡 が出てくる。本題じゃないけど、このサイトの構成がややおかしいと思う。スマホファーストなのは分かるけど、ちゃんとした業者に作ってもらえばよいのにと思ってしまった。閑話休題。竹田城跡は天空の城とも呼ばれる、知る人ぞ知る名勝であることは間違いなくて、私も1度は行ってみたいと考えている。ちょうど車も入手したところなので今年こそは行ってみたいと思う。それでよかったら会社の開発合宿やコミュニティのイベントなどにも応用していきたいと思う。都会にはない、地元のよいところや観光資源を活かして地域に貢献できるようにしたいという想いは歳を経るごとに感謝の気持ちとセットで実感できるようになってきた気がする。

1週間を管理しようとしない

#issue management  #communication  #team building  #postmortem 

1時に寝て5時に起きた。ホテルのテレビを付けっぱなしで寝たら朝のニュースで起きた。なんとなくニュースをみながら7時ぐらいまでのんびりしてた。

1週間のイテレーションはナンセンス？

毎月行っているマイルストーンのふりかえり。今回で3回目なのでメンバーもだいぶ慣れてきた。11, 12, 1月と3ヶ月に渡って課題管理をメンバーに実践してもらいながら開発してきた。当初、開発のイテレーションを1週間で行うか、2週間で行うかの話し合いで短い方がいいんじゃないかとなり、あまり深く考えずに1週間のイテレーションで開発をまわしてきた。しかし、いまとなってはこれは開発のイテレーションとは違うものになっている。

最初の1ヶ月はメンバーにとって慣れないワークフローだから、1週間のイテレーションでこの issue をやる・やらないといった厳密な取り決めはしなかった。その後、徐々に慣れてきたのを見越して、定例会議のときに issue 一覧をみながら、メンバーに2-3個ぐらいの issue をアサインしたり、issue の優先順位付けを明確にしたりしてきた。必ず issue を完了させるという強い制約を課していないものの、だいたい毎週アサインしたものをメンバーは対応してくれていたので、マネージャーとしての私の視点からもとくに問題はないようにみえた。要はうまくまわっているのでそれ以上の管理をしなくてもいい状態だったと言える。

一方で、本来の課題管理のイテレーションとは異なる開発のワークフローになっていて、それがよいことなのかどうか、私自身にも明確な答えがなかった。それでメンバーに尋ねてみた。いまの1週間単位のイテレーション (開発のワークフロー) をどう思いますか？

メンバーからは、1週間の作業内容を厳密に決めなくてもいいんじゃないかという意見が出た。それは私の考えとも一致していたものの、開発のイテレーションを2週間に伸ばすことについて話しているときに、そうしたとしても、定例会議は毎週やりたいという意見が出た。要件確認や仕様共有のために重要だという。通常、イテレーションの成果共有のために定例会議とイテレーションの長さは一致している。仮にイテレーションを2週間にしたら定例会議は2週間に1回となる。しかし、メンバーの視点からはイテレーションを1週間にするか2週間にするかについて関心はないものの、毎週の定例会議で行っている情報共有は重要だという認識があった。

ここで開発のイテレーションと定例会議の頻度は別にあわせなくてもいいんじゃないかと考えるきっかけを私は得られた。スクラムもスプリントと会議体の頻度はセットになっているのでこの発想はなかった。ちなみにアリエル時代は1つのイテレーションが3ヶ月で定例会議もなかった。そして、うちのチームは1ヶ月のマイルストーンに対してふりかえりをセットにしている。これはもはやイテレーション開発の文脈でいえば、実質うちのチームはマイルストーンと呼んでいる1ヶ月が1つのイテレーションになっていて、1つのイテレーション内に4回の定例会議があるというイテレーション開発のワークフローになっていることに気付いた。課題管理の考え方やワークフローがもっと洗練されていくと、毎週の定例会議をやらなくてもよいようになっていくのが私の経験から自明である。しかし、うちの開発は私も含めて8割以上がフルリモートワークなので、メンバー全員の顔を合わせる機会を作るという観点から毎週の定例会議は大事な場にもなっている。

実際の開発のマネジメントをしてみると、私自身、分かっていなかったことや新たな発見があって、まだまだ自分自身も修行の身であることを実感する。ここでの結論としてわかったことは次の通りで、ロードマップにおける最初のフェーズが完了する3月末までは現状のワークフローを継続してみることに決めた。

  • 開発のイテレーションとして1週間は短過ぎて管理対象としてあわない
  • 開発のイテレーションと定例会議の頻度をあわせなくてもよい
  • フルリモートワークの場合、メンバー全員を集める目的は情報共有だけではない