よくこんな話を聞く。
プログラマと話す時、細かいところまで確認されて話にくいと。
伝える側はおそらくは電話でさくっと伝えて終わらせたいのだろうけれども、段階を踏まれて事細かく且つ理屈っぽく話をされるからだろう。
更には電話による口頭のやりとりを拒否されて、メールでやりとりをしてほしいと言われることもあるだろう。
上記の問題に対して、私なりの経験をまとめておくことにしよう。
それが前から記載している妻へプログラミングを教えている理由に繋がってくるから。
ブログやネットショップといったコンテンツマネージメントシステムを設計から開発まで関わった身として、
システムの不具合というもののほぼすべては自身でイメージできなかった
いってみれば想定外の動作が大半で、
一般的にイメージされる不具合(バグ)というものはほとんどありませんでした。
ユーザからの不具合報告の大概は、開発側が想定できなかったケース、もしくは複雑化した時に想定していない箇所に影響を与えていたというもので、何度も繰り返すが、想定できなかったということに尽きる。
典型的な不具合というものは開発中に発見してその時に解決している。
プログラミングというのは他のものづくりと異なり、自然や物理法則といった人為的でないものをほぼ受けない、ほぼ100%自分の頭で考えたことが動いてしまうという特徴がある故、想定できなかったというものが顕著に不具合として目立ってしまうという特徴もある。
想定できないということは、突然電話で「あんたが作ったシステムでデータを登録しようとしても登録できないんだけど直して」という連絡があったとしても、想定した範囲では動いているので、
・今回の不具合はユーザ側がこちらの想定していない使い方をした。
・もしくはサーバの設定に想定していないものがあるから動かない。
のどちらかになる。
想定できない以上、電話にて不具合の報告をされても何が原因か？想像することなどできない。
というわけで、どの画面でどのような操作をしたらどのような結果が返ってきたか？というものを事細かく確認するということを行う。
どの画面でというのは最低でもURLはほしいし、操作に関してもどのボタンとなるとキャプチャがほしい。
結果は投稿できなかったから良いとしても、上記の内容を電話で伝えるのは非常に難しい。
エラーメッセージが表示されていれば、それを伝えてくれれば良いけれども、エラーメッセージ程電話で伝えることが難しい。
それ故、不具合の報告は電話等の口頭ではなく、メールで行ってほしいという流れとなる。
となるとプログラマ同士は逐一メールで電話で行うようなやりとりを行っているのか？ということになるけれども、プログラマは他のクリエイティブ職と同様、まとまった時間を設けなければ死活問題となる職種であるが故、メールであっても頻繁にやりとりが発生すると困る。
というわけで、電話では伝えにくいような内容であっても簡略的に伝えるための手段を検討したり、そもそも問題が発生しないようにルールを設けて、他の人が仕事に参加した時でもある程度読めばわかるという環境づくりに注力を注ぐ。
上記で代表的なものといえば、各言語の規約、高機能エディタ、テスト自動化、タスク管理、オープンソースの思想(ノウハウ共有)だろう。
言語の規約の中で秀逸だと感じるのが、null値と空文字だろう。
null値というのは「値がない」ということを表し、空文字というのは「0文字の文字列」ということを意味している。
どちらも値がなければ明示する必要はないじゃないか！
ということになるけれども、何も存在していないことと、初期段階で値がないということを明示しておくことは大きく異なる。
後に何らかのことをやりたいんだなという意思を伝えるための良い手段となる。
高機能エディタは、
ある程度コードを書くとコードを自動で修正してくれたり、プログラムを実行する前に記述ミスを伝えてくれたりする。
これらに支援によって、考えるべきところと考えなくても良いところを機械の方が教えてくれることになる。
テスト自動化はシステムが小さい時から、作った機能毎にこう動いてくれれば良いなといったコードを作成し、それを小さな変更が入る度にすべてのコードが想定通りに動いているか？ということを調べる手段で、ある程度の問題であればテスト自動化で発見できる。
タスク管理というものはどの業種でも行っていることだけれども、
Redmineというオープンソースのプロジェクト管理の思想が秀逸で、チーム内で誰にどんな仕事が割り振られているか？が確認できることはもちろん、進捗状況に加えてメモ書きすることもでき、問題の再発防止策としての検索機能を兼ね備えている。
各々の課題で悩んでいる箇所をメモして共有して、解決できそうな人がコメントを残しておくことで一種のノウハウ集が出来上がる。
何か問題が発生した時は一旦Redmineを確認してから、なければ詳しい人に聞いてみるというフローを一つ追加しただけで、誰かの時間を費やしてしまう確認業務が大幅に削減される。
この発想の延長上にあるのが、オープンソースソフトウェア(以後、OSSと略す)の思想だろう。
By http://www.opensource.org/ - http://www.opensource.org/logo-usage-guidelines#The_Standard_Logo ru.wikipedia からコモンズに Rubin16 が CommonsHelper を用いて移動されました。, CC 表示-継承 2.5, Link
OSSとは用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称。
OSSの思想として、ソフトウェアは自由に使用できるべきで、そのソフトウェアから価値を生み出せというものがある。
ソフトウェアを有償にすると、優秀な頭脳を持っていても資金面で使用できない人の資産を社会が活用できないという損失が発生する。
その損失から社会を真に良くする画期的なプロダクトが生まれなくなる。
だから最も大事なところはみんなが使用できて、使用者が改変できる権利が必要だと。
その思想の流れからか、Web上ではソフトウェアに限らず、開発上で苦戦した問題の解決策が溢れ、競合であっても同じ問題を共有して業界全体が成長するという他業界ではそうそう起こり得ない現象をよく見る。
プログラミング情報のナレッジコミュニティであるQiitaとかが良い例だろう。
話は長くなったけれども、
・プログラミングでは情報を的確に伝えて、誰もが確認のための時間を多く費やさないために考えられたこと
・物事の考えるべきところと考えない方が良いところの線引き
・一度発生した問題は他の人でも参照しやすい、もしくは調べなくても良い仕組みを作ること
・世界中にある資産を上手に活用すること
上記の4項目をプログラミングを経て体験してほしいと考えている。
コンピュータはほぼ100%人の頭で考えられて作られた仕組みなので、人々が何を考えて今があるのか？コンピュータに触れるのが一番手っ取り早いはず。
これだと教科書的で受け手は面白くないので、この後にインターネットで自分で考えた何らかの仕組みや自身の生活で少しでも労力が改善されるものが作れたら良いなと。
関連記事
チャットワークとGoogle Apps Scriptで音声入力で投稿してみる
