はじめに

クリスマスイブですね！！！

Ateam Lifestyle Inc. Advent Calendar 2021　24日目は、エイチームライフスタイル CTO室室長の @tsutorm がお送りします。

工数が足らない！！

ソフトウェア・Webサービス開発に仕事として携わり初めて、今年で20年になりました
いやー意外とあっという間でしたね！

そんな20年間に渡って、私の周囲に大なり小なり付き纏っている言葉があります。

"工数が足らない"

21世紀にもなって、多少変わるかなと思いましたが、現在も変わらずあちらこちらより聞こえてきます。意外と変わらないもんですね。みなさんの周りではいかがでしょうか？

散々論じられている話ではありますが、2022年に向けこの"工数が足らない"について、私なりに原因の考察と改善の提案をしていければなぁと思います。

注意

全体トーンとして少々ソフトウェアプロジェクトとしてはネガティブなネタを扱っていますが、現職のエイチームライフスタイルに固有の問題として頻発していて困っている話ではありません

特に次項で挙げる問題点は前職の受託開発プロジェクトでの経験をもとに記載しています。

"工数が足らない"事による問題

ソフトウェア開発プロジェクトにおいて"工数が足らない"ことで様々な問題が発生します。
よく見かける問題を以下にピックアップしてみました。

1. 想定したリリース日からの遅延

工数が足らなくてリリース想定日にリリースできません！！

一番多いのはこれでしょうか。

開発が想定期日までに終わらない事で、リリース日の変更を余儀なくされます。ステークホルダーからの信用を失ったり、他の計画（主にマーケティングやブランディング、予算）との整合性は失われ、各方面との調整を余儀なくされます。

ですが、変更された計画も当初計画を引きずることがあり、十分に余裕をもった期限が再設定されないことも少なくありません。また、場合によっては原因の報告や謝罪に追われることもあるでしょう。

そして思うのです。**工数が足りていればこんなことにはならなかったのに・・・**と。

2. 時間外労働の増加による過労

工数が足らなくて残業でカバーするしかないんです！！！

主に、1を挽回するためにということが多いですが、なんとか挽回するために残業などの時間外労働でカバーしようとした結果、開発メンバーに過労という形でしわ寄せがやってきます。
平日毎日遅くまで開発をする。場合によっては土日も返上でリカバリなんてことが常態化した結果
疲労からくる判断の遅れ・間違いや心身の不調。最悪退職なども含めたメンバーの離脱になんてことも。。。

そして思うのです。**工数が足りていればこんなことにはならなかったのに・・・**と。

3. 品質の低下

工数が足らなくてテストする余裕がないんです！！！

ソフトウェア開発における品質は、それこそ論じようと思うと１本どころじゃないくらい本が書けてしまうので、細かく解説は割愛します。t_wadaさんの質とスピードとかを是非御覧ください。

工数が足らない局面では、外部品質や機能要件といった一定エンドユーザーの目に触れる部分に対しては十分になるよう保全の努力がされることが多いですが、工数が足らない局面では、内部品質や非機能要件が見過ごされる場合が多いです。

結果、リリース後に想定したパフォーマンスが十分に出なかったり、予期せぬ入力による予期せぬエラー、権限で見えない筈の見えてはいけないがなんか見えるなどの不具合、それを治そうとしてもプログラムの見通しが悪く、原因調査と修正に時間がかかるがリリースの圧力はより強く１，２へ・・・なんてことも。

そして思うのです。**工数が足りていればこんなことにはならなかったのに・・・・**と。

そもそも"工数"とは何で、何と比べて足りないのか

他にもいっぱい問題が起きるんですが、もう書いてて自分でおなかいっぱいです。
工数が足らないばっかりに非常に不幸な目に合うことがよくわかりました。
工数は足りている方が良さそうですよね。

そうですね。足りていないなら足しましょうか。そう、足しましょう！
足りていないだけ**工数とやらを足しましょう！！**そうすればこれらの問題はすべて解決・・・

とはならないのは皆さんもご存知の通りかと思います。

不思議ですよね。

そもそも"工数"とは何なんでしょうか。

また、足りる足りないで表現できるということは、一定の"量"を扱っている筈です。
それはなんの"量"なんでしょうか。
また、何と比べてどれくらい足らないのでしょうか。

工数は開発の原材料？

そもそも開発・プログラムとは何でしょうか。簡単なプログラムを書いてみましょう

console.log("Hello World")

このプログラムを書くのに実際に掛かった量で表せるものはなんでしょうか。タイピングの量？PCが消費した電気の量？私がプログラムに費やした時間？

Wikipediaを引用すると、一般的な工数の定義は以下とのことです。

工数（こうすう）とは作業量を表す概念のことである。製造業を中心に、全ての産業で使われる概念である。
本来は人間に対して使われるが、工作機械やロボットなどの自動化設備に対しても使われることがある。

工数を次元で表すと、[工数]=[時間]×[人]となる。工数を表す単位には慣例的に秒、分、時、日など時間の単位がそのまま使われる。人月など“人”を付ける場合もある。(中略) 工数は、見積りや工程設計によって計算される。

前述の話と組み合わせると、私が10秒程度で作ったこのプログラムは10人秒の工数が掛かったと言えるでしょう。
工数というのは、開発活動に要した時間の量を指しているということでしょうか。

工数が足らないというのはまだ完成してない段階で使われる言葉です。未完成の段階では計画作業量 > 実績作業量となるので足りないのは当たり前です。そうじゃないですよね。

コンソールに"Hello World"って表示するプログラムなら5秒で書けるだろ！としたとき、計画 5人秒となりますが、3秒経過した段階で"やべ残り2秒じゃ流石に時間が足らなかったか"と気づいたときに、"工数が足らない" という話になるのです。

つまり、計画の工数に対して、実績の進捗を差し引いた計画許容残工数が、必要と見込まれる残工数に対して足らない。という話を丸めて工数が足らないと言っているのです。

工数を足せない理由

それでは前述のケースを想定して簡単に工数を足せない理由について考えてみましょう。

本来10人秒必要
計画 5人秒と見積もった
3秒経過したが、残り2秒では時間が足らないことが予想される

このHello World表示プログラムの**"工数が足らない"**を解消するにはどうすればいいでしょうか。

時間は足せない

実績は10秒というのがわかっているわけですから、残り 2秒で 10-3=7秒分の仕事をすれば解決しますね。

2秒で7秒分の仕事ができるでしょうか。もっというと、2秒を7秒に拡張することは可能でしょうか

そんなことができるのは精神と時の部屋くらいで、今の人類には無理です。

もう一度言います。時間を足すことは無理です。無理なんですよ。

現実を見ましょう。

人は足すのは効果的ではない

それでもなんとかしたいですよね。

工数 = 時間 x 人と定義される計算式の内、時間が固定的であるなら、もう１つの要素、人を足すことは可能そうです。こちらはどうでしょうか。人を足せば時間は変えられなくても工数は増やそうですね。これで間に合うでしょうか。

もうこれは皆さんおわかりの通り、大変有名な名著「人月の神話」で語られる**ブルックスの法則**です。

遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである

先程のケースですと、残り2秒で7人秒の工数が必用なので、3人増えれば工数としては (1+3)×2=8人秒確保できます。分担すればなんとか2秒で完成するでしょうか。

「console.log("Helまで終わってんだよ！俺が残りのlow って書くから、お前はWorldってかけ！そしたらくっつけて完成だから！！！」ってやってる間に2秒終わりますね。

人は足せますが、効果的ではない局面が多いということです。

工数が足ることは無い

残念です。工数が足らない状況は理解できますが、工数を足して解決することは難しいと言わざるを得ません。

だから、"工数が足らない"と100万回唱えても、何も解決しないのです

では、工数が足らない局面で、何を解消すべきなんでしょうか。

工数が足らない時に、解決可能な取り組むべき問題 は工数そのものとは別にありそうです。

例示した事例の残り7人秒の例では流石にやれることは限られますが、現実は数日・数週間・数ヶ月といった時間軸で語られるはずです。効果的な対応はどのようなものがあるでしょうか。

"工数が足りない"からの脱却法

やらなくても良いことをやめる/やらない

即効性があって一番効果的なのがこれです。

そもそも Hello Worldって表示するプログラムなんて死ぬほど存在することが想定されます。Githubで検索してみたら1,716,309リポジトリ見つかりました。自分で作る必要は本当にあるんでしょうか。

そもそもHello Worldって表示して何したいんでしょうか？その開発をやる意味はどの程度あるのでしょうか？

リソースは残念ながら限られています。限られたリソースの中で最大限効果的なことを選ぶ事が現実には必要です。

プロジェクトの鉄の三角形という概念をご存知でしょうか。リンク先では「スコープ」「リソース」「時間」となってますが、「実装すべき機能」「開発に使えるリソース（お金）」「時間」と考えると、時間とお金を固定化した場合、実装すべき機能数を調整するしかないのです。

また、開発の結果得られる価値を予め推定や評価できるのであれば、今やらなくても良い開発をやらないということで劇的に改善することが出来ます。

やらなくても良いことをやめることがとても重要なのです。

ちなみに、やらない判断をしたけどアウトカムが同一の場合、10秒掛かっていたものが0秒で終わるんで、アウトカムに対しての生産性はなんと無限大です。

計画は不十分であるという前提でプロジェクトを運営する

やるべき価値がある開発だったとしましょう。

Hello World程度のプログラムでも正確に見積もれるでしょうか。
見積り通りに開発プロジェクトは推進するんでしょうか。
実際は様々な要因で思い通りに行くことは少ないです。

間違いの無い計画を立てて、その計画通りに仕事を終わらせるのは大変難しいのです。

PMBOKも第7版で不確実性に適応する事を重視するような変更が入ったように、計画は不十分あることを前提に見えないことや問題が起きそうなことを早めに検出していく活動をすることが重要です。

開発に使える時間の割合を増やす

時間を増やすことは出来ません。できるのは割合を調整することです。1日の内、何割位の時間を開発に活用できているでしょうか。

不要なミーティングは減らしましょう。割り込みも減らしましょう。仕事の手戻りも減らしてとにかく手離れさせましょう。といった地味な活動が意外と複利的に活用可能な時間を増やす効果を産んでいきます。

LeanとDevOpsの科学でも、変更失敗率を改善し手戻りを減らす事でリリース速度を上げ高速にデリバリできることが説明されています。

とりあえず/一旦という仕事の仕方は、手離れするかどうかをちゃんと考えてやりましょう

また、リグレッションテストの自動化は特に寄与率が高いと思います。メルペイさんのリグレッションテストの自動化を段階的に実装した話 – 高野純知【Merpay Tech Fest 2021】などが参考になります。

品質とスピードは両立できるのです。こういった活動に少しづつでも時間を割く意思決定をしましょう。

知識・能力をチームとして獲得して実現可能性を上げる

やる価値があって、不確実性を踏まえたプロジェクト推進をして、それなりに時間を確保できていたら100%大丈夫でしょうか。

そもそも、**1度もやったことない事を正しく見積もることはできません。**やったことないですからね。

Hello Worldの例で言えば

「コンソールに表示する」方法を知らない人にとっては、3分あっても足らないかもしれません。
そもそも「プログラミング言語とはなんぞ」という人からしたら30分あっても独力では難しいかもしれません。
でも、1度やったことある人からしたら、おそらく10秒程度で終わるでしょう。

知識や能力によって実現可能性は大きく変化します。逆に言うと、**知識や能力が実現可能性を大きく高める。**ということです。

そのため、

デキる人(テックリード等)を早めに入れておく
レビューやペアプロなどチーム全体の知識や能力を高める取組みをする

ことが重要です。

また、自己研鑽も大事です。利用しているライブラリのContributorをフォローして情報を得たり、実装で必要なライブラリのコードをちゃんと読んだり、レビューやペアプログラミングを依頼して自分にはなかった知見を得たりということは、遠回りのようですが自分の実現可能性を上げます。そのためには

作業で自分の時間を100%食い潰す仕事の仕方はやめる

です。がんばって学ぶ時間を確保しましょう。

まとめ

"工数が足らない" という状況は残念ながら発生する
"工数を足す" という解決策は無い
"工数が足らない" から脱却するために
- やらなくても良いことをやめる/やらない
- 計画は不十分であるという前提でプロジェクトを運営する
- 開発に使える時間の割合を増やす
- 知識・能力をチームとして獲得して実現可能性を上げる

という地味ーな活動が重要じゃないでしょうか。というお話でした。

文字ばっかりでした

終わりに

明日は @masatomasato1224 さんが〆の ShallowDive Serverless Stack を投下してくれるようです！良いクリスマスを！！！