1. H o u- N e t P r o j e c t P r e s e n t’
s
GeneXusを利用した基幹業務システム開発
Copyright© NIHONHOUSING

2. ■会社概要
日本ハウズイング株式会社 1958年創業
資本金 2,492百万円
事業所 46拠点
職員数 5,098人
本社ビル（東京・新宿）
主要業務 マンション管理事業
ビル管理事業
不動産管理事業
営繕工事業
顧客数 約37.5万戸
1

3. ■ 不動産業界の仕組み
管理＝建物の価値や機能を保全する仕事
企画
日本ハウズイングの事業領域
マンション管理
管理
ビル管理
建設
不動産管理
仲介 営繕工事
販売
2

4. ■ マンション管理とは
Hard 『建物を守る仕事』
建物の
点検
住民の意見
『犬を飼いたい』
『ゴミ置き場にカラスが・・』
修繕 『段差があって車椅子が通れない・・』
『ここで子供が遊んだら危ない・・』
『防犯上不安だな・・』
清掃 『住民同士の交流の場があったら』
『イベント（お祭り等）を開催したい』
Soft 『住みよい環境を作る提案』
3

5. ■ ビジネスモデル
管理委託料
月々○○○○円
報 酬
サービスの提供
建物管理・清掃管理
管理費等会計管理
管理組合運営サポート
コミュニティサポート
安心快適生活 等々
ストックビジネス
Stock Business
4

6. ■ 管理業界の特徴
●安定した市場
建てられたマンションを市場としたマン
ション管理業界の安定性
●安定したビジネスモデル
景気の動向に大きく左右されることはな
く、安定した収益を上げることのできる
安定
ビジネスモデル＝ストックビジネス
Stability
●拡大する市場
毎年建てられるマンションのストック数
は年々増加しており、マンション管理市
場は拡大している。
●管理ニーズの増加
成長 築２０年を超えるマンションの増加によ
る管理ニーズの増加
Growth
5

7. ■ 受託戸数推移（平成14年3月～平成24年3月）
87.3％ 375,412
370,000
364,364
リプレース 353,171
350,000
管理会社の変更 340,467
330,000 328,411
310,000 312,261
297,736
290,000
284,786
過去10年平均年間増加戸数
270,000
15,451戸
266,755
（2011年度上位10社平均5,863戸）
250,000
247,247
230,000
221,597
210,000
Mar.2002 Mar.2003 Mar.2004 Mar.2005 Mar.2006 Mar.2007 Mar.2008 Mar.2009 Mar.2010 Mar.2011 Mar.2012
6

8. ■ 日本ハウズイングの目標と取り組み
【 目 標 】 マンション管理業界におけるナンバーワン企業のステイタスの確保と確立
・新しいサービスや新商品の積極的な研究・開発
・新システム導入による業務の簡素化・作業効率化
・専門性の高い人材育成による顧客ニーズへの対応
・コンプライアンス体制の強化、内部統制の徹底による経営の透明性・健全性の更なる向上
【 取り組み 】 駆け付け無料
平成19年4月より「顧客満足度の向上」を目的として、業界に先駆けて
4,000を超える多彩なメニューによる専有部サービスを開始
マンションを対象とした省エネ型照明による「プログラム型排出権削
減事業」としては国内初
転勤留守宅管理サービス、室内リフォーム工事、イベント代行サービス、マンション居住者向
け情報誌「Housing News」創刊、「Housing News Online」開始、「エコするマンションの会」
事業計画化、諸問題に対するセミナーの開催等、すでに開始しています。
7

9. ■ 開発システム
名称 Hou-Net（ハウネット）
目的 現システムの抱える問題を解決しながら、当社の今後の業務に対し
【効率の良い、使いやすいシステム】を構築する
問題点
1. 個々のシステムが持つデータが、有効活用されていない。
2. 業務セグメント毎にシステム化され、業務プロセスが標準化されていない。
3. システム間の連携で障害が発生するリスクが増えている。
4. ハードウェアやソフトウェアが老朽化し、メーカーサポートが終了する。
5. 蓄積データの保存期限などが明確化されず、データが巨大化し、システムを
圧迫している。
6. セキュリティー機能が弱い。
7. 内部統制（ＩＴ統制）に準拠する仕組みが整っていない。
機能数 約1100機能
8

10. ■ Project History
2009年2月～ 2009年11月 要件定義・基本設計 → 成果物の信頼性が低い
2009年12月 開発ベンダー再検討開始 → IT Frontier社に決定
2010年2月 基本設計再スタート → 時間が足りず
2010年8月 リカバリプラン → GeneXusの検討開始
2010年10月 開発をウォータホールからアジャイル型に転換
ワークフレームをGeneXusに決定
2010年11月 イテレーション開始
2011年3月 東日本大震災勃発
2011年4月 フロント業務機能 先行リリース開始
2011年11月 並行稼働開始判断 → Go判定
2011年12月 業務トライアルとして並行稼働開始
2012年4月 単独稼働（旧システムのサンセット）
機能追加や改修のため、GeneXusでの開発は現在も続いている。
9

11. ■当社固有の複雑な業務モデルのシステム統合へのチャレンジ
当社のモデルはB to Bの側面とB to Cの側面を合わせ持つ。
縦割り組織（マンション、ビル、不動産、営繕）で運営されてきた歴史があり、
システム統合は容易でなく、用語もバラバラ。
新規物件の開拓、コンペを重ねて受注を拡大し国内トップシェアに上り詰めた。
そのため、個々の顧客の要望をきめ細かく実現
⇒個別の手続きも多数。
業界内の競争が激化する中、トップシェア維持のためには、個別サービス拡充と
効率・生産性向上の相反する課題を克服する必要あり。
ＩＴ活用でどのように貢献すべきか？
10

12. ■ビジネス要件把握の難しさ
個人、組織、会社の要求
代表者だけでは決められない
部署毎に優先順位が異なる
個別対応か？
標準化か？ 要件が
把握しきれない
わからない
頻繁に変わる
時間をかけて繰り返し議論しても
計画時点で本当に必要な機能を充分に洗い出すことは困難
11

13. ■GeneXusとの出会い
想定したボリュームより膨らんだ為、スケジュール、費用面等について苦慮
開発ベンダー（IT Frontier社)より、GeneXusを用いたアジャイル開発の提案）
採用後、変更をある程度許容し、吸収しながら進めることができた。
⇒今必要な機能の議論に割り切ることができた。
⇒プロジェクトで３か条を定め要件が膨らみすぎないよう統制もおこなった。
開発工程が自動化されるため、実際に動作する試作品を何度も検証しながら要件を
引き出すことができた。
成果物をイメージしやすく、エンドユーザ、システム企画部、開発者間の意思疎通
がスムーズになった。
仕様検討により多くの時間を使うことができ、約1100機能という大規模開発をベン
ダー協力のもと実現させた。
12

14. 2012年3月3１日にサービスイン
13

15. ■大規模基幹システム開発の課題
サブシステム単位の仕様検討となりがち（ハウネットもそうでした）
全体の整合性確認、最適化が後工程にまわる。
⇒手戻りはプロジェクトにインパクトを与える。
→しかし今回はGeneXusにより全体最適化のためのプログラムの作り直し
をサービスイン直前のたった２か月間で完了した。
当社のトランザクションデータ（約９千万件）を処理するため、システムレスポン
スの向上には重点をおいた。
GeneXusはコードを自動生成するため、パフォーマンスを意識せず実装してしまう
ため、パフォーマンスチューニングは、想定外の対応が必要であった。
GeneXusによる開発は、仕様変更によりテーブル構造が大きく変化するため、旧シ
ステムからのデータ移行には想定より労力を要した。
プロジェクトの進め方においてはこれらを考慮する必要がある
14

16. ご静聴、ありがとうございました
15