まちん

主にAndroidアプリを作ってます。

ネクストスキル週次ゼミ(3月のゼミまとめ)

3 月のネクストスキルの週次ゼミのまとめです。

3 月は主に、要件定義や設計、システム開発における契約について学びました。

3 月に学んだこと

第 1 週

要件定義と設計について学びました。

  • 要件定義・設計の成果物の例
    • システム開発の流れ
      • 企画、要件定義、基本設計、詳細設計
    • ウォーターフォールかアジャイルかなど、要件定義をどこまでやるかは状況にもよる
    • 要件定義の成果物の例
      • 全体像
        • システム概念図
        • コンテキストモデル(おすすめ)
      • データ
        • DFD(データフローダイアグラム)
        • 概念モデル
      • 業務
        • ユースケース図
        • ユースケース記述
        • 業務フロー
      • 機能
        • 機能一覧
        • 画面遷移図
        • 画面モックアップ
      • 非機能
        • 非機能要件一覧
      • テスト
        • システムテスト仕様書
    • 基本設計の成果物の例
      • 全体像
        • アーキテクチャ設計書
        • システム構成図(フレームワークなども記載)
      • アプリケーション
        • アプリケーション・アーキテクチャ設計書
        • ドメインモデル
        • API 仕様書(Swagger etc)
      • データ
        • ER 図
      • インフラ
        • インフラ構成図
        • ネットワーク図
        • 運用設計書
      • テスト
        • 結合テスト仕様書
  • UML を中心とした作図の入門
    • 現実のある側面を切り出したものがモデル
    • UML などでおすすめの図
      • アクティビティ図
        • 業務フロー
        • プログラムの処理の整理
      • ユースケース図
        • ユースケースの整理
        • アクターがシステムを触り始めて、システムから離れるまでの単位
      • シーケンス図
        • 処理の流れの整理
      • コンテキストモデル
        • 全体像の整理
        • RDRA で紹介
        • 関連するシステムや登場人物を書く
        • 比較的簡単につくれて、効果が高いのでおすすめ
      • クラス図
        • アプリケーション設計
          • レイヤーやその中のクラスの連携
          • オブジェクト指向なプログラムの整理
        • ドメインモデル
        • 概念モデル
    • 作図のポイント
      • 細かく 1 つの図に書きすぎない
      • AsIs と ToBe を分ける
      • モデルの限界に注意
      • 最初から厳密に書かない(叩きに使える。ないよりマシ)
  • 要件定義・設計の流れの例
    • 提案、契約フェーズ
      • ヒアリングや情報収集
      • 概要スケジュール作成
      • 成果物一覧や優先順位づけられた WBS のようなもの作成
      • ざっくり見積書作成(松竹梅)
      • 契約(準委任がいい)
    • 要件定義
      • コンテキストモデルで全体像を整理
      • スコープやフェーズ決め
      • ユースケース図で利用方法の整理
      • 概念モデルで整理
      • CRUD 操作などが見えてくるので、機能一覧作成
      • 機能を踏まえた画面遷移図、モックアップ作成
        • 画面イメージいきなりは良くない。POA 的なやり方。変化しやすい
      • 非機能要件一覧を作成し合意
    • 基本設計
      • システム構成図
      • アプリケーション構成図
      • リファレンス実装
      • API 仕様書、ER 図作成(必須)
      • 残りはインフラ構成図や運用設計書や、技術検証など
  • PM と要件定義は別
    • 要件定義には、エンジニアリングスキルが必要

しっかり要件定義をやろうと思うとたくさんやることがあるよなと再認識しました。

コンテキストモデルは初めて知りましたが、かなり有用そうだと思いました。新規プロジェクトや、既存プロジェクトへの参画時などに、図を書こうと思いました。 たしかに、全体像がわかるものがあるだけで、どこの話をしているのか共通理解しやすいし、どこが連携しているのかわかるだけで、開発のスコープが絞れるのには共感します。自分も実際に要件定義や PM 寄りの仕事をしていた時に、キックオフなどでシステムやアクターがどう連携しているのか書いた全体像を持っていくと、議論している最中にどこが足りないか出やすかったと思います。

第 2 週

IT エンジニアが知っておきたい法務知識について学びました。

  • 開発契約の基礎知識
    • 自社開発 or 受託開発
    • フリーランスの定義
    • 受託開発の契約
      • 派遣契約
        • 時間を売る
        • 指揮命令は依頼する側
      • 請負契約
        • 成果物を売る
        • 指揮命令は依頼される側
        • 報告義務なし
      • 準委任契約
        • 時間を売る
        • 指揮命令
        • 再委託 NG
        • 報告義務あり(請求されたら)
    • 準委任がエンジニアとしては損しにくい
    • 何を作るのか決まっていない状態で請負契約は危険
    • アジャイルで請負という矛盾
    • 開発の進め方で、大体契約は決まる
      • アジャイル: 準委任
      • ウォーターフォール
        • 企画
        • 要件定義(と設計の一部): 準委任
        • 設計、実装、テスト: 請負(仕様が凍結されている前提)
        • 運用保守
    • 契約書はなくても契約は成立する。契約書は何かあった時のための証拠
    • 揉めたくない、長期や高リスクなら契約書
    • 契約書の作成は大変だが、自分で作った方が有利にしやすい
    • 仕様の凍結をして、2 転 3 転して NG を出された場合は、逆に損害賠償を出せる可能性があるかも
    • 逆に準委任契約でも責務不履行がありうる
  • Web サービスに必要な法務文書
    • プライバシーポリシー(個人情報保護)
      • 個人情報や、パーソナルデータ(位置情報、購買履歴など)の取り扱い
      • ほぼ全てのサイトで必要
    • 利用規約
      • 契約書のような位置付け
      • ポイント
        • 準拠法
        • 裁判所
        • 禁止事項
      • 競合他社の利用規約を読むのはおすすめ
      • 弁護士に頼んでも、サービスの性質によるため、全部丸投げはできない
    • 特定商取引法に関する表示
      • 通信販売に関する広告を行う際の表示義務
  • サービス開発で役立つ法務知識
    • EC
      • 景品表示法
      • 資金決済法
    • メール・チャット
      • 特定電子メール法
    • 電気通信事業法
      • 他人の通信を媒介する場合は、届出が必要
        • クローズドなチャットは、届出を出さないといけない
    • セキュリティ
      • 個人情報保護法
      • マイナンバー法
      • GDPR
      • PCI DSS
    • ライセンス
      • OSS

必要な知識だけど、なかなか学習に腰を入れにくかったり、どこから勉強すべきかわからないなどありますが、まず道標を知ることができたのでよかったです。

第 3 週

エンジニアのキャリアとお金の話について学びました。

講師の個人的な経験などもあり、オフレコっぽかったので、だいぶ端折ります。

  • IT エンジニアのキャリアについて
    • 色々聞いて、自分で決めるしかない
    • IT エンジニア
      • 技術
        • 1 つの技術特化
        • フルスタック
      • マネジメント
        • PM
        • スクラムマスター
        • 組織づくり
  • IT エンジニアの単価・収入の話
  • 「フリーランスエンジニア」は結局どうなのか

お金の話とかなので、なかなか聞きづらいことを知ることができてよかったです。

フリーランスになるにしろならないにしろ、正社員でも、自分の単価はどれぐらいなのか意識することは、ビジネスマンとして重要だなと思います。自分のエンジニアとしての市場価値を考えることにつながるはずです。

第 4 週

受講生のアンケートへの回答の講義でした。

  • エラーハンドリング・例外設計について
    • 例外設計
      • まず大事なのは握りつぶさないこと
      • 基本無視しない。処理の続きを書くか、再度例外を投げるべき
      • 例外的場面しか使わないこと
      • 例外を使うか、戻り値で表現するか
        • メリット、デメリットある
        • 言語の文化にもよるところもある
    • 例外のハンドリング
      • どのレイヤーでハンドリングするべきかは、エラーの内容次第。そのレイヤーで解決すべきならそこで処理する
      • web アプリでよくあるのは、どこでも catch できない場合は、グローバルな例外ハンドラを使って、一番外側でハンドリングする
        • HTTP ステータスに変換
        • 技術的なものとビジネス的なものに分けるなど
    • ログの監視
      • エラーハンドリングするだけじゃダメ
      • ためて、エラーがどれだけあるのか確認。
      • 物(ERROR レベル)によっては Slack 通知
  • MVC、MVC2、MVVM について
    • UI とかインターフェイス層に関わるアーキテクチャ
    • MVC と MVC2
    • MVVM: View と ViewModel が双方向バインディング。両者の変更が互いに反映
    • UI 周りの実装は、フレームワークに強く依存するので、そのやり方に則るのが 1 つ手としてある。
    • サーバーサイドならそもそも WebAPI で実装することが多いので、最近は MVC とか MVVM とか考えない
  • PC 自作の概要
    • CPU が一番大きい要素。次に GPU(グラボ)
    • CPU
      • Intel Core i シリーズ or AMD Ryzen
      • CPU 内の GPU あり or なし
    • マザーボード
      • CPU に対応するマザーボードが決まっている。あとはサイズやメモリのスロット、ケースなど踏まえる
    • メモリ
      • 規格を見ながら、マザーボードに合わせて選ぶ
    • SSD
      • NVM or M2
    • GPU(グラボ)
      • メモリスペックを見て選ぶなど
    • 電源ユニット
      • CPU と GPU の電力を計算し選ぶ
    • PC ケース
      • 好きなものを
    • CPU クーラー
    • OS
      • windows が定番(ゲーム)
      • linux もおすすめ(開発環境)
      • 両方入れるのも可能(バーチャルマシンや、デュアルブート)
  • ドメイン駆動設計入門
    • ドメインを中心にソフトウェアを作る
    • みんなでユビキタス言語(共通言語)を使って、ドメインエキスパート(その領域に詳しい人)と話して、ドメイン知識をそのままソフトウェアで表現
    • 具体的な手法や、実装上のプラクティスがあったりするが、それはあくまで補助
    • 戦略的設計
    • 戦術的設計
    • ドメイン層の設計
      • ある程度複雑なゲームとかが練習としておすすめ
    • パフォーマンスが求められる場合は、DDD は相性が悪い
      • ルーターの実装など
    • ビジネスロジックが複雑な場合は、相性がいい

例外設計はやはり難しいなと感じました。どこでハンドリングするかも、フレームワークやアプリケーションアーキテクチャ、要件などによるので一概に言えないし、状況次第な感触があります。その分野(フロントエンド、サーバーサイド、モバイルなど)や言語である程度は定石みたいなのがありそうなので、まずはそれに従うのが良さそうと感じました。

また、自作の PC を組み立てたことがないので、チャレンジしてみたいと思いました。部屋が狭いという理由で断念してますが、引っ越したらすぐにでも買うかもしれません。

第 5 週

コンピュータやプログラミング言語とは何かについて学びました。

  • CPU がソフトウェアを実現する仕組み
    • CPU
      • 足し算(四則演算)
      • メモリの読み書き
      • リングプロテクション(発展)
    • CPU の構成要素
      • ALU
      • プログラムカウンタ
      • レジスタ
  • OS の役割
    • CPU
    • メモリ(ROM)
      • BIOS(UEFI)
    • メモリ(RAM)
    • ストレージ
    • 入出力
    • OS(カーネル)
      • CPU、めもり、ストレージを管理
      • プロセス管理
        • 複数の処理を並行処理
      • メモリ管理
        • 別のプロセスのメモリは見れない
        • 仮想アドレスの割り当て
        • CPU の動作モード
        • カーネルのみ別プロセスを触れる
      • ファイルシステム(I/O)
        • メタデータ(i ノード)をファイルシステムが保持
        • メタデータを参照してストレージの番地を辿る
  • 言語処理系と計算理論について
    • プログラミング言語を書いた文字列だけでは動かない。それを解釈するプログラムが必要。
    • コンパイラとインタプリタの仕組み
      • インタプリタの実行ステップ
        • 字句解析(Laxer)
          • 意味のある単語単位を抽出する(トークン化)
        • 構文解析(Parser)
          • AST(抽象構文木)にする
          • 再帰下降構文解析
        • 評価(コード生成)
    • 計算理論
      • コンピュータにできること
        • 計算可能
          • 万能チューリングマシン、チューリング完全
        • 計算不可能
          • ある言語のプログラムがクラッシュするか判定

コンピュータサイエンスで学ぶもの盛りだくさんでした。最近のアプリを作るだけだとなかなか意識することが少ないかもしれないが、そもそもの原理を知っておくことで、できることできないことの判断や、根本原因の解決などに役立ちそうでした。しっかり全部学習するには時間はかかるかもですが、興味があるのでやっていきたいです。

インタプリタを作成するデモを見ましたが、字句開析、構文開析部分は HTML や XML のパーサーの実装したことがあり、それにとても近いなと思いました。

まとめ

今月は、一般的なアプリ開発の直接的な話ではなく、エンジニアが後回しにしそうだけど、システム開発において重要なことを学習できました。

週次ゼミを終えて

1 年間という長丁場でしたが、しっかり全て参加することができました。(動画視聴含む)

まず続けたられたことがよかったです!

IT エンジニアに必要な知識を、体系的かつ効率的に学べたと思います。もちろん知識を深掘りしていく必要がありますが、何も知らない状態ではないので、深ぼるときにかなり役に立ちそうです。

この講座を誰におすすめしたいかというと、全エンジニアにお薦めしたいです。意外と基礎的なところでも取りこぼしていたり、スルーしている部分があるはずですし、モダンな開発で必要な知識として外れていないと思います。

自分は直近で Android とサーバーサイドアプリケーションの実装などをやっていますが、この講座で学習したことが直接的に生きていると感じます。迷った時の考え方の指針として利用したり、必要になった知識を補完する際の道標にしていて、とても役に立っていることを実感しています。

今後の学習ですが、自分に足りないもの、やりたいこと、知りたいことに優先度付けながら学習していきます!

← ホームへ