WEBエンジニアのポートフォリオ作成！WEBサービス作りの参考に！

 

こんにちは、古賀です！

 

本記事では、

についてお話します！

 

「ポートフォリオ」と言っても、スキル一覧等が記載されている自己紹介サイトではなく、「成果物」の方のポートフォリオです。

WEBエンジニアであれば、WEBサービスのことです。

WEBエンジニアを目指して、未経験から就職するとなれば、WEBサービスの作成は必須になりつつあります。

そのWEBサービスを実際にわたしが作った時の、

• 「手順」
• 「考え方」
• 「作り方」

などを紹介するので、WEBサービス作成の手助けになればと思います！

 

自己紹介が遅れましたが、

わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして

約１０年間働いておりまして、現在フリーランスとして活動しております。

プロフィールの詳細はこちらです。

※ちなみにわたしは大卒後にSIerへ就職したので、「未経験からポートフォリオを作成して就職した」ことを経験していません。

そして、フリーランスとして活動していく上で作成したポートフォリオとなるため、未経験から就職を目指す方々と少し状況が違います。

あくまでWEBサービス作りの参考までに！

 

作成したWEBサービス及びソースコードはこちら(野球、ソフトボールのスコア管理WEBサービス)です。

このWEBサービスの使い方については別記事でお話したいと思います。

今回はどのように作っていったかを中心にお話します。

 

※YouTubeに同内容を公開しております。

WEBサービスを作る前に

 

はじめに実際に手を動かしてWEBサービスを作る前にやるべきことを挙げると、

この３つです！

何のWEBサービスを作るか決める！

まずはどんなWEBサービスを作るのか決めましょう。

と言われても

「何を作ったらいいのか。。」

となりがちです。

 

そうなってしまったら「自分が使うもの」を目的に作るのが良いと思います。

WEBサービスとしての本質は「周りが使いたいもの」を作るのが一番良いですが、

いきなりそれだとハードルが高いので、まずは自分を満足させるものを作りましょう。

わたしの場合は、草野球をしていて、

「あまり手間をかけずに簡単にスコアをつけたい」

と思っていたので、野球のスコア管理サービスを作りました。

自分が使うものであれば、WEBサービスを作り上げるまでのモチベーションを保つことにも繋がると思います！

似たようなWEBサービスを調査！

作るWEBサービスのテーマが決まったら、似たようなWEBサービスがないか探してみましょう。

実際の事業でも行うことですが「市場調査」をします。

その中で

• 参考にする部分
• 差別化する部分

を見つけましょう。

わたしの場合は、「スコア入力」や「成績項目」の部分を参考にしたり、

草野球あるあるの「途中参加」、「途中退場」、「再出場」、「他のチームと成績比較」したりできるところを差別化ポイントにしました。

なかなか作るイメージが沸かない部分は、参考にできるポイントを見つけてイメージを沸かせましょう。

差別化ポイントは自分が使う時をイメージして「あったらいいなポイント」を見つけましょう。

そこがポートフォリオの「オリジナル要素」、「こだわりポイント」になります！

 

「作りたいWEBサービスを決める」と「WEBサービスの調査をする」、この２つの順番は逆でも良いです。

WEBサービスを見て回っていて、

「このサービスのここを改善したいから作った」

でも全然ＯＫです！

作る機能を決める！

テーマを決めて、作りたい他のサービスを調べたら、実装する機能を書き出してみましょう。

ここで言う「機能」はプログラムの中身のことではなく、ユーザ目線で必要な機能のことです。

私の場合だと、

• ユーザを作成
• チームを作成
• 選手を作成
• スコア入力
• 試合結果を見る
• 成績を見る
• メッセージを送る

機能などです。

ここで大事なことは、

「付ける機能を多すぎないようにする」

ことです。

 

機能が多ければその分作る期間も長くなりますし、難易度もあがり挫折してしまいがちです。

自分のスキルと照らし合わせて、背伸びしたら届くくらいの機能を作るようにしましょう。

実際のWEBサービスでも最初は少ない機能でリリースして、後から機能をつけ足していくことがほとんどです。

まずは最低限必要な機能だけ作って、後から付け足す意識でも問題ありません。

WEBサービスを作るための技術を決める！

作る内容を決めたら、次は技術目線で作るための技術を選びましょう。

具体的には、

などです。

 

ちなみにわたしが使用した技術は、

です。

 

わたしの場合は慣れているMicrosoft周りの言語や技術を使用しましたが、自分の進みたい道でよく使用されている技術を極力選んだ方が良いです。

言語の場合、機械学習系のライブラリを使用する必要があるのであればPythonですし、並行処理が多くあればGo、特に理由がなければ使われている割合が多いRuby、PHPといった感じです。

 

DBの場合は、MySQLやPostgreSQLの方がよく使われていますし、クラウドサービスもAWSやGCPの方が一般的です。

進める道を増やすためにも、最初はできるだけメジャーな言語やDBを使用することをオススメします。

また、

• dockerでの開発環境作成
• CI/CD(自動テスト＆デプロイ)

といったことも対応できればベストです！
※ちなみにわたしはやってません！

サービスで使用する技術に関して、

など色々とありますが、全部無理に入れようとはせずに必要になった技術だけ入れれば良いと思います。

わたしの場合だと、スコア入力はスマホ対応が必須だったので、レスポンシブ対応は必須でした。

あとはログイン状態を保つためのセッションや、各一覧ページのページングや検索というように、最低限必要な技術だけ使用しました。

無理に盛り込もうとすると、機能が膨れ上がってしまうので注意しましょう！

WEBサービスを実際に作る！

作る内容、使用する技術を決めたら、実際にWEBサービスを作り始めましょう！

作る順番は人それぞれなところもありますが、わたしが実際に行ったWEBサービスを作る大まかな手順は、

です。

作るページを決める！

まずは実装する機能に対して、作るページの単位とそのページにどんな項目が必要か決めましょう。

チーム開発を想定して、一度設計書をしっかり書いたりしてもいいですが、個人開発であれば設計書はそこまで必須ではないと思います。

わたしの場合は、機能を書き出したメモに対して、その詳細をどんどん書き足していく感じです。

これが実際のメモの一部ですが、ページや機能に対して雑に書き足しているだけです。悩みや課題も忘れないように一緒に書いています。

Order
⇒Edit、Create(割り込み用)
GameScene　※シーンは修正を考えるとID保持？　イニングindex必要か？そうであれば保持しなくてdeleteinsertでOK
⇒Edit(Create)
修正割り込みとか難しそう(打撃の割り込み)。。やっぱり考慮は後回し
シーン修正は既存表示で再読み込み機能はつけるべき
InningScore
⇒Details
※createEditはGameEditへ
イニングスコア詳細は履歴を並べる⇒シーン編集へ遷移できるように
Game
⇒Details、Edit、
・試合一覧の遷移ボタンに基本情報修正(GameEdit)か試合修正(GameSceneEdit)か？
⇒それぞれボタンを用意する、試合前だと試合へボタンは出ない
試合終了だとリザルト画面へ(GameScoreEdit)
※GameScoreEdit２パターンにする？
GameScoreEditで何を変更させるか？
イニングスコアは確定、投手成績も確定(勝ち負けホールドなど)、野手、投手のdetailは別画面(打席事入力はシーンで治す、結果のみは別画面、打席事でも紐づけ解除で入力可能にしたい)
成績一覧で
・イニングスコアクリックで該当イニングの先頭修正に遷移する
GameScore
⇒Edit、Details

GameScoreFielder、GameScorePi
⇒Create、Edit
各選手の成績を入れる単純画面
⇒全部同一画面にした

Score
⇒Index,Pitcher、Batter、Team
※すべて(個別チーム、公開チーム共有)　パラメータでわける
Index　年度、試合種別、カテゴリ(使用球、年代)、選択可能、できたら規定投球回(試合数*イニング(最高でも9)/9)、規定打席(試合ごとに3.1*イニング(最高でも9)/9を加算)（各チームの値を出してその平均にする）
⇒チーム：順位、チーム名(リンク)、勝、敗、分、勝率、得点、失点、本塁打、盗塁、打率、防御率　※勝順
投手：順位、チーム名(リンク)、投手名(リンク)　勝
順位、チーム名(リンク)、投手名(リンク)　防御率
順位、チーム名(リンク)、投手名(リンク)　奪三振
順位、チーム名(リンク)、投手名(リンク)　勝率
野手：順位、チーム名(リンク)、野手名(リンク)　打率
順位、チーム名(リンク)、野手名(リンク)　打点
順位、チーム名(リンク)、野手名(リンク)　本塁打
順位、チーム名(リンク)、野手名(リンク)　盗塁
他ページ　年度、試合種別選択、カテゴリ(使用球、年代)可能、できたら規定投球回、規定打席、ソート可能
⇒

既定試合数
ソート
⇒ordervalueに値入れ、指定列を色替(JS)
規定に関する項目は条件を絞る⇒これはマニュアル指定でいいかも⇒項目みてIsIgnoreフラグの指定を強制的に変える
適切な戻るボタン
詳細ページ遷移ボタンにソートアイテム指定
Team
⇒Details
・チーム詳細画面に成績表示
⇒通算、年度別
Member
⇒Details
・選手詳細画面に成績表示
⇒通算、年度別
Message
⇒全般
トップ画面にメッセージがあるかどうか？既読機能つける？
カードを作成して右側に配置
左側に一般投稿、ダイレクトメッセージの切り替え
縦スクロール
⇒いらないかも

メッセージの種類
一般投稿(Pub、Rep)
の返信(Pub or Pri)
ダイレクト投稿　チームを指定(Pri)
の返信(Pri)

とりあえず
左に新規投稿画面、スマホだと上
他と同じように右側に一覧画面作る(切り替えあり、一般最新、自分に関わる一般、ダイレクト)⇒画面乱れるからテーブルよりカードの方がいいかも
⇒カードのデザイン
チーム名(リンク)、アカウントID(リンク)､メッセージ本文、時間
親メッセージと子メッセージデータ必要(親ID持っておけばいいかも)
履歴クリックでやり取り表示
返信ボタンクリックで返信(モーダルでいいかも)
既読機能⇒開いたらにする？ボタン押したらにする？

削除済みは本文非表示
公開投稿は公開チームしか使用できない
修正はなし

単純なページであれば特にページの絵は必要ないですが、複雑なページであれば入力項目と表示させる項目の位置を表した大まかな絵を描いておきましょう。

テーブル設計＆作成をする

ページの概要が決まったら、それを実現するためのテーブルを設計して、DBにテーブルを作成しましょう。

ページの概要をもとに、必要テーブル、そのテーブルの項目を書き出していきます。

テーブル設計においても、設計書を別に作る場合もあると思いますが、わたしの場合は特に設計書を作ることはなく、テーブルのコードを直接書いています。

使用するフレームワークによってはコードからテーブルを作成(マイグレーション)してくれるので、テーブルに関してはコードで一元管理を行っています。

 

また、テーブルを作成したらいくつかサンプルデータを作っておくと良いです。

動作確認を行ったりする際に最初からいくつかデータがあると非常に効率が良いです。

 

少し余談ですが、ページを作っている途中で、必要になったら随時テーブルを追加していく方法もありますが、

テーブルはなるべく一気に作成した方が良いです。

今から作るサービスの全体像をしっかり把握することができて、事前に課題が発見できたり、ミスを防ぐことに繋がるからです。

「後から追加していく」、「一気に作る」の切り分けは凄く難しい部分ですが、

「機能単位」は後から追加でもＯＫで、「機能作成」自体は「一気に作る」イメージです。

効率や品質の面を考えても「一気に作る」作戦はとても有効ですので、一気に作れるところは一気に作ってしまいましょう。

各ページを作る＆デプロイする

ページの概要、テーブルを作成したら、メイン作業のページ作成をしていきます。

ページを作る順番は好きな順番でも良いですが、ユーザが操作するページを順番に作っていけば、作りやすいと思います。

わたしの場合だと、

の順番でした。

 

単純なページであればスキャフォールド(作成、編集、削除、参照、一覧ページを自動生成してくれるフレームワークの機能)を活用しても良いと思います。

わたしの場合だと、ユーザ、チーム、メンバーあたりはスキャフォールドで一度ページを自動作成してから、

必要に応じて変更していくスタイルで進めました。使える機能は積極的に使っていきましょう。

 

そして、ある程度ページを作り終えたら、本番環境にデプロイしてみましょう。

出来上がってからデプロイしても良いですが、作成途中にデプロイすることで、

と良いところが結構あります。

 

また、デプロイはプログラム作成とはまた違った難しさがあるので、「デプロイが問題なくできる」ことで不安がなくなり、

メンタル的にも非常に楽になります。

キリの良いところで定期的なデプロイをオススメします！

 

各機能を実装するまでに、実装方法や意味不明なエラーで悩んだりすることがあると思います。

そこを自己解決できるかがWEBサービス作成で一番大事なところです！

自分で調べたり、他人に質問をしたりして課題を１つずつ解決していきましょう！

それが自分のレベルアップに繋がります！

調べる力や質問力についてはこちらの記事でお話してますので、読んでみてください。

質問力を鍛える！質問の仕方次第で得られる経験値が決まる！

サービスを知って、見て、使ってもらう工夫をする

各ページを作り終えてサービスが完成したら、最後にそのサービスを知ってもらったり、見てもらったり、使ってもらうために工夫をしましょう。

わたしの場合だと、

といったところをしています。このブログもそうですね！

 

GithubのREADMEには、サービス概要やサービスURL、使っている技術情報などを記載しています。

サービス自体のトップページや各ページにはサービスの特徴や操作方法を記載しています。

また、気軽に触ってもらえるようにログインなしで成績ページを見れるようにしておいたり、

サンプルアカウントを用意して、アカウントを作らずに各機能を体験できるようにしています。

わたしも正直どれも完璧には程遠いですが、最低限のことはやっておきましょう！

とにかく少しでも見てもらう、触ってもらうことを意識することが、WEBサービス作りの大事なポイントだと思います！

まとめ：WEBエンジニアのポートフォリオ作成

ここまでの話をまとめます。

 

わたしが作成した「野球のスコア入力」機能は、なかなか複雑なパターンもあるので、

• 不足している機能がないか
• 機能を実現するためのDB設計
• 試合で起こりうるパターンの洗い出し

など、サービスを作るためにバックエンドや上流の力が必要なサービスになりました。

それを実現できるところが自分の強みだと思っているので、

自分の長所が表れているWEBサービスになったのではないかなと思います。

ポートフォリオを見てもらう担当者にアピールする意味も込めて、

「自分が使いたい」に加えて「自分の長所が生きる」WEBサービスを作ることをオススメします！

 

また、今回の話はポートフォリオ作成のためだけでなく、実際にWEBサービスを作成する時にも応用できます。

特に「市場調査」であったり、「見てもらう」、「触ってもらう」ことを意識して作るところは実際のWEBサービスでも同じです。

技術力がある程度付いたら、今度は本気でWEBサービスを作ってみるのも良いと思います！

仮にヒットしなくても、必ず良い勉強になると思います！

わたしも今度やってみたいと思います！