本格的な情報システム開発プロセス

参考として、本来の情報システム開発のプロセスは、以下のようになります。

このような本格的な情報システム開発プロセスのサイクルを把握しておけば、ビジュアル・プログラミングでもフィジカル・プログラミングでも対応でき、小規模でもこのサイクルを何度か経験して力を付けていくことが可能です。

システム開発の工程には、いくつかの種類があり、ここでは、最も代表的なウォーターフォールモデルで説明します。「要件定義」の上流の工程から下流の工程の「検証（テスト）」へ順におこなっていくのが、このウォーターフォールモデルというシステム開発の種類の特徴です。

システム開発プロセス

①要件定義（要求定義）

顧客からどのようなシステムを作りたいかという「要件」を、システム開発会社が受け、その「要件」を整理してまとめることを「定義」としています。この工程では、新しく開発するシステムに、どんな要素を盛り込みたいかを顧客と明確にしていきます。

この要求をもとに、予算や人員、期間を計画していき、完成したシステムの使用目的やターゲットについて、顧客とシステム開発会社とが打ち合わせを何度も行う、最も重要な工程となります。システム開発の最終的な完成に相違がないように打ち合わせでは、しっかりと認識をすり合わせておきます。
※成果物：要件定義書

②仕様決定

要件定義の内容をもとに、全体で必要な機能やユーザーインターフェースの仕様を決定します。ユーザーインターフェースとは、簡単にいうと、画面などの外見的な見た目のことです。ユーザーにとって使いやすいシステムを作るためにとても重要な工程になります。ユーザーの使い勝手においてダイレクトに影響しますので、システム開発会社との打ち合わせの際には、しっかり希望を伝えて、その内容を詰めていきます。
※成果物：仕様書

③設計（外部、内部）

仕様が決めれば次にプログラムの設計を行います。外部設計はユーザー側からの視点ですが、内部設計においてはプログラムの設計など、開発者側からの視点でシステムを設計します。
※成果物：設計書

④製造（プログラミング）

設計工程での設計書が完成したら、それに基づきプログラムの作成を行います。指定された「プログラム言語（Java,PHP,Python,C# など）」を用いてプログラミングしていきます。プログラマーとして腕の見せ所です。全体工程の一部であるこの製造工程を、小学校で「プログラミング教育」として実施するということです。
※成果物：プログラム

⑤検証

まずはプログラムを作成した本人が、その手掛けた範囲のテスト仕様書作成しテストを実施します。次に、他の人が作成した複数のプログラムを組み合わせた状態で、それらがうまく機能するかを検証します。例えば、データの受け渡しなどの際にプログラム同士が正常に連携するかをテストします。

最後に、それらすべてを含めたシステム（総合）テストをおこないます。その名の通り、すべてのプログラムが、本当に要件定義の通りに動くのかを確認する工程です。例えば、多くのアクセスへの耐久性や処理速度などをテストします。
※成果物：テスト仕様書

なぜ必要なのか

① なぜ「仕様（要件）」があるのか？

自分のための、自分だけが使用するプログラムは、自分の仕事を効率化するために稀に作ることもありますが、世の中のプログラムは、社会全体のため、人々のため、特定の組織の人に向けて作られることがほとんどです。だからこそ、顧客という存在からの「要件」や「要望」が重要になり、「仕様」としてまとめておく必要があります。

「こういうものが欲しい」という要件があるから、それを満たし解決するプログラムを作成するという流れです。例えば、スーパーに買い物を頼まれて、“何を買うか聞かず”に、商品をどんどんカゴの中に入れていくでしょうか？逆に、必要のないものを作成しても意味はありません。

そして、作成したプログラムは、仕様（要件）をすべて満たしていることが必要です。そのためには、検証と修正を繰り返して完成させることになります。また、要件より良いものを提供したいと「提案」をすることもあります。

顧客の要件を満たすために、議論を重ねて要件をまとめ（仕様）、決定事項を整理し（設計）、実際に作ったものを（製造）、正しく動作させる（検証）。この一連の過程で必要とされる様々な「力」を、児童たちが将来どのような職業に就くとしても、身に付けることは極めて重要なことです。

② なぜ「検証（テスト）」が必要なのか？

プログラムを組んで作成したコンピュータシステムは、それを「作る側」と「使う側」が存在します。システムは「作る側」の自己満足で終わることはありません。常に「使う側」の人のことを考えながらプログラムを作成していきます。

せっかく作ったシステムがエラーばかり、要望と違う、使いづらいでは、誰も使ってくれません。例えば、「あなたはテストが終了５分前に終わっても、見直しをしないで終了時間をただ待ちますか？」そのために、「検証（テスト）」というのは非常に重要な工程です。しかし、今後はこのような重要な工程を飛ばして、プログラミングすることに特化した、「ただ作って終わる」ことが教育現場で行われるのではないかと懸念されます。

③ なぜ「動けばいい」だけではダメなのか？

プログラムを作成する際は、後の修正やメンテナンスを前提に、それを考慮の上、設計や製造方法を事前に検討します。また、プログラムコードは、どんなにぐちゃぐちゃでも、仕様通り動けばいいのでしょうか。自分だけが理解できればいいのでしょうか。

それは間違いです。他の人が後からそのプログラムコードを修正するようなメンテナンスも考慮するのが実際の現場では常識です。また、他の人が作ったプログラムコードをもとに、修正を施すことでも思考力は鍛えられますので、そのような演習を取り入れてもいいかと思います。

▼Amazonおすすめ本