こんにちは、あのぶるです。

一応シリーズ最終回の今回は、コンピュータになるべく楽に、間違いなく指示をするためにどうしたらいいか、という話をしたいと思います。
前回までの記事はこちらからどうぞ。

hajimete-it.com
プログラミングとは何か〜その1: コンピュータが出来ること
こんにちは、あのぶるです。「プログラミングって何？」と質問をされたとき、あなたはどのように答えますか？RFC等で明確に定義があるわけではないようですが、現在では概ね「(プログラミング言語を使って)コンピュータへの命令を作成すること」という説明がされているようです。私はよく、もう少しだけ噛み砕いて「コンピュータへの作業指示を作ること」と説明しています。コンピュータへの作業指示とは？という話をする前に、まずは「そもそもコンピュータは何をしているのか」という話をさせてください。今あなたがこの記事を読んで...

hajimete-it.com
プログラミングとは何か〜その2: コンピュータに指示を与えるということ
シリーズものの記事ではあるのですが、「前の記事を読んでいないと全くわからない」ということはおそらくないと思います。が、もしよろしければ前回の記事もご覧いただけると嬉しいです。こんにちは、あのぶるです。前回の宣言どおり、今回は「コンピュータに指示を与える」とは一体どういうことなのか？というお話をしたいと思います。例題として、「猫の絵を描く」というタスクを実現するときのことを考えてみましょう。人にお願いする場合と、コンピュータ(ロボット)にお願いする場合でどのように違いが出るかを見ていきたいと思い...

よく使う指示をまとめておく

まずは一番シンプルに、「よく使う指示をまとめておいて、簡単に呼び出せるようにする」という方法があります。

例えば「円を描く」という動作を何度も繰り返したい場合を考えてみましょう。
現在主流として使われているほとんどのプログラミング言語では「メソッド」や「関数」などと呼ばれる機能が提供されています。
これは、一連の動作をどこかにまとめ名前をつけておくことで、他の場所からその名前を呼ぶだけで同じ(ような)動作を実行することができる、という仕組みのことです。
前回も出てきたお絵描きロボットに半径3cmの円、5cmの円、10cmの円の3種類を描かせたい場合、どんな風に関数を準備すればよいでしょうか？

drawCircleRadius3cm(centerX, centerY)
drawCircleRadius5cm(centerX, centerY)
drawCircleRadius10cm(centerX, centerY)

(centerXとcenterYは円を描く位置を指定するための中心の座標を表しています)

このように3種類の関数を用意しても良いですが、半径からロボットの動きを計算することができればさらにまとめることもできそうです。

drawCircle(radius, centerX, centerY)

こうすれば新しく半径7cmの円を描きたくなったときも簡単に対応できます。

このように指示を纏めるときには注意点があります。
それは、「引数」と呼ばれる、この関数で言うradius、centerX、centerYの値がどんな値になってもロボットが壊れないように準備をしておく必要があるということです。
「ロボットが壊れるかもしれない状態」というのは、たとえば

  • ロボットがそのまま解釈できないデータが送られてくる(数字が欲しいところに文章が送られる、など)
  • ロボットが物理的に動けないような値が送られてくる(半径が大きすぎてロボットの腕では足りない、など)

というようなものが挙げられます。

※加えて、「本来の目的とは違った動きと解釈できるデータを送られる」というケースもあります。これも安全なシステムを作る上では大事な視点なのですが、今回のテーマからは外れるので割愛します。

意図したものから外れたデータを受け取ってしまった場合、ロボットが壊れないようにするためにはどうしたら良いでしょうか？
原則として、関数が正しく対応できないデータについては「エラーとして扱う」という方法を取ります。

  • 文章が送られてきたら「その値は使えません」とエラーを出して何もさせない
  • ロボットの腕が届かない場所に円を描く指示をされた場合はやはりエラーを出す

というようにすれば良いのです。

使う道具を変える

さて、今まで使ってきたロボットの例で、「わざわざロボットに手で絵を描かせる必要はあるのか？」と思った方、正解です。
単純に「同じ絵が大量に欲しい」が目的であれば、今であれば間違いなくこの方が楽で正確に実現できますし、おそらくかかる費用も安く済むはずですよね。

特に仕事でプログラミングをするとき、役割によっては「解決すべき課題に対して求められた方法が本当に最善なのか」を疑うことも必要になります。例えば「社内会議室の予約システムを作ってほしい」と言われても、実は会社で使っているカレンダーアプリで十分用が足りた、というのは案外よくある話です。ある意味で「ミスが避けられないなら何もしなければいいじゃない」の極みとも言えます。
直接的な利益には繋がらないかもしれませんが、十分にスキルのあるよい開発者はむやみに新しいシステムを増やすことを勧めない傾向があると感じています。

番外: ユニットテストのすすめ

今まで紹介したものとは逆の発想というか何というか、人間のミスをコンピュータにフォローしてもらおう、という考え方から生まれた手段のひとつとして、ユニットテスト(テストコード)を書くというやり方があります。
正しく運用すればプログラムを変更するたびにコンピュータが勝手にテストしてくれ、手作業で同じテストを繰り返すのに比べて圧倒的なスピードで実行されるため、かなり気軽にかつ安心してプログラムを変更することができるようになります。何しろコンピュータは同じことを繰り返すのは得意ですから。
繰り返すようですが人はミスをする生き物なので「テストコードが間違っていたらどうするの？」という懸念が生まれるかもしれません。それに関しては個人の経験上、仕様自体を勘違いしていない限りテストとアプリケーションのコードが同時に同じように間違っているということは稀で、テストコードの間違いで不具合を見逃すリスクよりはテストコードが存在するメリットの方が圧倒的に上回るかな、という印象です。
今までの経験では特定の状況のテストを書き忘れて不具合を見逃した、は恥ずかしながらいくつかありましたが、テストだけが間違っていて不具合に気付かず、本番環境で実際に問題が起きた、というケースはなかったと思います。多分……
最近よく耳にする「ルンバに掃除してもらいやすいように気をつけていたら床に物を置かなくなり、結果部屋が綺麗になった」という話ではありませんが、テストコードを書きやすいプログラムは自ずとメンテナンスもしやすくなる傾向があるようです。

ある意味「怠惰であること」が美徳とも言われ、「未来の自分が楽をするために目の前の手間を厭わない」という姿勢が実際良い仕事に繋がるのがプログラミングの世界です。
筆者は新人の頃、当時の上司に「単純作業と8時間が与えられたら8時間黙々とその作業をするのではなく、7時間で単純作業を自動化するプログラムを書き、残りの1時間でそのプログラムを実行するのが技術者というものだ(要約)」と言われたことがあります。次に同じ作業が発生したら、今度は作ったプログラムを実行する1時間だけで済みますからね。
「楽をする」という言葉にネガティブな印象を受けるかもしれませんが、そうして出来た余裕はきっと自分自身やチームに良い効果をもたらすはずです。単純に休暇を取ってリフレッシュするもよし、気になっていた不便を改善するもよし、もっと楽に開発ができるような新しい技術にチャレンジするのも良いかもしれません。

正しく怠惰に、自分だけじゃなく周りの人も楽にするプログラマになりましょう！

The following two tabs change content below.
Twitter のプロフィール

あのぶる

Software Engineer
杜の都で育ち、赤べこの街でコンピュータのいろはを学んだソフトウェアエンジニア。今はスマホゲームのためのWebAPIを作るお仕事をしています。最近はすっかりガルパンおじさん化。