安っぽい宝の地図

ソフト屋の仕事シリーズ。
その１
その２

ソフト屋のお仕事として、作るものが決まったら次は設計を始めます。
何をするかっていうと、そのものズバリ『設計図』を作ります。

プログラミングって結構自由なんです。シンプルなモノを作ったとしても10人が作ると10通りのプログラムが出てくるぐらい、同じゴールに辿り着くための道筋が多い。
例えてみるとレゴブロックみたいなものだろうか。「船作れ」って言われて、大きめのレゴにちっさい突起をプチっとくっつけて「出来た！」っていう人もいれば、物凄い精密で巨大な物を作り上げる人もいる。そんな雰囲気です。
この“適当に作っていってもいつか完成する”っていう自由さは凄く魅力的なんだけど、あまり無計画につくりはじめると大変なことになります。
船の前側を作って、飽きたから後ろ側を作って、くっつけようとしたらサイズが合わないから前側を作り直すとか。これが大人数で作るものだったりしたら、個人個人が自由にやってると永遠に終わらなくなってしまう。

というわけで設計図いらなそうなプログラミングでも一応設計図を書いてからやれ、と言われてます。

しかし、ある程度の図を書いても、プラモの設計図みたいに完全に組み立て方を説明するようなものは書けません。せいぜい「あー、こんなイメージね」というレベルの強制力しかないような図しか作れない。
強制力を持たせるために細かく書き込んでいくと、もうそこまで考えるならプログラム書いたほうが早いってなるし。

だから設計図書けといわれるけど正直めんどい。いつもテキトーです。どれぐらい適当かというと……

「今度のアレ、どういう感じに作ります？」
「うーん、Aパーツはセンサーとマニピュレータ、Bパーツは足の動きね。そんで通信のフォーマット共通にしといて、コアファイターにデータ送るようにしとけばいいよ。あとはコアファイターで入力したデータをおんなじフォーマットで送り返せば多分動くからさ」
「あー、それいいっすね。変な拡張パーツ付けろって言われた時も対応楽そうだし」

多分、どこもこんな感じだと思うんだけど……みんなもっとマジメに設計してるんかなあ。
今考えてみると、図工の授業なんかで粘土細工を作るときなんかも、一度落書きでもいいから完成イメージを書いてから作ろうっていう感じに教えてくれたらよかったのに。