株式会社Casa TECH BLOG

日々、FAX/電話/紙等リアルと戦う事業系IT部門の戦士たちのブログです。

アナログ事業会社でシステム開発チームを立ち上げる①

こんにちは、CasaでいくつかのWEBサービスのプロダクトマネージャーをしてます、穂高です。

アナログな不動産業界で家賃保証事業をやっているCasaで、WEBサービスを開発を進める中で、課題をどう改善したか、どうやって改善しようとしているのかを紹介していきたいと思います!

Casaでシステム開発を行うときに困っていたこと

もともとSIerなどシステムの開発がメインの会社にいた自分にとって、Casaという事業会社、それもアナログな業界での開発は想定外のことが盛り沢山でした😭

  • 開発に手戻りが多い!
    • 画面仕様書で認識合わせをし、その通りに作っても受け入れのテストで仕様時には要件の変更が発生する
  • 特定少数ユーザーのための要望が強い!
    • 現行の業務ありきで、そのためのWEBサービスになっているため数人しか使わない特殊な業務への対応が求められる、、、
  • 優先順位が突然入れ替わる!
    • 優先順位を誰が決めるのか、決めたのかが社内で統一されていないため、優先順位が突然入れ替わる、、、、
  • 基幹システムのDBが複雑すぎる!
    • 基幹システムが古く、場当たり的な?メンテナンスが繰り返され、正規化されていないテーブルが多いし、使われていないテーブルもたくさんある、、、
    • 似た項目や同じ内容の項目が多くどれが正解か、どの場合にどれを使うべきなのか調査に時間がかかる、、、
  • 問い合わせの電話がめちゃくちゃ多い!
    • リリース前に説明会をした内容なのに質問の電話が沢山、、、
    • そもそもパソコンの使い方の電話からかかってくる状態、、、、

これらの中で今回は開発の手戻りについて、どう工夫して改善してきたかを紹介します!

開発に手戻りが多い!

私が3年前に、Casa情シス部門にジョインした際は、開発は外部の方にお願いしており、社内の調整とベンダーコントロールが役割でした。 開発のメンバーが手戻りが多い!って悲鳴をあげるのはそれまでの開発現場でもあることでしたが、画面仕様書など要件や設計段階で認識合わせした前提すらひっくり返る状態でした。

エクセル方眼紙を駆使した仕様書から最終形が結びつかない!

当時要件の認識合わせや仕様書としてベンダーの方に書いていただいていたのは、下のようないわゆる画面仕様書。

外部仕様書キャプチャ
当時利用していた外部仕様書

SIerやお堅い現場で教育を受けた自分にとってはとても見慣れていて、とてもわかりやすい仕様書でしたが、画面仕様書やワイヤーフレームと最終形とを一致させることはシステム開発をしている人以外にとっては一般的なことではないことを痛感しました。
(開発側としては)こんなに丁寧に仕様書を作って認識合わせをしたものの通りに実装しても、業務部門には分かりにくい仕様書であるため、受け入れテストで要件をひっくり返されてしまっていました。

作り方を工夫をしなければ!

このままではお金はかかるわ、エンジニアのモチベーションは下がるわ、開発部門の信頼はなくなるはで開発自体が止まりかねない!
そこで1年以上をかけて少しずつ、時には大胆に下記のように開発のプロセスを変えていきました。

  1. 開発をAgileに近づける
  2. 動くモックから作り始める
  3. 内製の開発チームを立ち上げる

1. 開発をAgileに近づける

もともとベンダーさんに請負契約でお願いした最初の経緯もあり、ウォーターフォールで開発は進んでいました。
請負った側からすれば決めたはずの仕様変更が多く、開発は終わらないし会議の雰囲気は悪くなる一方、、、
そこでAgileに開発を寄せて、フィードバックを受ける前提で進んでいくようにしました!

2. 動くモックから作り始める

フィードバックを受けながら進むようにしたものの、フィードバックをもっと早くもらわないと開発の効率が悪すぎるので、途中成果物を最終形に近いものにすることにしました。
プロトタイプをエンジニアでも作れるツールProttを利用して、動く紙芝居を作るようにしたりもしましたが、今は機能が空っぽのモックの画面だけをまず実装して、ブラウザで実際に触ってもらって確認をしています。
実際に画面同士がつながって触れることの効果は大きく、これでかなり手戻りは無くなりました。

3. 内製の開発チームを立ち上げる

画面レベルでの要件のずれがなくなると、こちらの要件を業務を知らない外部のベンダーさんに伝言ゲームすることで生まれる誤差が目立つようになってきました。仕様として伝えたじゃん!みたいなことが多くなってきたのです。
伝え手も受け手も能力が必要ですが、なかなか複雑な業務とお金が絡むこともあり、外部に委託すること自体が難易度が高く、当時の開発体制ではそこを乗り越えることができませんでした。
そこで業務部門へのヒアリングを、もっといつでも手軽にできるように内製の開発チームを立ち上げて、仕様の調整から開発、リリースまでを完全に内製化しました!
内製化するって構想してから完全に移行するまで半年くらいかかり、これはこれで大変だったので別の機会に詳しく書きたいですね。


細かいことをあげればキリが無いですし、まだまだ伸び代だらけですが、システムも開発プロセスも都度見直しながら改善して進んで当時よりはだいぶ良くなったと実感しています。

今後もどんどん改善しながら、よかったことをシェアできればと思います!