2015/5/22 kintone hive 株式会社AmidA 講演資料

1. kintoneが可能にする
「ブロック＋紙ねんど」スタイルの開発

2. AmidA / ハンコヤドットコム
 1998年から印鑑ECサイトを運営
 現在は、年間27万件以上の出荷実績
 日本で最初に Google Adwords 広告を導入

3. 今回のプレゼン内容
1. 開発プロジェクトについて
2. ブロック＋紙ねんど型の実装
3. 情報インフラとしての活用

4. パート1
開発プロジェクトについて

5. Kintone導入のきっかけ
社 内 シ ス テ ム
リ ニ ュ ー ア ル の 失 敗

6. 前回はなぜ失敗したのか？
× リリースまでに約1年半かかった
× 完成品が要望に沿わず作り直しが多発
× 高額な開発費が成果物と見合ってなかった

7. プロジェクトに期待されていたこと
 現在の業務の運用効率をアップして
 将来の事業拡大に対応できるシステムを
 低予算で短期間にリリースする
...しかも今回は
絶対に失敗できない

8. Kintoneを選んだ理由
柔軟性と手軽さの両方を兼ね備えている
低予算でスタートでき規模拡大にも対応
前職で導入、効果を実感できたので安心
＝全てをクリア

9. 今回の適用範囲
ECサイト バックヤード 基幹システム
ここから導入

10. プロジェクトとして成功
〇 初期バージョンを約1ヶ月半でリリース
〇 利用者の完成イメージとギャップなし
〇 必要な部分だけ外注して開発費削減

11. 導入効果もすぐに実感できた

12. 隠れた成功の鍵 - プロジェクトの進め方
① プロトタイピングでギャップ解消
② スクラム型プロジェクト管理
③ リリースと修正を高速で繰り返す

13. テスト対象ユーザーのみ公開
フィードバック
① プロトタイピングでギャップを解消

14. ① プロトタイピングでギャップを解消
ヒアリング
画面
イメージ
機能
テスト
リリース
80%の完成度で確認
開発者 利用者
フィードバック
フィードバック
必要な要件や要望
フィードバック
テスト画面で項目確認
100%完成リリース
要望リスト作成

15. ② スクラム型のプロジェクト管理
（出典: http://www.ryuzee.com/）

16. ② スクラム型のプロジェクト管理
要望リスト リリース分 今週分
×6週間
1か月半で
リリース

17. ③ リリースと修正を繰り返す
① プロトタイプで見てるから安心
② ヒアリングで確認できてるから安心
③ 何かあってもすぐ修正できるから安心
現場からリリースOKが出やすい

18. ③ リリースと修正を繰り返す
要望リスト リリース分 今週分
×6週間
初回リリース
修 正 ・ 更 新
確定版リリース

19. KPTを使った振り返り – プロジェクト
 基幹システムへの拡張
Keep
 リリース時の撤退ラインが決まって
なかったことによる混乱
Problem
Try
 プロトタイピング
 スクラム型のプロジェクト管理
 リリースと修正の繰り返し

20. 続けること – プロジェクト
Keep
Problem
Try
 基幹システムへの拡張 プロトタイピング
 スクラム型のプロジェクト管理
 リリースと修正の繰り返し
 リリース時の撤退ラインが曖昧で、
バグ発生時に旧システムに戻すか、
新システムのまま行くか混乱

21. 改善すべきこと – プロジェクト
Keep
Problem
Try
 基幹システムへの拡張
 リリース時の撤退ラインが曖昧で、
バグ発生時に旧システムに戻すか、
新システムのまま行くか混乱
 プロトタイピング
 スクラム型のプロジェクト管理
 リリースと修正の繰り返し

22. 試してみたいこと – プロジェクト
 基幹システムへの拡張
Keep
Problem
Try
 プロトタイピング
 スクラム型のプロジェクト管理
 リリースと修正の繰り返し
 リリース時の撤退ラインが曖昧で、
バグ発生時に旧システムに戻すか、
新システムのまま行くか混乱

23. パート2
ブロック＋紙ねんど型の実装

24. 前回の開発
フルスクラッチ開発
紙ねんどで0から手作り
＝

25. フルスクラッチの利点
〇 細かい要望にも応えられる自由度の高さ
〇 プラットフォーム固有の制約が少ない
〇 これまで培ったスキルや経験が生かせる

26. フルスクラッチの問題点
× リリースや修正に時間がかかる
× エンジニアの開発コストがかさむ
× 全ての要望に対応しないといけない空気

27. 今回の開発
ブロック（ミドルウェア）
紙ねんど（フルスクラッチ）
＋

28. ブロック部分
① kintone 基本フォーム
② kintone 画面カスタマイズ
③ DataSpider等 他のミドルウェア

29. ブロック部分① 基本フォーム

30. ブロック部分② 画面カスタマイズ

31. ブロック部分③ 他のミドルウェア
データ連携＝
帳票印刷＝

32. 紙ねんど部分
① kintone API連携
② kintone カスタマイズビュー
③ 外部プログラム フルスクラッチ構築

33. 紙ねんど部分① API連携
API通信 API通信

34. 紙ねんど部分② カスタマイズビュー
HTMLで画面の自由度アップ

35. 紙ねんど部分③ フルスクラッチ
他の方法で実装できないモノも
紙ねんど（フルスクラッチ）
があるから安心

36. 隠れた成功の鍵 – 自社開発と他社パーツのバランス

37. システム構成 – v1.0（開始前）
カート
モール
在庫
出荷売上
販売管理
ページ
発注 入荷
与信 請求
指示書
指示書
受注 出荷登録 ML
外注フロー
印影 Tail
商品
納品書
送り状
ピッキング
リスト
出荷フロー受注フロー
製造フロー
分析
DB

38. カート
モール
在庫
出荷売上
販売管理
ページ
発注 入荷
与信 請求
指示書
指示書
受注 出荷登録 ML
外注フロー
印影 Tail
商品
納品書
送り状
ピッキング
リスト
出荷フロー受注フロー
振分
製造フロー
分析
DB
システム構成 – v1.7（現在）

39. カート
モール
在庫
出荷売上
販売管理
CMS
発注 入荷
与信 請求
指示書
指示書
受注 出荷登録 ML
外注フロー
印影 Tail
商品
納品書
ピッキング
リスト
出荷フロー受注フロー
振分
製造フロー
分析
DB
送り状
システム構成 – v2.0（予定）

40. KPTを使った振り返り – 実装
 顧客サポートアプリ
 コールセンターアプリ
 BI分析ツール
Keep
 エンジニアの確保ができない可能性
Problem
Try
 ブロック＋ねんど型の開発
 社内エンジニアの担当制
 外部パートナーへの協力依頼

41. 続けること –実装
Keep
Problem
Try
 顧客サポートアプリ
 コールセンターアプリ
 BI分析ツール
 ブロック＋ねんど型の開発
 社内エンジニアの担当制
 外部パートナーへの協力依頼
 エンジニアの確保ができない可能性

42. 改善すべきこと –実装
Keep
Problem
Try
 顧客サポートアプリ
 コールセンターアプリ
 BI分析ツール
 エンジニアの確保ができない可能性
 ブロック＋ねんど型の開発
 社内エンジニアの担当制
 外部パートナーへの協力依頼

43. 試してみたいこと –実装
 顧客サポートアプリ
 コールセンターアプリ
 BI分析ツール
Keep
Problem
Try
 エンジニアの確保ができない可能性
 ブロック＋ねんど型の開発
 社内エンジニアの担当制
 外部パートナーへの協力依頼

44. パート3
情報インフラとしての活用

45. 情報インフラとしてのkintone
情報を蓄積していく部分 コミュニケーション部分

46. AmidAの場合
半年で100以上のアプリを作成

47. 利用している範囲
① 社内全体での情報共有
② 外部パートナーとの連携
③ 各部門ごとの業務の効率化

48. 利用範囲① 社内全体アプリの例
社内連絡やQ&Aで情報の見える化

49. 利用範囲② 外部パートナーアプリの例
海外BPOパートナーのタスク管理

50. 利用範囲③ 各部門アプリの例
マーケティング施策の管理
■担当者からの施策内容・結果レポート ■管理職からのアドバイス

51. 部門ごとのアプリを作る目安
① 部門またはチーム全員が使う
② 便利さが kintone > Excel
③ ずっと保管すべきパスワード等

52. アプリの作り方
By 鳥井 信治郎（サントリー創業者）
完璧を目指さず、まずはスタート。
”やってみなはれ”

53. アプリの作り方
とは言え…
”ブラッシュアップ＝作り変え”
することを前提で設計した方が安全
安全 第一

54. データ移行について
アプリ作り変え＝要データ移行

55. 簡単に移行できないデータ①
×テーブル行
別アプリで作成

56. ×添付ファイル
簡単に移行できないデータ②
外部リンクへ変更

57. 隠れた成功の鍵 – 利用ユーザーの自由度
部門ごとに管理者
要望3
要望2
要望1
要望1
要望2
要望3

58. KPTを使った振り返り – 情報インフラ
 社内ペーパーレス化
Keep
 運用開始タイミングが明確でなく、
利用者ごとに温度感がバラバラ
Problem
Try
 ボトムアップの業務改善

59. 続けること – 情報インフラ
Keep
Problem
Try
 社内ペーパーレス化 ボトムアップの業務改善
 運用開始タイミングが明確でなく、
利用者ごとに温度感がバラバラ

60. 改善すべきこと – 情報インフラ
Keep
Problem
Try
 社内ペーパーレス化 ボトムアップの業務改善
 運用開始タイミングが明確でなく、
利用者ごとに温度感がバラバラ

61. 試してみたいこと – 情報インフラ
 ボトムアップの業務改善  社内ペーパーレス化
Keep
Problem
Try
 運用開始タイミングが明確でなく、
利用者ごとに温度感がバラバラ

62. これからも改善を続けていきます
≫ http://www.amida.co.jp/
≫ http://www.hankoya.com/