よくトライ＆エラーができるというけれど…
プログラミング教育の記事などを見ると、「トライ＆エラーをしながら」「間違ってもやり直せる」とかよく出てきます。
これが独り歩きしてしまってしまうと少し方向を間違えてしまうなと思う所があります。
（というか他のもそうだと思うんですけどね…）
確かにプログラミングは作っても間違いがあるのが前提です。
だからテストを丁寧にする訳で、きちんと確認をするための時間を取ります。
特にまだ他人に見せる前の段階ではトライ＆エラーは発生します。
実際の開発ではトライ＆エラーは特定の箇所でしかやりません。
その程度の状態で開発に移ることはないと思います。
当てずっぽうでは意味がない
「何も考えもなく、いきなりパソコンの前に座って適当に作り、それで動くか分からないコードを動かして、失敗したらやり直す」
というのは間違いです。
- やりたいことを決め
- 実現方法を考えて
- プログラミングする
という流れが重要です。
２番と３番を同時にやるイメージでいる方もいるかもしれませんが、それだと少なくとも学習にはならないでしょうね。
どんどん作業をしていくというと「アジャイル開発」という言葉があります。
機能単位の小さなサイクルで、計画から設計・開発・テストまでの工程を繰り返すことにより開発をするのがアジャイル開発です。
適当にガンガン作るのがアジャイル開発ではありません。
機能毎に
- 要件定義
- 設計
- プログラミング
- テスト
を繰り返しますので、当てずっぽうに作っている訳ではありません。
トライ＆エラーができる箇所
例えば以下のようなケースを考えます。
「新しいデータベースに接続を切り替え、新しいデータベースから会員の名前を取得する」
という事をしなければならないとします。
その場合、「新しいデータベースに接続を切り替え」の部分はトライ＆エラーが発生する場所で、「新しいデータベースから会員の名前を取得する」はトライ＆エラーはしません。
大体トライ＆エラーが発生するのは以下のようなケースです。
- 新しいライブラリ（部品）を導入した
- ライブラリ（部品）を新しいバージョンに変えた
- 開発が始まったばかり
開発初期は必要な部品が足りなかったり等発生するため、エラーが多くなりがちですが、時間と共に落ち着きます。
部品導入などの場合、プログラミング以前の問題で、「これを使って実現できるのか？」という観点でトライ＆エラーが多く発生します。
いくつかの部品を組み合わせたり、時には取り替えたりをしながらなので、どうしてもイメージ通りにいかない場合があります。
一方でプログラミングが始まってしまえば基本は一本道です。
むしろ一本道にしておかなければなりません。
プログラミングを書き出してから考えてしまっていると、学習という観点では身につかないと思っています。
まずは頭の中で設計し、もし間違えたらきちんと設計部分からエラーを修正し、プログラミングをする癖をつけておくことが論理的な思考に繋がります。
誤字脱字、ケアレスミスはトライ＆エラーの範疇ではないです。
『プログラミング＝手段』です
プログラミング教育等でIT業界が熱を帯びることは喜ばしい事です。
ただ、プログラミングは手段であることをきちんと理解してほしいです。
ハッキリ言って、設計がまともにできない人がプログラミングをすることは困難です。
作業の手順を頭の中で描けない人が、プログラミングをしてもただ手を動かすだけになってしまうでしょう。プログラミングは手段ですので、作業を頭で考えた結果、システム導入（プログラミング）以外の方法で対応するというのも実際の現場ではアリです。
いきなり作り出すのではなく、教科書に書いてある通りにするではなく、まずは自分で頭の中で作り方をイメージ（設計）し、できればそのイメージを紙に書いてから作り出すということを意識してほしいと思います。
