第24話:発注者責任とイニシアティブ

発注者責任とイニシアティブ

 

同窓会の翌日、2月24日(月曜日・祝日)。もう一泊する希望に佐々木は、前日遠藤から聞いた話をかいつまんで話した。
人材がスキルを磨きながらキャリアアップしていく、雇用の流動性が高い米国らしい話だね、と希望は言った。
「希望は、アジャイル開発、っていうのを聞いたことあるか?」
「もちろん。私の会社では全部がスクラムによるアジャイルよ。今どきウォーターフォール型開発はやらないよ」
「そうか」
「まだリリースされて日が浅い技術を使ってプロダクトを企画するときは、利用者がどう思うか、なんて目の前に物がないのに想像もつかないでしょう。机上で、事前にぜーんぶ起こり得ることを考えてから、実装するなんて無理よ。まず、ユーザーが感触をつかむ画面やデザインを作ってみて評価する、そして次のバージョンに反映する。そういう風にβ版を改良し続けていきながら、不確実な要素を徐々に取り除いていく感じね」。
希望は、ベンチャー企業では、このようなアジャイル開発が普通であると言った。
「システムに完成形、ってそもそもあるのかしら。ユーザーの要求も、時間とともに変わっていくのが普通じゃない」
「うーん。そういうアジャイル的なやり方をすると、要求がいつまでも収束しなくて、雲をつかむような話にならないのか」
「そこでね、問題を分解するの。部分的な問題に小さく分けて解いていく、という考え方ね。ウォーターフォールだと、机上で全部設計して、開発、テストでしょ。大規模な開発になれば、ユーザー企業側は開発したシステムを受け入れテストの段階になるまで、本当にオーケーできるか分からない。それまで不安じゃない?」
「そう、その不安が的中してね・・・」
希望は尋ねた。
「呉服の桐生で導入するのは、CRMパッケージソフトウェアなんでしょ」
「そう。今回は、いわゆるPaaS(Platform as a Service。パース)というものだ。部品の組み合わせによって、企業側の業務仕様に合わせて導入できる柔軟性が特徴だ。それでも現場の要求に合わない部分は、カスタマイズ開発で対応させるというやり方なんだ」
「それならパッケージソフトウェアに合わせるのが定石よね。そうすると実装が少なくなる分、アジャイルの速度が増すはず。カスタマイズは最後の手段くらいに考えていかないと」
「確かにそうなんだが、現場で働いている社員が、既存のプロセスを変えるのを嫌がるんだ」
「でしょうね・・・。でもそれを変えるのがリーダーシップというものだけどねぇ」
佐々木は二の句が継げなかった。
その夜、寝床でひとり、佐々木は、プロジェクトマネジメント要件定義について、希望や遠藤との会話を反芻していた。いくつか共通する言及や指摘があった。
1)発注者と受注者と間で結ぶ不明確な請負契約の妥当性
2)要件定義の丸投げを含む、受注者への依存と責任の押し付け
3)一年を超えるウォーターフォール型開発における要求変化のリスク
4)呉服の桐生でイニシアティブをとれる、経営、業務、ITの視点を持つ人材の育成
4つめの呉服の桐生社内における人材育成は、一朝一夕にはいかない。人事評価制度や労務管理を含めて上層部の戦略的な判断にかかわってくる。従業員の同意が必要で、今すぐ変えられるわけではない。ならば今、動けること、できることは何か。
(開発方式を、ウォーターフォールから、アジャイルに変えてみるか)と佐々木は思った。新たな情報システムのイメージを業務部門や経営層に伝えるために、ある程度動くものを作って見せることで、現場の要求を早期に洗い出す。協力が得られれば、要件を固めることができるかもしれない。
そうなると、日比谷ソフトウェアとの、いわゆるSI契約、請負契約も見直すことになるだろう。SI企業におんぶに抱っこ、で進めるわけにはいかなくなるからだ。その代わり、開発が失敗したら、SI企業に責任を押し付けてしまえ、というこれまでの暗黙の慣習、免罪符は使えなくなる。なぜなら、自分たちの情報システムだから。その開発リスクを発注者自ら負うのは必定だ。
(請負契約を、準委任契約に切り替える、という提案をしてみるか)
システム開発には、大きく自社での開発と、ベンダーの請負による開発がある。前者の自社開発が明らかに主体的な開発となる。ただ、組織内の要求が曖昧模糊として、さらに技術の蓄積が組織にない場合、すべての工程(フェーズ)を自社開発で実施するのは難しい。そこで、ベンダーに一部の工程を協力してもらう。それが準委任契約である。
準委任契約をするとすれば、どの工程か。それは主に設計と開発、だ。呉服の桐生に乏しい技術力を、日比谷ソフトウェアから借りたい。他方、要件定義についてはすべて自社で行うことにする。振り返るとこれまで行った呉服の桐生のITプロジェクトにおける要件定義とは現状の分析にとどまることがほとんどだった。協力を依頼するベンダーも現状の当社の業務の仕組みや事務のルールの理解に努め、それを新たな情報システムに置き換えることで省力化、効率化を図ることが主な役目だった。ところが、今回のCRM導入はそうではない。自社にとっても未知なる領域だ。ビジネスモデルもルールもまだなく、前例のないところから作らなければならない。ベンダーにそれを委ねるのは筋違いだ。にも関わらず、日比谷ソフトウェアに任せきりだった。前田や加藤らのチームが各部門のビジネス担当者にヒアリングを行い、その業務内容や課題をまとめる方式であった。それでは現状のビジネスの殻を破ることはできない。もうこの方式では、うまくいく気がしない。
準委任契約にすると、プロジェクトの主体は、呉服の桐生になる。そして社内に不足している人材・技術力をベンダーに借りる、というスタンスを明確にする。立場上、プロジェクトマネージャーは、佐々木になり、それを補佐するプロジェクトマネージャーとして、日比谷ソフトウェアの加藤、前田になるだろう。ただ、こうすることで呉服の桐生においては、上流工程における人材の不足を補い、プロジェクトを通じて育成を促す効果が期待される。
(準委任契約にすると、現場の参画意識が高まり、結果的にプロダクトの品質つまりユーザーの満足度が高まるとも言われる。やったことはないが、失敗リスクも下げられるかもしれない。契約に関する問題を本質的に改善できるかもしれない)
ただ、アジャイル開発も準委任契約も佐々木には経験がない。日比谷ソフトウェア側に誰か知見を有する人がいるだろうか? 週明けにも加藤に尋ねてみよう。

←第23話:アメリカから来た旧友 第25話:褪せない着物の魅力→

ページ上部へ戻る