アジャイル + スクラム + カンバン

スクラムがすでにアジャイルを指しているというのはさておき、これ考える。連投してすまん。

冷静に考えたら

1. WIP
2. 進捗状態
3. ポイント（報酬）

を一つのポイントで評価するのは悪手では？となった

WIPについては普通にチーム内の人数分をキャパにするのが一番丸い気がした。難易度観点にしたとき、例えばチーム3人いるのに、ポイント上限に達して2issueしか引き取れなかったとなったら、一人何すんねん。となるのではと思ったので

着手中タスク = 人数の状態を保っていればいい気がした。

進捗状態については、複雑さだけを観点にしたほうがいい気がした。優先度が高くて複雑さが低いものと、優先度が低くて複雑さが高いものを同等ぐらいのポイントに設定してしまうと進捗状態が嘘になる。

0~100までの進捗状態は時間をベースに評価するべきで、タスクの時間見積もりは開発者のスキルとタスクの複雑さの2観点でしかないはずなので。

ポイント（報酬）についてはそのまま進捗状況と相関させるでいい気がした。

成果をoutput / inputとして評価する場合、質は開発者のスキル次第だったりプロジェクトの最初の設計次第になる。inputに入る時間を削ることでoutput / input = KPIとしたときにKPIを改善することができるので、じゃあ進捗を進めた分だけ評価が正しいよねという。

ただそれだと優先度が高いissueをやるインセンティブがないんだよなぁ。。。

タスクの複雑さ + 優先度とした場合、前述したとおり

• タスクの複雑さ低, 優先度高
• タスクの複雑さ高,優先度低

が価値的に釣り合ってしまう。

優先度が進捗状況と関係性が深いか？というのを考えたとき主観的には低いと思うから、そこを進捗状況の評価に使いたくない。

となるとやっぱり進捗状況はタスクの複雑さだけで評価して、報酬ポイントに関してはさらにそこに優先度をかける形で算出する。みたいにすればいいのかなーと思った。

つまりこうなる

1. WIP: チームの人数 = タスク数になるよう制限
2. 進捗状況: タスクの複雑さをもとにストーリーポイントを見積り、それをもとに算出
3. 報酬: ストーリーポイント  * 優先度

---

まあ問題はgithub projectsの機能で個人にポイント割り当てする仕組みはないからissueに報酬フィールド用意して開発者とレビュアーにポイント割り当て。それを別途集計する必要があるという点すかね

github actionsとissueのカスタムフィールドを使えば多分できる。PRマージした人間を開発者、承認した人間をレビュアーとして、承認とマージをトリガーになんかしらのDBにポイントと開発者を突っ込んでいけば後で集計自体はできる。と思った

ソフトウェア開発によるissueのポイント化観点

ギルド式開発の続き

要はissueの難易度見積もりなんだけど考えるとむずすぎワロタ。

そもそもウォーターフォール開発ではなくアジャイル開発がいいよねという話の根元には「やってみなくちゃわからない」が少なからずあるという話で、issueの見積もりはあくまで見積もりになっちゃうよなぁという

まあでもissueをいい感じにポイント化できたらいい感じにゲーミフィングができて面白そうなので観点洗い出しをざっくりやりたい

※ちなみに調べた感じgithub projectsを使ってstory pointでポイント付けするのがいい感じ。そうすることで残ストーリーポイントから進捗状況を可視化できたり、良いことが増えそう

タスクの複雑さ

複雑さをどう評価するかだけど、

• 開発者の中で知っている人の少ない技術
• 複雑なアルゴリズム

の2観点かなと思った。複雑なアルゴリズムは例えばDEXアビトラでいかにして最速検知 + 最速txを達成するかみたいなやつ

知っている人の少ない技術は例えばだけどAPI作ったことない集団だったら、Hello Worldを返すAPIを作るだけでもそこそこ大変だよねという話。

不確実性

• 外部APIや外部システムが関わってくる

あたり、内部仕様が不透明なほどよくわからないエラーに引っかかったりするので。

またテストコード実装も面倒になってくる。外部APIかかわってくるところのテストのためにmockを作りたいけど、ドキュメントがあてにならねぇ！みたいになると面倒だよねという

他issueへの依存度

Aissueがあったとして、そのissueを解決しないと他issueが進まない。というケースはポイント高めたほうがいいと思った。

AissueをクリアするためにはB,C,Dissueの解決が必要。というケースでAissueをあげるかについてはB,C,D側が一つ目の考えでポイント上昇しているので別にいいかなと思った。

ポイントを報酬として考えたら、優先度を上げるときもポイントを増やす形で対応できるわけで、そしたら前者パターンがいいのか。

issueに観点ごとのポイントを書いておけば、「難易度低いけど優先的に解決してほしいタスクでお得やん！」となって引き取ってもらえるかも

優先度

依存度の話と大体同じ気がする。

---

考えてて思ったけど、ポイントと進捗度が紐つく形になるとポイントの美味しいタスクが優先的に処理される -> ポイントがおいしくないタスクが後々処理されるになって、進捗がスプリント後半になるほど鈍化するのでは？

まあでも後で高速化するよりはそのほうがいいのかもしれない。ポイントがそのスプリントに対して占める重要度やウェイトを示すようにしておけば、まあ別に問題ないような気もするし。

いやー考えてたらテンション上がってきた。

ちょうどよく開発中のbot、構造気に食わなくて作り直してたので、オレオレ開発やろうかな。github projectsで。一人でやることにはなるけど、とりあえずやってみてどんな感覚になるのか試してみる

チーム単位じゃないからポイントがあんまり意味ないような気がするけど、進捗状況を確認できるのは単純にモチベーション理論的に素晴らしいものだし、ロードマップ作製 -> スプリント分割自体はやってみれるし。

土日の楽しみができたぜ

ギルド式開発

妄想してた。

アジャイル開発の手法としてスクラム、カンバンというのがある。

スクラムはスプリント（アジャイル開発の一単位）ごとにPDCA回していくやり方みたいなのを体系化したやつという認識。（mtgによる毎日の簡単な状態確認もある）

1スプリントは2~4週間程度で、いったん全体のプロジェクト完遂までをロードマップとして定義。それを複数のスプリントに分割して、1スプリントずつ進めていくイメージ

ウォータフォールと違って、スプリンドのフィードバックのタイミングで手戻りが必要なら後ろのスプリント期間を調整したりして、手戻り用のスプリントを差し込むとかもできる（期限ぎりぎりのタイミングになるほど難しくなりそうではある）

カンバンはこのアジャイル開発の作業の可視化と効率化を目指したものという認識で、大体こんな感じでタスクを分類

1. ToDo: とりあえず現在上がっているタスク全て
2. Doing: 着手できる状態になったタスク（今のスプリントで着手する想定のタスクとか？）
3. In Progress: 着手中
4. Review: 着手されたタスクがレビュー中
5. Testing: タスクがレビューを通り、リリースされ想定通り動くか確認中
6. Done: タスクが完了

これをカンバンボードと呼ばれるもので視覚的に管理するイメージ

※看板はアジャイルの1スプリントに限定されず、全体の作業状態の確認でしかないっぽい。状態設定自体は大体今あげたやつぐらいだとは思う。Doingにするタイミングは優先度とか作業の進捗状態から触れるようになったタイミングでとかなのかな？そういう意味ではスプリント単位もあながち間違いではないのではと個人的には思うけど、厳密な定義的にはアジャイルにカンバン手法は限られるわけではないっぽいので違うかもしれない

ユニークだなと思ったのがWIPとプルシステムみたいなやつ。

WIPは各チームのタスク容量みたいなやつで、Doingに置かれるタスクは最大でも3つ。みたいにタスク数を制限するみたいなやつ。ただこれ決めたら「じゃあタスク進めなければいいのでは？」と思ったりしそうなんだけど、その辺はうまく監視すんのかな

プルシステムはWIPを前提としたもので、要は抱えているタスク数が3から2になったら3になるようにタスクが引き込まれる。みたいな仕組みを指してるっぽい。

あとはin progressのものが完了したら担当者は状態をreviewにして、レビューできる人は状態がreviewのものをキャパに応じて引き取る。といったもの

---

凄い完成されたシステムだと思ったのでここからさらに妄想。

ゲーミフィング、要はよりゲームっぽくして報酬機能を刺激する仕組みにしたいというところで考えたのがギルド式開発。

前提として

1. アジャイル開発
2. スクラム
3. カンバン

の仕組みを採用する。ロードマップをざっくり作って、それを2~4週間のスプリントに分割。そのスプリントの進め方はスクラムのフレームワーク通り

タスクの進捗管理もカンバンを使う。ToDoにはタスクが発生した時点で難易度、優先度あたりを決めてissueを作成。みたいに大体カンバンと同じ仕組みでスプリントを進めていく。

Doingに落とすのはスプリント単位で実行予定のissue。で、それを各チームもしくは開発者が引き取る（プルする）。極端なブラック化を避けるためにWIPを設定しておく

ほぼアジャイル + スクラム + カンバン通りなのだけど、ここにさらにポイント管理を付け加えたいというのがギルド式開発の考え。

ファンタジーものでよくあるギルドのようにissue単位に報酬が存在していて、その報酬をもとに開発者はissueを引き取ることができる。ポイントは金銭や評価、ランキングなどの報酬機能を刺激する何かに結び付ける。みたいなイメージ

まあこれの問題は営業とかでよくある問題と同じで、評価制にすることでチーム内やチーム間、個人間の軋轢を生むし、ノウハウの共有が避けられる可能性があるという点。

書いといてなんだけど、ギルド式開発で運用したいポイントはそのままカンバンのWIPのポイントとして使えるようにできるし、そこを頑張るほうが健全なのでは？となったりした

アジャイル + スクラム + カンバンまでは導入しているところはしているだろうし、ここに評価軸を置くなんてことは誰もが思いつくことだろうけど、調べた限り明確にやってる人の話は目にしなかったのでリスクがあまりにも大きいと思う人が大半なんだろうなと思った。俺もそう思う

まあでもゲーミフィングが有効であるのは確かだし、最下位が見えないようなランキングはいいんじゃないかなと思ったりした。ランキングの悪い点は自身の劣等感を感じる人間が出るというところなので

桜井さんがスマブラ作るときにランキングを世界戦闘力という形にしたのもその対策のためという話だったし。ポイント制 + 上位のみランキング化。というのがギルド式開発の落としどころかもしれん

---

余談だけどアジャイル + スクラム + カンバンの方式見ててめっちゃ美しいなと思った。ソフトウェア開発は特にハードウェア開発と違って手戻りは比較的しやすいわけだけし、アジャイルと相性いいよなとか。

スクラムのPDCA的やり方は無難に強そうだよなとか

特にカンバンの視覚化やWIP・プルシステムによるキャパオーバーを避けたりする仕組みはマジでいいなと思った。カンバンボードとかだれが使うねんってちょっと思ってたんだけど、認識変わったわ。プッシュ的な思想でとらえてたから使いづらそーと思ったけど、プル的な思想でカンバンを見るとめっちゃいいね確かに

WIPの点数化をいかにうまくやるかはゲームでいうレベルデザインのところになってくると思うので、ここがキモなんだろうなという気もする。

めっちゃ俺の考えた最強のプロジェクト進行やりてーと思った次第でした。おわり

PC周りの最適な環境について考えてた

どうにも色々作業をしていると不便さというかストレスを感じるシーンが多いように思っており、その原因について考えてた。

結論から言えばおそらくこれは配線で給電やサブディスプレイとのHDML接続など、優先マウスなどにストレスを感じているように感じた。

（考えてみると、大量のA4用紙の紙束なんかを見ると無性に全部丸めて捨てたくなったりするし、ごちゃごちゃした環境にストレスを感じる性格なのかもしれない。）

そこでサブディスプレイは安価なandroidタブレットを購入し、spacedeskというアプリで無線接続することにした。マウスもワイヤレスマウスを導入した。

無線に変更するとラグ関係の問題が出てくるが、入力する際のUIはノートPC側。参考資料などはサブディスプレイ側にすればそこまで問題が出ないと考えた。

懸念点としてはウェブアプリ開発時にサブモニタ側でそれを確認するケースだが、まあ問題ないだろということで目をつむることにした（まだ考えている最中でこれ書いてるので試してない）

これでゼロ配線で作業できるような環境を作れたが、問題になるのは充電。

日常的に作業をしていて長時間に及ぶ作業の場合ノートPCの充電が切れることが多いように感じた。

そうなると結局永続的に給電するために電源と接続する必要が出てくるため配線問題がクリアできなくなる。

そこで二つの解決策を考えた。

1. 2in1の小さな電源を用意し、そこからそれぞれに給電する
2. モバイルバッテリーを二つ用意し、そこからそれぞれに給電する

個人的には2かなと思った。

結局配線のストレスは、電源とデバイスの距離に比例して大きくなると考えたので、その距離を短くするためには電源を持ち運び可能なものにするしかないという考え。

2in1のモバイルバッテリーを一つ用意して、そこからそれぞれに給電するというのも考えたが、それをすると結局二つのデバイスはモバイルバッテリーを通じて接続されているような状態になり、ストレスのもとになるような気がした。

であればデバイスごとにモバイルバッテリーを用意しそこから給電。デバイスを使って無いときにモバイルバッテリー二つを充電する。という形を作れればストレス軽減ができるのではという考え。

うまくいくかわからないけど、実際何を使うかは調べる予定。

---

ちょっと調べた。

今使ってるpcのusbc給電には最低でも40w必要らしい。

anker nano power bankとかよさげだなと思ったのだけど、これだと出力足りない。

出力を満たしつつってなると結構大変かも。あと意味不明だけどusbc給電すると処理が遅くなって、タイピング速度に表示が追いつかなくなる。充電問題だけはうまく解決できなさそうだなぁ。。という次第でした

詳細設計書を捨てるには

※ウェブエンジニアとしての意見

まず前提として詳細設計は捨てられるなら捨てたほうが良いと思ってる。以下理由

• メンテナンスコストが高い
• 工数が増える

平時のメンテナンスはそこそこ問題なく行えるが、多忙時や緊急性の高いアクシデントが発生した場合の修正は設計書修正まで含めずPR単位でのみ行うことが多く、ソースコードとの乖離が生まれる。

乖離量が増えると同時に設計書を適切に修正する難易度が跳ね上がっていくため、メンテナンスコストが増えやすい。

また単純にPR作成のたびに設計書修正も重なってくるため工数が増える。

そもそも仕事の成果はoutput / inputで測れると考えているので、input量の増える詳細設計は捨てたい。

• output: 成果物
• input: 労力、時間、金などリソース

そもそも詳細設計を作れるということはその情報があるはず

誰かの頭の中かドキュメントかあるはずなので、ゼロイチ時点であったとしてもissueに言語化した要件を書き下すだけであとは開発者にどう実装するかは委ねてよいと思う。

ただここでスキルでの差が発生してしまうため、開発ガイドラインは固めておく必要がある。コーディング規約など

また外部APIなどを利用している場合は、そのドキュメントなどのリソースをまとめた情報も必要になる。

こういった情報をwikiで整理し管理しておけば、管理コストの低い情報のみで成果物を生み出すことが可能になるはず

基本設計はいる

基本設計は必要だと思う。DBは何があるか、APIのリクエストレスポンス、画面定義書など。ただこのあたりは自動生成する方法があるので、実装ベースで更新をかけていくことが可能。

システム全体の構成図や機能一覧については客がいるなら作ったほうがいいような気がするけど、いないならいらなくね？とは思う。システム構成図はIaCが実質ドキュメントの役割を果たせると思ってるので。

機能一覧は若干必要な気もするけどウェブだったらルーティングファイルが十分にその役割を果たしてくれるのでは？と思う。何をするページなのかまでは不明なので、前提知識量の多いものであれば別途情報を管理する必要がある気はする

wikiに何を書くか？

wikiに共通して必要な情報を整理し、それをもとに成果物を生み出すことができれば工数を削れるのでよいと考えた。

wikiには以下辺りをざっと書いておくといい気がした

• ドメイン知識
• プロジェクト情報: 何をしたいのかなど
• 開発ガイドライン: コーディング規約、レビュープロセス、テスト粒度など
• 運用メンテナンス: 手順書やノウハウ
• TIPS: 外部API使ってるならそれのドキュメントやノウハウなど、リファレンスまとめたり
•  

後々更新がかかりそうな情報については粒度粗目に書いたほうが良い。更新コストが伸びるので

プロジェクト情報辺りは怪しいので粒度粗目でいいと思う

詳細設計の代わりになるのは？

テストコードとソースコード。

テストコードで観点が見えたり、ソースコード自体を見れば特定処理の実装は十分にわかる。

詳細設計の有利点はソースコードを見るより設計書を見たほうが早く理解できるという部分にあると思うが、ぶっちゃけよく見かける詳細設計、日本語でプログラミングしただけでは？みたいなもの多いのでむしろ読みにくい。関数なども使わずに一息に書き下したソースコードを見てる気分になる

開発ガイドラインを十分に書きこんで周知し、またレビュープロセスを適切に運用すれば詳細設計書不要でコードベースで概要把握可能でしょと考えた。

---

ソースコードと1:1の関係になってる詳細設計書、ソースコード見ればええやん！としか思わないので、成果最大化のためにも捨てたほうがいいと思う。

ゼロイチで開発するシーンやウォーターフォールで開発するシーンでいるでしょ。となるのは若干分からないでもないけど、issueに言語化されたものを載せれば十分な気がしてる。

ただバリデーションやエラー文言、画面仕様どうするかなど細かい点を考えるとゼロイチ時点では欲しいよなぁとなるのはめっちゃわかる。

ここに関してはテストコードベースで読み解けばいい気がする。

要はどのような観点でテストするかをissueで言語化し、それをもとに実装者がテストコードを書く。そのテストコードをレビュアーが確認し、バリデーションやエラー文言などの部分が適切であるか評価する。的な

どんなエラー文言とするかは共通化したほうがいいような気もするので、wikiでドキュメント化しておくといいのかなぁという気がする。

少なくとも各機能ごとに書かれた詳細設計書でそれぞれエラー文言を書き下している状態よりはそのほうがいい気がする。

ウォーターフォール開発ではどうしても詳細設計書を捨てる選択肢は難しいし、客がいる場合はそれを作っておくことも仕事の一つとして含まれていたりする場合もある。

ただ仕事は成果という部分だけに重きを置くべきだと思ってるし、成果はoutput / inputで評価できるものだと思っているので、捨てても開発できるはずのものをわざわざ含めてinputを増やして成果を下げるのはよくないと思った次第でした。おわり

外貨ヘッジして課税されるのバグだろ

※ネタです

ドル円を50:50の割合で保有すればデルタニュートラルな状態で円の価値が下がればドルが上がってトントンだし、その逆もしかり。

っていう考えで外貨保有で為替変動リスクをキャッチできるんだけど、円価値が下がった場合は円ベースでは利益になるので課税対象になるのだけどバグでは？となってきた

100万を50万:50万になるようにドル円に振り分けた後、ドルの価値が20%上昇して60万円相当の価値になる。

そうした場合、円ベースでは110万円保有しているわけだけど、ドルベースで購入する外国製品はその分寝上がっているので、本当に利益なのかこれ？となってくる

値上がりで円ベースの価値は棄損しているといえるのに、利益分に税金がかかって金とられるのバグだろ。という話でした

実際は身の回りの製品すべてがドル影響を受けるかと言ったらそうでもないので冒頭通りネタです

迎合人間から考える人間関係

迎合と呼ばれるパーソナリティは一言で言えば「自分を押し殺す」タイプで、とにかく相手と同調することをベースに人付き合いをする行動パターンを指します。

同調をするとは具体的に読み解けば、

• 相手の意見と自分の意見が同じだと伝える

ということになるので、迎合人間は常に後出しをする必要が出てきます。

自分から意見を出せば相手が逆の意見を出した場合対立の関係性を作ってしまうため、基本的な行動パターンが後出しになるということです。

どうしても自分から意見出しをしなければいけない場合、顔色をうかがうような疑問形の意見出しになりがちですし、仮に対立する意見が出た場合はすぐに意見を変えることも多いです。

※自分視点では自然な振る舞いだと思っていても、相手視点からすると心開いてくれてないなぁと感じさせてしあう原因がこの辺の後出しや顔色うかがってそうな雰囲気

迎合パターンの問題点は3点

1. 自分を押し殺すことになるのでストレスがやばい
2. 相手に自分の気遣い分のリターンを求めてしまう
3. 親密なコミュニケーションが行いづらい

という部分にあります。

1,2はほぼ同じような話ですが、迎合パーソナリティの人は対立を恐れるあまり相手の意見を受け入れ続けてしまいます。

自分自身の理性の部分では自然な振る舞いとしてそれをやっているつもりでも、どうしても徐々に精神的ストレスが積み重なり、無気力になって殻に閉じこもったり、爆発するように怒ってしまったりなど最終的に問題が発生しがちです。

3についてはそもそも親密なコミュニケーションって何？という部分が重要です。

親密なコミュニケーションとは具体的に言えば、「赤の他人には言いたくないしいうことにストレスを感じる話題を気兼ねなく話せる状態」といえます。

性や金、コンプレックスに将来の夢、一昔前ならオタ話なんかもそうですね。こうした話題は気恥ずかしかったり嘲笑されてしまいそうな恐怖感などを持っており人に話すのがはばかられます。

これらを話せるのはそれだけ関係性に安心感があるためであり、親密なコミュニケーションをとれる関係性は非常に満足度が高い状態だといえます。

じゃあ親密なコミュニケーションをとれるようにするにはどうしたらよいのか？

これをするには関係性に心理的安全性が必要だといえるわけですが、じゃあそれを持つ関係性を作るにはどうすればいいの？という話になります

結論から言えば必要なものは対立です。

対立というととげとげしいですが、意見の相違を楽しめるような関係性を作っていくことが大事ということになります。

心理的安全性とはいいかえれば「喧嘩したとしても関係性が終わらないし、相手から理不尽な言葉やストレスをかけられない、もしそうなっても言い返すこともできる」みたいな状態です。

健全な親子は反抗期を過ぎてもなんだかんだで仲良くしているもので、これは大きな対立や争いを経験しても最終的にはいい関係を維持することができるという認知があるからこそです。

「これをいったら傷つけてしまうかも」「悩みを打ち明けたいけど笑われてしまうかも」こういう不安があるからこそアイデンティティとかかわりの深い話をしづらい = 親密なコミュニケーションがとれないという話なので、対立しても関係性を維持できたという共通認知こそが重要といえます。

「私を破壊するに至らないすべてのことが、私をさらに強くする」みたいな言葉がありますが、人間関係にも同じようなことが言えるわけです。

実際問題、ライフハック界隈ではよく仲良くするための話題といったものが挙げられていますが、多くの場合それは意見を求めるもので、抽象的にはお互いの意見を食い違わせてその相違を楽しみながらより良い関係性を築いていくための話題だといえます。

もちろん対立ばかりではなくときには同じ意見だとなることもよい関係性には必要なことだと思いますが、迎合パーソナリティの人が人間関係に苦しむことからも、そこで無理をして同調を繰り返せば、ほぼほぼ微妙な関係性に終わってしまうので気を付けましょう。

ちなみに楽しく対立するポイントはIベースで話すことだと言われており、言い負かそう、相手の意見を変えようなどとは思わないことが重要です。

あくまで今回の話は説得や交渉、ディベートなどではなく、雑談して日々の生活を人とともに楽しくいきたいがためのものなので。

1. 私はこう考えている。というスタンスで話す
2. 相手が意見を話しているときにさえぎらない

この2点を守ればOKです。

ありがちなのは「あなたの意見もわかるけど、私は〇〇な理由でどちらかといえば□□派かな」みたいな感じ。こんな雰囲気で話せば大抵問題ないです

程よい対立を積み重ねてよい関係性を作っていきましょう。おわり