Posts for: #2022/11

仲の良いチーム

1時に寝て何度か起きて7時に起きた。起きてからも昨日の夜にやってた勉強会の資料作りをずっとやってた。

1on1 で設計談義

あるマージリクエストで私が nil ガードを実装した方がよいとコメントした。その意図がわからないという話になって nil ガードを実装する背景について、実際のコードをみながらメンバーに説明した。プログラミングの文脈では全然難しくないことではあるけど、あまり経験がない人にとってはその意図や考え方を学ぶのは難しいかもしれない。こういった、詳しい人に聞けばすぐ解決するけど、ググって調べるのは難しいこともある。1on1 のような身近に話す機会があると、定例会議でみんなの時間に話すほどの重要度ではない話題を聞くことができる。そこで聞いた意見をベースに私が issue 化したり、ある話題をチームで話し合う打ち合わせの機会を設けたりしている。

メンバーの送別会

私があるチームのマネージャーをして1ヶ月が経つ。メンバーの1人が退職することになった。実はマネージャーになって1週間後に転職が決まったという話しだった。いきなり開発体制がバタバタしたけれども、私からみたらやることは変わらないのでその影響は最小限に留められたのではないかと思う。いまのところ、当初の開発の計画にも変更をきたしていない。出張でオフィスに来ている機会なので私もそのメンバーの送別会に参加した。他の社員さんも20人ぐらい参加されていた。飲み会の雰囲気をみていて若い人が自由に発言して楽しんでいるのを傍から眺めてた。飲み会の雰囲気ってその組織の性格が出ておもしろいと思う。イヤな人がいないのは組織において重要になる。後日、経営者の方々とそういう会話をしていたら小さい会社はみんな仲良くできるといった話しをされていた。たしかにそれぞれのメンバーの顔とやっていることを見渡せる規模だから親近感を抱きやすいと言えるかもしれない。ここ数年どこへ手伝いに行ってもよい雰囲気をもつ会社は多い。変な言い方だけど、よい世の中になったと思えて嬉しい。

初めてのマイルストーンふりかえり

0時に寝て何度か起きつつ5時に起きた。慣れないホテルでの就寝なのに昨日はバテバテだったから割と眠れた方だと思う。

ふりかえり

1ヶ月 (厳密には4イテレーション) をマイルストーンとし、マイルストーンを終えたらふりかえりを行う。前にスクラム開発で行っていたふりかえり手法をベースにしながらやってみる。ポジティブなふりかえり向けに fun/done/learn という手法がよさそうだったので採用してみた。ツールは jamboard を使った。

初めてやってみたので進め方そのものにいくつか反省があった。オフィスで大きいスクリーンに映してみんながみえるようにしながら jamboard にコメントを書き込んでいく同時作業が割と忙しかった。jamboard で付箋を書くときの操作性が微妙によくない。慣れの問題かもしれないけど、なにかあとひと押しの操作性が足りない気がする。

最初なのでやり方の例として私も付箋にコメントを書きながらやっていた。私が参加者の1人として振る舞うと進行が止まってしまって忙しくなることに気付いた。あとで付箋に対して「いいね」をつけて共有してもらうときに、私の役割が開発者としての振る舞いとファシリテーターとしての振る舞いが混ざってしまって、他の参加者がどう感じたかはわからないが、私自身がいま何をやろうとしているのか分からなくなるといった混乱をきたすことがわかった。ファシリテーターとしての私はメンバーの意見を聞いてまとめ役をしないといけない。しかし、開発者としての私が意見を発してしまうと、私の意見を私がまとめることになってしまい、その客観性を担保しているのかどうかが分からなくなってしまう。要は簡潔なまとめなのか、個人の意見なのかの見分けがつかない。ファシリテーターとして振る舞うときはメンバーとしての意見を言わない方が進行がやりやすくなることに気付いた。初めてやったときはこんなもんか。次回への反省につなげる。

やったことは、課題管理システムから自分が担当者の issue をフィルターして眺めればすぐに把握できるが、ネガティブなふりかえりの気付いたことや改善したいことを掘り返す方法がないことにも気付いた。マイルストーンが1ヶ月なのでどこかに記録しておかないと忘れてしまう。go のプログラミングにまだ慣れていないといった付箋がたくさんあったが、それ以外はもう覚えていないというのもあったと思う。忘れないための一時記録の仕組みを考えないといけないことに私自身が気付いた。

東京出張 2回目

東京出張 2回目

0時に寝て4時に起きた。5時前には家を出た。初日だけは早起きして新幹線乗らないといけないので緊張する。新神戸6時10分発が始発になる。始発に乗った方が混雑もしていない。9時過ぎにはお手伝い先のオフィスについて業務を始められた。移動に約3時間。早起きは三文の徳みたいな話。

フルリモートワーク

朝一でオフィスに着いたものの、チームのメンバーの1人はお休み、2人は在宅勤務、上長は出張だったので私が一人だけオフィスワークしてた。普段は私がフルリモートワークなのでうちのチームはリモートワークの働き方が容易になるように業務を設計している。私がオフィスにいようが、普通にリモートワークするのはある意味で自然な働き方とも言える。周りのチームの人に「あっ、いたんですね」とか声を掛けられながら1人で黙々とお仕事してた。

全国旅行支援 + ただいま東京プラス

今回の出張は全国旅行支援で宿泊費が40%オフになっていて、且つ ただいま東京プラス という取り組みで3000円/日のクーポン券が付いていた。 region PAY というアプリにクーポンを登録して QR コード決済で対応店舗で買いものできる。すべてのお店が対応しているわけではないが、普通に周りの飲食店やコンビニなどでも使えた。ちょっとよい晩ご飯の定食を食べて、帰りにコンビニで飲みものを買って帰るぐらいの贅沢ができる。至れり尽くせり。

競輪選手というキャリア

ホテルでたまたまテレビをつけたらやっていておもしろかった。競輪オタクが競輪選手になったらめっちゃ強くて無双している、どこかのラノベみたいな話し。競輪という競技を私はあまりよく知らなかった。なぜこんなことができるかというと、競輪というスポーツは純粋な体力や身体能力で勝敗が決まらないらしい。試合展開の駆け引きがあって最後に勝敗が決まる。競輪オタクはすべての選手のプレースタイルを記憶していて、個々の選手の戦術を予測して対策できるから勝てるのだという。

出張前夜

0時に寝て6時前に起きた。昨日は夜にサッカーの試合をみながら寝た。早朝から田んぼ作業やって、慌てて戻ってイベント行って、バテバテで夕方はやや熱が出て寝込んでた。

玉ねぎを植える準備

昨日の続き。6時から田んぼへ行ける状態ではあったけど、まだ外が暗かったので7時から始めることに。畝を軽く耕して草をひき、苗を植えるための筋を作って、玉ねぎの苗を植えていく。途中から近所の手伝ってくれている方も参加して3人で作業をしていた。玉ねぎの苗を引く人、苗植えのために畝を耕す人、玉ねぎの苗を植えていく人といった役割分担。お昼休憩を含めて私は13時半まで手伝って神戸へ戻ることに。

草をひいたり玉ねぎの苗を植えたりするのに中腰で立ったり座ったりを繰り返す。筋トレに例えるとスクワット運動を何度も繰り返しているのに近い。太ももが筋肉痛になった。

ホームパーティー

13時50分に実家を出て15時頃に三ノ宮に戻る。ガソリンを満タンにしてレンタカーを返すのに10分ほどかかった。高速道路を降りて近くのガソリンスタンドへ行くルートを開拓しないといけない。一旦家に戻ってから三ノ宮.dev のホームパーティーイベントがあるというので行ってきた。13時からやっていたが、私は実家に戻ってたので16時前ぐらいから参加した。どういうイベントかまったく理解してなかった。いつもとは違う場所を借りてもくもく会みたいなのをやるのかと考えていたら普通にゲームしたり雑談したりするイベントだった。だからホームパーティーという名前なのかと行ってみて理解した。LienSpace という部屋貸しのレンタルスペースを借りて行われた。普通にマンションの一室を借りるような感じ。 3000円/時で4時間借りてたみたい。私が行ってから軽く雑談して人生ゲームやってそれでお開きになった。

レンタカーを借りて実家に帰る

2時過ぎに寝て7時に起きた。昨日の夜は洗濯と晩ご飯食べるために早めに帰って家事をやった後にオフィス戻って1時半ぐらいまで作業してた。

ストレッチ

今日の開脚幅は開始前152cmで、ストレッチ後156cmだった。先週に引き続き調子はあまりよくない。右股関節の詰まりと右太ももの張りがかなりある。今週も先週と変わらないぐらい座っている時間が長かったのでなんとなく結果は推測できた。来週は出張するから歩く機会が増えて逆に運動不足解消になってよい結果につながったりはしないだろうか。

レンタカー

母の脳梗塞疑いの検査入院 もあり週末に一度帰った方がよいだろうということでレンタカーを借りた。いつもコンパクトというカテゴリで借りると TOYOTA VITZ か HONDA FIT になることが多い。FIT は2-3回目なのでだいぶ車の雰囲気にも慣れてきた。今度から FIT 指名でいいかもしれないと思うぐらいには気に入ってきた。

神戸市内から垂水パーキングエリア

三ノ宮から垂水ジャンクション近くのパーキングエリアまで30分ほど。このパーキングエリアにはたるみ食堂という普通のパーキングエリアよりもちょっと豪華な雰囲気がするものが食べられる。一番人気とあったのでジャンボチキンカツ定食を食べた。おいしかったし、量も多かったので890円ならコストパフォーマンスはよかった。一方でお腹いっぱいになってこんなにたくさん食べなくてもよかったとも思えたので今度は別のものを頼んでみたい。たるみ食堂の隣にセブンイレブンがあってちょっとだけお土産も置いてあるけど、ここでは神戸のお土産はあまり選べないことに気付いた。ご飯を食べるところやね。

垂水パーキングエリアから淡路サービスエリア

垂水パーキングエリアから20分ほど。サービスエリア内のお土産は9割淡路島のお土産でちょっとだけ神戸、大阪、京都のお土産もある。姉にお土産を買って帰らないといけない。ここにはスタバがあって、スタバのケーキがよいという。昔からあったみたいけど、あまり意識してみたことがなかった。たしかに淡路サービスエリアにスターバックスがあり、明石大橋を眺めながらコーヒーできるよい立地にあることに気付いた。初めて入ってみてケーキとドーナツをお土産に購入した。

淡路サービスエリアから実家

淡路サービスエリアから高速道路も空いていてがんがん飛ばして実家まで40分ほど。自分で運転して帰るとあちこち寄り道できるし、たまに車の運転してストレス解消にもなるし、高速バスよりも速いし、お金がかかること以外はそれなりに楽しかった。まだまだ車を買う経済的な余裕はないけど、いつか車買って気軽にドライブに出掛けるような生活がしたい。

高速道路の料金

合計で2,540円だった。高速道路を普段走ってないので値上がりしているのかどうかすらわからない。

  • ETC 生田川 -神戸本線出 普通車 600
  • ETC 須磨本線 -垂水JCT 普通車 160
  • ETC 特割垂水第三 -西淡三原 普通車 1,780

玉ねぎを植える準備

帰ったら母が田んぼで作業してたからそのまま手伝うことに。肥料をまいて名前の知らない農具で玉ねぎを植える畝を耕す。雨で田んぼがぬかるんでいて作業しにくかった。昔は田んぼいっぱい玉ねぎを植えていた。いまはちょっと食べるぐらいしか植えないのでほんの数個の畝を耕すだけ。

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

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 に書いてあることにすべて従う必要はないものの、簡単にできて役に立ちそうなものはどんどん導入すればよいと私は考えている。

マーケティングと炎上

0時に寝て6時半に起きた。夜にコードを書こうと思いながらネットで遊びながら寝てしまった。今日は echo 移行のコードを書いていてレビューしてもらったりしていた。11月入ってから業務中に数時間コードを書いたのは初めてかもしれない。

あるサービスの社長とマーケティングと承認欲求と

昨日たまたまタイムラインであるサービスを退会したというツィートをみかけて、なんかあったんやろかと調べたら note の記事が原因だとすぐにわかった。私が読んですぐ思ったことは次の曖昧な姿勢でこれはまた物議を醸しそうだと思えた。

  • 事実はどうだったのかの結論が曖昧
  • 事件はなかったと明確に書いているのに相手と示談したという矛盾
  • 自社の当該社員に落ち度があったという矛盾

被害の有無について私はまったく知らないし関心もないが、虚偽なら虚偽と書けばいい。内容からなんらかの被害はあったようにも受け取れるため、被害者への配慮がまったくないことに懸念を感じた。いかなる背景や理由があろうと、被害を被った人がいる場合にその内容について書く文章はただ事実と謝罪のみである。過去の謝罪会見などで言い訳して余計に非難を浴びる事例はたくさんある。当事者としてできることは謝罪することしかない。これがまず鉄則。当該記事にはその姿勢がまったくみられなかったために炎上に至ったのではないかと思う。

リスク管理の専門家とも相談していてなぜこんなことが起きるのか。sns 慣れからの承認欲求もいくらかあると思うが、社長として「世間の耳目を集めるネタ」を入手したと思ってしまったのではないか。コンテンツを作るにはネタが必要でそうそう毎日おもしろいネタなどない。今回の事件は滅多に起きる事件ではなく、マーケティング的におもしろいネタになるとそのサービスの社長は考えたのではないかと推測する。リスク管理の裏側を語っていて、その在り方にクレームをつけている人たちもいる。私からみたら会社なんてそんなもんという内容でしかない。しかし、それを公けにすることで被害者が傷つかないかというのをまず第一に考えるべきである。もしこの被害者のインシデントが虚偽であればまったく問題ない。しかし、そうではないにも関わらず、会社のリスク管理の詳細を被害者が読んでどう思うかという配慮がまったくなかった。私からみて嬉々として詳細を書いてしまい、会社の危機に陥っているようにみえる。

おそらく社長個人の人柄や性格は悪くないのだと思う。自分の会社や身内を守ることのみに頭がいっぱいになってしまった結果、被害者への配慮という視点が抜け落ちてしまったのではないかと思える。私自身、そう在れるかどうかはともかく、経営者として客観的な視野をもって日々の業務の判断を下すように努めている。自社の損得ではなく論理的に考えて落とし所はここだろうという、私なりの論理最適解を顧客に提案するようにしている。このインシデントは社長が自分たちの会社のことしか考えなかったから発生したもので経営者の姿勢を問う事例の1つであると私は考えている。この状況からその会社がどういった顛末になるのか、今後の動向もみていきたい。

go の学び直し テスト編

23時に寝て2時に起きて気分悪くて寝付けずにだらだらしながら気付いたら5時になっていた。その後いつの間にか寝て8時に起きた。

go の学び直し

Gopher塾 #1 - Testing - DAY 3 に参加した。

マネージャーとして go 開発のマネジメントをしているため、メンバーの開発者よりは知識やスキルが高くないとコードレビューや適切な指示ができない。2018年ぐらいまで go 開発をしていたが、その後はずっと java 開発をしていたため、最近の go 開発の話題はあまり把握していない。毎週チーム勉強会 (いまのところ、go 開発の話題) をやっていると、チーム外からも開発者が参加してくれるようになった。チーム外からの開発者が go 開発するときの参考にもなるよう、マネージャーのお仕事の付加価値として、組織全体へ go 開発の知識やスキルを提供できればと考えながら働いている。

今回はテストについて話題で7割ぐらいは知っている知識ではあったが、3割ぐらいは最近の話題や静的解析の知見からの深い洞察を話されていてとても参考になった。知っている知識でも幅広いテストの話題の中で厳選されたコンテンツになるのだろうから本質的に大事なことや最初に学ぶべき優先事項を知ることもできた。私がメンバーに教えるときのコンテンツの参考として役に立つ。まったく知らなかった話題としては、txtar というテキストをアーカイブしたフォーマットをファイルシステムとして扱えるようにした txtarfs や、1.18 から追加された fuzzing というテストの入力値を自動生成する機能が追加されたこと。あと groovy でいうところの power assert に近い機能を提供するライブラリとして google/go-cmp をいまはテストに使うらしい。たまたま Go Test Comments を読んでいたら go-cmp は go の開発チームが保守していて go のバージョンに依らずほとんどの比較の要件にあうツールのように説明されていて利用を推奨している。

元同僚の来訪

0時に寝て4時に起きてドラクエタクトしてだらだらして7時に起きた。

echo を採用

昨日の続き。echo か chi でそれぞれサンプルコードを書いたものを定例でメンバーに説明して echo に決まった。echo は知っているメンバーもいたけど、chi は知らなかったみたい。アプリケーションに近いせいか echo の方が認知度が高いみたい。既存コードの移行は私がちゃちゃとやろうと着手したものの、わりとコードが込み入っていて2-3時間でできるものでもなかった。環境変数周りの処理も dry の原則に違反していたので caarlos0/env を使うことにした。エントリーポイント周りのコードをリファクタリングして merge request を作成した。明日中には既存の http ハンドラー周りの移行をしてレビューができるようにしておきたい。

遠方より来る

たまたまタイムラインで元同僚が近くに来るというのをみかけてせっかくの機会なので晩ご飯を食べに行ってきた。大阪に泊まっているのにわざわざ神戸まで足を運んでくれた。感謝。ゲームのコミュニティに属していると私は思っていたのだけど、最近はゲームよりも vr の世界の住人らしくて、vr の世界のコミュニティに入り浸っているらしい。そんな生活を何年もしているうちに仲間うちで仲良くなって、たまにオフ会で会ったりもするとのこと。全国に vr の世界の仲間がいるから出張したときにオフ会したりするそうな。oculus quest 2 をもっているけど workrooms ぐらいしか使ってなくて、若い人はもっと進んでいるなと関心をもって聞いていた。

内製のデータベースのプロダクトが完成して社内でも使ってもらう運用段階まできたとのこと。データベースをフルスクラッチから3年かけて開発できるだけの余裕のある会社は少ないだろう。本人もいくつか社内・社外の事情が重なってプロジェクトが中止にならず運がよかったと話されていた。開発の区切りもついたので今後のキャリアや転職も含めていろいろ考える時期になっているみたい。まだ30歳前後だと思うのでいろいろ挑戦したらよいと思う。

帰りに三ノ宮の街並みも少し紹介した。三宮という地名は他にも一宮から八宮まであって 神戸八社 と言う。間違えて九まであると言ってしまった。八までだった。2021年に 神戸三宮阪急ビル が完成して阪急三宮駅の周辺が再整備された。夜歩きしても楽しめる雰囲気にはなっている。

http フレームワークの選び方

昨夜いろいろあって帰ってくるのが0時過ぎになった。23時過ぎから雨降りで雨の中、自転車で帰ってきた。2時に寝て5時に起きて7時半に起きた。危うく寝坊するところだった。

母の入院

昨夜のいろいろのすべて。最悪の事態を想定してお手伝い先にも今日休むかも?と昨日の夜時点で一報を入れていた。結論としては休む必要はなかった。「ろれつが回らない」という連絡を受けて姉が救急車で病院へいくことを指示して即検査で即入院した。母は過去に目がみえなくなって脳梗塞だったことがある。幸い一通り検査して問題はなかったものの、念のために2日間入院して明日退院する予定。姉に病院の付き添いとかいろいろやってもらったので、私も週末に帰って様子をみてくる。お仕事が立て込んでてんやわんやだけど、そのために神戸で自分の会社をやっているのもあるので仕方ない。母は車を運転しない方がよいだろうという見立てで週末にレンタカーも借りた。久しぶりに高速バスではなく、高速道路をドライブしながら実家へ帰る。

echo と chi でサンプルコードを書いてみた

go の http フレームワークの選定 の続き。明日、定例があるのでメンバーにソースコードを共有しつつ、http フレームワークの採用を決めようと考えている。特定のルーティングとミドルウェアの適用をする簡単なサンプル。

net/http のレイヤーであれこれカスタマイズしたいなら chi でよい気もするけど、web api のアプリケーションのレイヤーにのみ注力したいなら echo を使った方が楽そうという私の第一印象。web api サーバーを書いてて request のパラメーターを扱うことはあっても response writer を扱う必要性をあまり感じたことがない。json しか返さないのだし、構造体を返したら勝手に json に変換してくれたらそれでいいんじゃないかと私は考えている。

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

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 に限らず、チケットを束ねるだけのハブチケットまたは親チケットに通常のチケット機能を設けない方がユーザーにとってわかりやすいようにも考えている。ハブチケットや親チケットに特化した要件や振る舞いはあるはずで、多くの課題管理システムはそれを追求していないようにもみえる。