HOME > ソフテックだより > 第58号(2008年1月23日発行) 現場の声編「ソフトウェア外注管理の難しさ」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ


ソフテックだより 第58号(2008年1月23日発行)
現場の声編

「ソフトウェア外注管理の難しさ」

1. はじめに

ソフテックだより第8号で「外注委託を成功させるための工夫」についてご紹介させていただきましたが、今回は実際の外注管理の体験談を元に、ソフトウェア外注管理の難しさについて書きたいと思います。

2. 現在行っている開発の外注管理について

2006年の暮れに、お客様から大規模システムの開発依頼がありました。その頃、社員は別案件の開発で埋まっており、「人が足りないだろうな」と思いつつ、見積もってみたところ、指定納期を守るには常時8人以上の参入が必要な開発であることが分かり、明らかに人が足りない状況でした。お客様には仕様の変更や納期の相談を行いましたが、これといった打開策はなく、お客様からは「協力会社を使ってでも、なんとかしてほしい」との要望がありました。社員はほとんど確保できなかったため、開発のほとんどを協力会社にお願いして開発せざるを得ない状況になりました。以前に開発をお願いした協力会社などにあたり、なんとか人が揃い、開発ができる状況になりました。

開発体制は図1のようにしました。管理者である私を含めて社員3名、派遣2名、Y社請負4名、Z社請負1名の10名による開発です。塗りつぶし部分が協力会社です。派遣Cさんには、マイコンソフト開発とPCソフト1開発の2つを掛け持ちでお願いしています。社員AはPCソフトサポート作業、社員Bはスケジュール遅れによるヘルプのために途中から参入した社員であり、開発当初の社員は私1人だけでした。

現在行っている開発の体制図
図.1 開発体制図

当社で1つの開発に7人もの外注が参入することは初めてのケースであり、また、私自身、外注管理ではいくつかの苦い経験があり、不安がありました。

3. 今までの外注管理の失敗について

今までにも何度か協力会社に開発をお願いしたことがありますが、大きな失敗が2回ありました。

(1). 納期間際になっても全くソフトができていなかった

2人月程の開発を請負で依頼していた協力会社があり、納期間際にデバッグのため何度か来社していただいていましたが、なかなかソフトが動かず、「なんかおかしいな」と思い、プログラムソースコードの提出を求めたところ、サンプルとして渡していたプログラムソースコードに数行手が加えられた状態だけだったことが分かり、愕然としました。
前に開発を依頼したときはきちんとやっていただいたため、安心してお願いしていたのですが、進捗確認を全く行っておらず、遅れに全く気づきませんでした。担当者の体調不良等もあり、当社で引き取って開発を終わらせました。
いくら実績のある協力会社でもきちんと進捗確認は行うべきだと反省しました。

(2). 派遣社員が必要とする知識を持っていない

既存ソフトの変更が多い開発で請負では出せない開発があり、派遣社員に来ていただいて開発を行ったことがありました。しかし、来ていただいた派遣社員の方が、開発言語に関する知識が乏しく、仕事の出し方に苦労しました。ベースとなるプログラムがあればプログラムを組めることは分かりましたので、自分がベースとなるプログラムを作り、派遣社員の方にはそのプログラムをベースにプログラムを作っていただきました。しかし、自分の作業量が大幅に増えたため、自分の作業担当分が予定通りに進まない状況になり、納期面で問題が発生しました。
派遣社員を受け入れるときはスキルの確認を行いますが、その時は誰でも良いので協力してほしいという状態であり、期待している作業ができるかどうかの判断が甘くなっていたのは問題でした。

4. 外注管理で工夫したこと

現在行っている開発の外注管理を進める上で、工夫したことについて書きます。

(1). 毎週1回、進捗確認を行う

3-(1)項の失敗がありましたので、協力会社には毎週1回進捗報告を行っていただくこと、また、作成途中でもよいので、成果物を提出していただくことを発注前提としました。

(2). レビューの実施

請負にはフェーズ単位(外部設計完了、内部設計完了など)で期限を設定し、フェーズ完了時にレビューを実施しました。また、派遣作成分については、機能作成完了毎にコードレビューを実施しました。レビューでは数十項目の指摘事項が発生し、事前に問題が見つけられ、成果があったと思います。

(3). 細かいミスについてもきちんと指摘する

1つのソフトのプログラムコードは行数にして数万行にもなり、文字数にすると数百万文字にもなりますが、その中の1行、1文字でも間違っていると、それが不適合となります。今までは文書の誤字脱字などのミスについては、「まぁいいか」と指摘せずに妥協してしまうことがありましたが、そのようなミスがプログラムコードにも現れると考え、細かいミスにも妥協しないように心がけました。納品資料はもちろん、説明用の資料などについても誤字脱字を指摘するようにしました。このように細かいミスを防ぐことが大きな問題を防ぐことになるのではと考えます。

5. 外注管理で失敗したこと

4項にあげたような外注管理の工夫を行いましたが、失敗もありました。そのことについて書きます。

(1). 納期間際になっても外部設計書ができていなかった

Y社にお願いしたPCソフト2開発の外部設計書が納期間際になってもほとんどできていない問題がありました。3-(1)項で紹介した失敗と同じ失敗を繰り返してしまいました。
毎週1回の進捗報告は行われていましたが、報告内容を見ても進捗度がよく分からず、作成途中の成果物も提出されず、最初のころは「まぁ始まったばかりだからな」と思っていましたが、数週間経ってもその状況は変わりませんでした。さすがにおかしいと思い、「どのような状態でも良いので、作成途中の成果物を提出してください」と催促したところ、ほとんど外部設計書ができていないことが分かりました。Y社全体で対策を打っていただき開発全体には影響が出ませんでしたが、毎週1回行うと決めた進捗確認が意味のないものとなっていました。進捗が分かるように再報告を依頼し、成果物は必ず提出していただくことを徹底すべきでした。

(2). 請負のコードチェックを行わなかった

図1開発体制図にあるように、社員AにはPCソフトサポートをお願いしていました。サポート内容は、毎週4時間、協力会社から提出されたプログラムソースコードについてチェックすることでした。しかし、社員Aは別件の作業で忙しい状態であり、チェックしてもらえませんでした。

(3). 受入検査を何度も実施

Y社にお願いしたPCソフト2開発の受入検査は協力会社と一緒に実施しましたが、何度も不合格となり、受入検査は12回にも及びました。これにはいくつもの原因がありますが、仕様認識違いが1つの原因であったと思います。「上流で品質を作り込む」がものづくりの基本ですから、外部設計、内部設計の段階で気づけなかったのが問題であったと思います。また、5-(2)項のコードチェックをきちんと行っていれば事前に気づいた問題もあったのではと思います。内部設計レビューまでうまくいっていたので、「問題は出ないだろう」と私も楽観視していました。社員Aにきちんとコードチェックを行うように強く要求すべきでした。

(4). 派遣社員が作成したコードに手直しが必要

派遣社員が作成したコードについては、機能作成完了毎にコードレビューを実施し、4-(2)項で書いたようにコードレビューで事前に不適合が見つかり、レビューの効果を感じていました。しかし、ところどころで私の普段のコーディングスタイルとは違うところがあり、気になっていました。プログラムには人それぞれの個性があり、同じ仕様のプログラムを作ったとしても、同じコードができあがることはありません。そのため、「動くのだから、まぁいいか」と妥協してしまったところもありました。
派遣社員の派遣期間が終わり、自分がプログラムを引き継ぎましたが、派遣社員が作ったところで不適合が発生したとき、自分のコーディングスタイルとあっていないため、解析にも時間がかかり、修正にも時間がかかってしまう状況になりました。結局、自分のコーディングスタイルにあうようにコードを手直しした部分もあり、「あの時、妥協しなければよかった」と反省しています。

(5). 予想以上の管理時間が必要

開発当初の予定では、私も図1開発体制図にあるマイコンソフト開発に入る予定でした。しかし、お客様との質疑応答、協力会社との質疑応答、週1回の進捗確認、納品資料のチェック、レビュー実施、ソフトの受入検査など次々とやらなければならない作業が発生し、結局、プログラムは全く作りませんでした。よく考えると、過去に外注管理に失敗したときは自分もプログラムを作っており、外注管理まで手が回っていなかったのだと思います。一般的にも、開発者の人数を増やしても、効率は比例的には上がらない(人数が多ければ多いほど効率が下がる)と言われており、このことは今回の開発で実感しました。

6. これからの課題

これまでの外注管理の失敗を踏まえて、これからの課題について書きます。

(1). 認識違いをなくする

お客様との間で認識違いがあるように、5-(3)項のように協力会社との間にも認識違いが発生します。お客様および協力会社とはノーツを使用して文書で質疑応答を行いますが、お客様から質疑応答があったとき、当社には伝わるが、それをそのまま協力会社に伝えても伝わらないことがあり、その逆もあります。そのため、当社で補足して伝えることがありますが、時間のないときはそのまま伝えてしまうことがあり、うまく伝わらなかったり、誤って伝わったりしてしまうことがあります。
質疑応答を行うときには、なぜそのように思ったのかなどを伝えなければ、誤って伝わってしまうことがあるので、お互い意識して質疑応答しなければならないと考えます。例えば、仕様変更を行う場合に、なぜそのような変更が必要になったのかなど、背景も含めて説明していただくなどです。背景も含めて仕様変更内容を知ることで認識違いが出にくくなりますし、当社や協力会社から別の実現方法の提案や改善提案などもできると考えます。

(2). 妥協をしない

外注管理の失敗を振り返ると、私自身が妥協してしまったところが、失敗につながっています。その時は、「今から後戻りが発生すると納期に間に合わないかもしれない」や「現状のままでも仕様通りに動作するので問題ない」と妥協してしまいましたが、このようなことは必ず問題となって自分に舞い戻ってくるものだと思いました。決めたことや、やらなければならないことについては、一切の妥協を許さない覚悟でやらなければならないと思いました。

7. お客様からみれば当社は外注である

まだまだソフテックは外注管理の経験が乏しく、改善していかなければならないことが多々あります。しっかり外注を確保し管理することができれば、「人がいないので開発できません」などと、せっかくのお客様からの開発依頼を断ることもなくなります。
今回の外注管理には失敗が多くありましたが、1つの開発でこれだけの協力会社に開発依頼することはなかなかできないことであり、非常に勉強になりました。お客様からみれば当社は外注であり、当社が協力会社に望んでいることは、お客様が当社に望んでいることと同じであると言えます。また、お客様の先にエンドユーザがいれば、お客様が今回の当社の立場になります。外注管理の苦労はどこにでもあり、外注管理は開発全体の成功を左右する非常に重要な位置付けであると考えます。

(M.A.)


関連ページへのリンク

関連するソフテックだより

ページTOPへ