【プロマネ】プロジェクトの「測る化」の実践

はじめに

開発グループPMO(プロジェクトマネジメントオフィス)の大嶋です。

過去10年近くのプロジェクトマネージャー(PM)的な役割を経て、下期からウィルゲート開発グループを横断的に見るPMOとしてゼネラルマネージャー(以下GM)を補佐する形で組織戦略の立案遂行や開発本部の運営、採用活動などを主なミッションとしています。実はこのブログ自体もそういった役割の一環として、よりよい形に変えていくことを意識しています(笑)

ウィルゲートは大きくコンテンツマーケティング事業とメディア事業があり、それぞれの事業の中でも大小複数の開発プロジェクトが並行で進んでいます。1週間~1ヶ月くらいで終わるものが大半ですが、中には半年からそれ以上の規模で動いているものもあります。

今回は、大きめのプロジェクトを対象としてコンディションを客観的な視点で見て必要に応じた打ち手に繋げるために、GMより託された『変化に強い計画・問題発見の技術 プロジェクトの「測る化」』の書籍を参考に行った取り組みをご紹介します。

変化に強い計画・問題発見の技術 プロジェクトの「測る化」

変化に強い計画・問題発見の技術 プロジェクトの「測る化」

 

 

プロジェクトの何を「測る化」するか

ビジネスにおいて「見える化」というワードは、トヨタ自動車が浸透させたものとして有名だと思います。ウィルゲートでも、主に開発プロジェクトの「見える化」はカンバン方式でタスク管理するツールを活用して行われてきています。

tech.willgate.co.jp

今回は「測る化」ということで、一歩進んでプロジェクトにおいて見えづらい指標を定量化する試みになります。
書籍に則ると、定量化するべきものは以下の「QCD+S」が対象になります。

  • Quality ・・・品質
  • Cost ・・・コスト
  • Delivery ・・・納期
  • Scope ・・・スコープ

この中でもスコープは普段なかなか見えづらいですし、ウィルゲートの開発プロジェクトにおいても進行途中で開発要件が変わることは少なくないので、特に注目して「測る化」をしていきました。
余談ですが、開発スコープが変わることはややもするとネガティブな捉え方もされがちかと思いますが、中長期のプロジェクトであるほど時間の経過とともに周辺の状況も変わっていくものなので、一定の変化はあるべきものと捉えて普段から計画や目標設定をしています。

どのように「測る化」したか

  • スコープについて
    まず最も注目したと述べた「スコープ」に関しては、ファンクションポイントを算出することで「測る化」としました。ファンクションポイントの考え方自体は1979年に提唱されているそうですがウィルゲートではほとんど初めての試みとなったので、Web上の情報を参考に算出方法をみんなで学んで実践しました。
    チームによってはスクラム開発手法に則りストーリーポイントを見積として使用しているところもありますが、今回はプロジェクト横断的に実践するために書籍も参考にファンクションポイントを使用しています。

    FP 法のイメージをつかむ - あしのあしあと

  • コストについて
    コストの「測る化」についてはこれまでも会計処理のために、毎月開発に掛けた工数(時間)をもとにして算出していたのでそれを転用しました。
    基本的にはエンジニア1名あたりの単価×人数となり、そこにそれぞれのプロジェクトへの稼働比率(100%専任なのか、2つを50%ずつなのかなど)を加味して算出しています。
  • 品質について
    品質についてはサービスで起きた障害事案は開発組織全体で統括的に管理しているんですが、プロジェクトが完了してしばらく経たないと評価できないものになります。従って今回はプロジェクトによって管理方法が異なることを理解した上で、リリースまでのテスト工程で検出したバグや、変更依頼の件数を障害管理表からカウントして使用することにしました。
  • 納期について
    今回は完了したプロジェクトを扱ったので、進捗状況の測定は対象としませんでした。
    代わりに、どのくらいのアウトプットしたのかを「測る化」するべく、カンバンのチケット数と、コード量を計測することにしました。
    コード量の測定は、以下のようにgit logコマンドをリポジトリ(ブランチ)別に、プロジェクトの期間(--since,--until)を指定して実行する形で行いました。
    ただしそれだけだとフレームワークや外部ライブラリのコード量もカウントされてしまうので、該当する箇所のディレクトリまで指定したコマンドを合わせて実行してその分を差し引く形にすることで、実際に記載したコード量だけをカウントするようにしました。

    # コード行数をカウント(全行数,追加行数,削除行数,総更新行数)
    git log --numstat --pretty="%H" --no-merges --since= <sincedate> --until= <untildate> --author="" <branch> <directory> | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d,+%d,-%d,%d", plus-minus, plus, minus, plus+minus)}'> output.csv
    # コミット回数をカウント
    git log --pretty=oneline --no-merges --since= <sincedate> --until= <untildate> --author="" <branch> <directory> | wc -l | awk '{printf "," $1}'>> output.csv
    # ファイル数をカウント
    git ls-files  | wc -l | awk '{printf "," $1}'>> output.csv 
    

 

「測る化」した結果

「QCD+S」の軸で3プロジェクトの「計る化」を行って以下のような数値がまとまりました。

f:id:oshima106:20180309192213p:plain

こうして得られた数字に対して、それぞれの指標を掛け合わせた係数を算出することでプロジェクトのコンディションを定量的に評価する基準値としていけるのではないか、と考えています。

f:id:oshima106:20180309193425p:plain

気をつけたこと

  • はじめに自分でやってみる
    こういった取り組みをする上で、現場のプロジェクトリーダーの協力は不可欠でした。
    開発業務に専念したい現場になるべく負荷を掛けずに実現するために、PMOである自身が先行して小規模なプロジェクトを対象に取り組んでみて成功イメージを作ることで、分担して現場にお願いするところとそうでないところを切り分けることができました。
  • 正確性の追求よりも早期実現を重視
    いわゆるスモールスタートというわけでもないですが、まず運用をはじめてそこから改善していければいいと考えて取り組みました。例えば今回初めて取り組んだファンクションポイントの計測では、完璧を求めて粒度を細かくしたり複数名でチェックして正確さを担保するといったことは避けて、「1時間で行える範囲で算出する」という取り決めで簡易的に行いました。コード量についても同様で、厳密に全てのライブラリ部分を除外したカウントするようなことはせず、おおよその規模感を出すことを優先しました。
  • 異なるサービスのプロジェクト間での横比較は行わない
    「測る化」をして数値が「見える化」されると、どうしてもそれを比較したくなってしまいます。
    しかし、プロジェクトごとのシステムを構成する言語・フレームワークミドルウェアだけでなく、関連する事業のステージやステークホルダー、サービスの特性も異なるので、横比較してもほとんど意味がないと考えています。従って比較は同じ事業/サービスや、時間軸で連続性のあるプロジェクト同士でのみ行うものとしました。(例えば、一連のプロジェクトのフェーズ1とフェーズ2で比較するなど)
    これまでのプロジェクトを遡って「測る化」は行っていないので今は比較対象がなく、今回を起点にして今後の比較基準に活用できればと考えています。

まとめ

簡単ですが、プロジェクトの「測る化」を実践してみた事例のご紹介でした。
書籍にならうともっと緻密に、様々な切り口での「測る化」の観点がありましたが、あくまで目的としてはプロジェクトのコンディション把握と改善であり、さらにはいかに価値のある開発を行うかということを忘れずに今後も継続していければと思っています。