Copyright© NIHONHOUSING

H o u- N e t P r o j e c t P r e s e n t’ s

GeneXus を利用した基幹業務システム開発

Hou-Net Project■ 会社概要

日本ハウズイング株式会社 1958 年創業

資本金 2,492 百万円

事業所 46 拠点

職員数 5,098 人

主要業務 マンション管理事業ビル管理事業不動産管理事業営繕工事業

顧客数 約 37.5 万戸

本社ビル（東京・新宿）

2

Hou-Net Project■ 不動産業界の仕組み

管理＝建物の価値や機能を保全する仕事企画

日本ハウズイングの事業領域

マンション管理

ビル管理

不動産管理

営繕工事

建設

販売

管理

仲介

3

Hou-Net Project■ マンション管理とは

HardHard

SoftSoft

『建物を守る仕事』『建物を守る仕事』

『住みよい環境を作る提案』『住みよい環境を作る提案』

住民の意見『犬を飼いたい』『ゴミ置き場にカラスが・・』『段差があって車椅子が通れない・・』『ここで子供が遊んだら危ない・・』『防犯上不安だな・・』『住民同士の交流の場があったら』『イベント（お祭り等）を開催したい』

建物の

点検

修繕

清掃

4

Hou-Net Project

報　　酬報　　酬

ストックビジネスStock Business

サービスの提供サービスの提供

■ ビジネスモデル

管理委託料月々○○○○円

管理委託料月々○○○○円

建物管理・清掃管理管理費等会計管理管理組合運営サポートコミュニティサポート安心快適生活　等々

建物管理・清掃管理管理費等会計管理管理組合運営サポートコミュニティサポート安心快適生活　等々

5

Hou-Net Project■ 管理業界の特徴

安定安定StabilityStability

成長成長GrowthGrowth

● 安定した市場建てられたマンションを市場としたマンション管理業界の安定性

● 安定したビジネスモデル景気の動向に大きく左右されることはなく、安定した収益を上げることのできるビジネスモデル＝ストックビジネス

● 安定した市場建てられたマンションを市場としたマンション管理業界の安定性

● 安定したビジネスモデル景気の動向に大きく左右されることはなく、安定した収益を上げることのできるビジネスモデル＝ストックビジネス

● 拡大する市場毎年建てられるマンションのストック数は年々増加しており、マンション管理市場は拡大している。

● 管理ニーズの増加築２０年を超えるマンションの増加による管理ニーズの増加

● 拡大する市場毎年建てられるマンションのストック数は年々増加しており、マンション管理市場は拡大している。

● 管理ニーズの増加築２０年を超えるマンションの増加による管理ニーズの増加

6

Hou-Net Project■ 受託戸数推移（平成 14 年 3 月～平成 24 年 3 月）

リプレース管理会社の変更

210,000

230,000

250,000

270,000

290,000

310,000

330,000

350,000

370,000

221,597

247,247

266,755

284,786

297,736

312,261

328,411

340,467

353,171 364,364

375,412

過去 10 年平均年間増加戸数15,451 戸

（ 2011 年度上位 10 社平均 5,863戸）

過去 10 年平均年間増加戸数15,451 戸

（ 2011 年度上位 10 社平均 5,863戸）

87.3 ％

7

Hou-Net Project

■ 日本ハウズイングの目標と取り組み

転勤留守宅管理サービス、室内リフォーム工事、イベント代行サービス、マンション居住者向け情報誌「Housing News」創刊、「Housing News Online」開始、「エコするマンションの会」事業計画化、諸問題に対するセミナーの開催等、すでに開始しています。

【　目 標　】　マンション管理業界におけるナンバーワン企業のステイタスの確保と確立・新しいサービスや新商品の積極的な研究・開発

・新システム導入による業務の簡素化・作業効率化

・専門性の高い人材育成による顧客ニーズへの対応

・コンプライアンス体制の強化、内部統制の徹底による経営の透明性・健全性の更なる向上

駆け付け無料【 取り組み 】

平成 19 年 4 月より「顧客満足度の向上」を目的として、業界に先駆けて 4,000 を超える多彩なメニューによる専有部サービスを開始

マンションを対象とした省エネ型照明による「プログラム型排出権削減事業」としては国内初

8

Hou-Net Project■ 開発システム

名称 Hou-Net （ハウネット）

目的 現システムの抱える問題を解決しながら、当社の今後の業務に対し【効率の良い、使いやすいシステム】を構築する

問題点1. 個々のシステムが持つデータが、有効活用されていない。2. 業務セグメント毎にシステム化され、業務プロセスが標準化されていない。3. システム間の連携で障害が発生するリスクが増えている。4. ハードウェアやソフトウェアが老朽化し、メーカーサポートが終了する。5. 蓄積データの保存期限などが明確化されず、データが巨大化し、システムを圧迫している。

6. セキュリティー機能が弱い。7. 内部統制（ＩＴ統制）に準拠する仕組みが整っていない。

機能数 約 1100 機能

9

Hou-Net Project

■ 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 での開発は現在も続いている。

10

Hou-Net Project

■当社固有の複雑な業務モデルのシステム統合へのチャレンジ当社のモデルは B to B の側面と B to C の側面を合わせ持つ。縦割り組織（マンション、ビル、不動産、営繕）で運営されてきた歴史があり、システム統合は容易でなく、用語もバラバラ。

新規物件の開拓、コンペを重ねて受注を拡大し国内トップシェアに上り詰めた。そのため、個々の顧客の要望をきめ細かく実現

⇒個別の手続きも多数。業界内の競争が激化する中、トップシェア維持のためには、個別サービス拡充と効率・生産性向上の相反する課題を克服する必要あり。

ＩＴ活用でどのように貢献すべきか？

11

Hou-Net Project

■ ビジネス要件把握の難しさ

個別対応か？標準化か？

個人、組織、会社の要求代表者だけでは決められない

部署毎に優先順位が異なる

要件が把握しきれないわからない頻繁に変わる

時間をかけて繰り返し議論しても計画時点で本当に必要な機能を充分に洗い出すことは困難

12

Hou-Net Project

■GeneXus との出会い

想定したボリュームより膨らんだ為、スケジュール、費用面等について苦慮

開発ベンダー（ IT Frontier 社 ) より、 GeneXus を用いたアジャイル開発の提

案）

採用後、変更をある程度許容し、吸収しながら進めることができた。

⇒今必要な機能の議論に割り切ることができた。

⇒プロジェクトで３か条を定め要件が膨らみすぎないよう統制もおこ

なった。

開発工程が自動化されるため、実際に動作する試作品を何度も検証しながら要件を

引き出すことができた。

成果物をイメージしやすく、エンドユーザ、システム企画部、開発者間の意思疎通

がスムーズになった。

仕様検討により多くの時間を使うことができ、約 1100 機能という大規模開発をベ

ンダー協力のもと実現させた。

13

Hou-Net Project2012 年 3 月 3１日にサービスイン

14

Hou-Net Project

■ 大規模基幹システム開発の課題

サブシステム単位の仕様検討となりがち（ハウネットもそうでした）全体の整合性確認、最適化が後工程にまわる。

⇒手戻りはプロジェクトにインパクトを与える。 →しかし今回は GeneXus により全体最適化のためのプログ

ラムの作り直し 　をサービスイン直前のたった２か月間で完了した。

当社のトランザクションデータ（約９千万件）を処理するため、システムレスポンスの向上には重点をおいた。

GeneXus はコードを自動生成するため、パフォーマンスを意識せず実装してしまうため、パフォーマンスチューニングは、想定外の対応が必要であった。

GeneXus による開発は、仕様変更によりテーブル構造が大きく変化するため、旧システムからのデータ移行には想定より労力を要した。プロジェクトの進め方においてはこれらを考慮する必要がある

15

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

16