LoginSignup
1
0

More than 1 year has passed since last update.

社会人としてやってはいけないミスをしてしまった。

Posted at

注意点

この記事は個人開発(ポートフォリオ作り)の中であった大きなミスについて取り上げています。
タイトル詐欺みたいになってしまったら申し訳ありません。

どのような問題を起こしてしまったのか?

先に結論から伝えてしまうと
「プロジェクト(作成中のポートフォリオ)を1個つぶした」

何があったのか?

現在、私はIt企業に転職をするためにポートフォリオ作りを行っています。
8月下旬ごろから2つ目のポートフォリオづくりを始めていました。

作成しようとしていたポートフォリオはかなり外部APIに依存したシステムとなっていました。
アプリケーション案の作成及び、調査の段階でAPIについて簡単に調べ、仕様に組み込んでいました。
※この時の簡単に調べるとは1~2のようなことです。

  1. APIから得られる情報を記事やサイトから調べる
  2. 実際にAPIを使用して、ポートフォリオ作りをされた方の記事を読む


そして下記のような流れでアプリケーションを作成していきました。

開発の流れ
アプリケーション案をまとめる。
           ↓
アプリケーションに必要な物の調査
           ↓
アプリケーションの機能一覧、画面遷移などの作成
           ↓
アプリケーションデザインの作成------------------>※今回の問題が発覚した場所
           ↓
アプリケーションの仕様作成
           ↓
アプリケーションの実装

デザインを作成している時にデータフローを作成していなかったことに気が付き、
データフローとデザインを同時並行で作成しながら開発を行っていました。
そこでデータフローを考えるうえでAPIから取得できる値を
詳しく知る必要が出てきたので、実際にAPIを実行して値を取得しようとしました。

しかし、APIが動いておらず、ポートフォリオ作りが止まってしまいました。

どのように対応したのか?

ポートフォリオ作りは止まってしまったので、すぐに以下の対応を取りました。

  • 代わりとなるAPIを探す
      →似たようなAPIがあることは調査していたので、再調査を行い、代替案になるものがないか探してみました。
  • アプリケーションの仕様を変更の可能性を探る
       アプリケーションの仕様を変更して、外部APIに頼らないような設計を考えてみました。

その結果どうなったのか?

代わりになりそうなAPIは見つからず、仕様も一番大切な機能だったので、仕様変更することができませんでした。

結果として、今回のポートフォリオ作成は中止となってしまいました。

もしこれが会社だったら?

ポートフォリオが白紙になってしまった時、 「これが会社でのプロジェクトだったら?」 と考えてみました。
その時、見も毛もよだつ思いがしました。
自社開発の場合
「自分の調査不足で会社のプロジェクトを1個つぶしてしまう」
受託開発の場合
「自分の調査不足で受託取引が1つなくなり、取引先の信頼を損ね、債務不履行を起こしてしまう」

この二つが頭の中を大きくよぎり、この失敗2度と起こしてはいけないと思いました。

今回のような問題を未然に防ぐためには?

  • 調査のゴールをしっかりと決めておくべきだった。
     調査をするうえで、どこまで調査したら、調査終了なのかを決めておけばよかった
APIを調査する上でのゴール
  使用するAPIから必要になりそうな情報を収集することができるのかを確認すること
  APIが正常に稼働しているのかを確認すること
  実際にAPIを実行して、ステータスコード200と必要な情報が取得できるのかを確認すること
  • 調査の段階で代替案を考えておくべきだった。
     もし止まりそうなものサービスや外部APIを使用する際、別のサービスまたは外部APIから
     同じようなデータが取得できるかを調査の段階で明確にしておくべきだったと思っております。

もし会社で同じような問題に直面してしまったときはどうすればいいのか?

  • 問題が発覚した時点で相談する。
  • 代替案がないか調査を行う。

基本的には上記の2点かなと思います。
アプリケーションの開発が動き始めているので、
プロジェクト全体を巻き込んだ仕様変更などは難しいと思われます。

まずは報告し、問題の共有を行う。
次に代替案がないかを調査していくのが基本的な流れかなと思いました。

しかしながら、一番は
このようなミスが発生しない様に事前の対策はしっかりと行い、問題が発生しない様にすることが最優先と思います。

おまけ:外部APIに大きく依存していることでどのようなデメリット

外部APIに大きく依存した設計を行ってみて、感じたことも簡単にですが書いておきます。

  • 外部APIが停止してしまうとアプリケーションも実質停止してしまう。
     外部APIに大きく依存している場合、アプリケーションの機能停止などが起こってくる。
     APIが停止した際にはそのアプリケーションをどうするのかを考えておく必要が出てくる。
     
     
  • 外部APIの変更などによりアプリケーションの修正が必要になってくる。
     外部APIの変更により、データ構造の変化などにより機能が停止してしまうことがある。
     その時に、アプリケーション側のソースコードを修正して、apiの変更に対応しなければならない。

終わりに

正直なことをいうと自分が実際に直面した問題や実際に体験したことを解決したいと思い、今回のポートフォリオを作成していました。
ですのでポートフォリオをつぶしたときかなりは落ち込んでしまいました。

一方で本当に幸いだったのはこの問題がポートフォリオ作りで発生してくれたことは本当にラッキーだったなと思いました。
今回の失敗から調査要件のことや外部APIに依存することのデメリットなどがかなり鮮明に見えてきたのはかなりの収穫だったなと思っています。

この経験を糧に次のポートフォリオ作りも行っていきたいと思います。

案が白紙になってしまったので、前回のポートフォリオを作成したときに時間の関係でアウトプットできなかったものなどを
アウトプットしていきたいと思います。

誤字脱字などがありましたら、コメントしていただけると助かります。

最後まで読んでいただき、ありがとうございました。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0