プログラムの基本は入力と出力
プログラムの基本は入力と出力
2021年12月23日
プログラムの基本は入力と出力
プログラムミングの基本は入力と出力を意識することにあります。この記事では、入力と出力のコンセプトについて紹介します。
関数や Method の基本
プログラミングでよく利用する関数や Method の基本は、入力と出力を意識する事にあります。 実際には、プログラム自体が何らかの入力（インプット）を受け取って、それを処理して何らかの出力（アウトプット）をするのが基本です。
その途中の過程で呼び出される関数や Method も、何らかのデータを受け取って、何らかの処理結果を得るという処理の繰り返しで成り立っているのが基本です。
つまり、プログラミングを設計する場合、何が入力で何が出力かを決める事の繰り返しになります。
プログラミングでよく利用する関数や Method の基本は、入力と出力を意識する事にあります。 実際には、プログラム自体が何らかの入力（インプット）を受け取って、それを処理して何らかの出力（アウトプット）をするのが基本です。
その途中の過程で呼び出される関数や Method も、何らかのデータを受け取って、何らかの処理結果を得るという処理の繰り返しで成り立っているのが基本です。
つまり、プログラミングを設計する場合、何が入力で何が出力かを決める事の繰り返しになります。
入力や出力がない場合もあるのか？
ところで、多くのプログラミング言語では、値を返さない関数や Method が存在します。Void 型と呼ばれるケースです。このタイプの関数や Method は値を呼び出しもとに返しません。値を返さないので、出力がないように見えますが、殆どの場合何もしないわけではありません。
一連の処理をして、ある部分のデータを更新したり、出力を画面上にアウトプットしたり、ネットワーク経由でデータを送ったりなど何らかのアウトプットがある場合が殆どです。
入力にしても同じような事が言えます。特に関数に値を渡さない場合でも、何らかの形でデータを処理するケースが殆どです。それが、ネットワークなどからデータを受け取る場合もあれば、利用者がデータを入力する場合もありますし、外部で定義されている変数の場合もあります。
関数や Method の引数や返り値だけで考えると、入力や出力がない様に見える場合もありますが、プログラミングでは、通常は何らかの形でデータを取得して、それを処理して何らかの変化が起きます。その変化が出力でありアウトプットという事になります。
ところで、多くのプログラミング言語では、値を返さない関数や Method が存在します。Void 型と呼ばれるケースです。このタイプの関数や Method は値を呼び出しもとに返しません。値を返さないので、出力がないように見えますが、殆どの場合何もしないわけではありません。
一連の処理をして、ある部分のデータを更新したり、出力を画面上にアウトプットしたり、ネットワーク経由でデータを送ったりなど何らかのアウトプットがある場合が殆どです。
入力にしても同じような事が言えます。特に関数に値を渡さない場合でも、何らかの形でデータを処理するケースが殆どです。それが、ネットワークなどからデータを受け取る場合もあれば、利用者がデータを入力する場合もありますし、外部で定義されている変数の場合もあります。
関数や Method の引数や返り値だけで考えると、入力や出力がない様に見える場合もありますが、プログラミングでは、通常は何らかの形でデータを取得して、それを処理して何らかの変化が起きます。その変化が出力でありアウトプットという事になります。
プログラミング以外でも役に立つコンセプト
この入力（インプット）と出力（アウトプット）という概念は、プログラム以外でもとても大切な考え方です。例えば仕事のやり方にも適用できます。特に設計や製造の仕事の場合はこの考え方が基本です。よく耳にするのが ISO9000 と呼ばれる品質管理の認証がありますが、そのコンセプトはこの考え方に他なりません。
仕事には何らかのインプットがあって、それをどうにかして結果を出す。その結果が別の仕事のインプットになってという様な形で色々な仕事や作業が決められているかを検証しています。そうして、その仕事や作業のやり方がきちんとドキュメント（文書化）されているかなどをチェックしています。
それに対応しない仕事でも、仕事には大抵はその仕事を依頼する人がいて、何らかの結果を期待されるわけです。その結果を導くのに必要なのがその仕事のやり方などを書いたドキュメントという事になります。プログラムの場合は、ドキュメントの代わりにコード（プログラム）があるイメージです。
この入力（インプット）と出力（アウトプット）という概念は、プログラム以外でもとても大切な考え方です。例えば仕事のやり方にも適用できます。特に設計や製造の仕事の場合はこの考え方が基本です。よく耳にするのが ISO9000 と呼ばれる品質管理の認証がありますが、そのコンセプトはこの考え方に他なりません。
仕事には何らかのインプットがあって、それをどうにかして結果を出す。その結果が別の仕事のインプットになってという様な形で色々な仕事や作業が決められているかを検証しています。そうして、その仕事や作業のやり方がきちんとドキュメント（文書化）されているかなどをチェックしています。
それに対応しない仕事でも、仕事には大抵はその仕事を依頼する人がいて、何らかの結果を期待されるわけです。その結果を導くのに必要なのがその仕事のやり方などを書いたドキュメントという事になります。プログラムの場合は、ドキュメントの代わりにコード（プログラム）があるイメージです。
なぜ入力と出力が重要か？
プログラミング以外でもこのコンセプトが利用されるには理由があります。 プログラミングでもこのコンセプトを使うと良い事があるので利用しています。
それは「境界」がはっきりするからです。
境界というとわかりにくいかもしれませんが、仕事でいうと責任の範囲が明確になるという事です。 入力をもらってからが仕事の開始になるので、その仕事や作業をする人の責任になります。その前は、その入力を作る人がいて、そこまでがそこの部分の責任者になるわけです。その仕事の責任は決められた仕事や作業をやって出力を次の人に渡すまでがその担当者の責任という事になります。
責任の所在がはっきりしているので、問題が起きた場合にどこに問題があって、誰の責任かが明確になるのでスムーズに対処できます。
プログラミングでも同じで、どのモジュールが何をやるかが明確になって、問題の箇所を特定しやすくなります。また入力と期待される出力がわかるので、テストのプランやテストを実行する場合にもわかりやすくなります。
つまり、より見通しやすく品質の高いプログラムを開発しやすい状況を作り出すことが可能になるからです。
プログラミング以外でもこのコンセプトが利用されるには理由があります。 プログラミングでもこのコンセプトを使うと良い事があるので利用しています。
それは「境界」がはっきりするからです。
境界というとわかりにくいかもしれませんが、仕事でいうと責任の範囲が明確になるという事です。 入力をもらってからが仕事の開始になるので、その仕事や作業をする人の責任になります。その前は、その入力を作る人がいて、そこまでがそこの部分の責任者になるわけです。その仕事の責任は決められた仕事や作業をやって出力を次の人に渡すまでがその担当者の責任という事になります。
責任の所在がはっきりしているので、問題が起きた場合にどこに問題があって、誰の責任かが明確になるのでスムーズに対処できます。
プログラミングでも同じで、どのモジュールが何をやるかが明確になって、問題の箇所を特定しやすくなります。また入力と期待される出力がわかるので、テストのプランやテストを実行する場合にもわかりやすくなります。
つまり、より見通しやすく品質の高いプログラムを開発しやすい状況を作り出すことが可能になるからです。
まとめ
入力と出力、そして入力の処理方法を明確に決める。とても基本的でシンプルな事ですが、これがきちんとできるとプログラムの開発効率や、品質が格段に向上します。
これがハッキリ決められていると、その中のモジュールを作るのもやる事が明確になるので仕事を割り振りやすくなるなど色々な部分でメリットがあるからです。
他にも、このような仕事の割り振りかたをすると、ソフトウエア開発に限らず、与えられた仕事の内容も明確で、仕事（作業）のゴールも明確になります。そして、ゴールが達成できたかどうかを基準に評価を決めると、比較的公平な評価がやりやすくなります。もちろん、仕事や作業の難易度もありますし、仕事の品質（クオリティ）などの要素もありますが、その辺りを考慮しても曖昧な評価基準で評価するよりは明確な基準ができるので評価される側と評価する側の合意も得やすいメリットがあります。
ソフトウエアのコンセプトを通して、仕事でも同じ様な意識を向けられる様になると仕事のやり方も変わってきます！
入力と出力、そして入力の処理方法を明確に決める。とても基本的でシンプルな事ですが、これがきちんとできるとプログラムの開発効率や、品質が格段に向上します。
これがハッキリ決められていると、その中のモジュールを作るのもやる事が明確になるので仕事を割り振りやすくなるなど色々な部分でメリットがあるからです。
他にも、このような仕事の割り振りかたをすると、ソフトウエア開発に限らず、与えられた仕事の内容も明確で、仕事（作業）のゴールも明確になります。そして、ゴールが達成できたかどうかを基準に評価を決めると、比較的公平な評価がやりやすくなります。もちろん、仕事や作業の難易度もありますし、仕事の品質（クオリティ）などの要素もありますが、その辺りを考慮しても曖昧な評価基準で評価するよりは明確な基準ができるので評価される側と評価する側の合意も得やすいメリットがあります。
ソフトウエアのコンセプトを通して、仕事でも同じ様な意識を向けられる様になると仕事のやり方も変わってきます！
コメント
コメントを投稿