いつもお世話になっております。SEです。
なんかバズりそうなタイトルにしましたが、タイトル負けしそうな内容で恐縮です。
まず、基本的に開発の流れは（ウォーターフォール的に言えば）以下のような感じになるかと思います。
- 基本設計：どういう機能を持ったもの作る？
- 詳細設計：具体的にはどういう動きのものを作る？
- テスト
- リリース
古臭い考えかもですが、この考え方はアジャイルであろうと何だろうと作り方という意味ではあってもよいと思います。
（小話を挟むと、アジャイルは作り方を定義しているものであって、
どのようにシステムを組み立てていくかという意味では上記の”昔ながらの考え方は学んでおいていいと思います。温故知新温故知新）
今はやりの言葉でいえばデザインシンキングなどのワークで作るもの考えた後には実際にモノを作るフェーズになりますが、
実際にチームでモノを作っていこうとしたときには、その手法についてどうしようか？と思うことも多いと思います。
（具体的にどうやって作っていく？アイデアは決まったけど、どういう構成で作る？など。。。悩みは尽きません）
というわけで今回は、物を作り始めるにあたってどのように進めていったらいいかわからない
という方向けに自分がいつもやっているやり方を書いてみます。
以下のような方向けです。
- 作るものは決まった。作り方が決まっていない
- チーム開発が初めてでどうやって進めていったらいいかわからない
- 具体的な開発イメージがわかない
内容としては「システム構成」「チームでの開発ヒント」といった感じのお話となります。
あんまりそれぞれで紐づけはないので、気になる分だけ読んでいただいても大丈夫です。
一部ポエム要素も含みますので、苦手な方はブラウザバック推奨です（死語）
あ、ちなみにこの記事は序章であり、全体で二部構成にしています。
つまりこの記事では”システム開発における概説”にとどめておきます。
20日も記事を投稿する予定でしてそちらは、実際に作ってみようという二本立てです。
よろしければそちらもwktkしつつ待っててくださいね。（待ってない？こりゃ失礼いたしました）
想定読破時間：10分（あるいは15分ぐらい）
アーキテクチャ選定：システム構成
最近のアプリ開発ではそのアーキテクチャで本当に様々な構成をとることができます。
今回は比較的開発しやすいWebアプリケーションを例にしてそれぞれの要素からアーキテクチャを考えてみます。
ただ、どんなシステム構成であっても画面構成はあるはずでこれらの要素は覚えておくとよいと思います。（つまり逃げられません）
Webアプリケーションとしての要素
サービスを作ろうとなった場合にはいろいろな構成が取れると思います。
ネイティブアプリやウェブサービス、最近ではSPA/PWAといった構成も取れ、本当に多種多様になってきたなと思います。
が、やはりWebアプリケーションがお手軽でいろいろ派生しやすいと思うので、今回はライトにこの手法で考えていきます。
となったときに、Webアプリケーションは3層で考えることができます。
フロントエンド層
いわゆるアプリケーションとして描画される部分。すなわち、使い手にとってのインターフェース（さわり心地）の部分です。
いうまでもなく重要な部分であり、ユーザの満足度に直結する部分であります。
構成要素としては基本的にはHTML/CSS/Javascriptを利用して、構成していくことになります。
- HTML：画面の構成を定義する。
- CSS：画面の見た目を定義する。
- Javascript：画面での動きを定義する。
個人的におすすめなのは、イラストを描けるスキルです。（実際にささっと絵をかいてチーム間で共有できるのは大きな強みです。）
上にも書いてある通り、使い手に直接触れる分なので、気合の入り方が違いますね。
最近ではUI/UX（のうち、特にUI）といった文脈でも語られることが多いぐらい、スペシャリストスキルが必要だと思います。
バックエンド層
いわゆるデータを管理、扱う部分。そのほかにも、サーバサイドで稼働するようなものはここに所属していいと思います。
バックエンドの最たるものとしてはデータベースの周りで、データの構造の定義や提供を行うといった役目です。
ここの作りこみが甘いと、性能問題に直結します。よってここも重要な部分であります。
- サーバサイド（Controller）：クライアントからの要求を受け付ける。
- サーバサイド（Model）：DBとかにアクセスしたりいろんなものを処理したりする。
- サーバサイド（View）：Controllerから要求を受け付けて、Modelとやり取りしたりして画面を組み立てる。
- 永続化層（DB）：実際にデータが格納されている場所。消えないよ。
なんとこの記事でMVCまで何となくわかるようになってしまうなんてお得ですね。（ぶっちゃけハイパーラフ解説なので、詳しくはぐぐってね）
サーバサイドとしては、Java(SpringFramework)とかPython(Flask)とか、PHP(CakePHP)とかがあります。お好きなものを選んでね。
DBとしては、MariaDBとかPostgreSQLとかOracleDBとかですかね。
ミドル層
昔はフロントエンド層とバックエンド層の2層であったと思いますが、最近はその中間であるミドル層というのがあると感じます。
「画面構成を定義したい」フロントエンド層と「データを管理したい」バックエンド層で、データをやり取りできるようにするというのがミドル層です。
イメージしやすい言葉でいうと、「RESTAPIなどでバックエンド層のデータをフロントエンド層で利用できるようにする」ということです。
ここが結構曲者で、バックエンドとフロントエンドのその両方でもない感じになるので、なかなかイメージしにくいです。
が、モダンなウェブアプリケーション開発を行う上では結構なくてはならない要素のうちの一つです。
ここの構成がイケてないとのちのちに影響があります（拡張しようとしたときになすすべがなくなります。つみです。）よってここも重要です。
- REST：既存の技術であるHTTPのルールを使ってデータをやり取りするよというルール
システム開発はいろいろな構成が取れるのが魅力だとは思うのですが、ここのデータのやり取りというのはなかなか単純ではあるものの、
耳なじみはないエリアじゃないかなと思いまして、でもこれがないと成り立たないといった縁の下の力持ち的な要素があるんじゃないかなと思います。
3層構造それぞれの役割
話してきましたが、PCのコピペのように要はどこの要素も重要ということなのです。
重要といっても別に身構える必要はなく、ある程度（御幣を恐れずに言えば）薄くでも広く全部経験しておくことを強くお勧めします。
なぜなら、この3層は比較的強い結びつきがあると思うからです。
例えば、フロントエンド側では、データがどのように格納されているか、どのようにデータが受け取れるのかわかってないと処理が書けませんし、
バックエンド側では、その逆でどのように取り扱われたほうがよいかを常に考えてテーブル等の設計をしたほうが効率が良いです。
そしてミドル層という意味では、バックエンドから上手に情報を取得し、上手にフロントエンド側で使えるようにしてあげる必要があります。
チーム構成によってはフロントエンド側にミドル層の役割を持たせたりすることもあれば、バックエンド側でミドルの処理まで作ってしまうこともあります。
この辺りは個々人のスキルセットや、開発ボリューム等を見て誰がミドル層を担うのかは決めていく必要があります。
（往々にしてバックエンドの開発はボリュームは少ないので、バックエンド側でやることも多いのですが、実際に描画をするのはフロントエンド側なので、フロントエンド担当とコミュニケーションが取れていないと、、、大変なことになることもあります。
サーバサイド or クライアントサイド
いわゆるメインロジック（アプリケーションの肝）をどこで構成するかによって、システム構成を2つのパターンに分類することができます。
- サーバサイド：サーバ側で処理を書くのでセキュリティを担保しやすい。がしかしサーバを用意するのが手間。
- クライアントサイド：いわゆるSPA構成であり、実行基盤を作りやすい（サーバレス）。がしかし、セキュリティとか担保するのがちょっと大変。
正直作りやすさとかでの比較はありません。自分のやってる言語が一番やりやすいでしょうから。
ただし、TimeToMarketのような”とにかく早く世に出したいんだ”というときにはクライアントサイドのSPAとかに理があるのではないかなと思います。
こらむ：最近のフロントエンド風潮について
正直画面描画の部分であるフロントエンドが大切にされている風潮はあると思います。
勿論、使い手に直接触れる部分なので、大切なことに変わりはないのですが、それを動かす側がないと始まらないのは事実だと思います。
私が最近思っているのは、HTML/CSS/Javascriptは書けます、という人は最近めちゃめちゃ増えてきていると思うんですが、
じゃあ実際ミドル含むバックエンド層ができる人がどれぐらいいるかというと、結構少ないように思えるんです。
それ自体は別に悪いことじゃあないんですが、フルスタックエンジニアといわないまでも、最低限バックエンドの処理は扱えるようになっておいたほうが絶対にエンジニアとして大成すると思います。（サーバ？なにそれおいしいの？では一定レベル以上になるのは難しいのでは？と思っちゃったりします。すべてはつながっているので）
（回顧厨、古参厨で申し訳ないですが、温故知新というのは結構本当なんだと思います。最近の技術は発達しすぎていて、ブラックボックス化されすぎているんじゃないかなぁと思ったりします。それだと、見落としてしまうことも多いのではないかと。。。）
フロントエンドを卑下しているものでは全くないです。むしろ素晴らしいです。ここで言いたいのはもっとバックエンド側にも焦点を当ててほしいなと思う独り言でした。
具体的な構成
具体的な構成でいうと、それぞれ以下を利用することになると思います。
フロントエンド：HTML/CSS/Javascript/React(SPA構成)
バックエンド(AWS利用)：APIGateway/DyanamoDB/(Lambda)/S3(SPA用)
※ミドル層はReactとして組み込みます。あるいはJavascriptとして機能を持たせます。
といった感じです。今はよくわからなくてもいいです。実践編でやりますので。
上記の例だとReactと書いてますが、これを使わないで行く方法もありますので、スキルスタックに応じまして選んでいただければと。
チーム開発
個人開発とチーム開発は気をつけるべき点が異なります。（というか増えます。）
主として、個人開発は自分の頭の中で完結していればよかったものを、チームメンバーで共有する必要があります。ここが大きく異なります。
個人開発に比べて大変ではあるんですが、その分できることも増えるので、頑張っていきましょう。
決めるべきこと
開発に取り掛かる前に以下を決めておくと取り掛かりやすい（チームメンバーで成果物のイメージを合わせやすい）と思いますので、意識してみてください。
システム構成図
先ほどのところでどういう仕組みを使ってサービスを作っていくかは決められたと思います。（例として、バックエンドはFlask,フロントエンドはReact、等）
続いて、それらがどのようにアクセスされるのか、どこで公開するのかを明らかにする図があると良いと思います。
結構落とし穴なのですが、誰がそのデータを持っているのか、関係者は誰なのかというのは忘れがちになります。
例えば、Twitterを使うので、データをもらう必要がある、とか、こういうデータは誰も持ってないので自分で持つ必要がある、とかは実際に書いてみないと気づかないことも多いです。
画面遷移図（主としてフロント）
アプリを作るとなった場合には、そのアプリがどんな機能があるかを考える必要があります。
それを表現するには機能の羅列をしてもいいんですが、実際にどんな画面があるかを考えて描いてみるとチームメンバーでイメージしやすくなります。
書いてみると案外ずれがあると思うんですが、例えばログイン画面は必要？とかってのは画面ベースで認識を合わせると合わせやすいかなと思います。
DBテーブル構成（主としてバックエンド）
バックエンドでAPIを作る時には、どういうデータを保存し、どのような要求に対してどのように応答するのかを考える必要があります。
それを考えるきっかけとして、実際のDBのテーブルを考えるとわかりやすいと思います。
例えば、サービスの機能として、ユーザ管理機能は必要か、例えば商品のデータを管理する必要はあるか、等ですね。
タスクの積み上げ（進め方）
上記やることが決まったら、タスクとして積み上げてみんなが見れる状態にしておくことも大切です。
誰が今何をやっているのか、何ができていないと問題がありそうなのか、この辺りをチームメンバーで共有しておくことも大切です。
そういう意味では、カンバンを活用することが多いかなと思います。
カンバンを描くときにフロントエンドやバックエンドに分けておくと、タスクの量がわかると思うので、それに従って人数の
役割決定
上記でそれぞれの構成が決まったら次にチームでだれがそのコンポーネントを担当するか決めます。
決め方は、経験があるとかやりたいとかで決めればいいと思いますが、短期間で作る必要があるとなったときには間違いなく経験があるので選んだほうがいいと思います。
ちょっと余裕があるときは知らない技術に挑戦してみるというのもいいでしょう。（ただし、プラスアルファで聞ける人がそのプロジェクトの中にいると、安心感が増します。）
開発を進めていくと、進めていく中でいろいろ障壁が出てくるので、ここでは想定されるものを書いておきます。
コードの共有
みんな大好きGithubがいいと思います。
ただし、ニュースになっている通り、公開で作ってしまうと思わぬ事故になる可能性もあります。
が、公開で作ると公開しやすい（あたりまえ体操）というのもあるので、、、公開がいいと思います。（結局）
パターン1：誰かがレポジトリ作る
パターン2：Organization作る
どちらでもいいですが、誰かのリポジトリでやっていったほうが早いかもですね。（Organization作るほどでもないことが多いと思います。）
また、Githubは結構すごくてプロジェクト管理という意味ではカンバン使えたり、公開するときもGithubPages使えるのでとりあえず公開プロジェクトにおいてはGithub使っておいて後悔はないと思います。（ギャグ）
ただし、バックエンドについて共有で開発していくというのはなかなか難しさがあります。（APIGatewayやDynamoDBの場合）
つまり、AWSのように真似婚から設定してしまうとソースコードがなく、誰かと共有してというのは難しいです。
こういった場合は一人の人に集中してしまいがちかなと思います。（ぶっちゃけ一人でやってもそんな大した量じゃないですし）
CI/CD
何れにしても最近のシステム開発においては自分でデプロイするなんてのはあんまりないように思えます。
というわけである程度CI/CDは考えておいたほうがいいかもですね。
私の場合は、GithubからNetlifyで連携させることやVercelで連携させて、GithubにPushしたらすぐにDeployされてて見える状態になっているというのはうれしさがあると思います。
個人的にはデプロイ出来たらSlackとかと連携させていればかなりモダンな感じしますね。
フロントとバックの会話
前述の通りフロントエンドとバックエンドは別のチーム（あるいは個々の人間）で開発することが多いです。
となったときに一番認識相違が発生するのはここの部分です。
一番よくあるのは、フロントエンド側では、名前と年齢が知りたいだけなのに、バックエンド側はIDとかも付与されて渡してしまって、それぞれの欲しい情報が違ってしまうというのがよくあります。
あるいは、フロントエンドが欲しい情報が実は違うテーブルにあって結合しないといけないとか。。。
なので、フロントエンドはバックエンドのことを常に意識して、どういう情報が欲しいかを画面構成に従ってコミュニケーションをとる必要があり、
また、バックエンドはフロントエンドがどういうものを作っているかを確認しつつ、うまいこと渡せるようにDB等を構成する必要があります。
ということで、とにかく（プロジェクトに関係あるかないかも関係なく）いろいろなお話をチームメンバーでしておくというのは良いシステム作りにはもはや欠かせないかなと思います。
コミュニケーションツール
チーム開発に欠かせないのはコミュニケーションツールだと思います。
実際、やり取りをするときによかったなと思うものを書いておきます。
- Slack：やっぱりLINEとかよりもエンジニアっぽくてよいです。いろいろ連携できますし、フロントエンドやバックエンドなど、役割ごとにチャネルを切れるのもGoodです。
- Miro：ホワイトボードって結構大切で、それぞれのイメージを共有したりすることは重要だったりします。それができるのがMiroで、これは是非一回使ってみてください。
- Github：前述もしてますが、カンバンとか使えるので、タスクの見える化とか結構便利に使えます。
テスト等も踏まえて
本来はテストコードも書くべきです。
が、プロトタイプでモノを作るときにはまぁ最悪なくても大丈夫かなとは思います。
けどやっぱりあったほうがそのあとどんどん開発効率がダンチになっていくので、おすすめです。
最後の稼働確認
作り終わったらみんなで万歳しましょう。達成感を味わうことも大切です。
本来はいろんな人にフィードバックとかもらえるとさらに次につながってよいのですが、いったんは完成した喜びをチームメンバーでかみしめたほうが楽しいです。
最後に
ポエムらしいポエムになってしまいました。
散文で醜い部分が多数あった（むしろ醜い部分しかなかった）と思いますが、お読みいただきましてありがとうございました。
最後になりますが2点蛇足的に付け足します。
やっていくとなかなか頭から作り直すことは難しくなってしまうのですが、最初に決めたコンセプトが達成できているか？というのはいろいろな場面で振り返るとよいと思います。
作っていくと結構”作りやすいもの”を作ってしまう傾向にあると思います。
別にそれでもいいのですが、本当に価値のあるものを提供したい、届けたい、と思うのであればなおさら、作っている中でも常に最初のコンセプト、信条に戻ってやり直せると最後にはとても良いものができると思います。（まちがえるもの、にんげんだもの）
もう一点、システムに対する愛着という意味では最初にシステム名を決めたりするのはとても良いことだと思います。
ほら、愛犬にだって最初に名前を付けるでしょ？それと同じで、名前を付けるという動作は簡単なことではあると思うのですが開発をするモチベーションに大きく貢献します。そういう意味ではどういう風に使われたらうれしいかな～とかいう会話もGooooooooodだと思います。（要はシステム開発はコーディングだけにあらず、システム開発を通して使ってもらう人に何等か楽しんでもらうというのが究極大切なことだと思うので。）
（名前を付けるのは簡単なことですがきっと白熱します。人間はどうでもいいことほど本気になるものです。それが楽しいと思うんですよね。）
それと同じ意味でロゴとか作るとめっちゃテンション上がると思うのでお勧めです。下手だっていいんです。それも味です。
ということで大変長くなってしまってすみませんでした。
本当は図とか入れたかったんですが空白がありませんでしたのでいったんこの状態でリリースです。万歳。
（気が向いたら構成とかそのあたりとかイラスト作りたいっす。自分でイラストは大事とか言ってるんで。でも書ききることが大事。）
では、また。