はじめに
このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。
ついこの間、その新会社で、PM的役割をこなす社員を対象に「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。
ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰かが、壇上に立つ法務部の人間に、こんな質問を投げかけました。
「たまにお客さんから『アジャイルで開発したいんだけど、契約は一括(作成請負)にしてほしい』って言われるんだけど、こういう場合はどうしたらいい？」
あまりに驚いたのでその後の経緯をあまり覚えていないのですが、確か壇上の人間には答えられず、会場脇にいた講師役社員の上司にあたる人物が、「契約をできるだけ細かく区切るしかない」みたいな回答でその場は収まったような記憶がおぼろげながらにあったり無かったりします。。
そのやり取りを聞いていたオレは、「どうしたらいい？じゃねーよ！契約以前にやること山ほどあるだろうか！！」と怒鳴りつけたくなるところでしたが、この場は法務研修、アジャイルの議論をする場ではない、とそっと胸の内の矛を収めた次第です。
今回のQ&Aで出てきた、客からの「開発をアジャイルで」「でも契約は一括で」という要望は、いったい何が問題なのでしょうか？
開発費用が高くなる
問いに対して法務部の上役が回答した「契約をできるだけ細かく区切るしかない」は、おそらく開発プロセスに「スクラム」を採用して開発を進めることを想定して言ったのでしょう。巷では昨今どうやら「アジャイル」＝「スクラム」というイメージが定着しているようなので、ソフトウェア開発を主務としていない法務部の人間がこう勘違いしてしまうのは、まぁ止む無いことだと思います。(質問してたヤツは絶対許さん！)
スクラムでは1イテレーションの開発対象(タスク)を確定すると、基本的にそのイテレーションの最中はタスクの変更は行いませんので、イテレーション単位で見積を作成しその都度契約を行うことは、まぁ可能か不可能かでいえば可能でしょう。
でも、契約作業にかかる工数は、非常に膨大です。見積を作成して、利益乗せて、正式な見積書作って、顧客側企業内で稟議通して、発注して。どんなに早くても2～3日はかかるでしょうし、1週間～10日はかかるのがザラ、というのがオレの個人的な感覚です。ところが、スクラムのイテレーションは、長くても3週間、短いところでは1週間というところも多いです。1ヶ月のイテレーション期間、というのはオレは今のところ聞いたことが無いので、少なくとも単月契約よりは短いスパンで契約作業が強いられることになります。これをやるのは相当シンドイですよ？
SIerサイドは契約作業にかかる工数を明示的に顧客に請求したりはしない(「見積は無料」という悪しき文化が定着している)ので、開発工数のいづれかにまぶして請求することになるのでしょう。結果、開発工数は多くなり、費用も高くなる。「アジャイルで開発する費用」として見込んでくれているならいいですが、費用が高くなることを顧客サイドは了承してくれているのかは甚だ疑問ではあります。。
スクラムのメリットが失われる
またもや「顧客のいうアジャイル開発」＝「スクラム」という仮説に基づいて弁を進めます。
以前たしか、原田騎郎さん(「カンバン仕事術」や「ジョイ・インク」「スクラム現場ガイド」らの訳者のお一人)がこんな事をSNSでおっしゃられていたと記憶しています。(ニュアンスが異なっていたり、そもそも発言者が原田さんじゃなかったらスミマセン)
「スクラムは開発チームにマーケティングを取り入れるための開発プロセス」
そもそも開発対象にブレが無かったら、ウォーターフォールで開発した方が楽ですし確実です。そうではなく、市場やユーザーのニーズに対応し随時開発の方向を見直す必要があるからこそ、スクラムでイテレーションまわして開発する必要があるのです。*2
イテレーションごとに契約を行うことによるオーバーヘッド増加について前述しましたが、費用だけでなく開発スピードにも弊害が生じます。仮に、イテレーション期間を3週間として設定し、契約手続きに毎回1週間必要だとすると、最低でもイテレーション開始2週間前にはそのイテレーションで開発する対象を確定し、見積を開始する必要があります。結果、実質1ヶ月強も開発対象を変更することが出来ないわけです。前イテレーションで作ったものが気に入らなかったとき、顧客側はどうするつもりなんですかね？ SIer側に無理を言って強引にねじ込むのでしょうか？ それとも泣く泣く我慢して次の機会を待つのでしょうか？
また、一括(作成請負)契約にする時点で、顧客側の担当者がどの程度このプロダクトにコミットする気があるのかが気になります。理想としてはプロダクトオーナーとしてフルタイムをプロダクトにコミットするのが望ましいですが、そこまで行かないにせよ、ある程度開発サイド(チーム)と対話しやすい距離にい続けることは非常に重要です。それにも関わらず、開発を発注した時点で要件をすべて伝えた気になり、以降をSIerに任せきりにするつもりなら、そもそもスクラムで開発する意味は皆無でしょう。開発契約を一括にしたい理由が、値段を先に決めたい・社内稟議を通しやすくしたい のであれば、心情的には理解はできますが、単にITに関わる作業を丸投げしたいだけであれば、おまえちょっとチャランポラン過ぎないか、と思わなくも無いです。
客がそもそも「アジャイル」が何なのかを分かっていない
だいたいにおいて、「開発をアジャイルでやりたい」とか言い出す輩ほど、アジャイルのことを何も分かってないケースが多いです。
そもそも「アジャイル開発」などと言うものは存在しません。「アジャイル(agile)」は「俊敏な」「素早い」「小回りのきく」といった意味を示す形容詞であり、「アジャイルな開発」というものはあっても「アジャイル開発」という開発手法や開発プロセスがこの世にあるわけではないです。アジャイルソフトウェア開発宣言(アジャイルマニフェスト)とその背後にある12の原則に沿う開発プラクティスがいくつも存在し、それらを総じて「アジャイル」と呼ばれているのに過ぎないのです。
前述のように「アジャイル＝スクラム」のイメージを持っていてくれているならまだマシですが、そんなレベルにさえないことが残念ながら大半のようです。
一年ほど前、「アジャイルがダメだと思う7つの理由」について議論する会というイベントが開催されました。その3年ほど前に鈴木雄介さんが問題提起した「アジャイルがダメだと思う7つの理由」について、もう一度議論してみようというのがイベントの主な目的。
この会でオレは「6.手段が目的になっている」の議論の場のファシリテーターを担当しました。アジャイルな開発を実施する上で「Don't do Agile, Be Agile.」(アジャイルをしようとするな、アジャイルであれ)という有名な格言があります。この格言の指摘にもあるように「アジャイル開発をすること自体が目的になっていないか？」というのが、この議論の場の主な議題。もっともこのイベントの参加者はアジャイルな開発に熟練しており、さすがに手段と目的を履き違えているような方はお一人もいらっしゃいませんでしたが、一方で面白い話が議論の中心になりました。
「最近は顧客から『アジャイルで開発してほしい』と言われることが多い」
冒頭のうちの会社の話とまるで同じです。が、でも詳細を聞いていくと、アジャイルで開発してほしいと言ってきた顧客の、実際の要望はまったく違うようです。
当たり前ですが、開発の本質はアジャイルにしようが何も変わらないので、アジャイルな開発手法に変えても吉野家のごとく旨く早く安く開発対象が出来上がることはありません。普通に考えれば当たり前なんですが、アジャイルという言葉がIT業界に定着した今、ユーザーサイドにはそれがバズワードとして広まり、背びれ尾びれが付いた状態で、まるで魔法かなにかのように認識されているのでしょう。前述のイベントの最後に自分たちの議論の場のまとめを簡単に発表したのですが、まるで童話の「オズの魔法使い」だなと思い、皮肉を交えて以下のように紹介したところ、会場からは大爆笑を頂戴しました。笑い話で済めば幸せだったのですが、残念ながらこれが今のソフトウェア開発の現実のようです。
「『アジャイルやっている』と言うと愛だの勇気などを要求されることがあります」 #アジャイルがダメだと思う7つの理由
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2016年5月18日
顧客から「開発をアジャイルで」「でも契約は一括で」と言われた時にすべきこと
では、SIer側は「開発をアジャイルで」「でも契約は一括で」と顧客に言われた場合、どうすべきでしょうか？ オレのたしない頭で3案考えてみました。
1.アジャイルに何を求めるのかを確認する
要は顧客に「お前の言うアジャイルってなんなんだ？」と確認する、ということです。コストダウンがしたいのか、なんとなくモノをヨロシク作りたいのか、要件があいまいでフワフワした状態から開発を始めたいのか、流行だからなんとなくやってみたいのか。顧客にこんなことを聞くと失注するのでは、と不安に思うのかもしれませんが、そこをあやふやにしたまま契約しても、双方ともに不幸を見るだけです。勇気を持って、まずは要求を明確に確認するところからはじめるべきでしょう。間違っても「アジャイル＝スクラム でやりたいのね」などと早合点しないように。
2.準委任(SES)契約を勧める
スクラムで開発することになった場合、納品物を最初に確定する一括(作成請負)契約はとてもリスキーです。契約期間中に数イテレーションを挟めば、最初の要求と異なる成果物になる可能性が十分ありえるからです。であれば、契約物を確定しない準委任(SES・作業請負)契約を勧めるのが望ましいです。準委任契約は成果物を保証しないので、顧客から嫌がられる場合が考えられますが、であればスクラムで開発を諦めるか、選択を迫ってみるべきでしょう。
3.一括契約ながら成果物をあいまいにしておく
スクラムで開発することは断れない、でも一括契約も避けられない、失注もしたくない。そんなジレンマを抱えた時の最終手段です。開発期間と案件参画人員数を単純に掛け算して工数を算出し、それを元に見積を作成、しかし成果物はなるべく明確に定義しない、という契約にします。一括契約ながら中身は実質準委任契約、みたいな契約にすることを目指したものです。顧客が「値段を先に決めたい・社内稟議を通しやすくしたい」という目的で一括契約を望んでいるのであれば、ある程度実現性はあるのかな、と思います。ただ、成果物があいまいになる都合、開発中に問題が発生して、最悪裁判沙汰になったりした場合には、結構大変なことになりそうな気がします。成果物とは異なる作業エビデンスを随時残しておく必要は出てくるかもしれません。
おわりに
色々書きましたが、こういうノウハウを持って対処していらっしゃる企業さんはきっといるのでしょう。どこかでそういうのを共有出来る機会があるといいんですけどね。
今オレは現場に出ていて、顧客企業内で働いています。この現場では、一応ウォーターフォールプロセスで開発しているんですが、要求はプロダクトバックログで管理して、都度(3ヶ月単位)でビジネスサイドからの要望を見直して開発対象を決めていたりと、ちょっとスクラムっぽいところもあるんですね。こういうやり方もあるんだなぁと密かに関心してました。
ちなみに今のオレの契約は準委任……いや、上司からは時間清算って強調されたなぁ、時間に見合った成果物が出せないとすぐリリースされるから、そうならないようにちゃんと働けよと散々釘を刺されました。ハーイ、気をつけマース。
上記に書いたような内容は、以前SlideShareに資料をあげてますので、良かったらそちらもご覧ください。