5/18日にDevLOVEというコミュニティが主催していた「公共交通ナビサービスの開発現場のリアル」という楽しいイベントに行ってきました！！
そのイベントでの雑感と講演のまとめを書きます。
雑感
会場がきれい！ナビタイムさんのオフィス1階にあるイベントスペースが会場でした。今月オープンしたばかりだそうで、色々なイベントに便利そうだなと思いました。
ナビタイムさんのイベントスペース凄いな #devlove pic.twitter.com/nF1rvOMYAP
— Manabu Uchida (@uchimanajet7) 2018年5月18日
同じナビサービスを運営する2社から講演者がでるということで、業界的な話とアジャイル的な話の両方を期待していきましたが、結果どちらも聞くことができ大満足な講演会でした！！
特に吉尾さん(3番手の発表)と小田中さん(4番手の発表)の発表では、とても具体的なアジャイルプラクティスが紹介され、メンバーでない私もまるでそこに参加しているような感覚を覚えると共に、実際のイメージを持つことができとても勉強になりました。マネージャーのお二人がとても嬉しそうにその成果を発表する様子が印象に強く残っています。
全ての発表を通じて、円滑で健全で活発なコミュニケーションが多くの問題を解決する様子を見ることができました。なかなか実行することは難しいですがスクラムなどのフレームワークにも頼りながら、明日からでも頑張ってみたいです。
ちなみに最後のパネルディスカッションの際のグランドルール「質問じゃなくて意見表明でもいいですよ」はとても感動しました！そうそうこういう時、まとまってないけど絶対クリティカルだと思う感想を抱いて、でも言っていいのか迷っているうちに時が過ぎるよね。。。と思って聞いていました。
以下は講演とパネルディスカッションの内容です。 ※正確に表現することを心がけていますが、聴きながら取ったメモですので曖昧な記述や誤った記述が含まれるかもしれません。ご容赦ください。
講演内容
オープニングトーク
- ナビタイムと「駅すぱあと」のヴァル研究所が同じイベントにでるって、なかなかやりにくかったんじゃないですか？
- ナビタイム社内では割とスムーズでした。
- ヴァル研究所もですよ。ちょっと社内がざわついたけど。
- 会場は今年のGWにできたらしく、きれいですね。
株式会社ナビタイムジャパン 村川さん
＜テーマ＞「ナビタイムの働き方改革」
※諸事情*1でトップバッターのヴァル研究所 下村さんが順番繰り下げ
第1の課題「サービスを出せていない」
2007年まで順調に新規サービスを生んでいたナビタイムだが、2008年ごろ新しいサービスが出なくなってしまった。
- 要因：何をするにもコストがかかりすぎる
- 階層構造が厚く、かかりすぎる調整コスト
- 「意味がない」「決まらない」会議多数。階層構造ゆえなんども開催される定例。役職者のパフォーマンスは低下
- 解決策
- 技術ごとの部ではなく、サービスをもつPJ*2を創設。
- 部長以外の役職を廃止し組織をフラットに
- 結果
- 会社がフラットになりました。
- PJは評価教育を切り離し、サービス開発に専念できた。PJ内に様々なロールの社員がおり、能動的な開発。開発速度が向上。
第2の課題「事業 VS ACTS(研究開発)」
事業を行なっているPJと研究開発の間で相互理解が不足してしまった。
- 解決策
- ジョブローテーションを充実させ、横断的な知識を持つゼネラリストを増やした。
- 全PJの報告会を誰でも質問、資料全公開なオープンな場にするなど、コミュニケーションの活性化に努めた。
- 結果
- プレスリリース増加(≒新規サービス増加)
- 有料会員数増加
- 残業時間削減(平均13時間)
株式会社ヴァル研究所 下村さん
＜テーマ＞「駅すぱあとの開発現場 - 維持する30年とは」
駅すぱあとの歴史
- 1988年発売 首都圏版 当時、ヴァル研究所の本流ではなかった
- バブル崩壊で経費の削減が求められた時、定期分割機能がヒット
- 当初はデスクトップアプリとエンジンが一体だった。mac対応をきっかけにエンジンを分離、他の商材でも活用するようになる。
Cで実装
- コアエンジンはスピードが命であり、Cで実装している。
- Cで直接使うのは面倒なので、バインディングを多く作った。
増え続ける機能
最初の開発者は3名だった。30年続いているソースリポジトリ。「ソース腐ってんじゃないの？」。当時はバージョン管理もなかったが、今はgitに移行中
- 機能的にも増えてきた。
- テストコードがろくになかった
- ノウハウが溜まっている検査チーム(QAチーム)が助けてくれた。が、テスト実行に12時間
- 次にインフラチームが助けてくれた。Azure使って並列化、自動化し、50分でできるようになった
- どちらも別チームから「越境」に助けられた。
- 現在は本体にも単体テストを追加
- 日々のメンテナンス
- ダイヤ改正、臨時ダイヤ、新しい料金体系、新規路線などは外部からの情報で常にメンテナンス
- サポート、ユーザーレポート、エゴサ
- 実地調査や事業者からのデータ
まとめ
- モブプロ、モブワークで知識を広めている。
- 「越境」するチームの力に支えられてきた。
株式会社ヴァル研究所 吉尾さん
＜テーマ＞「駅すぱあと バス制作だってアジャイル・プラクティス！」
バス制作チーム
吉尾さんがリーダーを務めるバス制作チーム
- バス社局からもらったデータを駅すぱあと用データに変換するバスデータの保守部隊
- 半数がプログラミング経験なし
課題
吉尾さんが配属された当時、全ての業務は非効率で辛いものになっていた。
- 状況
アジャイルプラクティスを実践
- 朝会
- KPTでふりかえり
- ペア作業
- 属人化解消が目的。
- それまでの担当者の手順に「なんで？」「わからん」というツッコミが入り、レビューの側面も
- 星取表
- カンバン
- 目的は「メンバーの状態」「タスクの状況」「タスクの属性」の見える化
- 朝会のコミュニケーションツールにもなっている。
- スプリント
- 計画会議で始まりふりかえりに終わる、一定の時間枠を繰り返す。「終わり」を決めることで恒久的な作業にメリハリがつく。
- DONEのみが成果であり価値
- 見積もりにはプランニングポーカーを使用。徐々に感覚値の精度が向上し、現在では2ヶ月先まで見通せるように。
- バーンアウトチャートを使った進捗の共有
- 全てはコミュニケーションに繋がっていた。
結果
- 対応バス社局数が増加、4/1改正対応数も改善、作業時間は減少
- 吉尾さん指標で作業効率は3年で160%に!!
- これからもたゆまぬカイゼンを
株式会社ナビタイムジャパン 小田中さん
＜テーマ＞「ナビタイムR&D部門がたどるカイゼンのキセキ」
自己紹介
- ACTS ルートグループ責任者
- ACTSのミッション
- 新価値提供(知って使ってもらう)
- 品質改善
最初のチーム「R&D部門」
- ゴールからずれるチームメンバー
- スキルが高く、突き詰める研究者肌な開発者たち
- その性格ゆえに、気になることがゴールからずれ、試行錯誤で堂々巡りする。
- デイリースクラム・スプリントレビューで高頻度に軌道修正
- 結果
- ゴールからのズレがなくなった。
- 最初に出なかったことは後回しになってしまった。
- ふりかえりシートの不備から、Problemがたくさん並ぶだけになってしまい、プロセスのカイゼンが進まず。
第2のチーム「チャットボット開発」
- タスクが無限に増える
- スキル、開発速度共に申し分ないプロフェッショナルたち
- それゆえ、周囲からタスクをどんどん積まれてしまう。
- 必要なものにフォーカス
- ユーザーストーリーやPDCAサイクルを作り、ログとユーザーボイスで正確性を担保
- プランニングは各メンバーに委ねた。
- 結果
第3のチーム「乗り換え経路探索エンジン開発」
- チームの目標達成進捗がよくない
- 若手が多い
- 個人のタスクが膨大
- 「よろしいならばスクラムだ」
- ようやくスクラム開始
- スクラムの完全導入すると、個がチームになった。
- 終電後ルート機能をイテレーティブに改善。目標を達成し、社内で表彰された。
まとめ
- フォーマルなスクラムは強力。型を少し崩してチームに最適化するのもあり。
- スクラムに懐疑的だった社員が「やりながらカイゼンしていけばいいよ！」
- スクラム経験者同士のハンガーフライトを実施した。
- R&Dと事業側、エンジニアとデザイナーが繋がるところをみた。つながりをどんどん増やしていきたい
パネルディスカッション(抜粋)
質問だけでなく意見表明もウェルカム!
「スクラムを導入するのは大変？」
- 小田中さん「超大変」「足かけ2年ぐらいかけた」
- 吉尾さん「開発の時はマッチョにやっていた。朝会などやりやすいところからやれば良い。」
「朝会とリモートワークは相反するのでは？」
- 吉尾さん「ハングアウトを使った。」
- 小田中さん「slackのGeekbotに昨日やったこと今日やることを投げて共有」
「どんな人を採用しているのか」
以上
