三つ巴☆テックナイトでお話しさせていただきました
Copyright © 2017. All rights reserved.受託の基幹システム開発をスクラムでやってる話ハンズラボ株式会社 鈴木大介
View Slide
自己紹介• 名前：鈴木 大介• 所属：ハンズラボ株式会社• 入社：2017年01月01日• 前職：SIer• 登壇経験：今回が初めて
2ハンズラボって？• 情シス部門Ø 東急ハンズの各種システムの内製開発と運用保守• 外販Ø 自社開発の経験を活かした受託開発、内製支援東急ハンズのシステム子会社
3私のミッション某小売業様の基幹システムの刷新をしてます。普通に受託のシステム開発案件です。
4技術要素• フロントエンド：Vue.js＋Element.UI• バックエンド：Python Django Rest Framework• データベース：PostgreSQL• 使用するAWSサービス：• EC2、Aurora、S3、SQS、AWS GLUE、ElasitiCash他• 開発ツール：Pycharm, Docker, github• 情報共有：backlog, slack
5開発スタイルどうする？「受託だし、基幹システム作るならやっぱり、ウォーターフォールでやる？」「ウォーターフォールってSierっぽくない？」「アジャイルってどうかな、情シス部門でやってるスクラムとか良いよね」
6決定という会話があったかはわかりませんが、スクラムでやってみようとなりました。
7アジャイルっぽく？設計フェーズ、開発フェーズ・・・で区切るのはやめて• 画面・機能単位で設計〜単体テストまでを一貫して行う• なるべくスプリント内で終わらせる• 環境構築や調査・調整などは工数から除外した課題としてタスク化する
8実施するスクラムイベントスクラムの基本に従い、この3つを軸にする• デイリースクラム• ホワイトボードでタスク管理• スプリントごとに振り返りとプランニングを実施する
9決めるだけ決めたのでとりあえずスタートしてみました。
10当初の感想意外とうまくいく？• 報告や相談のコミュニケーションが多い• 課題タスクの着手・消化が早い
11問題は起きる第一の問題。
12話し合いは大事だけどコミュニケーションが多いので、悩み事がすぐに共有・解決に取り組める。→ 議論が多くなりすぎて開発が進まない
13問題の原因• 課題が見つかったらすぐに相談していた。• 意見をまとめたり、調査するよりも議論で解決しようとしていた。• 満場一致を求めがち。
14このままだといくら時間があっても足りない
15どうすれば解決できるのか• 先に議題を決めて、資料を渡す。• 揃って議論よりもslackで作業の合間に意見を交わす。• 時間を決めて結論を出す。議論にかける時間が減った！
16次の問題第二の問題。
17プロジェクトが回りだしてから工数＝日数＝時間で管理してしまっているため、納期はきっちりしているが生産性が上がらない。スクラムの原則では時間で管理することはNG
18時間管理をやめてみる見積もりの工数は重み付けの結果である→これをそのままポイントにしてみよう！（例：60人日の機能→60ポイント）今まで終わったタスクをポイントに換算して、1スプリントで消化できるポイントを計測する
19こんな感じ資料作成・提供：ハンズラボ株式会社 三善
20結果残りタスクのポイント数 ＜ 開発期間で稼げるポイント数になるための生産性を見える化できた。
21現状はオンスケジュール〜やや前倒しで順調に進んでいます。
22スクラムをしてみたまとめ良いこと：• コミュニケーション量が増える• 誰が何をやっているかが把握しやすい• 自分の生産性がどの程度かわかるようになる• タスクの受け渡しが容易いまいちなこと：• 見積もり精度が悪いと生産性とスケジュールに揺らぎが出てしまう• リモートワーク・フレックス勤務と相性が良くない
23他にはチームでリモートワークをしたり
24他にはお菓子をチームで共有したりしています
25最後に弊社ホームページ・Wantedlyにてご応募ください。ハンズラボではエンジニアを募集中です！WE AREHIRING!
26最後の最後ちなみに弊社は休日・定時後に仕事っぽいことすると休めって言われるホワイト企業です。
Thank you!
bermonpainter
keathley
kastner
frogandcode
holman
maggiecrowley
philnash
caitiem20
akmur
andyhume
addyosmani
dotmariusz