SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Data Tech 2024

2024年11月21日(木)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

EnterpriseZine(エンタープライズジン)

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年夏号(EnterpriseZine Press 2024 Summer)特集『ニューリーダーに訊く──2024年春、CxOに就任した2人が目指す姿とは』

開発の現場スペシャル

教科書じゃ教えてくれない 本音で語る開発案件成功の法則

プロジェクト運営 “10”の鉄則


巨大プロジェクトを成功させた人でも、5~10人規模の案件では失敗してしまうこともあります。その理由は、「マネジメント」という言葉では語りきれない、現場の知恵やテクニックの有無にあります。本稿では、そうしたいわゆる“泥臭いこと”も含んだプロジェクト運営における10のポイントをまとめてみます。本稿が皆さんのプロジェクトでの活躍に役立てば幸いです。  (「開発の現場 Vol.006」より転載)

はじめに

 開発リーダーの役割りは、プロジェクトの規模と大きく関ります。本稿では、メンバーの人数が5〜10人程度のチームにおけるプロジェクトを想定しています。このレベルの人数をまとめる場合、20〜100人規模の場合とでは大きな違いがあります。それは、「チームメンバー1人1人と向き合える」「向き合う必要がある」ということです。20〜100人をまとめる場合、どうしても統計的/システム的な対応や考え方が求められます。こういった大プロジェクトを成功させている人が5〜10人のチームを成功に導けるかというと、必ずしもそうではありません。数字だけしか追えず、技術への理解が浅かったり、その人の人間的な魅力が薄ければ、誰もついてこないのです。大プロジェクトを成功させていても、PMP(Project Management Professional)を持っていたとしても、それだけでは成功に結びつかない難しさが、この規模のプロジェクトにはあるのです。

 もちろん、プロジェクトマネジメントが不要と言うつもりはありません。しかし、プロジェクトマネジメントについて学びつつも、メンバー1人1人のポテンシャルをどれだけ引き出せるかが進むべき道となります。そこはプロジェクトマネジメントのようなスマートな世界とは違う、泥臭い部分もある世界です。しかし、それだけに面白い/やりがいがある部分も多いのです。

鉄則1:プロジェクト/案件内容の把握を確実に

 プロジェクトの初期段階では、案件そのものを理解/把握することが開発リーダーにとっていちばん重要です。この認識がずれてしまうと、どんな計画を立てても的外れになってしまいますし、任された案件がうまくいくことはまずありません。

 案件内容というと要件だけを思い浮かべる方もいますが、それだけではありません。特に重要な確認点を次に挙げます。

  • 要件(特に案件の動機)
  • リリース日
  • 予算総工数

 案件に取りかかったら、まず行うのはヒアリングです。案件が手許に来たということは、案件を作ったり見積りをした人が必ずいるはずです。その人たちから、できるだけ多く情報を引き出すことが肝心です。訊き出す対象は上司や先輩、顧客になります。外部に訊く必要がある場合は、案件説明会などの開催を事前に計画しておく必要があります。

 こういったことは最初に訊くほうが楽ですし、当然手戻りは少なくなります。何も知らない新人が教育担当にアレコレと質問するように、案件リーダーの新人であるあなたは、疑問点やわからないことを上司や先輩にどんどん訊いていってください。いったん案件を引き受けてしまえば、今度は自分が案件の内容をすべて知っていることになります。案件を完全に引き受ける前に、「それをやるにはここを教えて」とやるべきです。それぞれの確認点について見てみましょう。

要件確認(案件の動機)

 案件の動機/目的の把握は、非常に重要です。動機を把握してないと、たとえば次のような事態が発生します。

  • コスト削減が目的であるのに、マニュアル操作の多いシステムを構築してしまった
  • 処理の高速化を目的としているのに、テスト計画にパフォーマンステストが盛り込まれていない
  • 法改正に伴う改訂なのに、法律の施行に間に合わないリリース計画を立てている

 また、この動機が強いものなのか、弱いものなのかも知っておきたいところです。動機が非常に強い場合は、先方は協力的でしょうが、要望なども多い可能性があります。逆に動機が弱い場合は、こちらから質問をしてもなかなか返ってこなかったり、最悪のケースでは案件そのものが無くなったりしますが、こちらの要望が通りやすい傾向があります。

 ほかにもチェックポイントはいくつかありますが、要件定義の話になりますので、詳細については省きます。

  • 新規案件か改訂案件か(影響調査の範囲)
  • 非機能要件の有無(パフォーマンスなど)
  • 使用する技術について(技術的な新規性の有無)
  • インフラ環境(セキュリティ対策や機器発注の必要性)

リリース日

 リリース日が決まっているか、も重要なチェックポイントです。決まっていない場合でも、顧客側の希望日があったり、チーム内やPMや顧客担当者間の暗黙の了解があることがあります。

 次に、そのリリース日が動かせるかどうかを確認します。プレスリリースを出していてリリース日がその中に明記されてしまっている場合、動かすことは困難でしょう。また、担当している案件が前提条件となって他の案件が動いている場合、当然、その案件よりも先行してリリースする必要があります。

予算総工数

 担当している案件について、どれぐらい手持ちの工数があるかを把握しましょう。見積りがこれからの場合は、見積り後に下記をチェックしましょう。もし教えてくれないのであれば、工数管理は誰か別の人がやることになります。

  • メンバーの人数を概数で出す 総工数:6人月(120人日)
    開発期間:2か月
    ※開発期間は案件開始予定日と案件終了日から求めます
    → 必要なメンバー:3人(=6(人・月)÷2(月))

 この時点では、2か月間(自分を入れて)3人が関わるんだ、という程度の認識で問題ありません。

  • 見積り内容の把握

     通常は見積りの際の前提や詳細があるはずです。人によっては、改訂箇所をソースレベルですべて書き出してあったりします。そういった情報は貴重ですので、必ず引き継ぐようにしてください。

 なお、この時点で、自分が考えている(だいたいの)総工数と見積り総工数が、明らかに乖離している場合があります。これはデスマーチへの危険信号か、案件に対する自分の勘違いか、見積り担当者が勘違いしていることになります。いずれにせよ、早急に案件の見直しを図る必要があります。

鉄則2:チームビルディングを楽しもう

 案件状況を把握したら、次はチームビルドです。チームビルドは、案件リーダーとして最も工夫のしがいがある部分だと思っています。これから案件を一緒に進めていくチームですので、よく考えて作りたいものです。

メンバーの決定

 まず、案件内容を勘案しながらメンバーを決めます。決め方はケースバイケースですが、いちばん重要なファクターは、メンバー各自のスキル/経験でしょう。特殊な技術が必要だったり、コーディング量が多い場合は、その技術に特化したメンバーを必ず入れるようにしましょう。改訂案件であれば、以前の案件の経験者も入れておきたいところです。

 逆に、「経験させてやってくれ」とか「人が余ってるから」、「ほかに誰もいないから」という理由で新人や未経験者をたくさん参加させられた場合は、大変です。基本的に戦力にならないどころか、説明などにほかのメンバーの時間をとられてしまいますので、できるだけ断りましょう。一般的には、5人のうち1人が未経験者、というくらいが限度と考えるべきでしょう。

 次に考えるのは、案件に参加できる期間です。普通は優秀な人ほど一案件に拘束可能な時間が少ないはずです。本当に優秀な人はレビュアーとしてのみ参加してもらうこととして、開発期間を通じて参加できるメンバーをできるだけ増やしてください。入れ替わりが激しいほどリーダーの負担が大きくなりますし、メンバーの責任感も低下してしまいます。最も人が必要な期間(たとえば製造期間など)のみ人を増やすこととして、あとは一定のメンバーで進めていくのがよいと思います。

 なお、メンバーがあらかじめ決められていることもありますが、交渉次第で変更可能な場合もあるので、できるだけ案件に合わせたかたちでチームビルディングをしましょう。

メンバー間のコミュニケーションパスを確保

 メンバーが決まったら、まずキックオフミーティングをします。案件の説明もそうですが、お互いが直接顔を合わせることが重要です。たとえば、Aさんが知ってることをBさんが訊いてきたので、「Aさんに訊いて」と言ったら、

  • ケース1:Bさんから「Aさんを知らない」と言われた(暗に話したくない)
  • ケース2:そのままになった(Bさんが自分で調べているらしい)
  • ケース3:BさんがAさんに訊きに行ったら、Aさんに邪険に扱われた

     → 結局、自分がAさんに訊いて、Bさんに伝えた

 こういう経験はありませんか? コミュニケーションパスがリーダーとメンバーの間だけにしかないと、リーダーは情報の伝達役のみで1日が終わってしまいます。メンバー間で面識があれば、上記のような事態はかなり軽減されます。人間は知ってる人と知らない人で驚くほど対応が違うものです。できるだけメンバー間のコミュニケーションパスを確保するようにしてください注1

注1

 著者の経験では、最初に飲み会を開くとかなり効果がありました。単純にメンバーがどのような人かを知る場にもなります。お酒がダメなら夕食を一緒に食べるということでもでよいので、試してみてください。

次のページ
鉄則3:利害関係者間でコミット、自分の負担を軽減

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
開発の現場スペシャル連載記事一覧

もっと読む

この記事の著者

渡邉 正(ワタナベ タダシ)

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/32 2007/07/30 17:09

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング