黄金の３日間とは

どうもJudaです。
2chまとめスレで「黄金の３日間」という単語が出て来た。マネージメントの基礎的な知識であるらしいがちょっと分かりにくいので調べてみた。
Googleの検索ででてくるのは、『黄金の三日間』であり、熊本の先生がまとめたサイトが見つかる。学校での学級運営のための教師へのマネジメントの心構えと実践方法が書かれている。
またAmazonで書籍を検索しても、学級運営のための書籍が出てくる。
文脈からすると「黄金の三日間」なるものは、学級運営のためのノウハウとして生まれ、それは始業式から始まる三日間においてルール作りを行うことが重要である。ということであろう。
これを実際のマネジメントまで一般化したものが、「黄金の三日間」を指すのだろう。
このことがおもしろいのは、学級運営という運営としての捉え方、またこの学級運営のノウハウが企業の小集団、プロジェクトに適応できるという洞察にある。
学級崩壊などが過去に世間をにぎわせたが、これは経営者である教師の失策ということになる。そして教師はただ学問を教えるだけの人材ではなく、同時に経営者としての手腕も問われる多義的な職業ということになる。このことは、注目に値すると思う。年の若い、担当クラスをもつ先生というのは、同世代のサラリーマンとは異なり管理者としてのスキルが問われる。この点は注目に値する。一般企業における管理者は、ある程度の年の者がやるのが、日本では一般的である。これは特定の業務に対しての理解無くしてマネジメントができないという発想に基づく話である。しかし昨今の高度に専門化していく業務においては、ここの管理者が配下の被管理者の業務について完全に理解することはまれであり、またそのために管理者は管理に特化すべきという認識が生まれている。
ここで話を教師に戻した場合、教師には割り振られている仕事は２種類あることになる。しかもそれぞれに専門的な知識が必要になる。このことを鑑みれば、教師という職業がいかに困難であるか分かる。一般企業でも４０人近い被管理者を完全に管理することのできる管理者がどれほどいるだろうか。またその管理者を育てられるだろうか。別の問題として、外部との交渉、つまりは保護者からのクレーム、学校組織内での管理者／被管理者関係など、多岐にわたる業務がある。このことだけでも教師という職業がいかに大変か分かる。
そして、「黄金の三日間」という現場での実践で確かに適応できる知識の創出やその知識の共有化を推進するあり方などは一般企業も取り入れることを検討してもいいと思う。この点を私はIT勉強会として行うと面白いと思う。それが含む企業的な問題については憂慮すべきものもある。

学校組織という特殊なマネジメント環境においてさまざまな管理方法が実験され、共有されていることはとても実験的に面白いと思う。被対象者においての、教育の一回性についてであるが、これは発展が線形で表現できないことからある程度は許容されるべきである。仮に線形である場合にも、人はさかのぼって評価を下しがちであるので、私はこの点からも許容すべきであると考える。それでも認められないのであれば、保護者が教育機関を選別することが必要である。公教育の現場に対してクレームを付けることは、その教育者の管理的なあり方からある程度までは認めるが、彼がプロであることを監視することにとどめるべきであると思う。未熟な管理者を教育するのは、学校組織の側であるので、外部からの強度の干渉は、教育の効率性追求を阻害すると考える。

公教育の現場において、一般企業からの参入を認めてもいるが、私は逆に教師を一般企業に管理者として導入する可能性も多いに期待したい。この人材の交流によって、より効率的な管理体制が探求されることを望む。

Happy Hacking Keyboard Lite 2 英字配列購入

どうもJudaです。
いい。やっぱりHHKのLite2はコンセプトが明確でとても素敵だ。
すっきりしたキー配置にはいつも感心する。
またLite2では、十字キーにHome,End,PageUp,PageDownのFnが設定してあることが憎い。
僕はとにかくこのHHKが好きなのだ。これ以上理屈をいくら並べても、それは好きであるということをとらえ損なう。閉じ込めようとしても完全に捕まえきれない。ただ多く語ることで、それが囲んでいる領域をぼんやりととらえるだけ。HHKが好き。これがもっともよく表している。
HHKは最高だぜー、わー。

コンテキスト

どうもJudaです。
今日は、「言語」という話を備忘録。
数学と音楽は、日常言語とは違う「言語」を持っていると思う。この場合の「言語」は一定の規約に準じる他者との相互理解のための意味コンテナ。数学の証明は、その作法を知らない者にとって、理解不能だ。音楽もたしなむ人にとっては、特定の旋律や進行がどういう意味合いを持つのかということを理解することもできるだろう。もっと一般化してしまえば、日常の会話でも使われている「言語」は特定の規約を知らなくては理解できないものになるだろう。
このときに、もっとも基礎となる「言語」というものは、もっともその「言語」を理解できる者が最大となるときの「言語」。使用効率がもっともよい者が基礎となるのだろう。これが標準となる。
標準をもとにいくつかの派生言語や、派生先での相互の翻訳がある。このときに、共通の根となるもっとも標準な「言語」を知れば、全てを知ることになると単純に考えることもできる。しかし派生が発生するという現象を鑑みれば、特定の事象を細分化し、他者と共有するために派生が行われていることが分かる。このときに、共通の根というのは非常に素朴なものだけを扱い、あまりにも漠然とし細分化されていないものとなる。この場合の派生関係は差異を進めることによって、もはや共通の根から派生したものとの関係性は薄くなる。これに対して、翻訳を行って、共通の変換規約を作り出しても、その変換は部分的にはうまくいくだろうが、一定以上の細分化が進んでいる場合には、翻訳不可能な局面が現れるはずである。それは、そもそもの派生が発生する契機に、コンセプトの相違に近いものである。
この変換によるロスは、「言語」固有の特質だ。またこのロスを語ることは、それが変換できないという変換可能であることを否定することによってしか、一方の「言語」では、表現できないのではない。
このときに、真に変換された無かった「言語」を理解するには、まったく別のものとして、新規に「言語」を習得する必要性がある。このことを自覚できずに、ロスの存在に気づくと、もどかしさを感じる。
この「言語」を意識、精神に置き換えたときにいかにしてこのロスを克服していくのだろうか。考えられる解は、共通の根まで戻り、再度双方の言語に双方の語を交換して登録を行うことだろう。ただ習得は非常に非連続的なものになる。ある意味ではコンセプトを破壊する。

仮に、これをクラスに置き換えた場合には、特にC++において、継承関係が完成されてるものに対して、新規に継承関係を動的にあるいはソースコードに直接記述することなしに追加していくことはできない。この流れでみたときに、Objective-Cの考え方はとても拡張性に富んでいて、洗練されたObjectOrientiedな言語設計である。もっともC++はオブジェクト指向でのプログラミングを許容する設計であり、複数のコンセプトが混在してる。だからオブジェクト指向への適応度の違いは、なぜC++とObjective-Cが存在しているのかということを再認識させる。このような違いに無自覚でいることは、その「言語」の本質を見失うことである。またその「言語」を使いこなしているのかという観点から言うと否と言わざるをえない。

ただし、この論法を人間に拡大してほしくはない。理由があって派生しているというのは、人工的なラベリングでの話だ。個々人の個別な身体の所有に関しては、その理由を提供するものではない。人間とクローンでは話は別だが、あくまでラベリングされた場合のみだ。

不幸自慢はあまりよくない。

どうもJudaです。
事実として不幸自慢が日本で多いかどうかは知りませんが、自分はついつい根底にそういう含意のあることを話してしまう。私はこれを理性的には恥ずかしいことだと思っています。
なぜ恥ずかしいのか。それは、自分が愚かであることを周りに言い回っているからです。他の人が簡単にこなせるかもしれないことに自分は「これこれの苦労をしてやった」という。それは単純に効率が悪かったのです。そうではないとあなたは言うかもしれません。しかし「それはこのようにすれば実に簡単にできる」と言われたときに、胸がもやもやしてしまうだろう。苦労した自分を認めてほしいのに、その自分はのろまであったと指摘されるのである。このことにもやもやを抱いてしまう。自慢であるのにその本質が不幸に根を下ろしているので、その指摘に素直に従えなくなる。それはさらなる恥である。善意に対して、悪意をもって応えるのは、決して善きことではない。
しかしそれを知っていても、不幸自慢をする。それは不幸自慢が周りに許容される自慢であると言う側面もある。だが、許されるかもしれないが、その本質もネガティブだ。
できることなら、効率よく楽しくさまざまなことに取り組みたい。苦しいことが嫌いだということではなく、互いが互いを高めて引き上げるような環境が望ましいということだ。そのなかに、苦しいこともあるが、それは別にネガティブなことではない。方向転換のための抵抗と同じである。

ドキュメントコメントについて

どうもJudaです。

ドキュメンテーションコメントの重要性について語ろうと思います。

コメントをつけるといっても、どれぐらいの詳細を書き込むのか、あるいはもっと根本的に、何を書くのか、ということは突き詰めると意外と決まっていないことが多い。もっともちゃんとした規約があるところもあるのでしょうが、それらを新規に制定していこうと思うと、Try&Errorではドキュメントを書く人、主に開発者が死にますのでここは重要ですよ。
その勉強のために、一冊本を調達しました。
エンジニアのためのJavadoc再入門講座
この本はまだ途中までしか読んでいないのですが、なかなかためになります。Javadocについて書かれていますが、ここからメタ＜ドキュメンテーションコメント付け＞を引き出していこうと思っています。

なにがドキュメンテーションコメントを深くつきつめる動機になったのか。

それは、レガシー化しているコードを保守、拡張、利用するということが通例であるのに、それらについての一家言をもっている人が周りにいなくて、個人的に困ったことになっているからです。またコメントと同時的にテストやテスト手法、ソフトウェアのもつ責任範囲など、主にソースコードを利用し、改変、配布する場合におこる問題への対処を根とした調査ですね。まわりもリファクタという行為に関してはまだ認知度が高いみたいだが、これに付随するテストに関してはあまり重要視していない。そしてリファクタを行う前にテストを用意しないと行けないという罠。どう考えても、テストは重要だなぁ。と、それを改変するときには、同時にドキュメントを正確にしていかないといけませんなぁという流れです。

そして、一番の関心事は、すべての問題の責任を押し付けられる可能性があることに対して、なるべく強固な方法で防御をしないと、何をされるかわからない危険です。危険は回避したいです。

ドキュメンテーションコメントは、それを利用する人に向けてという意味合いが強いので、ほとんどはPublic 向けな規則ですが、クラスの再利用の問題もあるので、個人的にはProtected、Virtualなメソッドに対しては原則的に必要ですし、例外を投げる可能性のある関数にも必要だと思います。さらに話を広げますと、例外の基準。こちらも実装をしている段階で、いろいろとも問題になります。通常の処理ではありえないものが例外ですが、実装段階でそれらをトラップできるとなると、それは例外なのか？という疑問もあります。そこのところも含めて、上記の書籍には幾分かの指針が書かれていたので、それをもとに考えを深めていく。