SlideShare una empresa de Scribd logo
1 de 59
Descargar para leer sin conexión
初心者による初心者のための
システム作りの流れ
1
株式会社セレス
サービスエンジニアリング部
安藤 雄介
2
▶ ハッシュタグ
▶ #ceres_tech
▶ #勉強会
▶ #初心者
Twitterアカウント
せれすたん
3
ACCESS POINT
▶ SSID
AP01-3D95A-G
▶ PASS
BA0BA8F8F2FFF
4
会場の使い方・注意事項
▶ お手洗いは20階に降りていただき、
エレベーターホールを背にして右手が男性、左手が女性です。
▶ ゴミ箱は後ろにあります。
燃えるごみ、ビン、カン、ペットボトルで
分別にご協力お願いします。
▶ 喫煙所はありません。ご容赦ください。
▶ Wifiと電源を用意しています。
Wifiはスタッフがお渡しした紙を見てください。
▶ 写真撮影しています。
終了後TwitterやWantedlyなどに掲載します。
顔出し・掲載NGの人はスタッフにお声掛けください。
5
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
6
自己紹介
× 安藤 雄介
× セレス入社4年目
× モッピーのシステム担当
× 元Java屋だったけど、現在はPHP屋
× アナログゲーム部の部長
× うさぎ好きの慎重派エンジニア
(らしい。マネージャ評価)
7
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
はじめに
システムを0から作った事がある方は
いらっしゃいますか?
8
× 保守運用が多かった
× 技術力に自信が無かった
× 手をあげてなかった
9
「新規システムをしたいです」
完全新規の社内システムへ
私は最近までありませんでした。。
10
要件定義
フレームワーク等の選定
CodeIgniter 3による実装
リリース
やったこと
11
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
1212
作ったシステム
社内向けの経理用システム
1313
何故作ったか
運用コストが高い
調査コストがかかる
1414
運用コストが高い理由
紙運用…
1515
調査コストがかかる理由
紙運用の為、検索不可…
機能
× 反社チェック
× スコアリング
× 資料管理
体制
私 上司
同僚
経理Aさん
経理Bさん
本部長
自社開発(ウォーターフォールモデル)
1818
利用イメージ
システム上で完結
スケジュール
18/06/14
~
18/07/10
要件定義
18/07/11
~
18/9/30
開発
18/9/30
リリース
2018/06/14 ~2018/9/30 (3カ月半)
20
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
一般的な要件定義
× ユーザ要求のヒアリング
× 要求の細分化
× 要件定義書の作成
一般的な要件定義のスキル
× コミュニケーション
× 具体的なシステムをイメージ
× 完成までの工程を考える
× ドキュメント化
一般的な要件定義の流れ
ヒアリング
ヒアリング
アクセス分析
自社・他社分析
課題設計
ワークショップ
コンセプト立案
仮説立案
情報設計
一般的な要件定義の成果物
1.業務要件
1-1.システム化の背景・目的
1-2.問題/影響/原因/対策など一覧
1-3.システム化の対象範囲
1-4.業務機能構成表
1-5.ビジネスプロセス関連図
1-6.現行業務フロー
1-7.新業務フロー
2.機能要件
2-1.システム機能階層図
2-2.画面一覧
2-3.画面遷移図
2-4.画面レイアウト
2-5.帳票一覧
2-6.帳票概要
2-7.帳票レイアウト
2-8.バッチ処理一覧
2-9.概念データモデル(ER図)
2-10.テーブル一覧
2-11.テーブル定義書
2-12.外部システム関連図
2-13.外部インターフェース一覧
2-14.外部インターフェース定義書
3.非機能要件
3-1.ユーザビリティ及びアクセシビリティ要件
3-2.システム方式要件
3-3.規模要件
3-4.性能要件
3-5.信頼性要件
3-6.拡張性要件
3-7.上位互換性要件
3-8.継続性要件
3-9.情報セキュリティ要件
3-10.情報システム稼働環境要件
3-11.テスト要件
3-12.移行要件
3-13.引継ぎ要件
3-14.教育要件
3-15.運用要件
3-16.保守要件
https://pm-rasinban.com/rd-doc
多い
今回のプロジェクトの場合
× 自社の社員にヒアリング
× 成果物作成は不要
× 要件の整理
× システム化イメージの共有
要件定義で一番必要なものは
なんだろうか?
26
愛
27
大変だったこと
× 運用の把握に時間がかかった
× 要件が頻繁に変わった
× 認識の相違が頻繁に起こった
× 既存業務からの移行
大切なこと
歩み寄りの精神
要件定義の仕方
× 資料を全部出してもらう
× 現状業務のヒアリング(MTG)
× 例える時は身近なもので
× 情報整理・システム化イメージ
学んだこと
× 資料を全部出させる
× 調整事項は議事録として残す
× プロットの絵を書く
× 初回データについて認識合わせ
一休み★
5分間の休憩をはさみます
33
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
フレームワークの選定
に必要な観点は?
34
パフォーマンス
と
メンテナンス性
35
36
パフォーマンス
https://github.com/kenjis/php-framework-benchmark
37
社内利用状況から選定
× CodeIgniter 3
× Slim
× Lumen
× Zend Framework
× Laravel
38
パフォーマンス検証
1. 検証環境を用意
2. フレームワークの最新版を導入
3. パフォーマンス検証
39
パフォーマンス検証用ツール
Apache bench
41
Apache bench(結果)
Concurrency Level: 10
Time taken for tests: 0.383 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 208000 bytes
HTML transferred: 190100 bytes
Requests per second: 261.28 [#/sec] (mean)
Time per request: 38.274 [ms] (mean)
Time per request: 3.827 [ms] (mean, across all concurrent requests)
Transfer rate: 530.72 [Kbytes/sec] received
42
パフォーマンスの結果
43
メンテナンス性
× 日本語の記事が多いか
× 日本語マニュアルがあるか
× 機能は多いか
× 新しめの参考書籍はあるか
44
メンテナンス性の結果
フレームワーク メンテナンス性の評価
CodeIgniter 3 〇
Slim △
Lumen △
Zend Framework △
Laravel 〇
45
総合
パフォーマンスが良く
メンテナンス性に優れた
CodeIgniter 3を採用
46
参考までに
PHP Web Framework Benchmark 2019(2019年08月05日に更新)
https://qiita.com/prograti/items/01eac3d20f1447a7b2f9
47
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
49
特徴
× 無料・軽量・高速
× MVC
× テンプレートエンジンがついてる
50
学んだ流れ
× ユーザガイドを確認
× チュートリアルを確認
51
ユーザガイド
https://codeigniter.jp/user_guide/3/
52
チュートリアル
53
使って良かったこと
❖ 日本語の記事が豊富
❖ 無料・軽量・高速
❖ 学習コストが低い
❖ ライブラリが多い
❖ ドキュメントが分かりやすい
54
知ってた方が良いこと
× 先に欲しい機能が有るか調べる
× 共通処理用のクラスを別途作る
× Configは環境で分ける
55
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
56
リリース時に困った事
× リリース漏れ
× メンバーと認識の乖離
× コマンドを手打ちしてミス
× 初回データが投入出来ない
× テーブル作成後確認漏れ
× リリース後の動作確認漏れ
57
リリース時の注意
× リリース手順書は必ず作成
× メンバーと認識すり合わせ
× コマンドは全て書く
× 初回投入データの投入方法を検討
× テーブル作成後確認
× リリース後の動作確認
58
目次
1. 自己紹介
2. はじめに
3. 今回携わったプロジェクト
4. 要件定義
5. フレームワーク選定
6. CodeIgniter 3による実装
7. リリース時の注意
8. まとめ
59
まとめ
× 要件定義は歩み寄りの精神
× パフォーマンスとメンテナンス性
× CodeIgniter 3はオススメ
× リリース手順書は作ろう
http://1.dev.lily.cloud.ceres.local/workflow/show/565
ご清聴
ありがとうございました
60
61
アンケート
❖ ご協力ください

Más contenido relacionado

初心者による初心者のための システム作りの流れ

Notas del editor

  1. 登記簿謄本…不動産所有者の氏名・住所、構造大きさなどが記載されたもの 反社チェック…取引相手に問題が無いか調査する機能 スコアリング…取引先との取引額を求める機能 資料管理…スコアリング時の必要な資料を保存 ユーザ管理…システム利用ユーザを管理 (社内システムが無かった為、別システムとして作成)
  2. https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
  3. https://geekly.co.jp/column/cat-technology/1903_059/
  4. https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
  5. https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
  6. https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
  7. 現在の運用の把握に時間がかかった (経理経験が無く、現在の運用も知らなかった為) 要件が頻繁に変わった (管理本部にシステム要件定義の経験者がいなかった為) プロットの絵をたくさん描いた (認識の齟齬が生まれがちだった為) 既存業務からの移行(初回データ)
  8. まずは、相手の持っている資料を全て出させ、 現在の運用と不足している会計知識を埋める 話した内容は全てredmineやメールで残す プロットの絵を書くと、以下の良い事がある 1.要件の変更を即座に認識合わせできる 2.画面数と画面の責務が明確になる 3.以上の利点から、結果的に見積もりが楽 (その代償として、かなりの労力が必要。。)