エンジニアリングの基礎を学べる【おすすめ本】ソフトウェアエンジニアリングの新人研修

ミミウサ

私、エンジニアではないけど、エンジニアの新人が学ぶレベルの知識はつけたいな。

エンジニアとエンジニアではない方の技術的な知識格差が広がりつつあります。

非エンジニアの方でも、エンジニアの新人研修で習うようなところからなら入っていけそうですよね。

非エンジニアである私、そう考えましてAmazonの中で必死に探しましたのがこちらの解説書です。

「ずっと受けたかったソフトウェアエンジニアリングの新人研修」宇治則孝監修　大野久美子/岡崎義勝/西原琢夫　著

解説書のレビューというよりは、内容を一部編集して概要だけまとめさせていただきました。

私と同じようにエンジニアリングの基礎を学びたい非エンジニアの方が、本書籍を選ぶ前の参考にしていただけたら幸いです。

Contents

開発プロセスとは
「機能要求と非機能要求」と「サービス評価」
1. 機能要求と非機能要求
2. 商用化のためのサービス評価
おわりに「意外と経験のあるエンジニアほど忘れていそうな内容」

開発プロセスとは

開発プロセスとはやりたいことが顧客の頭の中だけにある状態から、それをプログラムとして実現するまでの開発の手順を示すものです。

ウォーターフォール型

ウォーターフォール型では、開発は時系列に沿って段階的に進むと考えます。
分析や設計など抽象的な方法を行い、それが完了したら次にプログラミングやテストなど具体的な工程を行います。

各工程は基本的に後戻りせずに、順番に進めていきます。

ウォーターフォール型に対しては、次のような問題点が指摘されています。

不具合が最後の工程であるテストを行うまで見つからない場合が多い。
テストで見つかった不具合の原因が、分析や設計にある場合、最初まで遡って修正しなければならず、それに関連するそれまでの作業が無駄になる。
どこかの工程が遅れると、その後の全工程の進行に影響が及ぶ。

スパイラル型

スパイラル型では、ウォーターフォール型の開発工程の中に、さらに分析開発と検証、次の計画、次の目標設定のフェーズを設け、それらを繰り返すことによって各工程が正しいかどうかを確認しながら、まるで渦のように開発工程を進めていきます。

また、スパイラル型の開発プロセスでは、各工程でプロトタイピングのタイミングが用意されています。

プロトタイピングとは、実際に動く見本を作り、その動作イメージを具体的にすることで、潜在的な問題では要求を見つけ出すことを意味します。

アジャイル型

現代のビジネス環境は、刻々と変化しており、ウォーターフォール型の開発プロセスでは設計では、そのときのビジネスに最適であったシステムも設計から開発を行う間に生じたビジネスの変化によって、完成した時にはもう用をなさないというような事態が発生してしまいます。

アジャイル型では、次のような視点が取り入れられています。

プロセスやツールより個人そのものや個人間の交流を重視せよ。
広範にわたる大量の文書作成より、きっちり動くソフトウェアの作成に注力せよ。
契約に関わる交渉より、顧客と協調することに重点を置く。
無理に計画に従うより、目の前の変化へ柔軟に対応する。

これまでには考えられなかったような視点ですが、変化する顧客の情報を取り入れることができ、素早い開発が可能な手法として少しずつ普及が進んでいます。

XP(Extreme Programming)

XPは代表的なアジャイル型の開発手法です。

XP ではコミュニケーション、シンプル、フィードバック、勇気、の四つを価値ある事象として捉えて重要視します。

「機能要求と非機能要求」と「サービス評価」開発者同士あるいは顧客と開発者との間のコミュニケーションが不可欠であること、プログラムはシンプルであるほど良いということ、フィードバックされることが次のアクションを向上させること、そしてこれらを果敢に行うために勇気が必要であること、と言えます。

XP で開発を行うときは、イテレーションと言われる数週間程度の短期間を単位としてプログラミングを進めます。一定のイテレーションを重ねて、ある程度まとまりのある機能が完成したら、それをリリースします。そのリリースを繰り返すことでシステム全体を開発していきます。

「機能要求と非機能要求」と「サービス評価」

「要求定義と要件定義」で検討すべき、「機能要求と非機能要求」と「サービス評価」についてです。

機能要求と非機能要求

要求とは顧客の要求です。要求はさらに機能要求と機能要求に分類して捉えます。

両者の違いですが、システムに求められる処理機能を機能要求と呼びます。

機能要求は、顧客の業務に必要な手順を実現するための機能、例えば「顧客の氏名を登録する」、「顧客の氏名から住所を検索する」などが当たります。

これに対して、「顧客の氏名から住所を検索する処理は0.5秒以内で完了する」、「システムが故障した場合でも1時間以内にサービスを再開する」といった要求は、システムに求められる処理機能でも顧客の業務に必要な手順でもありませんが、システムが備えるべき条件と言えます。このような要求を非機能要求と呼びます。

このように性質の違う二つの要求は、この先の設計工程においても実現方法が異なります。多くの場合、機能要求はプログラム内部でのデータの処理の仕方やデータベースの作り方を、非機能要求はハードウェアなどのシステム構成要素を左右します。このように性質が異なるだけでなく、影響を与える対象や設計手法も異なるため、両者を分類してから別々に検討する場合が多いのです。