てっぱんITクラブ
今回はシステムを作るときの進め方について解説するよ
システムを作るときって、バーっとパソコンに向かってカタカタやるんじゃないんですか？
実は全くそんなことないないんだ。
むしろパソコンよりも人と会議をしていることや、カタカタよりも資料を作るときの方が長かったりするんだよ。
え！意外！！
ぼくがよくやっているゲームとかも、そういった作られ方をしているんですかね？
そうだね、会社によって細かくは異なるかもしれないけど、大きく分類するとシステムの作り方は同じなんだ。
今回はそんなシステムの作り方・開発手法について学んでいくよ。
目次
システム開発プロセス
システムを開発する時に大事なのは、闇雲に始めないこと。
しっかりとゴールを見据えて計画的に開発をしないと、結局何が作りたかったのかわからなくなったり、出来上がってみて思っていたのと全然違う場合があったりするんだ。
まして仕事でシステムを開発する場合、規模も大きくなって複雑な処理が多くなる。
そういった時に役にたつ開発プロセスがあるんだ。
開発プロセスに沿った開発を進めることで、誰でも比較的簡単にちゃんとしたシステム開発ができるようになるってわけさ。
共通フレームでの開発の流れ
開発の流れを示した共通フレーム2013というものが世の中には存在する。
大まかな流れはこんな感じ。
矢印の形で工程は進む感じだよ。図の細かい用語は後で説明するとして大まかな流れだけ掴んでおいて。
実際にシステムを開発するときは、ほとんどの場合この流れに沿って開発が進められるんだ。
また基本的に順番に工程は進むから仮に途中で間違いや勘違いが発生した場合は、工程を戻る必要があるから大変になる。
注意点としてはとにかく確認して、工程の戻りを減らすことだよ。
共通フレームを使う理由
共通フレームの細かい用語などを説明する前に、共通フレームを使うのには理由があるっていうのを説明しておくよ。
共通フレームがない時代はソフトウェア作りっていうのは職人芸のような要素が強かった。
システム開発をお願いしたら、完成するまでよくわからない状態になって、「〇〇の機能が入ってないじゃん、こんなの言わなくてもわかるだろ！」みたいな喧嘩だって起こってしまうことがある。
これを解決するために共通フレームができた。
共通フレームに沿った進め方をするので、今どの段階にいるのか、システム開発に必要な情報は何かを明確にすることができるようになったんだ。
これによってシステム開発が職人芸から、一般的なものへと移っていくことになった。
共通フレームを使えば最低限のシステム開発が行える安心感になるってわけさ。
企画・要件定義プロセス
じゃあ実際に共通フレームの内容説明に移っていくよ。
まずは企画・要件定義プロセスだ。
システムの規格プロセスでは、二つのことを実施するよ。
システム化構想立案とシステム化計画立案。新業務体制の全体像を作ったり、システム化構想を具体化するために対象業務の確認や分析をするプロセスだ。
開発スケジュールを決めて、導入した場合の費用対効果を予測することもする。
企画プロセスが終わったら要件定義プロセスだ。
システム発注者のニーズを考慮してシステム化の対象になる業務の業務手順や関連する組織におけ責任、権限などを決めて業務要件、組織及び制約条件を明確にしていくよ。
システム発注者の言葉を聞いて何をシステムに組み込むか、合意を取るプロセスになる。
システム開発プロセス
要件定義プロセスが終わったらウギはシステム開発プロセスになる。
システムの要件定義を行なって、システム方式設計を行う作業をするよ。
要件定義で決まったシステムの要件をシステムの技術的要件へ変換するプロセスだ。
勤怠システムを作る時で、要件に「勤怠は指紋認証で行える」というものがあった場合にシステム要件では「指紋認証を登録する方法」「指紋認証で認証を行える」などに分解していくイメージになる。
あとは非機能要件もこのプロセスで決めるんだ。
非機能要件とは、品質や速度などの一見ではわからない部分のことをいう。
稼働率や、何人までが同時アクセスしても大丈夫なシステムにするかなどを決めるプロセスだね。
ここまで完了したら、あとはシステム方式設計をする。
具体的にサーバを使うのかやプログラミング言語などを決めていく作業だね。
ここまででシステム開発プロセスは終わり、いよいよ実際にプログラミングをしていく工程が次だ。
ソフトウェア実装プロセス
コーディング作業の前にもう少し決めておくことがある。
セキュリティ仕様やデータ定義などの要件だ。
ソフトウェア要件定義と呼ばれる作業で、作るシステムの細かい部分を開発前に設計する作業だね。
そしてソフトウェア方式設計を行う。
ソフトウェア方式設計はソフトウェア要件定義で定めた要件をシステムの物理的な設計に嵌め込むんだ。
データ同士がどう繋がっているのかや、画面にどんな情報を表示させるとかをここで決める。
ソフトウェア方式設計が決まったら、次はソフトウェア詳細設計を行う。
ソフトウェア方式設計で決まった内容をもとに、実際にコーディングする前の細かい設計を行なっていくよ。
ソフトウェア詳細設計をしっかりしていればプログラミングは、ソフトウェア詳細設計に沿ってコードを書くだけになるくらい重要なプロセスになる。
ロジックなども書くよ。
そしていよいよ、ソフトウェアコード作成（プログラミング）プロセスだ。
ソフトウェア詳細設計をもとに実際にコード、プログラムを書いていく。
プログラミング言語の文法を使って粛々と書いていくだけだよ。
テスト
コーディング（プログラミング）まで終わったらあとは動かして、要件通りにシステムが動くかテストしていくよ。
ゲーム業界では大人数を雇って「壁に何万回もぶつかってみたり」「ひたすら村人に話しかける」なんてテストもあったりするけど、そのイメージに近い。
要件で決まったシステムになっているかを細かく確認する単体テスト、システム全体を通して問題なく動いているかを確認する総合テスト、想定している最大のアクセスに耐えられるシステムか確認するシステムテストなんかをやっていくよ。
受け入れ、検収、システム移行
一通りテストが完了したら、あとはシステム発注者に確認してもらう。
受け入れテストと呼ばれる作業で、受け入れテストに合格できるとシステム納品へと移っていく。
要求通りにシステムが完成していれば検収をもらえて、晴れてシステム開発が完了できるんだ。
あとはシステムを実際にユーザに見てもらえる状態にしていく作業、システム移行を行なっていく。
移行計画書を使ってどのような手順でシステムを本番化するのかを決めていくよ。
システム移行を経て初めてシステムは世の中に出ることになる。
ここまでが一通りの開発作業であとはシステムが世間に出てからやっていく作業だよ。
運用・保守
運用・保守と呼ばれるプロセスでシステムが世間に出ている間に発生するエラーやバグに対応していくプロセスだ。
業務に大きなダメージが与えられることが起こった時に、いかにシステムを停止させずに迅速に復旧するかなどが鍵になってくる。
以上が共通フレームを使った開発だ。
疲れたーどうだった？理解できそう？
お、大まかな流れはわかったかなって感じですね。
同じく！
細かいところで何をしているのかわからない部分はありますけど、こうやってシステムってできてるんだーって感じですね。
ちなみにてっぱん先輩も実際、共通フレームに沿って開発してるんですか？
やってるよ！細かいところで会社ごとにアレンジしていたり、決まったフォーマットを埋める形で開発資料を作ったりってことはあるけど大体この流れで多くの会社はシステムを開発すると思うよ。
ちなみに僕はテストが特に苦手だよ笑
え、なんで苦手なんですか？
軽く説明はしたけど、ちゃんと動いているかをかなり細かいところまで確認するのがテスト作業なんだけど、僕は数字を1つずつ変えながらテストするとか細かい作業って面倒くさいって思えちゃうタイプなんだよね。
受け入れテストで拾って直せばいいじゃんって思っちゃう悪いところなんだけど、そういった話もあるんだ。
へー、大事だけど実際やってみると大変すぎることもあるんですね。
そう、ナイスフォロー
共通フレームは大変なこともあるけど共通フレームに沿って進めることで品質を担保できるから重要なんだ。
開発手法
共通フレームで開発の大まかな流れがわかったところで、実際に開発手法はどんな感じがあるのか説明していくね。
開発手法によって、共通フレームに沿いながらも作る資料なんかが変わってくるんだ。
ウォータフォールモデル
共通フレームを順番にやっていく開発手法をウォータフォールモデルというよ。
川の流れのように上から順番にやっていくプロセスで最も古くてポピュラーな開発手法になる。
長所は進捗がわかりやすい点、短所はプロセスが進んだら戻るのが大変ってところ。
例えば、プログラミングしている最中に要件が不明確なところが見つかった時、プロセスを戻るのにすごいやり直しが必要になってくる感じだ。
アジャイル
ウォータフォールモデルは計画が狂うと一気に総崩れしてしまうマイナス点があったけど、そんな欠点を補う形で生まれた開発手法がアジャイルなんだ。
アジャイルは対応重視型の開発手法で、臨機応変さがすごい開発手法になる。
要件定義、設計、開発、テストを細かい単位で行なって、すぐにリリースする。
ダメな部分や修正の必要があれば、また要件定義、設計、開発、テストを行なってすぐにリリースする。
要件定義、設計、開発、テストを細かい単位で行いスピード重視にすることで、臨機応変さが出るんだ。
ウォータフォールモデルは、家を立てるイメージで設計からしっかりやって順番に開発が進む。
対して、アジャイルは、アプリ開発みたいなイメージだ。アプリはバグがあってもとりあえずリリースされる。アップデートを繰り返すことで徐々に完成されたものになっていくよね。
アジャイルはまさにそんなシステム開発手法になる。最初から完成されたものではなく少しずつ完成されたシステムを作っていくイメージだね。
もしかして、てっぱん先輩はアジャイル型の性格なんですかね！
あー確かにそうかもしれない！
ミスをすることを避けるよりもミスをどうやって次に活かすかの方が性に合っているんだよね。
私もそういうタイプですね。
やきそばくんはウォータウォールモデルっぽい性格だよね～
確実にやっていくタイプ♪
そ、そうですけど、なんか、ぼくだけ仲間はずれ、みたいですね…
落ち込むことなんてこれっぽちみないよ。
アジャイルが優れているとか、ウォータウォールモデルが優れているってことじゃないんだ。
それぞれ向いているシステムがあるって感じなんだよね。
システム開発で出てくる用語（WBS、UML、オブジェクト指向）
最後にシステム開発でよく出てくる用語について解説するよ。
WBS
Work Breakdown Structure（作業分解構成図）のことで、プロジェクト全体の細かな作業に分解して構造化する手法だよ。
実際の作業を細かく分解して何をいつまでにできそうかという計画を明確にするんだ。
これで実作業に分けた中でスケジュールに合わせて進捗管理とかをするのが主流だね。
UML
Unified Modeling Language（統一モデリング言語）はソフトウェア開発において、要求定義工程や設計工程などの成果物を統一させるためにできた資料の書き方になるよ。
資料の書き方を統一することでシステム開発をお願いする会社ごとにバラバラの成果物になってしまうのを抑制することができるんだ。
オブジェクト指向
データとデータをどうするかという手続き（メソッド）をまとめたものがオブジェクトだよ。
オブジェクトを使うと、メソッドさえ知っていれば内部構造を知らなくても利用できるメリットがあるんだ。
オブジェクトの詳細はそれ一つで1記事になるから別にまた紹介しているよ。
リバースエンジニアリング
機会をバラして技術を習得する行為のことをリバースエンジニアリングと呼ぶよ。
ITの世界では完成しているシステムの機械語を逆コンパイルしてプログラミング言語に戻してから、分析する手法のことをリバースエンジニアリングって呼ぶんだ。
まとめ
今回はシステム開発について説明してきたわけだけど
どうだったかな？
システム開発って大変なんですね。
私やっぱりIT業界には進めなさそうかもって思いました。
言葉で説明するだけだと難しく感じるかもしれないけど、決してL子ちゃんじゃできないなんてことはないと思うよ。
正直誰でもできるといってもいいと思う。
性格の向き不向きはあるかもしれないけど、ITの深い知識が全ての工程で必要かと言われるとそんなことないし、要件定義なんかはコミュニケーションスキルなんかの方が重要だったりするんだ。
そうなんですね！
もうちょっと頑張ろうって思えました。ありがとうございます。
今回はここまで！
今回紹介した内容が試験にどう問われるかはぜひ問題集を解いて、知識を自分のものにしてもらえればと思う。
はい！ありがとうございました！！
