ダメな見積もり
- 人足見積もり
エンジニアの頭数だけ揃えて、時間単価か月の単価を書いた見積書と言う見積もりしかない。過去に指示されたとおりの経験があるだけでましで、プロジェクトで必要とされるスキルセットを持っていないことはザラ。 - いいね！見積もり
顧客の予算に合わせた工数で見積もったり、見積書を作り、エンジニアを現場に送り込むか、常駐しているエンジニアに丸投げする。見積書には受託業務がふわっとしか書いておらず、現場が顧客に詳細を聞きに行くと、スコープが膨らみ、ねじ込まれる。見積もるエンジニアも営業も当事者でない。 - 勘と経験と度胸
顧客からの見積もり仕様があったとしても、過去の類似している案件と似ていると思い込みを根拠とした見積もり。ろくに要求を確認していなかったり、顧客の業種や客バカ度を考慮していなかったり、送り出すチームのエンジニアも決まっていないまま見積もるため、見積もりと実績の乖離が必ず生じるが、それはエンジニアチームのせいだと責任を押し付ける。 - ギャンプル
勘よりひどい。類似はもちろん、未経験分野でも無理くりに見積もる。それは見積もりと呼べるものではなく、博打でしかない。 - LoC
Line of Codeの略で、言語の標準的なステップ数と工数を掛け合わせて見積もる。実態は逆で、期間（時間的な長さ）や工数（工期と時間の掛け算した面積）が瀬制約条件で押しつぶされて面積の削減の辻褄をあわせるとき、生産性向上できるだろうと勝手に月あたりのステップ数を増やされたりする。同じコードを書いたとしてもIDEを使わずフルスクラッチでピュアな環境とIDEを使って書いたコード量が違うので信憑性はない。その点で、プログラムを共通化やライブラリ化せず、コピペして１−２行書き換えるような作り方をしているとコードの生産性は上がると言う矛盾を持っている。
スキップ
調子が悪く、一回お休み。
リモートワークで浮いた通勤の2時間はどこに消えたのか
リモートワークは、働き方改革で声高に言われていたが、なんだかんだ延々と進んでこなかった。それが新型コロナウイルス、COVID-19の登場で、今までリモートワークを渋っていた経営者も強制的にせざるを得ないと、判断させるまでの状況になっている。
こうしてみると日本は本当に外部からの強力なインパクトがないと変わらないのだな、と思う。
リモートワークをやってみると、今までの日常の無駄が浮かび上がる。通勤時間を筆頭に、話すことのない会議も出る必要はないと実感しているのではないだろうか。
カンファレンスや勉強会に出て行くようなエンジニアは一握りで、実はそう言ったエンジニアは意識高い系エンジニアだとメディアの役員に『あなたのことだよ』と言われたときに何を言っているのだと言い返してから久しい。
そのカンファレンスは、ことごとくキャンセルになるし、一部は実験的にオンラインに移行し始めている。勉強会やLTなどは規模もトラックもないからそれをやり易い。
在宅での通勤時間の無駄な体力の消耗やカンファレンスのオンラインが定着すると、移動時間が丸っと手に入る。ドアツードアで片道1時間なら、24時間中2時間が生まれる。
その2時間で何をするか。
採用面談でキャリアシートをみると、これから取り組みたい技術や興味のある技術を記載しているエンジニアを割と見かける。定型的なフォーマットだと、そういったことを書くことを無意識に書かなければならないと思っているのか、書く。もしかしたらエージェントに書くように指導されているのかもしれない。
ではその取り組みたいと思っていることをするチャンスではないか。毎日、通勤で消耗していた2時間丸々手に入る。それをどう使うかは取り組みたいことのあるエンジニア自身のことだが。
一つ言えることは、取り組みたいことがあるエンジニアは実際にはやらない。ずっとやらない。やるエンジニアは無理くりにでも時間を作ってやっている。なぜなら、自分でやりたいと思ったからだ。やりたいこと、取り組みたいことを実際にやっているエンジニアは、すでにやっている状態であるのでさらに次のやりたいことを見つけられる。
自分で自分を取り組みたいと書いた時点に置き去りにするのは、取り組みたいと書いたエンジニア自身である。組織でも、忙しい仕事でもない。
自分に指を向けて。
ソフトウェアの見積もり
「これどう思う」
そう言いながら手渡された本の目次を眺めてから、掻い摘んで本文を読むと、エンジニアの経験とは大事な価値だなと思った。
どういう意味かというと、その本では顧客側の視点はゼロだし、システムを受託する側としても到底、組織内の見積もりレビューを突破できないだろう。
目次をもう一度見直すと、システムやサービスをローンチするまでの体系的にカバーしようとはしておらず、オムニバス的な標題になっている。つまり、単なる共著、エッセイなのだ。
手元にある本を読んで、見積もりはこれで十分だと思うエンジニアはいないと思うのだが、でも、事業の特性や担当している業務によっては、それで十分と思ってしまうかもしれない。
もちろん、自分もシステムの見積もりを体系的に知っていて、いい感じに見積れるかと問われれば、まだ素人なのでと言ってしまうだろう。なにぶん、システム全体となると見積もるほど知識は持ち合わせていないし、見積もり経験の全くないところもあるし、ある領域は業務からだいぶ離れているので勘がない。
そんな自分でもいくつかの見積もり本を読んで、少しでも見積もりができるように知識を得ようとはしてきた。
システムやサービスを動かすためには、ソフトウェアだけ見積もっても使ってもらえない。見積もりもアプリのコードを作るところだけでは話にならないと素人だから勝手に思っている。
見積もること自体が無理なのだからと見積もる知識を持っていないのと、知った上で見積もることは無駄になるから、小さいタスクをやって、それを基準に相対しようというのは雲泥の差だと思う。
端的に言えば、観点が抜けるのだ。知っていたとしても、見積もりをするときに意識が及ばなければ抜けてしまうのは結果としては同じなのだが。
チームを守るサーキットブレーカー
新型コロナウイルスの検査で医療体制を崩壊させないために、医療機関のキャパシティを超えないように検査をコントロールするかどうかという図はこれまで何度かTLや厚生労働省の資料で見ていたが、昨日、ふと、これはエンジニアチームのリソースとタスクボリュームの関係と同じではないかと気づいた。
縦軸がタスクボリュームで点線はエンジニアチームのリソース、受け入れられる仕事量と見る。
単純にキャパ以上のタスクをやっていたら、タスクをこなすために長時間労働になるし、ミスができないタスクならエンジニアチームへの見えないストレスは膨れ上がるから、ピークにまで行ってしまうと、エンジニアチームは本当に逝ってしまいかねない。
冷静に図を見直せば、検査体制もチームでやっているのだから、もともと同じは当たり前で、何を今更言っているのだと突っ込まれそうである。
チームを崩壊させないためには、トップダウンでwipに当たる点線のラインを明確にひいて、何があってもタスクを突っ込ませないようにブロックしなければいけない。
放っておくと外野や当事者でない批評家のような組織内の対外的な風評を気にする輩がwipを無視して、後先もチームの崩壊も微塵にも考えずに対応しろと無責任に口を挟んでくる。
そこは何があっても守りきらないと崩壊したチームの残骸を見る羽目になる。その上、そうなった元凶が守れなかったマネージャに対してやっぱり、とかいうのだ。
そうさせない、普段からチームを守るために、どうなっていればチームのパフォーマンスを最高に発揮するかを考えて実践する。
チームのおかれる環境、コンディションはどういったパラメータで得られるかを微調整しながらセッティングする必要がある。
チームのサーキットブレーカーに当たるものだが、これはチームのメンバの交代、追加、減員で簡単に下がる。成長はそんな簡単には上がらないが。
現場の見積もり
・頭数見積もり
何人欲しいですか、そうですかじゃあ3人揃えますね、的な。人工。それを見積もりと呼ぶのか。
・顧客予算見積もり
受託側に見積もり根拠を持っておらず、顧客のやりたいことは言いなりで顧客の予算に合わせる。それを見積もりと呼ぶかは疑問。
・KK見積もり
感と経験で雰囲気で見積もる。エンジニアの自分のタスク見積もりもこれ。肝心なワークが抜けていることが多く、実態とはかけ離れる。
・類推見積もり
過去プロジェクトの定量的特徴と過去実績と見積もりたいプロジェクトの定量的性質を比較して試算する。記録することを考えて実績をとっていないから精度は甘いが、ないより1000倍まし。現実的には工程、エンジニア別の工数と定量的性質の情報。件数が貯まると良い。
・FP見積もり
使える手法なら定着していたと思うが、現実は厳しい。例えば、パッケージを使ったソリューション開発では使えない。
・cocomo II
ステップ数の算出自体が怪しい。言語別のLOCを持っている組織はあるのだろうか。
エンジニアで成果が出せないからPMをと思ったら
週末にTLで異業種からエンジニアに転職して、3年くらいやって思ったような成長を得られないからPMにキャリアを変えようかというものを見かけた。
自分の20代の頃に通ってきた悩みと重なるところがあるので気になるが面識もffでもないので変に知らないおじさんからあれこれ話しかけられても迷惑だろう。
なのでここに独り言を。
・アウトプットのついて
ツイートの中にあまり対外的なアウトプットをできていないと書かれていたが、無理をして対外的なアウトプットをやらなければと思う必要はないと思う。自分の経験を自分で理解した言葉で書き留めておけばいい。
それをどこかの手段は問わないが公にするのは構わないが、意味のあることは、自分の経験を自分の言葉で整理し直すこと。○○をしなきゃと思うとできていないときにつらい。それよりは、理解を言語化することと、それに時間を充てられるリソースの使い方の方に価値がある。
・PMはエンジニアと同じくらい勉強が必要
エンジニアで成果を出せないからPMというのは印象として、PMでも成果を出せるとどうしてそう思ったかを自分の言葉で言語化してみてからでも遅くはないと思う。
PMは人気のない専門家だ。ミッションと責任が割に合わないと考えるエンジニアが多いからだろう。まっさらに一からPMに必要とされる幅広い知識を学ぶ必要があるし、それはエンジニアをやりながら、並行して身に付ける必要がある。
未経験のエンジニアに採算を求めるプロジェクトを任せるほど体力があれば良いが、通常はそんなことはない。
エンジニアの素養を気にするなら、キャリアをピボットする前にピボットしようとしている先の素養を並行して確かめた方が良いと思う。
その上で、覚悟を、もしピボットした後で道を間違ったと思ってもやり直そうと意思を持ってピボットしてはどうだろう。
