BETA

【一人でWebサービス作る修行】企画設計・サイトマップ編【その1】

投稿日:2020-06-29
最終更新:2020-06-29

企画のコンセプトはこちらを参照
Web系ベンチャーに転職したので、一人でWebサービス作る修行始めた

前回の記事に拍手がついていた。
まだ宣言しかしてないのに目に入れてくれた人がいたなんて...。
こりゃちゃんと作りきらないと。

これから作るサービスは、簡単な書籍登録システムだ。
ゆえに「simple-book-recorder」というシステム名とする。
プロジェクト名を決めるのは大事だ。最初に名前を決めてしまえば、今後どんな方向にいくのかちょっとは見立てがたつし、データファイル名やスクリプト名のプレフィックスに頭文字を入れてしまえば他のリソースとも区別がつく。(「sbr-lambda-get-bookinf」とか)

さてまずはインフラを...と思い作業しつつ、今後の作業の見通しを立てようとしていたのだが、ここで疑問が走る。

ちゃんとシステムのコンセプトを決めずに開発が進むのか?

今回は練習というか経験値を溜めるためにサンプルな読書サービスを作ろうと考えていたが、
以下のようなことをちっとは頭使って考えなきゃならないのでは?

  • どんな趣味趣向を持ったユーザーが
  • どんなことを期待して
  • どんな状況でこのサービスを使うのか
  • その時どんな機能を提供したら、ユーザーの利益になるのか

Webサービスをトータルでデザインしていくことがまずは必要であると感じるようになってきた。
というわけで、トータルの方向性の段階からデザインに至るまで、以下の本を参照しつつ考えていく。
1冊ですべて身につくHTML & CSSとWebデザイン入門講座

全体の流れ

ここからの作業手順は大きくはこんな感じ。

  1. Webサービスの全体設計
  2. サイトマップ作成
  3. ワイヤーフレーム作成
  4. デザイン構築
  5. 実装・テスト
  6. デプロイ・リリース

じゃあ、全体設計でどうやるんだ?

全体設計

新しい企画をプランニングする時、筆者は普段ウチとソトを考える。
ウチとは自分の心の中。ソトとは競合のサービスや社会の動向をさす。
こうして現状と自分の頭の中を比べて、自分の頭の中にしかない部分、まだ社会に実装されていない部分を攻めていくのが常套手段だが、今回はみんながすでにやっている共通のことをやってみる
すでにリリースされている読書管理アプリを比較考量し、共通している機能を書き出すのだ。
なぜならそれが読書管理アプリに求められている最低限の機能であることを指し示し、その実装さえできれば今回の企画の趣旨を達成できるからだ。

例えばすでにリリースされている読書アプリはこのようなものがある。

既存の読書アプリ

  1. 読書メーター
  2. 読書ログ
  3. ブクログ
  4. 本が好き!

次にこれらを眺めてみて、どのような機能があるのか。体験してみる。
そして読書アプリに求められる機能をユーザーストーリーの形で書き出す。

ユーザーストーリー

  1. ユーザーはログイン・ログアウトしたい。なぜならユーザーごとにデータを管理したいから(1つのWebサービスでデータが公開されては困るから)
  2. ユーザーは読んだ本の属性データを記録したい。なぜなら過去に読んだ本を任意のタイミングで参照したいから
  3. ユーザーは読んだ本についてメモを残したい。なぜなら自分の感想をあとで見返して、別の本との共通点をさぐったりしたいから
  4. ユーザーは読んだ本をタグづけしたい。なぜならあとで検索して取り出すときの目印にするから
  5. ユーザーは記録した本を検索して取り出したい。なぜなら研究や別の読書でメモを参照したりして読書体験をより豊かにするため。
  6. ユーザーは記録した本の書影一覧をみたい。なぜなら本棚のように一覧にして並べることでインスピレーションが浮かんでくることがあるから

ゴタゴタ書いてはいるが、既存の読書アプリはこの何倍ものユーザーストーリーをカバーしている。
これだけだとみやすいでっかいボタンとわかりやすいテキスト入力欄だけがあるシンプルな読書アプリができそうな予感がしてくるが、そんなものが出来上がったら逆にヒットしそうな気だってしてくる。

余談だがこういったユーザーストーリを書いていると、夢が広がりすぎてしまう。
「論文のDBとリンクできたらいいんじゃない?」
「自分で選んだオリジナルな本棚がビジュアライズできたらかっこいい!」
「いや、既存サービスを徹底検証して、まだ誰もみたことのない機能を考案してやるぜ!」
ここでユーザーストーリーが拡大しすぎるとリリースまで漕ぎ着けず死んでしまうのがオチだろう。最低限サービスを成立させるものに絞るのがコツだ。
ザッカーバーグは言いました。完璧より終わらせろと。

ユーザーのイメージ像

ここまでくるとユーザーのイメージ像もなんとなく見えてくる。

  • 読書大好き人間
  • 高機能は求めない。シンプルに読んだ本が記録できればそれでいい。
  • ITへのアンテナ感度は一般人程度。
  • 読書のメモは長文になりがちなのでPCをよく使う

こんな人物像の人に刺さるようなサービスにしていく。

サイトマップ作成

ここから具体的なイメージを膨らましていく。
サイトマップ、ワイヤーフレーム、デザイン構築といったグラフィカルな作業をするのに、今回はFigmaというツールを使ってみる。

Figma

デザイナー御用達、無料かつブラウザベースで作れてなんなら共有もできちゃう今をときめくデザインツールらしい。
使い方はプロが親切に教えてくれている記事をありがたく上から読んでいく。

FigmaではじめるUI(Web)デザイン|Part1

そしたらサイトマップを作っていく。できたものがこちらなのだが...

...多分間違っている。
凡例で筆者がみたのは概念レベルでのまとまりだったのだが、「XX画面」と表記している通り、この図は具体的なページ単位で表現されている。だからこれから出来上がるシステムは基本的には五種類の画面しかないということ。

まぁ、設計情報が具体化することはいいことだし、小さいWebシステムを作っているのだから実際の画面単位でサイトマップができるならそれに越したことはなかろう。

次はワイヤーフレームを作っていく。先が長そうじゃ。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@editechの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう