＼回答があります！／

• 

  ABEChan@iOS/Android Developer

  プロジェクトマネジメント

  2年前
  まずは提供するプラットフォームの選定と優先順位、その後にそのプラットフォームを構成するのに必要な技術選択、そして必要リソースを見積もった上でそれ以降は細かいランタイムやフレームワーク、ツール等の選定になるかと思います。
  
  プラットフォームの選定はサービスの意思決定層のみで決定するのは難しい局面も出てきますので、それぞれをある程度把握した技術者も含めた上で決定する必要があると思っています。
  
  プラットフォームの構成する技術選択においては、現在アサイン可能なリソースのスキルセットやその後のリソース調達の容易さ、あとはランタイムやフレームワーク単位での大規模なリファクタの可能性ができる限り低いものなどを考慮します。
  
  1つの例ですが、ローコードツールを導入したり、あるいはネイティブアプリの場合にクロスプラットフォームフレームワークを選定の可能性の1つとした場合、そのサービスの近い将来像(追加が予想される機能など)をできる限り想定し、それらが実現困難な状態に陥る将来は避ける必要があると考えています。
  view数 10
  • 1
  • 1

• 

  北野勝久

  エンジニア

  2年前
  「事業ではなく、あくまで【開発】の観点で」と前置きいただいているので、以下のようなステップをクリアしている前提で考えてみます。（事業価値検証〜NoCodeでのプロトタイプ開発〜どうしても自分たちでコードを書かないといけないと解決できない、コードを書かないといけない理由が見つかっている）
  ・開発せずに価値検証できないかを考える
  ・NoCodeのプロトタイプで価値検証をして、事業として成立することが分かった
  ・プロトタイプでは解決できない将来のスケールの問題・コードを書く価値が見いだせている
  
  ---
  
  まずは利用者が価値を感じられる最小のプロトタイプで欠かせないデータとその関係性を、ユーザージャーニーマップとにらめっこしながら整理するところから考え始める気がします。
  ユーザージャーニーマップをみつつ、必要なイベントを洗い出して、そこからユーザーが意識するオブジェクトを抽出し、それをデータに落とし込んでいくイメージです。
  
  そうするとイベントとデータの関係性が見えてきて、RDBMSなのかNoSQLなのかといった、最適なデータストアを考える材料が見えてくるはずなので、データストアを決めて、それを扱うライブラリ（O/Rマッパー）から利用する言語やフレームワークを絞り込んでいく気がします。
  同時に利用者のユースケースやこれまでの価値検証の結果から、Webアプリだけで良いのか、Mbileアプリがはじめから必要なのかの意思決定も必要ですね。ほかには汎用的な業務（たとえば請求など）があれば、そこの開発をショートカットするためのSaaS APIがないかも同時に探すと思います。
  
  そうすると、最小の画面デザインと大まかな技術選定が決まってくるので、あとは走り出す…といった流れでしょうか。
  ちょっと理想的すぎるような気がしますが・・・笑
  view数 40
  • 2
  • 2

• 

  荘野敬也（bowyer-app）

  エンジニア

  2年前
  僕はモバイルアプリを開発しているので、モバイルアプリ観点で答えさせていただきます。
  
  僕の場合はどの開発言語を選択するかを検討しますね。
  

  副業案件を紹介し合うSNSのようなサービス

  ということなので、モバイルアプリを開発する際に各OS固有の機能は不要そうかなと考えています。
  その場合僕はFlutterを選択すると思います。
  Flutterを選択することで1つのコードで両OSのアプリを実装することができるので開発人数が少なくても良くなります。
  チームの規模が分からないのでなんとも言えないですが、コード品質を担保するという意味でFlutterの開発者は2人欲しいなと思います。
  view数 8
  • 1
  • 1

• 

  Atsuhiro Teshima

  エンジニア

  2年前
  現在動画のサービスを作っているのですがリアルタイムに大量に情報を処理を行う必要があったのでElixirを開発言語に選びました。(Elixir自体は経験がありましたが、RailsやNodeなど他の経験ある言語も検討しました。)
  
  SNSだとタイムラインの更新をWebsocketなどで行うことを考えると、Firebaseなどのツールを使ってそこをするのかNodeのようにWebsocketに強い言語を使うかが判断基準になるかと思います。
  
  あとはオープンソースで出ているSNSや仕事紹介ツールは結構ありそうなのでそれをみてどんなテクノロジーを使っているか調べるということもよくしています。
  
  SNSだとCloud Runとかで無限スケールできそうな気もするので、Cloud Runにハマるものが良さそうですね！
  view数 8

• 

  Haruka Ishii

  プロジェクトマネジメント

  2年前
  1.最初からコードを書かない（モックやデモ、ノーコードで機能にあたりをつける）
  2.プロダクトロードマップとチーム体制の変遷のロードマップを作成する（機能の変化・UXの変化を特に）
  3.2を踏まえて、可能な限りテックドリブンで進められるようミニマムな仕様にする
  
  とかはやっておいた方がよかった（次のプロダクトでは絶対やる）と思っています。
  もちろん色々思うところはあるのですが、時間が立てば立つほど指数関数的に複雑性が増すことを自分は本当の意味では理解していなかった節があり、品質を保証することも機能開発速度を維持することもエンジニアリングフレンドリーな形にしないと限りなく困難だと感じています。
  ビジネスを毀損しない範囲で限界までアーキテクチャを移行させ続けられるようにしないと厳しい瞬間が多いなぁと思ってます。
  
  自分はBtoBサービスの人なので↑のように考えていますが、toCサービスだとプロダクトのコアな価値がかなりぐるぐる変わるのでロードマップが作りにくく適切なアーキテクチャの選定はやりにくそうな印象はしています。
  view数 7
  • 1

• 

  Shoichi Namba

  エンジニア

  2年前
  他の方の回答を見ましたが言語選定からわからなそうだったのでそのあたりの話もさせていただきますと、時々フリーの方などでマイナーな言語やフレームワークを好んで使われている方がいたりします。そういった方にあたるとその後のその言語、フレームワークを使える人材の採用が難しくなり、ある程度事業進めた段階で困る可能性があります。
  
  そのため可能な限りよく使われている言語、フレームワークなどの選定だけは気をつけたほうが良いかと思います。特に現状はアプリを作るのであればアプリ、SNSということでサーバーサイドも必要、かつWebもあるのであればフロントエンドなど業種も多岐に渡っていますので、そのあたり総合して開発しづらくない選択をするよう気をつけた方が良さそうです。（もちろん気をつけすぎてもそれはそれでよくないので、問題ない範囲かだけはしっかり見定めたほうがよさそうです）
  
  同様に、開発手法も色々ありますが、これも最新の技術や開発手法を好きすぎる人だと色々こだわった作りにしすぎて開発効率が逆に落ちる可能性があります。このあたりも事前に把握は難しいかもしれませんが気をつけたほうが良いかもしれません。
  view数 14
  • 1
  • 1
  • 1

• 

  古田宏典

  プロジェクトマネジメント

  2年前
  マーケッターです。マーケッターの視点からは、状況別のユーザーの課題、その課題を解決するための方法（機能）、シームレスなUIです。
  view数 8
  • 1
  • 1