2018年
平成30年 昭和93年
141日経過 残り224日
21
営業日
05月 月曜日
May 皐月 Mon 仏滅
May Monday
今月営業日
008 / 019 日
今月休業日
002 / 012 日
今年営業日
137 / 241 日
お知らせNo.339. SSLはじめました。 2017/12/18
お知らせNo.305. ユーザー様整理いたします 2017/09/28
お知らせNo.223. Firefoxのパスワード記憶について 2017/03/23
お知らせNo.218. プラグイン機能の説明を作成しました。 2017/03/22
お知らせNo.211. LINEを公開しました。 2017/03/17




USER:
PASS:
新規登録
  • BBSみしお より
  • BBSみしお より
  • BBSみしお より
1人の会員

8
Unique
Visitors
Powered By Google Analytics
インフォトップ公告表示プラグインの実演です。

仕様書、デバッグ、説明書

担当@みしお 開始日:2017年03月24日 更新日:2017年03月27日

自作テーマ作成後のチェックについて

今年からまったくの素人にプログラミングとサーバー管理などを教えていくのにあたってマニュアルや進行を考えるのにいくら作成経験があっても教えるのとは違っていてむつかしいなあというところで、フォーラムに寄せられている質問にすべて答えられるようになると、それらに生かせるのではないかととても積極的にはおもっているのですが、本当にためになります。

みんなで出来上がったものに手をいれていくというのは本当に助かるのですが、私もコードを直で書き込んだりしてしまっていますが、それは教えるということと育つということからは外れてしまうのではないかと、毎回思いながらも、育ってほしいのか解決して問題からは離脱してほしいのか、自分自身の問いにもなっている気がします。

今回回答した中からいえば、仕様を書き出すことがチェックを「やった気になる」から「実際にやりはした」という結果に変えることができる、その差は微妙かもしれないけど大きなものだと思うのですが、それを伝えるすべが足りなかったと痛感させられます。

まずスコープというところから、変数を大きく宣言したり小さな範囲で宣言したりするものがあり、それの寿命や影響範囲があって他人のモジュールを邪魔しないようにとか、自分のルーチンの中で上書きしたりしないようにとかまず書き出すことが必要ということと、書き出したものについて「これでOK」というハンコをひとつづつおしていくという作業がデバッグになり、仕様書の作成にもなっている、この範囲をモジュール、関係性、というところも書き出して、これはOK、ここは修正、とスタンプをおしていけば、チェックもれがあったかなかったかも自分でも確認できるし、記録にものこせるし、仕様をまとめることもできるということになるのではないかということ、これは言葉で伝えるのは困難でした。絵でかけば、実演すればはやかったのかもしれません。ということでそういう作業を見せて話す、という実習もちょうど昨日やってたけど、やっぱり人の顔色とか反応とかでは伝わったかどうか、実感するのはむつかしいですね。
実感というレスポンスを自分、そして他人に求めるのはちょっと無理がありハードルがたかく、ただの感覚の問題なので意味もないのですが、これは数をこなして自己判断の材料と基準をあつめていくしかないと思います。
やった気になる、がここでは大事だと思うのですが、ほんとに気になっただけならまったく意味がないと思います。何万回チェックしようと、目視で暗算で、実際にうごかしたから、うごいたから、ということでは1回チェックしたことにも満たないのです。だって、やりましたっていっても、いっただけ、やったつもりでしょ、に言い返す根拠が示せないのです。
でも、やったつもりでもザルでも「どの項目が、どうなっているか」を書き出してそこにハンコをおすと「やりました」という証拠にもなるし道標にもなるし方法をしめすこともできるし、もしそのチェックがザルだったら精度をあげて精度をたもつという項目にもハンコをおせばいいだけです。それでもだめなら、永遠に伸びていくだけのタスクですが、どこかでハンコを押すスペースがなくなるでしょう。

これを全部やると、ハンコを押してあるところを全部空欄にすると、工程チェック付きの計画書ができるんですよね。工程表とか、仕様書とか。
この作り方でできてるのが「テンプレート」なわけで、その仕様にのっとって記事データを読み出せば形どおりにおさまるという構造でCMSはできているわけです。

作ったつくりっぱ、というのであれば検索してでてきたコードをコピペしてあつめればいいだけで、それで動作するプログラムを作ることも可能です。
むしろサンプルをそのまま使用期限無限のものならつかいつづける、などでもいい場合があります。生産という目的がプログラムではなく内容の構造物であるならなおさらです。ブロガーなどはプログラミングをする必要はないですが記事を作成するのに高度なプログラムを望むこともあるかもしれません。

プログラムをつくるエンジニアとして、デバッグという局面はプログラム計画自体の総括にあたるようなものに携わるチャンスなので、ここをしっかりしてもらえる人がふえたらいいなと思ってその思いのたけをぶつけてみたのですが、熱ければ伝わるはずだと勝手に根性論にもちこんで書いてみたら、案の定、伝わらなかったようです。

仕様書づくり、マニュアルづくりが、初学者や若者に
「それ必要あるんですか?動くでしょ?使えるでしょ?だったらいらないのでは?二度手間では?」
という質問をされる場面というのは、教育担当にあたらればいずれ直面する問題だと思います。そしてそれに「ぐぬぬ」としか言えない諸先輩方にもお世話になってきた手前、そうなるものだとも想像に難くありません。

しかし、それ自体がプログラミングというものなんだよ、コードを書く作業をしてきたあなたたちは、これから「プログラムを組む」アッセンブルする作業にあたって計画書や仕様書というのは先にするものではなくて足跡から道筋をつくる解析作業、といっても理系にしか通じないので文系的には「明日の可能性を拡大させるためにつみかさねる選択肢の要素」と説明する方法をさがしています。今回は足りませんでしたが。
コードを書くという土木作業をして、コンパイルという足場撤去作業をして、電気ガス水道下水公的認可といったアッセンブルという外部環境との関連を作り、立ち上がった建物のクオリティチェック、デバッグ作業をしながら、チェック項目を書き出した紙の内部基準を外したものをまとめて「説明書」をつくってお客さんにとどける、そういう作業の流れを、今期の教育対象者に伝えることができるようがんばりたいと思います。

サンプルとか事例をあわせて、図でしめせばすぐに終わる作業だと思うんですけどね。
それを積み重ねて貯めていなかった自分にすごく反省と、私にはできなかったからあなたたちがんばってという言い訳にもチェックリストをつくらないと「やった気になってまた研修日、アドリブですます」みたいなことになりそうだけれども。


このページはログインするとコメントを記入できます。
先頭に戻る