フルスタックエンジニアについて考えてみたい
フルスタックエンジニア
フルスタックエンジニアについて考えてみたい。
アプリをデプロイするには、開発環境と言語とフレームワークを使いこなすだけでは足りないことが多くある。
人材不足のために、有能な人に全て任せたいという依頼者側の都合も見え隠れする。
人材派遣(業務委託契約)ではなく、請負契約でアプリ作成を受注しているプログラマの方は、基本的には自分で全て行う(フルスタック)で行なっている。
ただ、通常の場合、フルスタックという場合には、クライアント・アプリ側とクラウド側両方の構築ができる人材をフルスタック・エンジニアという場合が多い。
下記では、アプリ作成業務を行う上で必要となるものについて、下のスタックから順に記述している。
*いにしえのウォータフロモデルでは下のスタックを上流工程と呼ぶ。
営業、契約事務手続き
営業活動 →引き合い →打ち合わせ →見積もり →業者選定 →契約
顧客折衝
まず、自分で好きなように作る芸術家(=アーティスト)なら必要ないことだが、一般的な開発者(=エンジニア、=プログラマ)は、クライアント(顧客)からどのようなアプリを実現したいのかを聞き出さなくてはならない。
このスタックは顧客ヒアリング(顧客折衝)と呼ばれている。
プログラミングの最中に行う顧客折衝の方法や応答すべき時間などは事前に取り決めしておくこと。
要件定義
次に、要件定義が必要となる。
特に、要件定義書などのようなドキュメント化をする必要はないものの、下のスタックでヒアリングした内容を顧客と自分の間で共有することは、上のスタックでのトラブル防止に役立つ。
以降のスタックについても、必ずしもドキュメントとして残す必要はないが、関係各位と共有するために、マークダウンなどで記述すると良いだろう。
機能設計
基本設計や外部設計とも呼ばれるものだ。
アプリを外側から見たときに、どのような機能があるのか、周辺機器やクラウドとコミュニケーション方法を定義していく。
・デプロイ環境
・クラウドサービス選定
・言語、開発環境選定
・クラウドAPI定義
・OS、ミドルウェア選定
・データベース(SQL/スキーマレス)選定
・画面操作フロー
・画面レイアウト
・印刷レイアウト
内部設計
プログラム設計、詳細設計とも呼ばれている。
下のスタックで定義した機能を実現するために、アプリをどのようにプログラムしていくのかを定義記述する。
・動作諸元定義
・テーブル定義
・アーキテクチャ選定
・オブジェクト定義(参照オブジェクト、値オブジェクト、区分オブジェクト、一覧オブジェクトなど)
プログラミング
言語の特色を生かし、後日のメンテナンス性を考慮したプログラムを作成する。
・DDD(ドメイン・ドリブン・デザイン)
・DI(ディペンデンシ・インジェクション)
顧客折衝
スクラム開発を行う場合には、設計やプログラミングしている間であっても、常に(営業時間内に限る)顧客と折衝しなければならない。
自分自身で時間管理し、年がら年中スマホ通知を気にしなければならないような状況に陥らないように自己マネージメントする必要がある。
自分の心身の健康のためにも。
・メッセージ
・チャット
・通話
機器選定、設置、設定、ネットワーク管理、セキュリティ管理
オンプレミスやデータセンタの場合には、機器設置、設定、ネットワーク管理、セキュリティ管理といった、いにしえのサーバ管理、ネットワーク管理といった作業が必要となる。
クラウドを使用する場合には、ほとんどのサービスがフルマネージドのため、いにしえのシステム管理者は必要ない。
動作テスト、運用テスト
A/Bテストを行う場合には、テスト仕様書(テスト項目、テスト方法を記述したもの)を作る場合がある。
デプロイ
ストアやクラウドやオンプレミスなどにデプロイする。
契約事務手続き
納品・請求
2023年12月 | ||||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
  |   |   |   |   | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |   |   |   |   |   |   |
iOS
web
アプリの著作権
ブロックチェーン/暗号技術
新しい社会
禅・大乗仏教
日本のなりたち