初心者による初心者のための システム作りの流れ
•Download as PPTX, PDF•
1 like•1,004 views
2019年9月11日(水)に開催しました、講義形式システム開発勉強会の資料です。 《参考》 ■Wantedlyのレポート記事 https://www.wantedly.com/companies/ceres-inc/post_articles/186255
Recommended
More Related Content
Featured
Featured (20)
初心者による初心者のための システム作りの流れ
- 2. 2 ▶ ハッシュタグ ▶ #ceres_tech ▶ #勉強会 ▶ #初心者 Twitterアカウント せれすたん
- 3. 3 ACCESS POINT ▶ SSID AP01-3D95A-G ▶ PASS BA0BA8F8F2FFF
- 4. 4 会場の使い方・注意事項 ▶ お手洗いは20階に降りていただき、 エレベーターホールを背にして右手が男性、左手が女性です。 ▶ ゴミ箱は後ろにあります。 燃えるごみ、ビン、カン、ペットボトルで 分別にご協力お願いします。 ▶ 喫煙所はありません。ご容赦ください。 ▶ Wifiと電源を用意しています。 Wifiはスタッフがお渡しした紙を見てください。 ▶ 写真撮影しています。 終了後TwitterやWantedlyなどに掲載します。 顔出し・掲載NGの人はスタッフにお声掛けください。
- 5. 5 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 6. 6 自己紹介 × 安藤 雄介 × セレス入社4年目 × モッピーのシステム担当 × 元Java屋だったけど、現在はPHP屋 × アナログゲーム部の部長 × うさぎ好きの慎重派エンジニア （らしい。マネージャ評価）
- 7. 7 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 9. × 保守運用が多かった × 技術力に自信が無かった × 手をあげてなかった 9 「新規システムをしたいです」 完全新規の社内システムへ 私は最近までありませんでした。。
- 11. 11 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 16. 機能 × 反社チェック × スコアリング × 資料管理
- 20. 20 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 21. 一般的な要件定義 × ユーザ要求のヒアリング × 要求の細分化 × 要件定義書の作成
- 22. 一般的な要件定義のスキル × コミュニケーション × 具体的なシステムをイメージ × 完成までの工程を考える × ドキュメント化
- 25. 今回のプロジェクトの場合 × 自社の社員にヒアリング × 成果物作成は不要 × 要件の整理 × システム化イメージの共有
- 27. 愛 27
- 28. 大変だったこと × 運用の把握に時間がかかった × 要件が頻繁に変わった × 認識の相違が頻繁に起こった × 既存業務からの移行
- 29. 大切なこと 歩み寄りの精神
- 30. 要件定義の仕方 × 資料を全部出してもらう × 現状業務のヒアリング(MTG) × 例える時は身近なもので × 情報整理・システム化イメージ
- 31. 学んだこと × 資料を全部出させる × 調整事項は議事録として残す × プロットの絵を書く × 初回データについて認識合わせ
- 33. 33 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 37. 37 社内利用状況から選定 × CodeIgniter 3 × Slim × Lumen × Zend Framework × Laravel
- 38. 38 パフォーマンス検証 1. 検証環境を用意 2. フレームワークの最新版を導入 3. パフォーマンス検証
- 40. 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
- 41. 42 パフォーマンスの結果
- 42. 43 メンテナンス性 × 日本語の記事が多いか × 日本語マニュアルがあるか × 機能は多いか × 新しめの参考書籍はあるか
- 43. 44 メンテナンス性の結果 フレームワーク メンテナンス性の評価 CodeIgniter 3 〇 Slim △ Lumen △ Zend Framework △ Laravel 〇
- 45. 46 参考までに PHP Web Framework Benchmark 2019(2019年08月05日に更新) https://qiita.com/prograti/items/01eac3d20f1447a7b2f9
- 46. 47 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 47. 49 特徴 × 無料・軽量・高速 × MVC × テンプレートエンジンがついてる
- 50. 52 チュートリアル
- 51. 53 使って良かったこと ❖ 日本語の記事が豊富 ❖ 無料・軽量・高速 ❖ 学習コストが低い ❖ ライブラリが多い ❖ ドキュメントが分かりやすい
- 52. 54 知ってた方が良いこと × 先に欲しい機能が有るか調べる × 共通処理用のクラスを別途作る × Configは環境で分ける
- 53. 55 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 54. 56 リリース時に困った事 × リリース漏れ × メンバーと認識の乖離 × コマンドを手打ちしてミス × 初回データが投入出来ない × テーブル作成後確認漏れ × リリース後の動作確認漏れ
- 55. 57 リリース時の注意 × リリース手順書は必ず作成 × メンバーと認識すり合わせ × コマンドは全て書く × 初回投入データの投入方法を検討 × テーブル作成後確認 × リリース後の動作確認
- 56. 58 目次 1. 自己紹介 2. はじめに 3. 今回携わったプロジェクト 4. 要件定義 5. フレームワーク選定 6. CodeIgniter 3による実装 7. リリース時の注意 8. まとめ
- 57. 59 まとめ × 要件定義は歩み寄りの精神 × パフォーマンスとメンテナンス性 × CodeIgniter 3はオススメ × リリース手順書は作ろう http://1.dev.lily.cloud.ceres.local/workflow/show/565
Editor's Notes
- 登記簿謄本…不動産所有者の氏名・住所、構造大きさなどが記載されたもの 反社チェック…取引相手に問題が無いか調査する機能 スコアリング…取引先との取引額を求める機能 資料管理…スコアリング時の必要な資料を保存 ユーザ管理…システム利用ユーザを管理 （社内システムが無かった為、別システムとして作成）
- https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
- https://geekly.co.jp/column/cat-technology/1903_059/
- https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
- https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
- https://geekly.co.jp/column/cat-technology/1903_059/ 企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。 もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが 要件定義の始まりとなります。 ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。 これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。 ■要求の細分化 システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。 ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。 ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。 また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。 機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。 最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。 ■要件定義書の作成 要件の機能を細分化できたら、いよいよ要件定義書の作成です。 要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。 要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、 システム設計の工程で頓挫します。 要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、 システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。
- 現在の運用の把握に時間がかかった （経理経験が無く、現在の運用も知らなかった為） 要件が頻繁に変わった （管理本部にシステム要件定義の経験者がいなかった為） プロットの絵をたくさん描いた （認識の齟齬が生まれがちだった為） 既存業務からの移行（初回データ）
- まずは、相手の持っている資料を全て出させ、 現在の運用と不足している会計知識を埋める 話した内容は全てredmineやメールで残す プロットの絵を書くと、以下の良い事がある 1.要件の変更を即座に認識合わせできる 2.画面数と画面の責務が明確になる 3.以上の利点から、結果的に見積もりが楽 （その代償として、かなりの労力が必要。。）