ソフトウェアの見積もり
「これどう思う」
そう言いながら手渡された本の目次を眺めてから、掻い摘んで本文を読むと、エンジニアの経験とは大事な価値だなと思った。
どういう意味かというと、その本では顧客側の視点はゼロだし、システムを受託する側としても到底、組織内の見積もりレビューを突破できないだろう。
目次をもう一度見直すと、システムやサービスをローンチするまでの体系的にカバーしようとはしておらず、オムニバス的な標題になっている。つまり、単なる共著、エッセイなのだ。
手元にある本を読んで、見積もりはこれで十分だと思うエンジニアはいないと思うのだが、でも、事業の特性や担当している業務によっては、それで十分と思ってしまうかもしれない。
もちろん、自分もシステムの見積もりを体系的に知っていて、いい感じに見積れるかと問われれば、まだ素人なのでと言ってしまうだろう。なにぶん、システム全体となると見積もるほど知識は持ち合わせていないし、見積もり経験の全くないところもあるし、ある領域は業務からだいぶ離れているので勘がない。
そんな自分でもいくつかの見積もり本を読んで、少しでも見積もりができるように知識を得ようとはしてきた。
システムやサービスを動かすためには、ソフトウェアだけ見積もっても使ってもらえない。見積もりもアプリのコードを作るところだけでは話にならないと素人だから勝手に思っている。
見積もること自体が無理なのだからと見積もる知識を持っていないのと、知った上で見積もることは無駄になるから、小さいタスクをやって、それを基準に相対しようというのは雲泥の差だと思う。
端的に言えば、観点が抜けるのだ。知っていたとしても、見積もりをするときに意識が及ばなければ抜けてしまうのは結果としては同じなのだが。
チームを守るサーキットブレーカー
新型コロナウイルスの検査で医療体制を崩壊させないために、医療機関のキャパシティを超えないように検査をコントロールするかどうかという図はこれまで何度かTLや厚生労働省の資料で見ていたが、昨日、ふと、これはエンジニアチームのリソースとタスクボリュームの関係と同じではないかと気づいた。
縦軸がタスクボリュームで点線はエンジニアチームのリソース、受け入れられる仕事量と見る。
単純にキャパ以上のタスクをやっていたら、タスクをこなすために長時間労働になるし、ミスができないタスクならエンジニアチームへの見えないストレスは膨れ上がるから、ピークにまで行ってしまうと、エンジニアチームは本当に逝ってしまいかねない。
冷静に図を見直せば、検査体制もチームでやっているのだから、もともと同じは当たり前で、何を今更言っているのだと突っ込まれそうである。
チームを崩壊させないためには、トップダウンでwipに当たる点線のラインを明確にひいて、何があってもタスクを突っ込ませないようにブロックしなければいけない。
放っておくと外野や当事者でない批評家のような組織内の対外的な風評を気にする輩がwipを無視して、後先もチームの崩壊も微塵にも考えずに対応しろと無責任に口を挟んでくる。
そこは何があっても守りきらないと崩壊したチームの残骸を見る羽目になる。その上、そうなった元凶が守れなかったマネージャに対してやっぱり、とかいうのだ。
そうさせない、普段からチームを守るために、どうなっていればチームのパフォーマンスを最高に発揮するかを考えて実践する。
チームのおかれる環境、コンディションはどういったパラメータで得られるかを微調整しながらセッティングする必要がある。
チームのサーキットブレーカーに当たるものだが、これはチームのメンバの交代、追加、減員で簡単に下がる。成長はそんな簡単には上がらないが。
現場の見積もり
・頭数見積もり
何人欲しいですか、そうですかじゃあ3人揃えますね、的な。人工。それを見積もりと呼ぶのか。
・顧客予算見積もり
受託側に見積もり根拠を持っておらず、顧客のやりたいことは言いなりで顧客の予算に合わせる。それを見積もりと呼ぶかは疑問。
・KK見積もり
感と経験で雰囲気で見積もる。エンジニアの自分のタスク見積もりもこれ。肝心なワークが抜けていることが多く、実態とはかけ離れる。
・類推見積もり
過去プロジェクトの定量的特徴と過去実績と見積もりたいプロジェクトの定量的性質を比較して試算する。記録することを考えて実績をとっていないから精度は甘いが、ないより1000倍まし。現実的には工程、エンジニア別の工数と定量的性質の情報。件数が貯まると良い。
・FP見積もり
使える手法なら定着していたと思うが、現実は厳しい。例えば、パッケージを使ったソリューション開発では使えない。
・cocomo II
ステップ数の算出自体が怪しい。言語別のLOCを持っている組織はあるのだろうか。
エンジニアで成果が出せないからPMをと思ったら
週末にTLで異業種からエンジニアに転職して、3年くらいやって思ったような成長を得られないからPMにキャリアを変えようかというものを見かけた。
自分の20代の頃に通ってきた悩みと重なるところがあるので気になるが面識もffでもないので変に知らないおじさんからあれこれ話しかけられても迷惑だろう。
なのでここに独り言を。
・アウトプットのついて
ツイートの中にあまり対外的なアウトプットをできていないと書かれていたが、無理をして対外的なアウトプットをやらなければと思う必要はないと思う。自分の経験を自分で理解した言葉で書き留めておけばいい。
それをどこかの手段は問わないが公にするのは構わないが、意味のあることは、自分の経験を自分の言葉で整理し直すこと。○○をしなきゃと思うとできていないときにつらい。それよりは、理解を言語化することと、それに時間を充てられるリソースの使い方の方に価値がある。
・PMはエンジニアと同じくらい勉強が必要
エンジニアで成果を出せないからPMというのは印象として、PMでも成果を出せるとどうしてそう思ったかを自分の言葉で言語化してみてからでも遅くはないと思う。
PMは人気のない専門家だ。ミッションと責任が割に合わないと考えるエンジニアが多いからだろう。まっさらに一からPMに必要とされる幅広い知識を学ぶ必要があるし、それはエンジニアをやりながら、並行して身に付ける必要がある。
未経験のエンジニアに採算を求めるプロジェクトを任せるほど体力があれば良いが、通常はそんなことはない。
エンジニアの素養を気にするなら、キャリアをピボットする前にピボットしようとしている先の素養を並行して確かめた方が良いと思う。
その上で、覚悟を、もしピボットした後で道を間違ったと思ってもやり直そうと意思を持ってピボットしてはどうだろう。
If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
アジャイル界隈ではしばしば『許可を求めるな、謝罪せよ』を耳に挟むことがある。チームを成長させたいなら、結果的にメンバに裁量を渡して自律を求めることになる。自分を律して活動するためには、メンバ自身で意思決定して、行動する必要がある。
そうしたことを求めるなら、やることなすこと一々、指示をしたり、やる前に確認をしていては、メンバは許可を与えるリーダに依存することになる。それは、裁量と自律と相反することでしかない。
裁量を与えるということは、自分の頭で考えて、基準に照らしてベターと思う方を実践することを期待しているということの表れなのだから、あれこれと言ってはいけない。
もし、メンバが自分でやったことがリーダの意図相反するのであれば、それはチームの価値観が浸透していないということであり、チームの文化になっていないということである。
リーダのやらねばならないのは、チームの価値観をチーム全員にリマインドすることである。
メンバにとっても、貢献をしたいと思うなら、チームの価値観を踏まえ、エンジニアとして自分で最良と思う選択肢を意思決定して、実践して確かめなければならない。
スピード感を持ち、結果を出したいなら、ことさらである。
やらずにアイデアを説明して理解してもらい、それから手をつけるよりは、やってしまってその結果についてコメントをもらう方が実物があるだけ話が早いし、何より実物があるのだからリーダは意思決定しやすい。
もちろん、小さなロットで、が望ましい。
If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
Grace Hopper
（翻訳）それが良いアイデアであれば、先に進んでください。 許可を得るよりも謝罪する方がはるかに簡単です。
Grace HopperはCOBOLの開発者であり、バグを広めた人である。
月刊退職エントリーまとめ（2020年2月）
流石に少ない。
思考と試行のフィードバックループ
これまで何度か失敗のことについて書いてきた。ページの下にある検索窓で『失敗』と入れて検索すれば過去のエントリが出てくる。どれほど失敗好きなのかとも思わなくもないが、人生なんて期待していたような結果になるより、期待していなかったことの方ばかりだ。人生の面白いところは、期待していなかった結果は全てマイナスの結果ばかりではなく、プラスになることも稀にある所だ。
仕事では、失敗はした方がいいということをこれまで何度か書いてきた。それも小さな失敗をして、失敗したやり方を学び、残った選択肢から成功に辿り着こう、と述べてきた。仕事だから失敗をして評価を下げたくないとか、昇進の機会を失いたくないとか、思うかもしれない。それについては誰も否定しないだろうし、結果を選べるなら誰だって成功する方を選ぶだろう。
でも、やっぱり失敗する。これは避けられない。初めてやってみる仕事は失敗の連続でしかない。システムを導入する前には、要件を整理し、運用に機能を適用して実務を設計する。このとき、要件の整理が甘かったり、ボヤケテいると運用自体が間抜けな設計になるし、現実的でない運用を設計すれば使われないシステムが居座るだけである。
そんな失敗にしないために、要件をちゃんとやれとか、運用を設計しろとか言っても正論すぎて、そうですねという感想というか馬耳東風にあしらわれるのが精一杯で、何も産まない。エンジニアであれば誰もがコンサルや第三者から正論ばかり指摘されてうんざりするという経験していると思うが、正論や正義はなんら解決策を産まない。
我々の欲しいものは、価値のある現実解である。その現実解は、労働集約的な要件から思考と試行を必要とする誰も答えを知らない要件に移ってしまった。それにどうアプローチするか、であるがそうした考えは別の人に任せるとして、思考と試行を必要とする要件の現実解を手に入れるためには、次のように取り組むと、試行から思考にフィードバックできるようになり、次に繋げられるので良い。
- 要件は小さくする
- 最小少人数でやる
- 先に、思考する時間枠を決める
- 思考してローンチできるまでを固まった時間でやりきる
要件を小さくするのは小さく失敗をするためである。
最小人数でやるのは、長々と議論をしないとか、意思決定を遅らせないためである。
先に、思考する時間枠を決めるのは、リソースを確保するためである。
ローンチできるまで固った時間でやりきるのは、細切れで断続的に作業をして、失敗がわかるまでの時間を伸ばさないためである。
この他にも、思考するときは紙に描いておしまいにすることも大事だ。清書なんていらない。記録が欲しければスマホで写真を撮って、slackに貼っておけば良い。でも、大事なのは描き残した紙だが、思考の結果があれば、そのまま試行に移れる。間に試作をするのであれば、紙をみて作れば良い。
