【プログラミング学習】プログラミング的思考について、開発現場の人間が考えてみた
平成29年3月に告示された新学習指導要領には、プログラミング教育が取り入れられるとあったので、今までのSEとしての経験を基に色々と考えてみました。
現場一筋10年で走ってきた人間ですので、表現がエンジニアに偏っているかもしれませんが、こんなことをやってるんだねーというくらいで読んでいただけたら幸いです。
小学生からプログラム！？
小学生段階の「プログラミング教育」はコーディングを覚えることが目的ではないとあります。
では、目的は一体何なのか？
小学生の段階では、文字入力など基本的な操作を習得、プログラミング的思考を育成と書いてありました。
将来、小学校の段階からプログラミングの練習をしてきたスーパープログラマーが入社してくるのかとビビっていたので少し安心しました。。。w
プログラミング的思考とは
一安心したところで、プログラミング的思考についてです。
新学習指導要領には次のように定義されていました。
自分が意図する一連の活動を実現するために、どのような動きの組合せが必要であり、一つ一つの動きに対応した記号を、どのように組み合わせたらいいのか、記号の組合せをどのように改善していけば、より意図した活動に近づくのか、といったことを論理的に考えていく力
「プログラミング的思考」を育成することで、やりたい事を実現する「願望実現能力」と、何か問題や障害が起こった時に解決して乗り越えていくための「問題解決能力」が身につくのかなと思います。
願望を実現する能力
「あれしたい！」「これやりたい！」と願望はたくさん出てきます。願望があって、実現したいと思うから仕事が生まれるわけですが、SEの開発現場ではお客様からの要望(願望)を基に何をすれば実現できるかを考えます。
まずは、要望(願望)について「どんなものを作るのか」を明確にします(エンジニアの工程では【要件定義】と言います)。
例えば、「カレーを作って欲しい」と要望があったとしましょう。
カレーといっても幅広いですね。一体どんなカレーでしょうか？
コクがあって牛肉がとろけるカレーとか、ひき肉を使ってピリ辛キーマカレーにしてほしい等カレーといってもオーダーは様々です。
要望(願望)を明確にしていくためにはヒアリング(つまり聞く！)が重要になります。
カレーを作ってほしい人(客)とカレーを作る人(エンジニア)同士で作るもののイメージ共有が重要となります。
カレーのお店ならそれを「メニュー」という形で提示していると思います。
要件定義が終わったら次は【基本設計】の工程に移ります。
基本設計では、作るのが終わるまでにどんな作業が必要となるかを検討します。
「カレーを作って欲しい」と要望を例に出すと、コクがあって牛肉がとろけるカレーが要件だったとしましょう。要件を満たすカレーを作るにはどんな作業を行なったら作れるかを検討します。
①材料を切る
②炒める
③煮込む
④ルーを入れる
⑤味見をする
①〜⑤の作業を行えば、要件を満たすカレーが出来上がるかと思います。
①〜⑤の作業の中にも細かく明確にしておくことが必要になることはあり、例えば「①材料を切る」では。切り方はどうするなど細かい決め事は決めておく必要があります。
なぜ必要なのかというと、プログラムには、一度実行してしまうと実行中の変更はできないという特性があるからです。
つまり材料を切り始めると、切り終わるまで変更がきかないということです。
実際は途中で変更が可能だと思いますので、意識するレベルでもよいかと思いますが、誰かに指示をする時などは気をつけた方がよいかもしれません。
問題を解決する能力
物事を進めていくと必ずと言ってよいほど、問題・課題にぶち当たります。
サラリーマンだと「通勤中に電車遅延の影響で出社時間に間に合わない」や、学生だと「文化祭の制作物の材料が足りない」などなど小さなことから割と大きなことまで様々です。
システム開発の現場でも頻繁に起こります。
「稼働中のシステムでエラーが起こった」「試験中にい不具合が発覚した」などなどしょっちゅうですw
色々と問題・課題はありますが、それを解決して前に進むしかないわけですが、どのように解決していくかが重要になります。
5W1Hで原因調査
問題が起きたらまずは原因を調査します。
原因調査で役に立つのが、英語の時間によく耳にしました「5W1H」です。
When(いつ)、Where(どこで)、Who(誰が)、What(何を、どんな)、Why(なぜ)、How(どのようにして)の頭文字をとっています。
必ず5W1Hじゃないといけない訳ではありません。例えば「試験中に不具合が発覚した」場合は、Where(どこのプログラムで)、How(どのように操作をしたら)、What(何が起きたのか)といったところから調査が始まります。
「稼働中のシステムでエラーが起こった」場合ならそこにWhen(いつ起きたのか)が入ってきて操作ログを確認したりします。
解決策を検討する
起きていることが問題・課題だ！と思うということは、逆にどのようになったら正解かもわかっていると言えます(哲学的ですねw)。
正解にするためにどこをどのように修正したら良いかを検討します。
「通勤中に電車遅延の影響で出社時間に間に合わない」場合だと、出社の時間に間に合えばOKなので、振替輸送を使うなど別の交通手段を利用して出社の時間に間に合わせます。
「文化祭の制作物の材料が足りない」場合だと、買い出しに行ったり、メンバーの中に材料を持っている人がいないか探してみたりして解決することがあります。
まとめ
SEになり、10年が経とうかしていますが、「仕事」についても目的は何なのか？そのためにどうしたらよいかとより考えるようになりました。
やや理屈っぽくなりがちですが、何かする時には順序立てて考えるようにするとうまくいくことが多いように思います。
現場寄りの表現でわかりにくい部分もあったかと思いますが、何か伝わるものがあればいいなと思います。