はじめに
こんにちは、Engineer Lab部所属の渡辺です。
この記事では、部内で行う独自の勉強会イベントについてご紹介させていただこうと思います。
私の部署ではKADOKAWAに関係するシステムの新規開発や改修、保守運用などを行っていて、プロジェクトやシステムによって様々ではありますが自分が関わっている範囲だとプログラミング言語はPythonやTypeScript/Node.jsでAWSにデプロイするようないわゆるWeb系と呼ばれるような仕事が多いです。
そういった仕事がメインなので開発プロジェクトの初期にはシステムを完成させるまでの「工数見積もり」を行うのですが、見積もりに難しさを感じているという声が一部で挙がっており、どうすべきか課題になっていました。
見積もりに関する書籍などもありますが、やはり実際にやってみて経験を積むことが出来た方が嬉しいですよね。とはいえ実践してみるとなるとどうしても機会が限られてしまいます。
そこで、部署の取り組みとして始めたのが「見積もりソン」です。
手探り状態から始めた試みでしたが、これまで4回ほど開催してきてようやく形も見えてきましたので、この記事ではその取り組みについてご紹介させてもらおうと思います。
「見積もりソン」とは?
見積もりソンとは、「見積もり」と「ハッカソン」を組み合わせて勝手に作った造語で、ハッカソンのように特定のお題に対して2名でチームを組んで成果物となる見積もりを出す、というハンズオン的なイベントで、いまのところ四半期に一度くらいのペースで開催しています。
KDXは普段はテレワークなのでほとんど出社する事はないのですが、この日はオフィスの広い会議室に集合してチームごと対面で相談しながら見積もりをします。
見積もる対象のお題(つまり開発してもらいたい要件)については、部署内でアイデアを温めている方から提供してもらっています。 BtoCのWebサービスであったり、社内の業務改善ツールであったり、Engineer Lab部に所属するエンジニアであれば技術セット的には概ね開発出来そうなものが選ばれています。
この企画を進めようとしたときに最初に悩んだのはまさにこのお題をどうやって調達するかという事でしたが、もし社内で適当なものが見つからなかったら「Architectural Katas *1 」というサイトを利用させてもらおうかと考えていました。 このサイトは、「ソフトウェアアーキテクチャの基礎 *2」という書籍で知りましたが、アーキテクトの練習に用いるための様々な要件の種が掲載されているサイトです。 もしこれを読んでいる方で自分の所でも試してみたいという方は参考にしてみると良いかもしれません。
さぁ見積もっていこう!
当日の具体的な流れについて説明します。
あらかじめ参加者を2人1組でチーム編成しておきます。 KDXのロールアサインに基づいて、ソリューションアーキテクト(以後、SA)役1名、アーキテクト(以後、Arch)役1名、という構成で、SA役が方針決めなどチームの推進役となり、Arch役の人はSAの指示に従い調査や作業量の検討を行います。
お題となる要件は事前にあらかじめ目を通してもらっているので、当日は90分で概算見積もりと概要システム構成を各チームごと考えてもらいます。
90分は短い!という話も度々話には出るのですが、どのチームもなんとか時間に収まるように成果物をひねり出してきて、それが結果的に各チームの個性にも繋がっているのでこれはこれで個人的にはアリだと思っています。 (ただ、これだとマラソン(ハッカソン)というより、短距離走と呼んだ方が実態に即してるかもしれませんね!)
各チームごと、ホワイトボードや紙を使ったり、スプレッドシートや作図ツールを使ったりしながら、お題の中身を理解、調査、整理して見積もりを行います。 SA役の方は基本的にエンジニアとして経験年数のある方がアサインされるので、そのやり方をベースに各々対応されている事が多い気がします。
という感じで、90分の間ワイワイ見積もりをしていきます。
ドキドキの見積もり結果発表
90分の見積もり時間が終わったら各チーム発表の時間です。
チームごと順番に発表+質疑応答 をしていきます。
発表で一番注目されるのはやはり「見積もり結果」つまり「人月」や「金額」です。 人月というのは、例えば「1人月」だと1人でやると1か月かかる作業量の事ですね。
自分のチームと他のチームの差がやはり皆さん気になるところで、見積もり結果に倍以上の違いが出て場が盛り上がったりすることもあります。
ただ、たった90分の見積もりで見積もり結果が正しいもなにも分からないのが普通なので、結果の優劣のようなものは特に設定していません。 あくまでも見積もりの根拠や見積もりのやり方などプロセスに関する事で、気づきや学び、経験につなげてもらっています。
見積もりとはある意味で未来予想をするということなので、結果的に見積もりに収まったということはあっても、見積もった時点で完璧というものはありません。 なので、どうやって実現するかという技術的な検討をするための幅広い知見に加えて、過去の経験を元に予測するスキルが重要であり、SA役の方の力量が試されるところかと思います。
ちなみに、見積もり自体はおおよそどこのチームも一旦「人月」や、もう少し細かく「人日」「人週」で出して、それに単価をかけることで具体的な金額にしている事が多いようです。
あくまでも練習なので見積もりソンでは計算しやすいように「1人月=100万円」ということにしていますが、90分で概算が見積もれる程度の規模ではあるので、だいたい数千万円くらいの見積もり結果というパターンが比較的多いです。 個人で数千万円の買い物とかあまり日常的にしないと思いますので、練習とは言え開発費の金額規模感の雰囲気が味わえる場としてはなかなか良いんじゃないかと思っています。
見えてきた見積もりパターンと今後の展望
Engineer Lab部のエンジニアは異なる会社やプロジェクトを経て集まってきた人たちだったので、ノウハウもカルチャーも定まっていませんでした。 そのため見積もりについても秘伝のタレのようになっていたところがありましたが、これまで4回やってきて部署内のみなさんがどのように見積もりをしているのか明らかになってきました。
以下はその一部ですが、
- タスクを大中小の3つに分けて、それぞれの工数感を決め打ちして概算の総工数を出す
- 最初の見積もり結果に対してバッファとして1.2や1.5など係数をかける
- 実現方法がよく分からないものについては一旦別に切り出しておく
などです。
手法的なところでそれほど目新しいものがあったわけではありませんが、大中小に分けたときのそれぞれの工数感の違いや、バッファ係数の使い方、見積もりをする際の1項目の粒度など、運用面での違いは見られました。
今後はこういった点を整理して、部署内共通で使える見積もり手法のガイドラインとしてまとめていこうと考えています。
また、これまでは工数を出すことにフォーカスしてきましたが、初期段階のアーキテクチャ概要設計についてもやってみたい意見もありましたので次回はその軸でやってみたいです。