社内勉強会資料 気力が尽きて賑やかし画像は無し

1. webエンジニアのお仕事
～開発手法と開発フロー～
2020/06/22 たなかひかる
Holyday技術基礎勉強会

2. 前回のお話の振り返り
・「httpプロトコル」っていう通信規格によって通信しているよ
・インターネットでwebページを表示するまでにはたくさんの役割の人がいるよ
・webサイトが見れない時はHTTPステータスを見てみよう
・HTTPステータスが5XXの時は急いでエンジニアを呼ぼう
・HTTPステータスが200なのに見れない時も急いでエンジニアを呼ぼう

3. 今日のお話
※今日の話は個人の見解であり
所属組織を代表する意見ではありません

4. 今日のお話
・「エンジニア」ってなに？
・開発フローのお話
・エンジニアの頭の中
・まとめ
・質疑応答

5. 今日のお話
・「エンジニア」ってなに？
・開発フローのお話
・エンジニアの頭の中
・まとめ
・質疑応答
※今日は時間の兼ね合いで超駆け足になります。質問がある方はコメントへ。
なるべく拾います

6. 今日のお話
・「エンジニア」ってなに？
・開発フローのお話
・エンジニアの頭の中
・まとめ
・質疑応答

7. そういえば「エンジニア」ってなに？
困った時のwikipedia
https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E8%80%85
技術者（ぎじゅつしゃ）とは、工学に関する専門的な才能や技術を持った実践者のことである。なお日本におい
ては、名称独占資格である「技術士」および「技能士」と違って、名称独占資格ではなく明確な定義のない呼称
でもある。実際的には、スキルを持つものの呼び名として工学以外の分野も含め広く用いられている。

8. そういえば「エンジニア」ってなに？
困った時のwikipedia
https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E8%80%85
技術者（ぎじゅつしゃ）とは、 日本においては、
名称独占資格ではなく明確な定義のない呼称で 、スキルを持つものの呼び名として
用いられている。

9. そういえば「エンジニア」ってなに？
困った時のwikipedia
https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E8%80%85
技術者（ぎじゅつしゃ）とは、日本においては、名称独占資格ではなく明確な定義のない呼称で、スキルを持つも
のの呼び名として用いられている。

10. ITエンジニアの職種について
色々な分け方がありますが、メインとしているレイヤーによって分けられる事が多いです。
・マネジメント
・インフラ
・サーバーサイドアプリケーション
・webフロントエンド
・ネイティブアプリ
・IoT
・組み込み
辺りが馴染みがあるかもしれません

11. エンジニアってどんな仕事をしているの？
技術によって組織の課題を解決するのがお仕事です。

12. エンジニアってどんな仕事をしているの？
技術によって組織の課題を解決するのがお仕事です。
個々のエンジニアが
何をメインの仕事とするのかは
開発フローに強く依存します。

13. 今日のお話
・「エンジニア」ってなに？
・開発フローのお話
・エンジニアの頭の中
・まとめ
・質疑応答

14. 「ウォーターフォール」と「アジャイル」
以前は「ウォーターフォール」という開発手法が多く取られていましたが
現在のweb業界では「アジャイル開発」が主流になりつつあります。

15. 「ウォーターフォール」と「アジャイル」
以前は「ウォーターフォール」という開発手法が多く取られていましたが
現在のweb業界では「アジャイル開発」が主流になりつつあります。
但し、言っているだけで「アジャイル開発」をきちんと理解していない組織が非常に多いです。
アジャイル宣言
http://agilemanifesto.org/iso/ja/principles.html

16. よくある「ウォーターフォール開発」
・工程を区切って、各工程の完了をもって次行程へ進む
・各工程では成果物を出し、レビューを行う
・後戻りをしない

17. よくある「ウォーターフォール開発」
・工程を区切って、各工程の完了をもって次行程へ進む
・各工程では成果物を出し、レビューを行う
・後戻りをしない
→落ちる水は上に戻らない

18. よくある「ウォーターフォール開発」
以下の工程を踏んでいく
1.要求定義
2.外部設計（概要設計）
3.内部設計（詳細設計）
4.開発（プログラミング）
5.テスト
6.運用
https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A9%E3%83%BC%E3%82%BF%E3%83%BC%E3%
83%95%E3%82%A9%E3%83%BC%E3%83%AB%E3%83%BB%E3%83%A2%E3%83%87%E3%83%AB

19. 「要求」と「要件」と「仕様」
・「要求」は顧客が作って欲しいもの(顧客観点)
Ex.)氏名を表示したい
・「要件」は満たすべき条件
Ex.)各ページに氏名が表示出来ること
・「仕様」は実際の振る舞いとしてどうあるべきかを定義したもの
Ex.)各ページのヘッダ部分に「○○[半角スペース]●●」と表示する。○○は姓、●●は名を表す。
https://qiita.com/digdagdag/items/2808205d89344ab8a3a1

20. 「機能要件」と「非機能要件」
・「機能要件」は機能として満たすべき要件
Ex.)各ページに氏名が表示出来ること
・「非機能要件」は機能を実現するためのシステムとして担保しなくてはいけない要件
Ex.)機能追加した場合も5秒以内に表示が出来る状態を維持する

21. 奥が深い「非機能要件」
「システムは動いて当然」の「当然」の部分を具体的にかみ砕くと
様々な要素が存在する
https://ja.wikipedia.org/wiki/%E9%9D%9E%E6%A9%9F%E8%83%BD%E8%A6%81%E4%BB%B6

22. V字モデルによる検証
開発における製品の妥当性を検証する手法として
V字モデルを採択することがある
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:VModelConcept.pn
g

23. 「アジャイル」だったらドキュメント不要？
ウォーターフォールモデルで要求される
・要件定義書
・設計書
・テスト仕様書
などはアジャイルの場合いらないとする向きもありますが大きな勘違いです

24. 「アジャイル」だったらドキュメント不要？
ウォーターフォールモデルで要求される
・要件定義書
・設計書
・テスト仕様書
などはアジャイルの場合いらないとする向きもありますが大きな勘違いです
従来の形式だとアジャイル開発における仕様変化に耐えられないので
従来とは別の形で記載をする必要はありますが
ドキュメントは必ず残しましょう

25. 「アジャイル」のリスク
「アジャイル開発」は密にコミュニケーションを取る事で
プロダクトの仕様変更に強いという側面を持ちつつ
組織やプロダクトのあり方によってはリスクがある、とも言われています
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%8
3%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA#%E3%83%99%E3%83%BC
%E3%83%A0%E3%81%A8%E3%82%BF%E3%83%BC%E3%83%8A%E3%81%AB%E3%82%88%E3%82%8B%E3%8
3%AA%E3%82%B9%E3%82%AF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E6%8C%87%E9%87%9D

26. 「アジャイル」のリスク
「アジャイル開発」は密にコミュニケーションを取る事で
プロダクトの仕様変更に強いという側面を持ちつつ
組織やプロダクトのあり方によってはリスクがある、とも言われています
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%8
3%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA#%E3%83%99%E3%83%BC
%E3%83%A0%E3%81%A8%E3%82%BF%E3%83%BC%E3%83%8A%E3%81%AB%E3%82%88%E3%82%8B%E3%8
3%AA%E3%82%B9%E3%82%AF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E6%8C%87%E9%87%9D

27. 「コミュニケーション」もコストである
営利企業にとってコストを減らす事は利益に繋がるので非常に重要な課題です
・共通認識を育てる
・一定水準の基礎知識を養う
・認識齟齬を最小限にする
という事は組織として非常に重要な事であり
アジャイル開発においての肝だと言って良いと思います

28. 今日のお話
※今日の話は個人の見解であり
所属組織を代表する意見ではありません

29. 「受託開発」と「自社開発」
受託開発の場合は、事前に見積もりなどを行う兼ね合いで
「ウォーターフォール」での開発が主流
自社開発の場合は、人員を確保した上で開発を行うので
比較的「アジャイル」が導入しやすく、実際にアジャイルでの開発を実施しているところが多い

30. 〇〇駆動開発
有名どころだと「テスト駆動開発(TDD)」など
https://qiita.com/kenji-yokoi/items/6b07a62415b56a959caf
大喜利みたいな開発手法も提言されていたりする
https://eiki.hatenablog.jp/entry/meteo_fall

31. 今日のお話
・「エンジニア」ってなに？
・開発フローのお話
・エンジニアの頭の中
・まとめ
・質疑応答

32. エンジニアのお仕事
だいたい日々以下の工程で仕事を進めています
・ヒアリング
・リスク確認
・調査
・設計
・実装
・テスト
・リファクタリング
・テスト
・リリース

33. エンジニアのお仕事
だいたい日々以下の工程で仕事を進めています
・ヒアリング
・リスク確認
・調査
・設計
・実装
・テスト
・リファクタリング
・テスト
・リリース

34. ヒアリングと調査
何を作るのかを確認します
その際に「なぜ必要なのか」「誰向けなのか」みたいな項目も確認して
非機能要件を頭の中で固めています
ヒアリングの状況によっては別の機能を提案したり、実装自体を見送る提案をすることもあります
実装しようとしている内容について
技術的に不明な箇所や現状のシステムにマッチするかなど
このタイミングで同時に調査を実施し、要件の修正をお願いすることがあります

35. エンジニアのお仕事
だいたい日々以下の工程で仕事を進めています
・ヒアリング
・リスク確認
・調査
・設計
・実装
・テスト
・リファクタリング
・テスト
・リリース

36. 設計と実装
どうシステムを作るかの構想をまとめて実際にコードを書き始めます

37. 設計と実装
どうシステムを作るかの構想をまとめて実際にコードを書き始めます
「設計工程には開発工程と同等かそれ以上の工数をかけるべき」
と言われるぐらいその後の工程に大きな影響が出ます
コードを書いていなくても遊んでいるわけではありません
※個人の見解です

38. 設計と実装
どうシステムを作るかの構想をまとめて実際にコードを書き始めます
サーバーサイドの設計としては
・データ設計
・クラス設計
・アーキテクチャ設計
など

39. 設計と実装
どうシステムを作るかの構想をまとめて実際にコードを書き始めます
フロントエンドの設計としては
・レイアウト設計
・クラス設計
・データモデル設計
など

40. エンジニアのお仕事
だいたい日々以下の工程で仕事を進めています
・ヒアリング
・リスク確認
・調査
・設計
・実装
・テスト
・リファクタリング
・テスト
・リリース

41. テストとリファクタリング
個人の開発環境やステージング環境などを使って要件を満たしているかのテストを行います
その上で、今後のコードの保守性と可読性をあげるためにリファクタリングを行います

42. リファクタリング？
個人の開発環境やステージング環境などを使って要件を満たしているかのテストを行います
その上で、今後のコードの保守性と可読性をあげるためにリファクタリングを行います

48. リファクタリングとは
プログラム言語は人間が解釈出来るように作られた言語です
他の人や明日の自分が見ても読みやすく認識齟齬が起きないように
適切な形へ書き換えていく作業や
無駄な処理を省いていく作業のことを「リファクタリング」と言います

49. リファクタリングとは
プログラム言語は人間が解釈出来るように作られた言語です
他の人や明日の自分が見ても読みやすく認識齟齬が起きないように
適切な形へ書き換えていく作業や
無駄な処理を省いていく作業のことを「リファクタリング」と言います
「プログラムは明日の自分への手紙である」
たなかひかる

50. テスト手法について
奥が深いので別の機会にしっかり話します
※よって割愛

51. エンジニアのお仕事
だいたい日々以下の工程で仕事を進めています
・ヒアリング
・リスク確認
・調査
・設計
・実装
・テスト
・リファクタリング
・テスト
・リリース

52. リリース作業
実装、テスト、レビューを経て本番環境へのリリースを行います。
最近はCI/CD環境が整いつつあるので
リリース作業もコマンド1発だったりボタンひとつだったりします

53. リリース作業
実装、テスト、レビューを経て本番環境へのリリースを行います。
最近はCI/CD環境が整いつつあるので
リリース作業もコマンド1発だったりボタンひとつだったりします
整っていない環境は「レガシーな環境」と言われて
例えばシステムごと売る、みたいな時にマイナス査定の対象になります

54. まとめ
・様々な開発手法があるよ
・でも開発手法をきちんと運用出来ている組織は意外と少ないよ
・エンジニアはヒアリングをしながらどう作るかを考えているよ
・出来たプログラムが他の人にも伝わるように修正したりもするよ

55. 質疑応答