株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。
2019年3月22日のイベントでは「『イマドキ』ソフトウェア 開発プロジェクトを見積りを通して知る ～システム開発のための見積りのすべてがわかる本より～」と題して、書籍『システム開発のための見積りのすべてがわかる本』の著者である佐藤大輔さん、渡邉一夫さん、畑中貴之さんの3名を講師としてお迎えし、開発プロジェクトの見積りについて、さまざまな視点からレクチャーしていただきました。
・プロジェクトとお金の流れを知る
・「イマドキ」のITプロジェクトでは、アジャイルやチケット駆動もあたりまえ？
・事例研究：クラウド時代の現場では何が起きているのか
【講師プロフィール】
佐藤 大輔さん
大手SIerでプログラマ、SEを経験し、2003年にSI事業と自社サービスを行う企業「株式会社オープントーン」を創業。現在、同社代表取締役社長。
渡邉 一夫さん
Java ServeletなどサーバサイドJavaの登場初期からJavaに精通し、数々のエンタープライズシステムの開発を手掛けてきた実績を持つエンジニア。
畑中 貴之さん
エンジニア、個人事業主として数々のビッグプロジェクトをマネジメントしてきた経験を持ち、現在はオープントーンにて取締役兼観光ビッグデータ事業部長を務める。
そもそも見積りって？プロジェクトとお金の流れを知り仕事の組み立てに生かそう！
まずは佐藤さんが、見積りの基本的な考え方を紹介してくれました。
「見積り」というと、これからかかる費用の明細が書かれた見積書をイメージしてしまうのですが、佐藤さんによれば、見積りとは、予算、納期、品質などの要素を、あらかじめ明らかにしておくことであり、それは「いわばプロジェクト計画そのもの」だということです。
たとえば日常よくある「この作業、いつまでに終わりますか？」という問いに「今週中には終わります」と答えたとします。その根拠を計算することも立派な見積りの一つです。
これは、残りの工数を確認して、開発～テストの期間を計算して何人日必要、と算出します。つまり見積り作業自体は、エンジニアが日々やっていることなのです。ただし、プロジェクトが大規模になると、この作業がビジネスに組み込まれていきます。
ここで、見積りのやり方を学びます。見積りの手法にはいくつか種類がありますが、わかりやすい積み上げ法で説明してくれました。
積み上げ法（積算法）は、名前の通り作業をひたすら積み上げていく手法だそうです。「24時間365日動かしたい」「5000人同時ログインに耐える処理能力」などといったユーザーの要望を聞き、エンジニアは何が必要かを考えていきます。
こうした作業でわかるように、見積りは概要設計をすることと同じです。すなわち設計を進めないと見積りはできません。
そのため、場合によっては見積りに、機能一覧、スケジュール、アクティビティ図、アーキテクチャ構成図、プロジェクト体制図（開発とユーザーの責任範囲等）が伴うこともあるそうです。
また、ここで紹介された積み上げ法以外にも、FP（ファンクションポイント）法、OP（オブジェクトポイント）法など、さまざまな見積り作成の手法があります。
見積りは、あくまでも予測に過ぎません。「やってみたら5日で終わらなかった」というのはよくある話。計画通りに進まなかったときに、それを次回の見積りのためにフィードバックしていくことが、現場において大事なことです。
「イマドキ」のITプロジェクトでは、アジャイルやチケット駆動もあたりまえ？
講師を渡邉さんにバトンタッチして、今度はアジャイル開発やチケット駆動開発についてのお話です。
先ほどの見積りのところでも触れられていたように、システム開発は不確実性との闘いであり、見積るのは難しく、常に不確実性とつき合いながらプロジェクトを進めていく必要があります。
従来のウォーターフォール型開発では、この不確実性を設計段階で解消していました。しかし、これをアジャイル型開発では、開発を進めながら解消していきます。
スプリントという単位で反復しながら開発を行うスクラム開発では、1スプリントごとに振り返りを行うことで、次回スプリントの不確実性を解消していくことができます。たとえば、今回のスプリントでは、チケットを消化できなかったとします。その原因を分析し、早々に修正をかけることで次回スプリントでは同じ過ちを回避するということができるとのこと。
また、チケット駆動開発においてGitのgit-flowやGitHub Flowなどの機能によるブランチモデルを利用して、開発フローの意思統一を図るというアイデアも紹介してくれました。
クラウド時代の現場では何が起きているのか
そして最後は畑中さんによる事例紹介です。
紹介されたのは観光ビッグデータを活用した情報提供サービスを構築するというプロジェクト。宿泊統計というビッグデータの分析基盤を構築し、そこから需要予測ロジックにより導き出される予測値を提供する「観光予報プラットフォーム」だそうです。
まずは、システム全体の概要図を作成します。
システム構成が見えてきたら、ソフトウェア開発規模を見積ります。
ソフトウェア開発規模を見積る際は、見積りしやすいもの、見積りがブレやすいものに分けるのがポイントです。事例では、見積りしやすいものとして、データ登録・整形、プログラム（バッチ）、情報発信APIシステム（API）などを挙げ、ブレやすいものとしてデータ提供システム（Webシステム）の部分を挙げています。
そして、システムではクラウド環境を利用するため、インフラのコストも見積ります。事例ではAWSを利用していました。
ソフトウェア開発規模とインフラの見積り、そしてプロジェクトに関わる作業を洗い出したら、概算見積表を作成します。
工数見積りにはRedmineを使ったそうです。理由としては、スクラム開発でチケット駆動開発を行うのにRedmine Backlogプラグインが使えるからだといいます。
実際のスクラム開発での流れは2週間で1スプリントを想定。しかし、最初はどれぐらいかかるかわからないので、「簡易登録機能だからこれぐらいか？」とか「僕は3日欲しい」などの意見を開発チームから聞き出し、1つ目のスプリントのストーリーポイント（≒作業時間）の見積りを作成します。
そしてスプリントを1回し、その結果から振り返り（KPT）を行い、これを反復することで、その後のスプリントにおける精度の向上を図ります。α版は苦戦しても、β版では余裕をもって開発が進められるようにするのがポイントです。
これまで「見積り」と聞くと「自分には縁がない」と思っていた方もいるかもしれません。しかしアジャイル開発が増えてきた昨今、日常業務にも深く関わってきそうです。改めて、自分のプロジェクトを確認してみるのもよいでしょう。
