読者です 読者をやめる 読者になる 読者になる

ソフトウェア開発におけるリスクと居心地の悪さについて

アウトライン

  • ソフトウェア開発には,時間の見積も,できるかどうかすらもわからない,リスクのあるタスクがある
  • リスクのあるタスクには,逃げたり既存の工数などに載せないで,特別扱いしてちゃんと負担を減らしながらリラックスして取り組む環境を作るべき

はじめに

 何で自分がソフトウェア開発という分野に居心地の悪さを感じるのか考えていた.納期の短さが原因だけではないことは明らかである.やればできるし,ただそれだけだからである.それよりも,常につきまとう漠然とした不安が物事を見えにくくしている.

 特にインタラクティブ・システムや拡張現実感技術,コンピュータビジョン,機械学習などの分野は,まだ単にライブラリを持ってきただけ機械的にシステムを構成できる分野ではない.そうでなくても,ある程度大規模で複合的なシステムなら,バグ1つの解消にえらく時間がかかったりする.

 このように,ある機能を実装したり,バグを取ったりすることにかかる時間は,極めて流動的である場合があり,「本質的に不可能」なことすらある.これらは,いわゆる「遅れ」とは異なる.「時間をこれだけかければ解決できる」という見積にブレがあることではなく,道筋やゴールも確定していない状況がある.

 このため,ある種の機能を「工数」「見積」で管理されることが非常に嫌だ.余裕があっても納期が付いているだけで不安感を感じる.これをリスクの問題として,この居心地の悪さを解消する方法を考えていた.ここでは,アジャイルなどの具体的な手法からは始めない.往々にして形式的な本質をついていない,騙されたような結論になるためである.

測定・把握できない種類のものがリスク

 まず言えるのが,リスクを個人の能力の問題にしてはいけないということである.それを言ったら,生物たる人間そのものがリスクである.確かに,問題を発見して解決する「勘」めいたものや,選択肢などについては,能力は常に向上していくし,向上に努めないといけない.しかし,例えばあるリスクのある機能に習熟していても,「似たような機能でも本質が全く違い,どれくらいかかるか見当もつかない」ような仕事が降ってくる場合もある.その場合リスクが堂々復活する.

 また,「スプリント単位でベロシティを計測する」というのも,どうも隔靴掻痒のきらいがある.この方法では「どれだけかかったか」を綿密に計測することで「どれだけかかるか」を予測する.もしくは,機能を短い単位に分割してどこが時間がかかる部分かを判定する.しかし,リスクのある「小さい機能のパーツ」を判別しても,本質的にどれだけかかるかわからないものだとしたら,結局それはリスクのあるものとして残ってしまう.

 要は,測定や把握のしようがなく,やりながら霧を晴らしていくしかないというところに,リスクの問題がある.そこで霧が晴れたらもうリスクではない.しかし,晴れるまでは納期やシステム全体との関係にもがき続けることになる.そこに至って,リスクは「直面している人間にとっての」リスクとなる.

どうやっていくか

 リスクに向き合う単純な方法が「既存の工数/見積に載せる」ということである.リスクがあたかもなかったかのように工数を充てて,出来た/できなかったと言うことはできるし,しかし,スタティックな工数は思考停止に近いものであるし,例えば4倍時間がかかってしまいました!すみません!というのは工数の崩壊そのものだろう.

 次に挙げられる単純な方法が「リスクのあることをやめてしまう」ということである.「非常に難しいですね」でぶった切ってしまうことも可能ではある.しかし,リスクのあることをやることで,大きな問題を解決したり,価値を大幅に上げることが可能であろう.大半の場合そのためにリスクに立ち向かう.プロジェクトが滅茶苦茶になっている場合は知らん.

 こんなことをやっていてもしかたがないが,リスクそのものを減らす確固たる方法はないので,具体的に「リスクに向き合う人」の負担を緩和する方法について考える.もちろん,リスクが少ない部分をちゃんとこなしたり,コードやタスク管理を綺麗な状態に保つなどの外堀を埋める作業は前提である.

 1つのアプローチが「タスクのリスクを可視化する」ということだ.定量化は難しいだろうが,「このタスクにはリスクがある」というのを3段階で入力できるだけで,だいぶ変わる.主観的な指標であるが,工数の計測より優位性がある部分もあるだろう.また,これをうまく扱えるプロジェクト環境というのも重要なのだが,これはこれで深い問題なので取り扱わない.

 もう1つが,「失敗してもよい」環境を一部でも作るということだ.契約上でも管理上でもいろいろやりかたはあると思うが,「できなくても大丈夫なこと」に一定時間を割けることが重要である.そうすれば,少なくとも多少安心して作業に取り組める.アジャイルが優れているのはむしろこの点である.計測さえしていれば,うまくいかなくても一応継続はできる.まあ開口一番顧客に「できるかどうかわかりません」と言うのは不安になって当たり前なので,うまくコンセンサスを取れるとよい.

 酷いのは優先度をいじくって単純作業の優先度を上げてこの時間を奪うことで,本当にストップするので,それは諦めと同じである.あと「俺達は忙しいのになにできなくても大丈夫なことやってんだ!」とか言わせない.忙しいならちゃんと一旦止める.とにかく時間を割くことへのコンセンサスが重要である.

まとめ

 まとめない.アウトライン参照.