Posts for: #Project Management

次開発の要件決めは既定路線

1時に寝て何度か起きて7時に起きた。エアコンを入れていると夜は寒くなってきた。

feedly pro+ にアップグレード

前からやろうやろうと思っていながら忘れて放置していた feedly のサービスに課金した。基本的に sns をやめていく方針でいるため、情報収集のソースを rss リーダーに戻そうと考えている。これまでも sns と並行で feedly を使ってはいたんだけど、もうちょっと feedly の機能も使ってインプットの効率を上げられないかと考え始めた。Pricing をみると、pro, pro+, enterprise の3つのプランがある。真ん中のプランが推しのようだったのであまり調べもせず Pro+ プランを選択した。いまのところ、検索の機能を使うぐらいでしかないが、そのうち ai 機能的なものも触ってみようと思う。

次開発の優先順位付けと担当者の割り当て

先週の要件発散会議 の続き。発散させた要件を整理して優先順位を決めて、担当者まで割り当ててしまった。課題管理がうまくできている必然なのか、なにも迷わずに自然にこのモジュールは○○さんでといった棲み分けもできて、それぞれが役割を果たせば開発の要件が満たせる体制になっている。全体像としての要件一覧は概ね用意した通りではあったものの、要件や設計の詳細の話しをしていると、私の要件の誤解もいくつかあって、それらは訂正しながら設計していくことにはなる。それでもメンバーも成長してきて、私がお膳立てしなくても、メンバーが自ら考えてうまくいくように設計してくれそうな雰囲気もみえてきたりしていて、それによって、私は面倒で厄介なインフラの再整備に注力できたりもしている。前開発がうまくいったので、なんとなく次開発もうまくいきそうな、始まる前から気を抜き過ぎにも思えるが、もう始まる前から開発が終わっている (うまくいくことが分かっている) ような感覚をもっている。できることは分かっていて、あとはどれだけの量を次開発で実装できるかといった、私が区切りの線をどこに引くかだけ決めればいいんじゃないかと考えている。よいチームになってきたなとちょっと誇らしい。

プロジェクト管理のドキュメントや資料の更新

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

開発方法論/開発ガイドの更新

前回の改訂 から約4ヶ月ぶりに開発方法論と開発ガイドを改訂した。

  • 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
  • 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

近いうち、チームに新規メンバーが入る。今回の開発を経て新たにわかったことや変わったところなどを更新するつもりで全体を読み直してみたが、大きく変わったところはなく小さいアップデートに留まった。開発方法論に 情報共有とコミュニケーションのレベル というタイトルで5段階のレベルについての考え方を追記した。この内容は私もまだ完全に言語化できているわけではない。「聞かなくてもわかる」という価値観の存在をまったく疑っていないが、その背景にあるコミュニケーションの在り方や人間関係や組織での運用についてまだ曖昧なところが多い。それも含めて考えるよい機会だと思ってうちのチームに向けた内容に整理し直してまとめてみた。もう2-3回ぐらいこのテーマで話しをしたりすると、より言語化できてもっとよいものができそうな気配は感じている。

fun/done/learn のカスタマイズ

昨年からふりかえりの手法として fun/done/learn という手法を採用している。2週間のイテレーションが終わったときに毎回このフレームワークを使って、やったことをメンバーに共有するといった用途のために使っている。大きな開発のふりかえりを行ったときにマイルストーンごとの fun/done/learn の個数の変化などもふりかえってはいるが、そこの統計値がなにかに役に立つようには、いまのところ、うちのチームでは思えない。

今回のふりかえりをしているときにメンバーから done はいらないのではないか?という意見が出た。この手法の発明者のオリジナルの記事 ファン・ダン・ラーン(FDL)ふりかえりボード と読むと、done = deliver だし、done しなかったことも含めてのふりかえりを実践していたことが伺える。うちらはやったことをふりかえるためのフレームワークとして活用しているため、done がデフォルトでプラス fun/learn が付くといった運用になっていた。その通りだなと納得して done に置き換わる、うちらの開発の運用にあうカテゴリを考えてみて give を採用した。ゴロがよいように fun/give/learn と呼ぶ。

give とは、このマイルストーンでやったことを形式知として、他のメンバーに共有可能な状態にしたという意図を表す。wiki を書いたりするのもよいし、テックブログを書くのもよい。暗黙知を形式知に変えるには少し手間暇がかかるのでちょうどよいカテゴリに思える。3つのカテゴリに属するときにもっとも価値が高いような運用にも向いている。そのためのボードも作って、これを jamboard の背景に設定してふりかえりをしている。何ヶ月か運用してみて、うまくいきそうだったら fun/done/learn の亜種としてどうだろう?といった提案のテックブログを書いてみたい。

次開発と要諦調和

0時に寝て何度か起きて7時に起きた。飲み歩いてお腹いっぱいでお酒もい飲んで寝たから連日でよく眠れなくて初めて泊まったホテルの部屋の印象が悪くなってしまった。ホテルに非があるとは思っていない。

3次開発の要件打ち合わせ

前回の開発課題の打ち合わせはここ 。2時間をとって要件を発散させる。

次は3次開発になるため、2次開発でできなかったこと + アルファな要件を発散させる。概ね予定調和にもなってしまって、私の中でモチベーションコントロールが難しい。私が準備していった展望や構想がブレていないことはよいことでもあるのだけど、会議がつまらないというか、私が緊張感を失ってしまう。私は自分の構想を一番理解しているのでそれをもっと明文化して関係者やメンバーに伝える必要がある。そこに私にはなかった刺激がいくつか入るとよいと考えている。1人の人間の考えることなんか、せいぜいうまくいって8割だと思う。残りの2割は誤っていたり、意味をなさなかったりするのではないか。だからこそ、他者の反論や別の視点の意見には注意している。

今回は用途の違う管理画面をどう設計するかが最も難しい意思決定の話題だった。いまも管理画面はあるが、一般ユーザーが使う情報更新のための管理画面を既存の管理画面に付加するか、独立した管理画面として新規に作るか。話し合った結果、後者のやり方で進めようと私は考えている。もともとの私の意見もそちら側であるし、次の開発体制やマイクロサービスに近いいまのアーキテクチャの構成を総合的にみてそれがよいと考えている。もうちょと突っ走ってやってみてメンバーから反発が起きないかを伺ってみることにする。

稀な出張飲み歩き

0時に寝てあまり眠れなくて7時に起きた、いつもと違うホテルのせいか、あまりうまく寝付けなかった。部屋も広くてよかったのになぜか落ち着けなかった。

プロジェクトの進捗報告

出張したときの月例報告の10回目。前回の進捗報告はこちら

概ね 事前に準備してあった資料 のまま次の3次開発へ進むことに決定した。いくつか経営者に確認することも用意していた。「よしなにはからえ」な方向で取り組めそうだ。1年近く開発を継続してきて、次の3次開発を終えれば品質面でも私からみて自信をもてるようにはなると思う。

そろそろ私の契約を終えてもいいんじゃないかと考えていたが、もう少し追加の開発に付き合ってほしいとのこと。それを受けて「もうちょっとだけ続くんじゃ」と自身のモチベーションコントロールをしていく。早ければ今月いっぱいで契約終了する可能性もあった。継続しても、あと3-4ヶ月程度で終えて、その後に私も3ヶ月ほど休もうとか考えていた。まだまだプロダクトの機能や品質に満足していない、私が長期休暇を取れる状態ではないぞという激励でもあったのかなと思う。

セルフ居酒屋

晩ご飯に 大崎一番家 さんへ行ってみた。

店主が1人でやっていて、お客さんはセルフで飲みものを手配する。冷蔵庫からお酒 (ハイビール、酎ハイ、瓶ビール) を取ってきて、氷も冷凍庫から勝手に容器に入れてもってくればいいと言う。あとで卓上に置かれた缶や瓶を数えて精算する。ボトルを入れているお客さんなんかはやってきて勝手に飲み始めたりもすると店主が話していた。食べものだけオーダーシートに書いて厨房にいる店主に声をかけて提出する。厨房の入口に置いていたら、都合のよいタイミングで受けとって料理を作ってもってきてくれる。こういうスタイルのお店を嫌う人もいるだろうけど、私は自分のできることが多いスタイルのお店は気楽で気に入ってしまった。店主も関西の人らしくて陽気な性格だった。料理が大皿なので1人だと2-3皿食べるとお腹いっぱいになってしまう。野菜サラダなんかは私は大皿でもりもり食べたいのでちょうどよかった。口コミでデミグラスカツがよいとあったので注文してみておいしかった。但し、1人で食べるには多過ぎで2-3人向けの分量だが。

こういう1人で全部やるという働き方そのものを私は好む。誰かと一緒に働くの、他の人間と一緒に働くのはどう繕っても気を遣う。居酒屋のような、本来は1人でできないことをお客さんの力も借りながら1人で成り立たせる工夫をあっぱれだと言いたい。以前 マイクロ法人のススメ に書いたが、1人で意思決定して楽しく働く、1人の会社が他の会社と協調して大きなお仕事や難しい課題を解決するという、新しい働き方に私も挑戦していきたい。

飲み歩き

大学の友だちに声をかけてみたら、そのとき浅草で働いていて、その後、ちょうどよい場所として新橋へ移動した。20時過ぎから新橋の居酒屋さんで飲んでいた。2-3年ぶりぐらいに会ったかな。社員が20人の頃に入社した会社がいまや社員が400人になっていて上場も視野に入れてお仕事しているとのこと。当然、その友だちも幹部社員になっていてすごいなぁと近況を聞いていた。マンションを3つ買ったとか話していた。

プロジェクトマネジメントやメンバーの育成など、私も最近はマネージャーをやっているからあーだこーだと話しをしていた。その友だちはもともとマネージャー職を目指していたので私よりもマネージャーとしての経験や知見が多い。その友だちも私に負けず劣らずのハードワーカーなので考え方は私と近いと思う。若い人に適正がなさそうでもどう教えるか、どこで見切るかといった話しが一番盛り上がった。その友だちは3年ぐらい面倒はみるが、それでダメなら適正がないと本人に告げて他の仕事に移ってもらうようにするという。適正がないと本人に告げることも優しさだという。たしかに大企業だと、まったくできない人が開発者として中堅社員になってたりすることもあり、それがプロジェクトの弊害になることを私は経験したことがある。あとお互いに年寄りでスキルもやる気もないのは無条件でダメみたいなところは一致した。以前、参加した オープンセミナーの懇親会 でも、成長しない社員に対してどう接するかの話しをしたことがある。そこでもこのままそのレベルで仕事を継続してもよいが、待遇はそれ以上あがらないことを伝えるとある管理職の方は話していた。

成長の度合いも個人差があり、どの程度をよしとして、どこで線を引くかは難しい。私はプログラミングが好きなら多少のスキルの個人差はあってもよいと考えている。しかし、会社になると組織に貢献しているかというのは大きな基準になるので必ずしも私の考え方は正しくはない。人間が人間を評価するのは本当に難しい。このまま小さい組織で評価とは無縁で働きたい。

昼に寝て夜に考える

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

ストレッチ

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

工事業者の訪問

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

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

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

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

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

ストーリーポイント再考

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

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

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

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

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

資料作りの一日

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つの案でいくのもよいかもしれない。機能要件は実際にお客さん先へ導入するときにもいくつか出てくるだろうけれど、非機能要件の運用に影響を与える懸念のところはなるべく早く改善しておきたい。次の開発期間にそこだけ対応すれば、一定の安心をもってお客さんへ提供できるようになると思う。

家に帰るまでが旅行

実家へ帰って疲れていたせいか、21時過ぎから寝てしまって2-3時間ごとに起きて5時半に起きた。親はもっと早くから起きているからその時間から朝ご飯が出てくる。

ドキュメント書き

持ち帰ったばかりの机とバランスチェア を使って初めてのリモートワーク。とくに問題なく作業できたのでよさそうに思う。今日は早くお仕事を切り上げるために7時からお仕事を始めた。issue の対応を見守りながらドキュメントをまとめて書いていた。新規追加した機能やまったく違う仕組みに置き換えたものがあるため、ドキュメントの変更量が多い。

お昼にメンバーからも qa テストの完了報告が届いて、私も自分がもっている issue ではバグ修正もすべて終えていて、あとはドキュメントと最後の GA 向けのパッケージングぐらい。いつもそう思うけれど、終わってみれば順調に予定通り開発のイテレーションを完了できた。今回は機能開発に約3ヶ月、QA に1ヶ月の約4ヶ月のイテレーションとなった。開発の状況をみながらマイルストーン (2週間) を増やしたりもした。その程度の調整もした上で予定通りと言える。3ヶ月のイテレーションに対して、私がマネジメントをしていれば前後2週間程度のズレしか出ない。こんなの当たり前だと思うが、以前お手伝いしたスクラム開発でのストーリポイントでは2ヶ月の見積もりに対して4ヶ月を要した。見積もりがめちゃくちゃだったと言える。

帰路に着く

てらださんが鳴門から淡路島南 IC に15時30分に着くという予定を教えてもらっていた。そのため、15時にお仕事を切り上げて、迎えに行って、それから神戸に一緒に帰ってきた。

たこせんべいの種類

帰路の途中で たこせんべいの里 へ立ち寄った。津名一宮 IC のすぐ近くにある。おそらく私は行ったことなかったと思う。長居するような観光施設ではないが、立ち寄ってみたらそれなりにおもしろかった。てらださんの奥さんがたこせんべい好きらしくて、いろいろ教えてくれた。50種類ぐらいある。たこせんべいっていろいろ入っていることは知っていたけど、こんなに多くの種類があるとは知らなかった。たこせんべいの個別試食ができて、コーヒーも飲めて、工場見学して、お土産にせんべい買って帰った。16時半には出発した。

新神戸駅

快調に高速道路を走って、3号神戸線を迂回して7号北神戸線から神戸へ戻る。道中で若宮-芦屋間で渋滞18kmとか出ていた。いつものこと。てらださんに 3号神戸線のうんちく をたくさん語って満足。この日のためのネタだ。17時には新神戸駅に到着して送り届けられた。無事に旅程をこなせてよかったと私がほっとした。

小旅行の所感

てらださんがオープンセミナー参加のために香川県へ来られるという話しを聞いて、車も買ったばかりだし地元だから案内しようと考えた。その延長で LT 発表しようと思いつき、ある記事を翻訳したらちょっとバズって世の中の役に立ったのかもしれない。

私はなにも用事がなければ出掛けないことが多い。いまは基本的にずっと会社のお仕事をしているし、そんな毎日でも不満もない。だからこそ、なおさらこういった縁の機会が大事だとわかるようになってきた。てらださんが来られなければ、この3泊4日の小旅行はあり得なかった。そして 車中泊の経験 も得られなかった。新しいことを学ぶ機会そのものが尊い。旅程を通して関わってくれた周りの人たちに感謝したい。

これは昔はらさんからも助言をいただいたことを覚えている。私が交際費を年間で2-3万円しか使っていなかったときのこと。

放っておいて会社にお仕事が舞い込んだりしない。
いまのお仕事がずっと続くことはあり得ない。
将来のために新しい縁を自分から探しに行かない限り、会社を継続できない。

開発フェーズの完了まであと2週間

0時に寝て何度か起きて7時に起きた。オーバートレーニング気味で夜帰ってきてゆっくり過ごしている。

定例会議

次のマイルストーンでこの開発フェーズを完了させる。その最後の打ち合わせとなる定例会議。話題が多過ぎて、始める前から今日の会議は1時間におさまらないんじゃないかと話しながら始めて10分ほどオーバーして終えた。会議時間が私の感覚とも一致していてよかった (違う) 。

qa テストでいろいろ issue が洗い出されていて、その中のアーキテクチャや仕様の抜本的な見直しを検討するのが2つ、管理画面の ui/ux に関する設計の2つ、よいことではあるが、私の設計の目が及ぶ範囲を超えて issue が上がるようになりつつある。本当はフロントエンド向けに ui/ux デザイナーがいれば画面設計について委譲したいところだが、そんな人はいないのでチームで話し合い、私が方針を決めて暫定的に修正していく。

また致命的な issue は出ていないという私の認識から、次の2週間でこの開発は収束させるという合意を行った。やや qa テストや issue の収束は遅れ気味ではある。いまから慌てても大きく変わることはないし、このチームは十分に私の課題管理の慣習にしたがって作業しているので、このまま成り行きでもうまく着地できるんじゃないかなと楽観的には考えている。その感覚は過去の経験からも来ているのだろうけど、もうこの歳になると脳ができることを自動的に判断している気がする。できるとわかっているから不安や焦燥感といった危機を感じられない。悪い言い方をするとさぼっているだけという見方もあるが、そういう感覚をここ2-3年で実感するようになってきた。

会議が終わってから私は reflection 関連のバグを2つ直した。

クレームへの階段

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

隔週の雑談

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

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

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

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

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

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

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

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

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

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

開発の瞬発力が足りない

最終の新幹線で帰ってきて、2時に寝て2回ぐらい起きて8時前に起きた。寝坊した。7時頃に起きてない時点で疲れているんやろなと思えた。

msgraph-sdk-go を使った開発

昨日の続き 。ライセンスやグループのメンバーを扱うときの特殊な処理を実装してからマージリクエストを送った。本当は火曜日の時点でできたらよかったことが2日遅れになった。モチベーションがあれば、日曜日や月曜日の夜にできたことかもしれない。加齢のせいかもしれないし、私の中でまだ開発になにかが足りない。誰かから責められるわけではないが、自分で自分に嘘をつかないために自分なら間に合わせられたものが2日遅れになっているという事実にだけは気付いている。id 連携のビジネスロジックに相当するところの置き換えに4日かかったというのはノウハウがなかったらそんなもんという気もせんでもない。一通り実装できたのであとは qa テストで複雑なテストケースのバグ出しをすればよいだろう。

イレギュラーな出張

本当は昨日の夜にもう少し開発しようと思っていたが、体力的に衰えているせいか、晩ご飯食べに帰ってそのまま家でだらだらしていた。翌1-3時前までオフィス戻って作業して、それから出張の準備をして、5時過ぎからいつも通り始発の新幹線に向かった。

定例会議

私のリファクタリング issue が1つだけ未達で残ってしまった。他の新機能開発はほぼ予定通り完了できた。メンバーががんばってお仕事してくれたことに感謝。無理なスケジュールを強いていないというのもあるが、ちゃんと見積もりと工数を管理できていることそのものはよいことだと思う。概ね予定通りであることを確認して、あと2つのマイルストーン (1ヶ月) を使って qa テストにあてる。これも web 開発からしたら驚くほどの工数を使っているようにみえると思う。しかし、品質の悪い web 開発を私はたくさんみてきたので結果的に qa をちゃんとやる方が工数削減になると私は考えている。

いま作っているプロダクトのライセンスが実は Apache License v2 になる。oss な会社だから基本的にプロダクトは oss なライセンスで提供しているらしい。とはいえ、リポジトリを一般公開しているというわけでもないため、広く oss として使ってもらいたいというほどのモチベーションでもない。お客さんが要求すればソースコードも提供するといったスタンスらしい。実際にお客さんがソースコードを要求してくることは皆無らしいが。

もうやんカレー

過去に虎ノ門で働いた頃、もうやんカレー好きな同僚がいて懐かしくて 新橋店 へ行ってみた。私がこのお店へ行っていた頃は10年以上のことなのに、昔とお店の雰囲気やメニューはあまり変わっていない気がする。スパイスが効いておいしかった。薬味?トッピング?にサービスで提供されるスモーキーなたくわんや玉ねぎのピクルスもおいしかった。

かぷせる旅籠 赤坂 SPABLIC INN

五反田から赤坂へ行くルートの1つとして、五反田 - 新橋 - 赤坂見附で行ける。乗り換えのアクセスがよかったり、新橋で晩ご飯食べるのもちょうどいい。前から知っていて1度泊まってみたいと考えていた かぷせる旅籠 赤坂 SPABLIC INN に泊まってみた。SPA:BLIC がコーポレートサイトらしい。結論から行って、私の感覚ではすごくよかった。また一泊出張のようなスポットで泊まるときがあれば予約したい。カプセルホテルだから料金は4,471円だった。いまの相場からいうとビジネスホテルでも1万2千円ぐらいするので半額以下と言える。カプセルホテルだから盗難防止を考慮して着替え以外はもっていかなかったが、ちゃんと鍵付きのロッカーもあったのでパソコン程度の荷物なら保管できる。

和風カプセルホテルで施設が新しく、ハイテクであちこちの入館やロッカー、チェックイン/アウトはすべて ic チップで行う。お風呂とサウナはこれといって特徴もなかった気はするが、大きなお風呂に入れるだけで私は満足。コワーキングスペースも併設されていた。休憩プランだと150円/時で使えるらしい。宿泊でももしかしたら使えたのかもしれない。コワーキングスペースが使えるならリモートワークをここでしてもよいのかもしれない。よいところをみつけた。