納期順守を巡る問題
例えば、あなたが私と同じSEだとしよう。そして、あなたが何らかのソフトウェアを作ることを人に約束したとする。その際には、必ず「で、それはいつ完成するの？」と尋ねられるはずである。
その質問に対して、あなたは何を基準に納期を返答しているだろうか。多くの場合、それは周囲の評判への気遣いではないだろうか。開発チームのマネージャーも、プロダクトオーナーも、そして自分自身も、設定された納期どおりにソフトウェアを作り上げることで、自分たちがいかに優れているかを示したいと考えているからである。
このときに問題になるのは、あなたが、そのプロジェクトの難度について十分な調査をしていない状態で納期を提示してしまうことだ。ソフトウェア開発プロジェクトは大抵の場合、単体で進行するものではない。表面的には無関係に見える他のプロジェクトと依存関係や競合関係にあることが往々にしてある。そして、それが調査によって明らかになったとしても、あなたがいったん口にした納期が調整されることはほとんどないのである。
この段階になると誰もが気にするのは、ソフトウェアの出来栄えではなく、納期を守り、自分たちの面目を保つために何かを世に出すことである。本来リリースされるべき機能が実現されるかどうかはもはや重要ではなくなるというわけだ。もちろん、ワークライフバランスを考える余裕もなくなる。そして、上司の目に悪く映らないようにすること──つまりは、納期を守ることが開発チームのすべてとなる。
当然のことながら、このような状況で正しいもの（= 顧客のためになる成果）を開発できる可能性はまずない。ゆえに、開発チームと顧客の双方を傷つけてしまうことになる。
ここで公平を期すために言っておくが、ソフトウェア開発にスピードや短納期が求められること自体は必ずしも「悪」ではない。可能な限り短時間で出荷する必要がある場合もある。ただし、そうした後は一息ついて、溜めていたアイデアに取り組んだり、弱点を補うことに時間を費やすべきである。
納期を守ることだけが開発チームの最優先事項になること──言い換えれば、「納期駆動」で開発が行われることは、上述したようにチームと顧客の双方を傷つけることにつながる。そこで以下では、開発チーム（あるいは、開発チーム内の誰か）が「納期駆動」に陥りつつあることを示す10の兆候を紹介する。自分のチームで当てはまる兆候が多くなったら、即座に改善の一手を講じることをお勧めしたい。
兆候1: 時間外労働を定常化させているチームメイトが出始める
チームメイトが深夜あるいは早朝にソースコードファイルをチェックインしたり、プルリクエストにコメントをしたりすることがあるだろう。こうしたことが1～2回程度、不定期に行われたとしても特に問題はない。ただし、それを定常的に発生させているチームメイトがいるとすれば、その人は納期に追われ、かなりのストレスを感じながら日々の作業をこなしていると判断すべきである。このような状態にある人は、まず最善の仕事を行うことはできない。
【対策】
長時間労働を定常化させているチームメイトを発見したら、即座に連絡をとり、チームメイトの負担を自分で軽減できるのであれば、それを行い、できない場合にはチームリーダー（マネージャー）に相談するよう促す。私もマネージャーに相談した結果、納期が延長になったり、負担が軽減されたりと、窮地から救われた経験がある。
兆候2:「イノベーション週間」が先送り、ないしはキャセルされる
読者諸氏は、「イノベーション週間」という制度をご存じだろうか。アトラシアンでは「ShipIT（シップイット）」という名称で、かねてからこの制度を採用しているが、開発プロジェクトに日々追われているエンジニアにとって、チームレベルで頭をリフレッシュし、想像力を磨ける貴重な一週間と言える。
例えば、この一週間を使うことで、ソフトウェア開発者は、日々の仕事からいったん離れて、新機能のアイデアをベースにしたプロトタイプを作成したり、新しいオープンソースソフトウェア（OSS）ライブラリを試したりすることができる。また、プロダクトオーナーも、バックログを再調整して要件を具体化する機会が得られる。さらに、デザイナーは次の作業のコンセプトを、時間をかけて描くことができる。
イノベーション週間が常に新しいアイデアをプロダクト化するために使われるわけではないが、すでに多くのテクノロジー企業がこの制度を取り入れている。ちなみに、アトラシアンの主力製品の一つであるサービスデスク＆ITサービス管理（ITSM）ツール「Jira Service Desk（現在はJira Service Management）」は、イノベーション週間によって生まれたプロダクトである。
いずれにせよ、イノベーション週間がエンジニアリング文化の一つとして組み込まれている場合、このイベントが、業務上の納期を理由に延期されたり、キャンセルされたりすると開発チームの士気に影響する。また、チームをまたいでこのイベントが行われる場合、革新的なプロジェクトが生まれるチャンスにつながることが多いが、あるチームの参加が納期を理由に遅れたり、キャンセルになったりすると、そのネガティブな影響はより強くなり、失敗に終わることが多い。
【対策】
イノベーション週間と、そこから生まれる成果を称賛する文化を構築する。その価値に対する理解がマネージャーやプロダクトオーナーに浸透すると、イノベーション週間を軽んじるようなかたちでプロジェクトの計画や見積もり、目標を立てるようなことをしなくなる。
兆候3: 技術的負債を返済するためにイノベーション週間を使ってしまう
イノベーション週間は、あくまでもイノベーションを創発するための場である。その場を現業の技術的な負債の返済に使うこと──例えば、バグのフィックスなどに使うといった行為は許されないことであり、そのような技術的負債の返済は、プロジェクトの当初の計画や見積もり、ロードマップに組み込むべき事柄と言える。
にもかかわらず、開発チームが「納期駆動」に陥ると、イノベーション週間を当たり前のように技術的負債の返済に使い始め、「バグ修正に1週間を使ったので、しばらくは開発に専念しよう。バグ修正は次のイノベーション週間でまとめて行えばいい」といった発言すら聞かれるようになる。
ただし、そのようなプロジェクトの進め方は明らかに間違っている。しかも、リリースごとに発生する固有のバグを適宜修正しながら開発を前に進めていかないと、ソフトウェアの停止といった深刻なインシデントやチーム間での摩擦につながるリスクが高まるのである。
【対策】
技術的負債を返済するための時間はすべてプロジェクトの計画に組み込むようにする。スプリントにつき、ほんの少しの時間だとしても、健全なプロダクトの創出へとつながっていく。
兆候4: 開発のスコープが交渉不能になる（ないしは、市場価値の高いスコープが切り捨てられる）
納期に間に合わせるために開発のスコープを縮小すると、結果的にソフトウェアの市場価値が失われることになる。さらに危険なことは、納期を守るために、開発のスコープを交渉ができない状態で固定してしまうことだ。
こうすることで、開発チームは、自分たちが開発しているソフトウェアが自分ごとであるという意識を持てなくなる。また現実的にも、スコープを調整する権利が開発チームにないソフトウェアは、そのチームの持ち物ではないと言える。このような状況で優れたソフトウェアが開発されることはまずない。
【対策】
上記のような状態に陥らないようにするには、次の2点（あるいは、いずれか）を、時間をかけて遂行する。
- プロジェクトの内容と開発すべき機能については、十分な時間をかけて調査・検討し、実現可能なスコープの範囲と、それに基づく妥当な納期の範囲を決める。
- プロジェクトの始動に際して、優先すべき事柄をトレードオフの関係にある要素（例えば、使いやすさとスケーラビリティ、など）を勘案しながら確定し、チーム内でコンセンサスを取り、かつ、スコープを維持するためにチームメンバー各人が、自律的に判断が下せるようにしておく。
兆候5: 販促上の理由からソフトウェアリリースの納期を決める
製品のマーケティングチームやPRチームは、社内でのアピールや販促上の適切な時期に新たな製品や機能を発表したいと常に望んでいる。ゆえに、新たな製品や機能の開発が遅れて発表の時宜を逸するたびに苦痛を感じる。
それに対して製品の開発チームは、開発のスケジュールが自分たちの一存では決められないこと自体に苦痛を感じる。
そして、顧客たちは、ソフトウェアの到着が遅れても苦痛を感じるし、品質が悪くても苦痛を感じ、常に約束の納期どおりに、自分の欲する品質のソフトウェアが届けられることを望んでいる。
【対策】
製品リリースの時期を巡り、マーケティング・PRと開発、そして顧客の要求との間にある種のコンフリクトが発生するのは仕方のないことで、それを抜本的に解決する良策はない。各者の苦痛を最小限に抑える唯一の方法として考えられるのは、製品／機能の提供時期について一定の幅を持たせて外部にアナウンスすることではないだろうか。
以上、チームが「納期駆動」に陥っている10の兆候の内、まずは5つと各対策のヒントを紹介した。後編の記事では、残りの5つの兆候と、より根本的な対策について触れる。
