職業柄、過去に様々なプロジェクトに関わり、当然ながら失敗もたくさんありました。

特にノウハウというものでもありません、公開できる程度の記事にしておきます。

今日は、そんな失敗も振り返りながら開発時に起こるトラブルをご紹介したいと思います。
私も過去は散々火を噴き、泡を吹き悶絶したものです。(今でもたまに泡は吹いていますが)
ぶくぶくぶく・・・orz

最初に断言しておくと、

「トラブルの発生しない開発プロジェクトはまずない」

悩む人たち

と考え、発注者やプロジェクトマネージャー・リーダーは心構えをします。

開発トラブルの多くは以下の要因に分類されます

  1. スコープや責任(成果)の明文化漏れ
  2. メンバーの欠員、欠格
  3. 契約金トラブル
  4. 開発期間設定

それぞれについて、考えてみます

スコープの定義とは、あなたの仕事はこれだけですよ。と明確にする事。
後から、「おい、これ誰やんだ?」的な作業が結構出てくるのもお約束です。

あなたの仕事はこれだけです

WBS(作業詳細)をなるべく大項目(レベル1)の段階で各担当者に割り振り、
各担当者(エンジニア)が、自分のやるべきレベル2以降を細分化してタスク
として落とし、もう一度プロマネに返すのが理想です。

例)

担当 工数
サーバー構築
Apacheインストール 鈴木 0.5
メールサーバー構築 0.5
小計 1
DB設計
UMLからの落とし込み 田中 3
モデル設計 田中 10
小計 13
設計
遷移 佐藤 6
詳細設計 佐藤 35
小計 41
合計 55

この例では、Apacheインストールにどれぐらいの日数を要するか?

までクライアントが気にかける事は無く、サーバー構築に1日かかるんだ。
という認識でいる事です。プロマネは各工程に無理がないか、経験と照らし合わせ、
リーダーは、各項目について本当に正しいかクロス見積もりで担当者と付き合わせます。

当然、これが規模が大きいのであれば、リーダーが一度レベル2を受け取り、
レベル3以降を割り振っても良いと思います。

各エンジニアは、最後、WBSを意識するよりも、細分化した以降はPivotalTracker※1
などで、自分の作業を徹底的に洗い出すのが良いでしょう。
全タスクが集まったら、プロマネ・リーダーは各タスクのTODO消化状況を追いかけ、
WBSの実績を達成実績で埋めていきます。

ポイントは、プロマネがWBS※2の細部まで手を伸ばさないことです。
エンジニアでも意見を言わないタイプの人は、「設計書に書いてある通りでいいのかな?
でも反対意見だと思われても嫌だし従っておこう・・・」という方もいます。
TODO・タスクの消化は任せるのもひとつです。

これが責任(成果)の明文化となり、各自のやる気(目標)を定める事にもなります。
発注者も同様に、スケジュールの細部(TODO/タスク)にあまり手を入れない事です。

過去にあったトラブルというか、困ったことですが、徹底的にタスクを監視する
クライアント様がいらっしゃいました。

予算も決まり、見積もりも確定したのですが、さらに進捗が気になるようで、
各エンジニアの作業詳細まで口を出されていました。

具体的には以下のような内容です。もう10年も前の話ですが。

クライアント「Apacheセッティングってあるけど、これは何?」
「はい、これはサーバー上に設置するプログラムですね。ブラウザからの応答に呼応するものです」
クライアント「その、Apacheってのは必要なの?誰が作ったの?フリーウェア?」
「これは、海外のファンデーショングループが開発する有志ソフトウェアで、信頼おけるものですよ」
クライアント「本当に信頼できるの?根拠か資料はある?」
「え?えっとですね・・・まずWebサーバーとしては稼動が世界一でして(以下略)」

さすがに全てが万事この調子だったので、WBSのレベル2以降はエンジニアに任せてください。
でなければ継続は難しいです、とまでお話して、相当気を悪くされたようでした。
今思えば、もっとやり方はあったのですが。

上記でいう役割は、プロジェクトリーダーになります。
技術を持った人間が細かく指示や相談に乗るのが良いと思います。
その結果をプロマネが受け取り、進捗表に落とし、クライアントへ報告となります。

リーダーは当然、メンバーの技量や作業内容を注視するのは言うまでもありません。

エンジニアは非常にプライドも高く(良い意味で)日々、移り変わる技術に追いつこうと
全力で勉強しています。だから、そこに口を出すと「知らないクセに」となりかねないのです。
プロマネも、進捗確認にとどまるのが良いのです。

ただし、作業状況が正常かどうかは徹底的にチェックは必要です。
常に実績をチェックし、スケジュール通りかどうかを見ていきます。

各担当に割り振られている開発プロジェクトでは、メンバーあたりの責任は重大です。
別の人が引き継ぐことが難しい事が多く、スキル仕事は振り替えがききません

私が実際に見てきた例のごくごく一部ですが、

■ 開発現場にて

・ちょっとコンビニ行ってきます、と出て行って戻ってこず行方不明
・無断欠勤3日、ある日いきなり両親が来て土下座。辞めさせてください
・立ち上がって急に叫びだし、そこらじゅうの机を蹴飛ばして消え去った
・頭が痛いと早退し、次の日から欠勤

欠勤退社メンタル

え?そんな馬鹿なことないだろう?
いえいえ。開発現場を長くやっていると、こういう伝説は飛ぶように話題が出てきます

では、上記は防げるか?

実は防ぎきる事はできません。
ギリギリで頑張っているエンジニアの糸が切れることはあるだろう、と心積もりが必要です。
まぁ、それすらトンデモない話だとは思うのですが。

ある程度の予測と防衛は可能だとも思います。過去の傾向を見ていると対策としては
以下のようなものになるのではないでしょうか。

1)スキルギリギリの仕事をメンバーにアサインしない

⇒ 自分の知識で充分余裕でできる仕事、ぐらいが妥当です。
「調べてなんとかできる」レベルの仕事だとコップに水がギリギリの状態
少しの仕様変更でパンクする可能性があります。

エンジニアの力量を見極める事が大事。
そして、覚えておきたいのは、エンジニアは未知の領域が大好きです。
常に新しいなにかに挑戦する事を望んでいます。
本人が希望しても、本当に実現可能か?
スキル見合いかを検討する必要があります。

時にはそれは成功しますが、確率された技術を選択する事も大切です。

2)納期のマージンを調整しておく ※事項で説明

3)WBSの工夫

⇒発注者やマネージャーの考える、「できた」と、
エンジニアが言う、「できた」の差違を詰める作業です。
少なくとも、単体テストレベルでエラーが出ず、正常にデータが登録
されて初めてタスク完了です。
本人申告+上位スキルエンジニアのチェックは最低必要だという事です。
一つのタスクを複数人数で同時に出す、工数チェックも良いと思います。※6
ついつい、やす~く見積もりを出すエンジニアが多いのです。
(俺はこれで片づけられるぜ、ふふ~ん、とか、ノリでざっくり出してしまうのでしょうが)
最終的には、エンジニア自身が自分で首を絞めることになり、可哀そうです。
見積もり時に早めに手を打った方が良いのではないかと思います。

これも多いです。一番最初のスコープ定義が曖昧な為に発生する事がほとんどです。
当然ですが、仕事してやる以上タダ働きはあり得ません。

お金のトラブル

クライアント・請負側、当然認識しています。もちろんですよね。
しかし、クライアントの「これぐらいはやってくれるだろう」があると、
些細な事でもプロジェクトは一気に火を噴きます。
やってもらいたい事、自分がやれる事、これは個別契約書と提出文書で明確にすべきです。

しかし、事前に全要件を洗いだせるでしょうか?私はそうは思いません。

例えば、開発後半の仕様変更等がそうです。
クライアントからすれば、画面をこうやって、ちょっとこうするだけじゃん。
と思われたりするのですが、ソースコードに落とすととんでも作業だったりします。

仕様変更も1箇所で収まることは無く、後から何度も繰り返し出ると、
開発会社は大変な負担になります。
「いい加減にしてよ!!!」
って机をバンバン叩くのも、開発現場ではよくある光景です。※3

最初から仕様変更は発生するのでよろしくね。(まぁ、宣言するのも可哀そうな話ですが)
という事を契約条項というか、金額に因果含めてしっかりと、開発会社に伝える事も必要です。
もう、絶対に変更あるから。っていう前提で一歩づつ確認しながら進めばいいんです。
それで納期が遅れるなら双方詰めればいいし、料金が発生したら言える環境を作りましょう。

後だしジャンケンが一番開発陣の嫌がる事です。
マラソンをしていて、ゴール直前でゴールが逃げていくような感じに見えるらしいです。

つまり、事前に起こりうる事項は開発側に伝えておくこと。
可能性の模索はプロマネの経験が非常に重要だと思います。

やっぱりそうなるか、と手綱を引ける技量が求められます。開発リーダーも同様です。
お客様にも、開発経緯で予測できたらすぐに伝える柔軟さが必要です。

最後に、開発期間です。
前項でも述べましたが、期間設定というものはエンジニアだけに頼ってもいけませんし、
ましてやプロマネやクライアントが勝手に見積もりものでもありません。
全員が目を通して然るべきものです。それでも誤差は発生します。

■ 開発者側の勝手な都合

スケジュールを短縮し、削る場面が最初から出てきます。これが一番の問題です。
営業としては、見積もりの根拠はすべて人件費が中心となりますので、
いかに開発期間を短く見積もるかがポイントになります。成約率をあげる営業上の理由です。

これぐらいでなんとか頑張れば見積もり安くなるでしょう。
しかし、このギリギリの見積もりが危険で、前項で出た「不足の事態」「仕様変更」
入った場合、どうなるでしょうか?

経営者の方ならピンと来ると思いますが、当然それ以上はできない。が答えになります。
発注側は相手を信用して作ってもらっているのに、作る側はもうできませんと答える。
代わりの業者はいないし、見つけても所詮他人のソースコード、莫大な手間がかかります。

安ければ良いというものでも無く、この辺の詳細見積もりもしっかり出せるかどうか?
がポイントにもなります。

■ 発注者側としては

発注する側からすれば、予算の中で納めて欲しいと思っています。当然です。余計にかけたく無い筈です。後出しジャンケンでお金がかかると言われても困ります。

しかし、ギリギリでお金が足りないと言われる場面もあります。
完成しないと終わらないし困る。
泣く泣く資金繰りをして払わざるを得ない状況を見てきました。

見積もりを確認する際は、こういった目に見えない部分を予測・確認することも必要です。
そして、開発会社にしつこく確認することです。

すべては、人件費が中心となっており、ソフトの内容が変更されるとお金も動く。
こういった認識をもって事前にしっかりと打ち合わせしておく必要があります。

■ プロマネとしてどう戦うか

結論 : 完璧なスケジュールもないし、完璧な設計もない。当然完璧なWBSなんて不可能

ついでに言うと、完璧な設計書は存在しない。

柔軟に対応

これぐらいの心構えで挑みたいところです。
毎日開発を進めていると、色々な変更が出てきます。

そのたびに、「話が違う」「それは無理」「できない」「人がいない」
等と言っていてはキリがありません。

最後は責任のなすりあい、怒号、そして疲れ切ったエンジニア、モチベーションの下がったクライアントやる気のない営業と、恐怖のデスマーチが待ち受けています。

話が変わって当たり前、追加があって当たり前、WBSに漏れがあって当たり前。
当たり前体操、ちゃんちゃん。なのです。ふざけてすみません。

「あ、やっぱりそうですか。じゃ、どうしますかねっ?」
と落ち着いてプロマネは対応したいものです。余裕があればですが。
あらかじめ、変更を前提に考えておくと、精神衛生上とっても楽です。

その余裕を作るには?ここが肝になりますが。

・クライアントには、事前に予測しうる追加料金や費用を伝えておく

⇒嫌がられます。というか、プロマネの癖に予算膨らませるのか?ぐらい言われます。
「そんなのかかるの?本当に必要なの?」
って話も出ます。プロマネは営業職に片足のつま先の小指の先ぐらいは入ってます。
でも、後から睨まれるよりぜったいマシです
妄想・想像の限りを尽くして、プロジェクト初期に全部吐き出しましょう。

・クライアントには、期間をなるべく余裕見てもらう

⇒期間=予算です。これも嫌がられますが、スケジュールに収めるのももちろん技量です。
しかし、開発会社とトラブルを起こして、クライアントともトラブルを起こして。
それでも無理なスケジュールを組みますか?
開発メンバー全員になんらかのトラブルが起きることを想定してスケジューリングしましょう。
私は少なくとも(ひみつ)%は余裕見てます。そして、そのマージンはいつも自分だけの秘密です。余裕あるなんて知れたらクライアントには削り要請が出るし、エンジニアはのんびりやるだけだし、いい事なにもないですもん。プロマネの芸の一つです。

・開発会社には、絶対的に協力を要請する

⇒エンジニアも誇りを持っています。(もってない所には発注しないようにしたい)
とにかく良いものを作りたい。協力してくれ。
と頭を下げましょう。そもそも、プロジェクトで偉いのはクライアントだけで、それ以外は上下関係なんてないと思っています。
真摯に取り組めば、メンバーは確実に協力してくれます。

・こまめにメンバーと接触し、会話する

⇒現場の雰囲気は重要です。そして、メンバーがとにかく発言しやすい環境が重要
エンジニアは静かな方が多いです。そしてチャットは強いです。
社内チャットでも、Skypeでも構いません。雑談をしても良いと思います。※4
顔文字だろうがなんだろうが、許すぐらいの雰囲気は必要だと私は思います。
メンバー全員が参加して会話できる場所を用意しましょう。
そういう環境を作っておくと、危なくなったときにすぐに「すみません、ヤバいです」
を聞く事ができます。上から目線のガチガチ組織だと、中々この信号がキャッチできません。

・そして、言うべき事を言う

⇒大事な事ですが、難しい事です。
クライアントであれ、無理な事は無理、お金のかかる事はかかる、とハッキリ言う事です。
私の経験上、どんなにクライアントと口論になったとしても、最後しっかりと完成すれば絶対に良い関係になります。そして次につながります。
中途半端になにも言わず、クライアントの要望だけを吸収して下請に投げるだけでは危険です。
火が噴いたプロジェクトは誰も得をしません。
腰を据えて、言うべき事は言いましょう。嫌な思いはその時だけです。

なんでもかんでも、ガチガチに固めるほど破綻しやすいです。
各WBSや節目がゴムのように伸び縮みする体制作りを目指したいものです。※5

と、最近は私は思うのでした。でも、これはWeb系のプロジェクトなので、他でやって睨まれてもクレームは受け付けません(笑)

まとめのまとめ

よるくま堂では、そんな悩めるWebサイト開発のプロジェクト支援を行っております。

各種経験ございますので、お気軽にご相談ください。

結構安い料金で承っております。

————————-

※1 以前、参加したプロジェクトで知りました。見つけた人も賢いし、作った人も偉いなぁと感心したものです
※2 WorkBreakStructure、ワールドビジネスサテライトではありませんワールドベースボールも関係ないです
※3 やっぱり多い
※4 話題は別にアニメだろうが女子アナだろうが、Amazonのネタだろうが、なんでもいいのです。
※5 予算は伸び縮みしません。もちろんその範囲で。
※6 スクエア・エニックス プロジェクトマネジメント講座 208p参照