top of page

システム開発で丸投げは失敗への特急券

更新日:2022年5月13日

丸投げは楽です。ホームページ制作でもSEOでも丸投げは楽ちんであることは事実です。しかしシステム開発に関してはエンジニアの知識が無いとしても丸投げは絶対にNGだといえます。



【失敗例】専門家におまかせしたら本質的に違うものが出来上がってきた


自社に業務システム部が無かったり、小規模開発の場合に発生することが多いように見受けられます。


こんなケースがありました。


既存で稼働している社員の出張管理システムで新たにいくつかの機能を追加する開発において、規模感が1か月ほどと社内予想を行っていたためベテランの担当は要件を新人さんに伝えて新人さんの勉強案件としました。


新人さんは要件を取りまとめて要件定義書に落とし込みをした後、システム会社に発注することになりました。


ただ、この新人さんはシステムについての理解が浅く、営業マンが実際にシステムを使う状況などを学ばずに「システム」としてのみ考えていたため要件定義に使い方を考えた仕様が反映されていなかったのです。


打合せで修正することが出来ず、システム開発会社の担当者には、


「基本的なことは定義書にまとめたので後は専門家の方にお任せします」


と丸投げしてしまったわけです。



システム開発会社としては裁量を任されたと解釈し、設計、構築に取り掛かりました。


工数が1か月程度ということもあり、定期的な週1MTGなどは行わず発注からある程度の出来上がりでチェックするようなスタンスでの開発なのも不幸でした。


1か月が経過し、開発会社から構築が完成したので確認をしてもらいたいという依頼が入ったため、ベテラン上司と新人さんおよび開発会社の人間2名がオンラインで会議をすることになります。


そこで出来上がったシステムのデモを行った時にベテラン上司は驚愕することになったそうです。

なぜなら、要件定義でまとめていた内容から全く異なる仕様になっていたからです。





【失敗の理由】「普通なら」、「一般的な」といった相手に裁量を求めるような依頼方法はNG


機能それ自体は達成されていましたが使い勝手が全く変わってしまったのです。



詳しく書けないのが歯がゆいですが、営業マンがこれまでどのようにしてこのシステムを使っていたかを知っていれば、導線がそのようになるはずもなく、ベテラン上司としてはそのあたりは話をしなくても理解していると思っていたそうです。



ところがよくよく話を聞いてみると新人さんは出張管理システム自体を営業マンと同じ状況で使ったことが無かったのです。


システムとして理解はしていても使う人の立場での理解が無かったのです。



開発会社はいただいた要件定義から設計を開始しましたが実際に使う人のことは理解していないため「構築するシステムが最良である」ことを優先して構築を行っています。



構築されたシステムは最新のトレンドが取り入れられておりそれだけを見ればとても素晴らしい仕上がりになっていました。



ところが既存システムを使っていた営業マンからすると、むしろ使い勝手が悪くなってしまったのです。



ベテラン上司はそのあたりを熟知していたので、このまま実装させてしまったら営業部からクレームが来ることが分かっていたのです。


だからデモを見たときに驚愕してしまったわけです。



デモを見終わってすぐに開発会社に修正事項を出すから時間が欲しいと依頼し、新人さんとベテラン上司で導線の引き直しを行う作業にとりかかりました。



新人さんが陥ってしまった失敗の根幹にあるのは自分のわからない部分を相手に任せてしまったことです。



このような時、よく担当者はこんな発言をします。


「一般的に使われているような設計でお願いします。」


「見てもらえれば普通にわかると思うのでそういった流れでお願いします。」


「そのあたりはむしろ専門だと思うのでおまかせします。」



これ、システム開発では一番危ないです。



すべて、相手に任せてしまっている言葉なのです。



相手がシステムを最初から一緒に作り上げてきているのであったとすれば或いは、失敗しなかったかもしれません。



ただそれでも危険性は高い発注方法です。



使い方を考えた要件定義のまとめ方と、作りたいものが出来ればよい要件のまとめ方は全く意味合いが異なってきます。



システム開発に限らず、使い方を考えずにモノだけ出来上がれば良い、などといった仕事は無いと思っています。


作る以上、使い手がいるわけです。



使い手を考慮せずに出来上がってしまったシステムは必ずクレームになります。



丸投げは発注するほうの無自覚だけではなく、受ける側も困惑するだけではなく、余計な工数がかかる原因となります。



ちなみに弊社では


例題で出した案件ですが最終的に弊社で改修作業を行うことになりました。


過去に複数案件を手掛けており、ベテラン上司との間で意思の疎通ができていたこと、仕事の進め方がハッキリと見えていたことからリスクになりそうなところが会議で洗い出せたからです。



改修作業では直接の担当者が先の新人さんとなっていたため、まずヒアリングをしっかりと行い、どのようにシステムが使われているかをしっかりと文章化し、新規機能(といってもすでにできあがっていますが)がどのような状況で使われるのかをまとめました。


新人さんも失敗例があった後、自身でシステムを使ってみたようですがイマイチわからないようなところもあったため、お願いしをして営業部から実際にシステムを使っている営業マンに会議にご参加いただくようお願いをしました。



こちらで想定していなかった使い方があったりしたため、設計に盛り込み改修作業を行うことにつながりました。



改修作業は1か月弱ほどかかりましたが、問題なく納品にこぎつけることが出来ました。



今でも新人さんとは案件でご一緒しており、仕事の回し方なども理解できております。


bottom of page