7
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

エンジニアになるなら知らなきゃヤバイ! システム開発の流れ

Last updated at Posted at 2021-11-08

エンジニア(プログラマー)の仕事

未経験の方だとエンジニア(プログラマー)はコードを書いてひたすら何かを作っていると
思う方がいらっしゃいますが実際は違います。

⚫︎プログラマーの仕事をざっくり分けると下の4つです。

1 クライアントからどんなものを作って欲しいのかヒアリングする
2 開発できるか調査をし、設計する
3 コードを書いて開発をする(基本は共同開発)
4 ドキュメントにまとめる

上の4つが仕事の内容なのですが、
エンジニアを目指してプログラミング学習をする時にコードを書くだけでは
戦力になれないことがわかるかと思います。

エンジニアの仕事(プログラマーの仕事)を一言で表すと、
実現したいサービスを形にする仕事かなと思います。

未経験から実務に入った時はいきなり設計しませんが、
ヒアリング、ドキュメントを書くことは実務経験の期間が短い人でもやるかと思います。
いずれは必要になるので学習段階から以下の2点は
学習段階から取り組む必要があるかと思います。

・相手の意図を汲み取り、適切なコミュニケーションをする
・ドキュメントにわかりやすくまとめる力

こういったことを力をまとめると言語化する力になります。
何をやりたいのか、どういうことなのかを言葉にしていく力のことです。
別の言い方をすると相手への気遣いかなと思います。

これらは実務で必須みたいです。

システム開発の流れ

上のことからコードを書いて開発は仕事の1つかと思います。
なのでこの記事でどのような流れで開発がされるのかを説明します。

下のような流れで開発が進みます。

1 企画
2 要件定義
3 開発
4 運用
5 保守

上のような流れで開発が進みます。
開発して終わりではなく、バグを修正したり、ちゃんと動くかテストをしたりします。
システム開発の流れを上のサイクルでまとめてソフトウェアサイクルと言います。
これから詳しくソフトウェアサイクルについて説明していきます。

システム開発の調達

調達とは開発をする人***(システムベンダ)に対して発注***をすることです。
開発の前に契約をする必要があります。契約締結までの流れを簡単に説明します。

基本は
発注側 ⏩システムベンダ
発注側 ⏪ システムベンダ

の両者のやりとりで行われます。

1 情報提供依頼
発注側が何かシステム化したいとなった時に、最新技術などの情報提供をシステムベンダに依頼
システムベンダが情報を発注側に提供

2 提案依頼書の作成と提出
システムの内容や予算をシステムベンダに提出

3 提案書の受け取り
システムベンダが具体的な内容を発注者側に渡す。

4 見積書の受け取り
提案内容にokが出たら、費用をまとめて発注者側に渡す。

5システムベンダの選定
提案内容や見積書を確認し発注し取引が始まる。

これから細かい流れを1つ1つ見て行きます。

要件定義

要件定義はつまりクライアントから必要な機能や何をやりたいのかをヒアリングします。
ex) 何か不便なことあるか? 業務を分析してどの業務を自動化したいかなど

要件をまとめて要件定義書を文章として作成し、クライアントに確認します。

システム設計

上の要件定義の内容をベースにしてどのように開発していくのかを設計して行きます。
例えば漫画とかゲームで兵器や基地を作る時にも設計図とかありますよね。
それと同じで設計図に当たるシステムを設計して行きます。

⚫︎外部設計
外部設計は利用者目線の設計です。
つまり実際のユーザーが触れる画面などです。
ex) このボタンを押したらこう表示されるとか

⚫︎内部設計
内部設計は開発側目線の設計です。
つまり外部設計と連携して裏側の目に見えない処理のことです。
機能ごとに分割して必要な処理と処理同士のつながりや入出力のつながりを
明確にしたりします。
ex) このボタンを押したらこういう処理が走ってこういう挙動になるみたいなど

⚫︎プログラム設計
プログラム設計はプログラムをどのように作るかの目線での設計です。
処理をモジュール単位に分けてモジュールごとに作成したりします。

プログラミング

システム設計をした内容をもとにプログラムを書き開発していきます。
プログラミング言語を書いてコンピューターにこうやって動けと指示を出して
いくことをプログラミングと言います。

こうしてプログラムで書かれたコード(ソースコード)を機械語に翻訳してプログラムが実行されます。

●補足
 
1 バイナリコード 
コンピューターが理解できるコードのことです。

2 ソースコード
人間が理解できる言葉で書かれたコードのことです。

テスト

プログラムができたらちゃんと動くのかをテストします。
例えばRailsで開発した場合はRSpecというテストフレームワークを使ったりします。

⚫︎単体テスト
単体テストはモジュールを検証するテストです。
例えばmodelのテストをするときは単体テストです。

⚫︎結合テスト
結合テストはモジュール間のインターフェースを検証するテストです。
複数のモジュールを組み合わせてテストをします。
例えばCRUD処理のテストをしたりします。

⚫︎システムテスト
システム全体を稼働させて動作確認をします。

⚫︎運用テスト
実際の運用と同じ条件下で動作確認をします。

詳しくはこちらの記事に載せてあります。
https://qiita.com/Hashimoto-Noriaki/items/960a8b4c79bf1ad09109

運用保守

運用は実際にリリースされたサービスを使い、
保守はちゃんと動き続けるかを管理していくことです。
実際に障害が起きた時に対応したり、日頃からメンテナンスをしたりします。

最後に

エンジニアはコミュニケーション力が大事だと言われますが
ここでいうコミュニケーションは巧みなトーク力でもなく
明るく社交的という意味でもありません。
現役エンジニアの方から何度もダメ出しをもらい、
主に下の3点かなと思いました。(冒頭の繰り返しになるのですが)

1 相手の意図を汲み取り、適切な質問をする。つまり相手に負担をかけない質問力。
2 自分のやりたいことや困っていることをわかりやすく言葉にし、相手に伝える力。
3 相手が読みやすく要点をまとめたわかりやすい文章。

自分は当初全くできませんでした。(まだ課題があり改善しなければいけないことばかりですが)
これらを改善できた方法は2つです。

1 現役エンジニアに質問をして指摘をもらう
 指摘がないと何をどう改善すればいいのかわかりません。
指摘、改善の繰り返しで上達して行きます。

2 なるべく自分の言葉でドキュメントを書く
Qiita,note,ブログあたりでいいかなと思います。
なるべく自分の言葉で説明できるといいかと思います。
この辺が難しければTwitterあたりから始めるといいかもしれません。
文字制限があるので要約の練習になるからです。

スクールでただ勉強するのではなく主体的に自分で取り組んていくのが大事だと思うので
実践してみてください。

⚫︎参考資料

7
13
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
7
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?