新人教育で何をやるべきか ＆ ＩＤＥ ＶＳ コマンドライン

　まず、唐突ですが、新人教育で、なにをやるか？という話について考える。

　このとき、新人教育で、終わった後に、どうなるか？というのを考えるといいとおもいます。
　たぶん、どこかの部署に配属されるでしょう。
　開発なら、どこかのプロジェクトに配属されるでしょう。

　で、配属されたところの開発環境をみて、「まったくわからない！どうやるんっすかあ？」って新人が言った場合、周りの人は、どう思うでしょうか？
　ＯＪＴで勉強せよ
　新人だからしょうがない
というふうに思ってくれるといいんですけど、たいていは、
　新人教育で、なにやってきたの？
っていうことになる。

　なんで、新人教育では、配属されそうな部署で、やりそうなことは、できれば、一通り見せておくのがいいって言うことになりますよね。まあ、新人なんで、できないのは、しょうがないですけど（できるようになるかどうかは、その新人の自助努力）。

　さらに、教育において、話が飛んだり、似たようなことで違うことがあると、理解しにくいっていう特徴がある。

　そういうことから考えると、できるだけ、一通りの流れだけをはじめから最後まで通してみせて、もし、追加して教えることがあれば、その通して見せた後、時間と能力に余裕があれば、やったほうがいいということになりますよね。

　はい、ここまでが、前置きです。

---

　で、今日の本題。

　なんか、プログラムの勉強は、ＩＤＥでやったほうがいいか、コマンドラインでやったほうがいいかなんていう議論がアツいみたい？

http://d.hatena.ne.jp/m_pixy/20050607#1118118345
http://blog.netbeans.jp/roller/page/kishida/20050528#12503_12525_12464_12521_125124
http://d.hatena.ne.jp/muimy/20050528#p1

　これって、素直に考えると、「会社でプログラムを教える場合であれば」、上記の新人教育の理由により、配属される（将来的に配属される可能性が大きい）ところの開発環境は、やっておくべきだと思います。理解できるかどうかの有無にかかわらず。

　ということで、コマンドラインで開発しかしないのであれば（Ｃの組み込みなどで、muleとgccだけでやってるとか）それでＯＫだけど、ＩＤＥで開発するなら、ＩＤＥもやらなきゃいけない。

---

　で、なにをはじめにやるかだけど、新人教育の場合、コマンドラインからＩＤＥに変えるなど、いろいろ環境が変わると、逆にわかりにくくなるので（関連が見えないから）、はじめやった環境で、一通り流しで教えるのがいいと思う（たぶん、ふつう、そうやってるよね）。

　応用力などの話は、ある程度量をこなしてから考える話だとおもう。まずは、覚えるので現実問題精一杯で、仕事になるのは、ぎりぎりいっぱいのラインだと思う。

　ただ、ＩＤＥのひとは、ひととおりＩＤＥでやったら、絶対コマンドラインも教えておくべきだと思う。最終ユーザーの稼動環境もＩＤＥなら別にいいんだけど、ユーザーはコマンドラインで行う場合、テストは、コマンドライン。。となると、困る問題がある。それは、また別の機会に書きます。ながくなるので。。。

---

　まずいのは、教育的にどうのこうのという考えで、現場と違うものをやってしまった場合。

　ＯＪＴでどうにかなるだろと思っても、まったく新しいものをＯＪＴっていうのは、その新人にも大変だし、派遣なんかだと、派遣先の上の人も「まったく知らない、やったことない人送って、なんなんだ！」って言われかねない（一度でも、見ている経験があれば、「あ、馬鹿なんだな、馬鹿はしかたない」って言うことになる可能性はあるが）。

　で、そーいうので、（派遣元である、会社の）上司に、派遣先の上の人からクレームが来ると、一度は、教育的のどうのこうのというので、納得していても、「おいおいおい、どーなってるんだあ」と文句がくる（上司なんて、その場で態度が変わるもの）

　なんで、なにをやるかというのも、会社の戦略とか、将来なにに力を入れているかの空気を読んで（前のブログだね）それにあわせたものを直接やるのがいいと思う。
　で、出来ない部分は、新人君に自助努力してもらうということで、いいような気がする。

---

　これは、あくまでも、会社員の場合で、自分の趣味や大学で覚える場合、何が言いかというのは別問題です。はい。

一体、どういうコメントを書いて欲しいのか！そもそも、コメントはなぜ書くの？について教わったこと

　みかままさん経由で知ったネタ

技術者の評価を下げる「悪い」コメントに注意しよう

　で、じゃあ、どういうコメントがいいわけ？

　つーか、コメントは、何で書くのかどか、どういう決まりがあるか？っていうのが説明していない気が（＾＾；）

　たしか、コメントは、読みやすさのためだけではなく、裁判など、トラぶったときの、最後の砦となる！だから、入れる。。。と、若い頃、教わった気が。。

　ということで、今日のねたは、ウィリアムのいたずらが、コメントの教わったことについて。

　なおExcelのドキュメント（仕様書）の場合について書くので、Excelのドキュメントにまったく興味の無い人は、いちばん下に、そういう人むけにまとめてあるので、そこだけみてください。

---

　Excelのドキュメントを書く理由は、契約書から、プログラムまで、このように考えられるから、このように展開したという流れ、一貫性を明確にするためだよね。

　そして、契約書の発注仕様書、あるいは、プロジェクト憲章となるドキュメント自身か、添付資料には、ＤＯＡのコンテキストダイヤグラムに相当することがかかれていて
（つまり、そのシステムの最終的な目的出力と、それに対する入力）、Excelドキュメントは、その入出力の定義（ファイル設計書、テーブル設計書、帳票仕様、画面仕様）とその入出力を、どう処理するかについて、展開していくことになる。

　そして、最終的な展開の細かい内容がExcelのフリーフォーマット部分にかかれる（＝クラスのメソッドの中身になる。ＤＯＡでは、ミニスペックに相当する。したがって、ＥｘｃｅｌフォーマットをＤＯＡで考えた場合、コンテキストダイヤグラムからミニスペックまでの展開は、まさにＤＦＤの流れだから、考え方としては、わかりやすい）

　で、フリーフォーマット部分は、たいてい、ちゃんとしたＳＥさんがつくれば、ビジネスパターン（デザインパターンとは違う、もっと、大きなきまったやりかたのくくり）ごとに分解して書いてくれる。

---

たとえば、フリーフォーマット部分は、こんな感じ。

（今日決まったスケジュールを、スケジュールマスタに追加するプログラムのフリーフォーマット）

１．引数データチェック
１－１．スケジュールマスタのハッシュマップチェック
　　　　NULLのとき、NULLでリターン
１－２．今日決まったスケジュールのハッシュマップチェック
　　　　NULLのとき、マスタのハッシュマップをコピーしたものをリターン

２．今日決まったスケジュールをマスタにマージ
２－１．マスタのハッシュマップをリターン用にコピー
２－２．マージ処理
　　　　（＝これは、ビジネスパターンなので、プログラマもわかってることとみなし記述しない
　　　　　　ちなみに、以下の処理をする
　　　　　　・今日決まったスケジュールのキー配列を取得
　　　　　　・その配列の最後まで、以下の処理をする
　　　　　　　　　マスタ（ここでは、コピーしたマスタ）にプットする）
　　　　　　　　
３．マスタのコピーを帰す

---

　ここで、１－１、２－１などは、実際のプログラムが書かれる。
　しかし「１．引数データチェック」のような処理の見出し、キャッチコピーのようなものや、「２．マージ」のようなビジネスパターン（お決まりの処理の見出し）は、プログラムに現れない。

　そこで、フリーフォーマットの見出し部分、
１．引数データチェック
２．今日決まったスケジュールをマスタにマージ
３．マスタのコピーを帰す

をプログラムのコメントにいれる。
そうすると、フリーフォーマット部分の記述と，プログラムとの対応が取れる。

---

　このExcelドキュメントのフリーフォーマット部分は、定型部分を根拠に展開している。
　また、以前書いたように、フリーフォーマット部分とテスト項目がつながっている。

　したがって、この方法だと、

　　　契約書　　　　　　（ＤＯＡのコンテキストダイヤグラム相当の内容）
　　　→Excelドキュメントの定型部分（ＤＯＡのＤＦＤ，ＥＲ相当の内容）
　　　→Excelドキュメントのフリーフォーマット（ＤＯＡのミニスペック相当）
　　　→プログラム（ミニスペックとの対応をコメントで示す）

　ということで、契約書からプログラムの対応関係が追えるようになります。
　そして、テストに関しても、フリーフォーマット部分から追えるようになっているようにして、プログラム間との品質管理ができるようになります。

　裁判ざたになったとき、契約内容が、正しく展開されているかどうかを追いかけるとき、この仕様書からプログラムまで追いかけられるということが重要になります（追いかけられれば、あとはその内容の正当性さえ示せばよいから）

　なので、フリーフォーマット部分の見出しとプログラムの関係がわかるようなコメントを入れないと、仕様書とプログラムの対応が切れてしまうから、仕様書を作る意味がまったくなくなるだろう！

　と若い頃、怒られた。

---

つまりExcelドキュメント関係なしに、一般的にいうと

　・コメントには、なぜ、その処理をしようとしているかの目的、意図あるいは
　・処理のキャッチコピー

を書くというふうに教わった。

サラリーマンって、実際、「責任」はあるけど、「権限」は無いよねえ、だから「空気読む」のが大事！

　あるブログをみていて、思った。自分の判断で決められることを権限と呼ぶとしたら、サラリーマンに権限は無いよねえ。
　もちろん、担当範囲はあって、その範囲で、一応決めていくけど、結局、上司が、その決めたことをひっくり返したり、いろいろと干渉してきたりすることが出来るわけで。。。そう考えると、サラリーマンの場合、上司の顔色をうかがわないで、自分の判断で決められる権限っていうのは、まずない。

　よく、サラリーマンの世界で、「ほう・れん・そう」っていわれるけど、あれも、報告・連絡・相談を、部下にしろという意味ではなく、上司にしろ！ということでしょう。

　つまり、「ほう・れん・そう」を、キレイ事じゃなく言えば、

　　　　「おれに、話を通さないで勝手にやるんじゃない」

　っていうことだよね。

　つまり、「ほう・れん・そう」しろ
　　　　＝上司に話を通してご機嫌を伺え
　　　　＝おまえが勝手に決める権利はねえ！
　ということよ。本当のところ。


　一方、責任っていうのが、解雇、減給（ボーナス減）ということであれば、責任はとらされるよね。たとえ、上司が賛成したとしても、いざとなったら上司は逃げるから。。。

---

　そういうふうに判断しないと、いまの談合事件とか、つじつま合わないよね。

　サラリーマンの多くは、自分が談合したいと思って、談合してないんじゃないのかなあ。

　だけど、しないと仕方ないので、している。
　でも、した結果、まずいこと（警察につかまりそうになる）と、担当者が責任を取らされるという構図だと思う。

---

　
　だから、サラリーマンで、生きていくとしたら、結局、上司のいいそうなことを予測して、どんなことをいいそうか、想定して、その範囲で決めていけ（仕事をやれ）ということになるよね。
　つまり、ネット的にいえば、「空気よめー」っていうことになると思う。

　で、これを、会社のお偉いさんや、大学の先生の好みのように変えると、「会社理念や経営戦略を理解し（＝上司のいいそうなことを予測＝空気読む）、それに基づき、柔軟に行動する（＝その範囲で、仕事しろ）」っていうことになるよね。
　おお、経営学も、「空気よめー」を推奨してるのね。。なんていうと、大学の先生は、怒るんだろうな、きっと。


　それがいやなら、フリーになる（もちろん、フリーになれば、自由になるかわりに、失うものも大きすぎる。フリーって、一歩間違えば、ぷう太郎だから）か、空気を読みきり、権謀術数を使って、上にたつかだと思う。

---

　
　ちなみに、冒頭に書いた「あるブログ」っていうのは、ここ。
　で、こんな話を書いたのは、この話以外に書きたい話題が合って、その話題を書く前提として、この話が書きたかった。

　ちなみに、その書きたい話題というのは、新人教育。今度、書きます（次に書くかどうかは不明だけど）