近未来都市の幽寂

Webポータル事業の企画・構想から公開・運用まで。

102_技術要件

やったこと

使用技術の選定

プログラム言語 … Ruby
フレームワーク … Ruby on Rails
CSSテンプレート … Bootstrap
CIサービス … Shippable
資源管理 … Git + Bitbucket
課題管理 … TrelloまたはRedmine

サーバOS … CentOS7
仮想化技術 … Vagrant + Docker
Webサーバ … NGINX
DBサーバ … PostgreSQL

検証環境 … VirtualBox
本番環境 … AWS(EC2)

とりあえず、ざっと選定してみました。
Ruby on Railsは以前から勉強したかったので、もはや絶対条件。
Githubのプライベートリポジトリは有料らしいので、無料で出来るBitbucketを使用しようと思ってます。
CIはJenkinsを勉強のために使おうと思ってたんですが、そのためにCIサーバを立てるのも面倒くさいので、ShippableというCIサービスを利用する予定です。
Trello・Redmineは正直使うかどうか、今のところは超絶怪しい…面倒くさくてやめちゃうかも。

WebサーバはApacheではなく、高速かつ軽量なNGINX。
DBサーバは商用利用が無償のPostgreSQLMYSQLはライセンス体系がややこしく、商用利用の場合はたぶんライセンス料が必要)。

本番環境として、レンタルサーバーVPSという選択肢はありませんでした(もう使ったことがあるので)。
HerokuにするかAWSにするか正直迷いました。というか今でも迷ってます。
勉強のためにはAWSがいいんでしょうけど、全ては料金シミュレーション次第ですな…

非機能要件の見直し

以上を踏まえ、前回のエントリーの非機能要件について見直しを行いました。


機能性(合目的性やセキュリティなど):
セキュリティはAWSのS3まかせ。
せめてSSL証明書は購入する予定。

信頼性(高負荷に対するタフさ):
AWSでスケールアップするなりして、
適当にチューニングする。

使用性(使いやすさ):
可能な限りシンプルなデザインに。
もちろんレスポンシブデザインで。

効率性(スピード、ムダの無さ):
開発速度はRailsまかせ。
処理速度はチューニング次第かと。

保守性(修正・機能拡張のしやすさ):
Railsの力を信じる。
後は内部設計で配慮するか。

移植性(別環境への移しやすさ):
VagrantとDockerがあれば移植は容易かと。

障害抑制性(バグりにくさ):
Gitの資源管理をしっかりやれば…
これは実装する自分の実力次第かな…

効果性(システムの費用対効果):
収支を概算する必要があるが、
まだやってません。

運用性(運用の容易さ):
Shippable使ったことないから分らんが、
本番環境の管理は確かに課題になってくる気がする。

技術要件(実現方式や開発方式など):
上記の通り。


はい。

時間の無駄でした。

わかったこと

知らないことが多すぎる

非機能要件はさておき、選定した技術についてはほとんど全てが未知の世界。
正直、書きながら「これ本当に全部やるのか…」と感じていました。
しかし、今回の目的は趣味と勉強のためなので、やるっきゃない。
本を読んだり、プロトタイプを作ってポチポチ動かしてみたり、少しづつできる技術の幅を増やしていこうと思います。

最終的に必要なサーバは3つ?

検証環境はローカルの仮想環境で賄えるので常時稼働用のサーバは必要なく、本番環境のサーバが一つあれば事足りそうな気がします。
しかし、法人としてサービスを展開していくのであれば、

  1. 本番環境用のサーバ
  2. 社内管理用のサーバ
  3. 会社HP用のサーバ

という、最低でも3つのサーバが必要なのではないか、と朧げながら思案中。
まぁ、2と3は一つのサーバにまとめることが出来なくもないですが。

つぎにやること

101_機能要件・非機能要件

やったこと

機能要件

e-words.jp

www.sangyo-rock.com


本業であるSI業において、要件定義の工程は何より重視されています。
顧客の要求事項をもとに、その実現要否および実現方法を整理して合意形成していくプロセスですね。
この工程を疎かにしてしまうと、後続の工程で頻繁に仕様変更が発生したり、フタを開けてみると顧客の思いとかけ離れたシステムができあがってしまったり…。
炎上・デスマという泥沼の様相を呈する原因になりかねません。
僕が従事している会社でも度々見られる光景で、最悪の場合はリリースできずに訴訟沙汰になります。

なので、要件定義が重要だという話は身をもって知っているわけですが、自前のWebサービスとなってくると話は別です。
なんせ、あれこれ言ってくる顧客はいない。
強いて言うなら想定出店者および想定購買者ですが、実際に公開してみたところで、使ってくれるかどうかも分からないサービス。
であれば、上流であれこれ考えず、自分の好きなものを作ろうと思います。
(一応、実現したい機能は、何となしにまとめた)

非機能要件

e-words.jp

itpro.nikkeibp.co.jp

機能要件に大して、非機能要件の方は何かと手薄になりがちですね。
機能要件が「顧客の要望を要件として定義付けしたもの」であるのに対し、非機能要件というのは「機能面以外のすべて」を指す、非常に便利で厄介な言葉だからです。

JUAS(日本情報システムユーザー協会)の「非機能要件要求仕様定義ガイドライン」によると、非機能要件は下記の10種類に分類されるようです。

  • 機能性(合目的性やセキュリティなど)
  • 信頼性(高負荷に対するタフさ)
  • 使用性(使いやすさ)
  • 効率性(スピード、ムダの無さ)
  • 保守性(修正・機能拡張のしやすさ)
  • 移植性(別環境への移しやすさ)
  • 障害抑制性(バグりにくさ)
  • 効果性(システムの費用対効果)
  • 運用性(運用の容易さ)
  • 技術要件(実現方式や開発方式など)

なるほど。こいつは面倒くさい。
Webサービスを実現していくに当たって、どんな言語やフレームワークを使用するのか、どんな環境を使うのか、技術要件を詰めていくことで自ずと定義づけしていけそうな気がするので、その辺の話は次回に回すとします。

わかったこと

要件の重みのギャップ

「SIでは要件定義がすべて」これは真理だと思います。
ただし、自前のWebサービスの場合、要件定義がふにゃにゃしていてもそれほど怖くはありません。
多人数で開発する場合ならいざ知らず、自分一人で開発するだけなら仕様変更もリリース延期も怖くない、気楽なモンです。
そんなことよりも、早く作り始めたい。

でも技術要件(環境定義)は大事

今回は後回しにしましたが、どの環境でどういう風に作りたいか、その辺はしっかり詰めていく必要があるかと。
ただし、作っていく過程で「なんか違うな」とか「これじゃダメだな」とか感じる部分が恐らく出てくる予感がしています。
なので、技術要件はとりあえず決め打ちにして、何かあったら技術要件を変えてしまえばいいと思ってます。
やったことがない技術分野なので、トライアンドエラーになるのは防ぎようがないことですが、なるべく下調べをして、可能な限り手戻りの少ないようにしたいと思います。

つぎにやること

  • 技術要件の検討

001_コンテンツ企画

やったこと

コンセプトメイキング

そもそも、どんなサービスを実現して世の中に流布したいのか?
こいつがないとお話にならない。パターンとしては、

  • 現時点で存在しないもの
  • 現時点で存在するが不満があるもの
  • 組み合わせると凄くなるもの

なんかがあるかもしれない。
僕の場合は、

「ECモール」+「ITトレンド」

というコンセプトが割と最初からあったので、考えるのは楽ちんでした。
そんなもんコンセプトじゃねーよ、という声が聞こえてきそうですが、本当はもうちょっと具体的で、あえて意味もなくボカして書いてます。
というか、そんなに考えてません。

競合分析

同じようなことやってるサイトはあるかなー?とネットを徘徊していると、ありそうでないんですよね。なので、とりあえず作ってみようと思います。

なお、ECモールとしてはAmazon楽天市場、ヤフショ、ポンパレあたりが有名どころでしょうか。
こちらとしてはほとんど趣味でやるような感じなので、出店者のイニシャルコスト、ランニングコストはなるべく低く設定しようと思います。
せめてサーバー代くらい賄える利益があればそれでいいや。その辺は気分次第で変わるかも知れんけど。

ちなみに、中野翔太さんという方が、2017年度版のECモール比較をされています。
ご興味のある方は訪問されてみてはいかがでしょう。

nakano-ws.com

ペルソナの設定

smmlab.jp

正直、めんどくさいのでやってません。
本当はやった方がいいんでしょうけど。

わかったこと

スピードこそ我が人生

ずっと以前から構想はあったので、今はなるだけ早く形にして公開したいと思ってます。
上流こそしっかり詰めろ、とは本業でも痛いほど言われてますが、ここは僕の趣味の世界。
「完全を求める」のではなく「完遂を求める」という姿勢で、多少機能が不十分でも、絶対に公開までもっていきたいところです。
公開するのが大事だという事は、ランサーズの社長である秋好陽介さんもおっしゃっています。

www.web-20.net

ポータルサイトは難しい

聞き苦しい言い訳かもしれませんが、ユーザーが多数集まっていることが前提のポータルサイトは、ユーザーを集客するまでの期間、ユーザーに何を体験してもらうか?という部分が非常に難しい、と感じました(今回は一応考えています)。
僕が敬愛しているブロガーのmegamouthさんも、ブログの中でこういった記事を書かれています。

www.megamouth.info

非常に秀逸な記事で、webサービスを作ろうと、目を¥マークにして画策されている皆様は、ぜひご一読されることをお勧めします。

つぎにやること

  • 要件定義的なこと

901_当ブログについて

再開のお知らせ

はじめましての方ははじめまして。
大阪の某IT企業でSEをしているみうらです。

当初このブログは「悪鬼羅刹の技術録」というタイトルで、自身の勉強のために、色々技術録的なものを書いて行こうと思っておりましたが、公私共々忙しかったため完全に放置しておりました。
が、最近は時間が取れそうになってきたので、ぼちぼち再開しようと思います。
どうでもいいけど、タイトルも思い切って変えました。

投稿内容

「悪鬼羅刹の技術録」を書いていた時は、

と、曜日別に勉強する内容を分けてブログを書こうと思っておりましたが、そんな器用なマネができるハズもなく、結局ほとんど何も書けませんでした。

その時の反省を活かし、当ブログではとりあえずWebポータル事業の構想・設計から公開・運用に至るまで日々の作業とその苦悩を綴っていこうと思います。

投稿頻度については、「悪鬼羅刹の技術録」のルールと同じく、勉強が少しでも進んだ場合、または少しも進まず詰まった場合でも、とりあえず1行でも書くように心がけていこうと思います。

投稿ルール

カテゴリー

0_SP_企画構想
1_RD_要件定義
2_ED_外部設計
3_ID_内部設計
4_EC_環境構築
5_PG_製造
6_IT_検証
7_RL_移行
8_OP_保守運用
9_XX_管理など

記事タイトル

{カテゴリー番号}+{連番}+"_"+{記事概要}

見出し

  • やったこと(実施内容)
  • わかったこと(所感・随想)
  • つぎにやること(ToDo)

 

管理人について

経歴

大学・大学院で数学について学ぶも、一番の学びは「自分には数学の才能がない」ということ。
それまでプログラミングの経験は一切なし。

卒業後は大手SIerに就職し、業務アプリのエンジニアとして職務に従事。
入社2年目くらいで仕事に飽きてきたため、副業を模索した結果、不動産投資と暗号通貨投資、少人数私募債などの投資で日銭を稼ぐことに成功。
MLMや物販は向いていないらしい。というか嫌い。

そこそこの副収入ができたので仕事を辞めようか検討していた矢先、社則が副業OKとなり路線変更。
とりあえず会社員やりながら、兼ねてからの夢であるWebポータル事業を立ち上げようと画策中。

技術

仕事で使用していた言語は、COBOL、C、VB6という化石のようなレガシー言語のオンパレード。
オブジェクト指向フレームワーク?何それおいしいの?
一応Javascriptphpについては知ってる程度だが、総じて技術力は低い。

DBはOracleSQLserverMysqlを少々。
メインフレームではISAMという謎のファイルを使用。
CRUDできればいいんでしょ?DDL?知らねw

アプリエンジニアでありながら仕事の行きがかり上、JP1やArcserveなどのミドルウェア、はたまたネットワーク構築やサーバーラッキングまで手掛ける羽目になる。
インフラの味を占め、Linuxについて独習し、VPSで簡単なLAMP環境くらいなら作れるレベルになった、インフラ寄りのアプリエンジニア。
(むしろ今ではインフラの部署に行きたい)

 

おわりに

大した内容にはならないかも知れませんが、書いた内容が少しでも、技術者、またはWebポータルサイト構築を夢見る若者の目に止まる物になるよう頑張ります。
なので、どうか温かい目で見守っていただければ幸いです。