ユートピア、って、確か…
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
うん、非常に素晴らしい価値観だと思うです。
えと…
プロセスやツールを、理解もせずに乱用して、個人間には「指揮命令系統」だけで対話どろこか挨拶すらもろくすっぽない現場とか
包括的というか「印刷したときの分厚さ」だけを求められるような(「変数一覧がない」とか言われたのはほんの２〜３年前だ orz)ドキュメントとか
あるいは「無謬性に彩られたありえない要求」とか
さらには「社内調整がまったく出来ていない、矛盾とミステリーとセンスオブワンダーに彩られた要求」とか
「動くソフトウェア」以前に「せめて矛盾がない要求仕様がほしいなぁ」とか
歩み寄るつもりなんてまったくなくて、でも一方で「後で無理を通すために」契約書すらないとか*1
とにかく上に提出した計画を「計画通り」に進めることだけに熱心なお方とか
開発時間と開発金額は「固定」だけど要求は「増える方向にのみ」変化に対して唯々諾々と柔軟かつ無制限に対応してくれて当然だ、とか
変更は「いった次の瞬間には出来ている」と疑わず、納品の前日夜半に平気で仕様変更を出してくるとか
そういう「悪夢としか思えないような」環境さえなければ、この宣言は非常に素晴らしいと思うわけです。
で。実際はというと…
「どうみても理不尽かつありえない、でも現実」
vs
「普通に考えて理にかなっていて穏当な、現実には決して存在しない理想的な幻想」
という、素晴らしい構図がここで見えてくるわけですね。
…ど〜したものやら orz
*1:下請法違反の可能性があるので気をつけましょう：PL法対策ｗ
右と左は同時に見られない
アンチパターン名：右と左を同時に見る
今、正面を向いているという姿勢を基準にして。
右を見てください、というのは可能だと思います。
同じように、左を見てください、というのも可能だと思います。
では「同時に右と左を見てください」を、一切の器具を使わずに行う事が可能でしょうか？
システムの、特に設計や依頼段階において、似たような事があるのですが。
断片的な機能のうち一部である「A」は、確かにそれ自体は実現可能で、「B」もまた、実現可能だとしましょう。
しかし、１つのシステム/機能/操作上において。「A」と「B」が混在可能かは、「Aが可能」and「Bが可能」というお話しとはまったく別の所にあるのですが。
が…
ある一定の比率で、こんな台詞が飛び交います。
「Aは出来るって言っただろ？ Bも出来るって言っただろ？ んじゃAでBだって出来るんじゃないか！！」
「いやだからAとBと、個々には出来ますけど組み合わせるのは…」
「Aは出来るんだろっ！！」
「…はい」
「Bも出来るんだろっ！！」
「………はい」
「んじゃAでBも出来るんじゃないか！！ つべこべいうな！！」
その後、そこのシステムがどうなるかは「推して知るべし」って感じです。
ある程度までは、出来るだけ誠意をこめた会話を。
ある程度を超えたら、頑丈な壁と保身と、一切の会話の拒絶を。…しないですめば、それに越したことはないんですがねぇ orz
「似非DIコンテナのようなものもどき」作りました〜
もっそ微妙ｗ
メモかねて。
先に使い方。
・configに「di_config」でDI用の設定ファイル名を書く
・di_configの書式例
# 仮想クラス名 = includeファイル名:newしたいクラス名 #------------------------------------------------------- # 基本書式 cgi_request = cgi_request_with_emoji.inc:cgi_request_with_emoji # 省略書式その１。includeファイルは「クラス名 + .inc」 view = :view_mobile # 省略書式その２。includeファイルは「設定したディレクトリ ＋ クラス名 ＋ .inc」 hoge = common/:hoge_advance
で、使用例。
include(正確にはrequire_once)はDI側でやってくれるので気にせず。
// インスタンスげと〜
$obj = DI::create('hoge');
// staticなクラスの場合(5.2-
call_user_func( array(DI::get_name('hoge'), 'callしたいメソッド名')[, 引数があれば]);
// staticなクラスの場合(5.3+
// XXX 未テスト。もしかしたら一回、名前を変数に入れないとダメかもしれない
(DI::get_name('hoge'))::callしたいメソッド名(引数があれば);
んで、裏側にあるもにょもにょ。
まず初めに。「あんたDIのことdisってたよねぇ http://d.hatena.ne.jp/gallu/20060822/p2 」という話は甘んじてうけますっていうか今でもあんまりその辺のスタンスは変わらず。
ただ一方で http://d.hatena.ne.jp/gallu/20071218/p2 にも書いたとおり「一部では」使いやすいことに気づいて。
で…その「一部」ん中に、フレームワークがあることに気づきました。
っても、そんなにごっつくたいしたことやっているわけではぜんぜんないゆえんが似非だったりようなだったりもどきだったりするゆえんですが。
えと…例えば、こんな１文があります。
$obj = new cgi_request();
ここで「やっていること」は「cgi_requestクラスのインスタンスを作っている」のですが。
ここで「やりたいこと」は、別に「cgi_requestクラスのインスタンスを作りたい」わけではなくて、厳密には「CGIのrequestを包括してあつかってくれるようなもにょもにょなクラスのインスタンスを作りたい」わけですよね？
なので。
今回、DIコンテナっぽいものを作って、この辺を一段、抽象化してみたという寸法です。
リアルソースは一両日中くらいに上げておきますんで、質問その他あったらよろです。
一応、既存のと互換性保てるようには作ったつもりではあるのですが。もしかしたら微妙に怪しい可能性が、否定はできないので。
え？ mixiアプリ…結構怖い？
上述の調査をしている過程で…なんか、微妙に「おいちゃん的に」より好まないものが見えた気がしたので。
http://developer.mixi.co.jp/appli/spec/pc/permission_model
の「パーミッションマトリクス」あたり。
えと…あえてちょっと「衝撃のでかい」書き方をすると。
たぶん予想通りなら
「"マイミクまで公開"で公開範囲を限定しているはずの、住所(市区町村まで)と生年月日がお外に駄々漏れ」
が可能な気がする。
んと…OwnerとViewerの概念をここで１から説明するの面倒なんで、とりあえず「アプリをインストールしている」状態を前提に考察(インストールしていない状態だと、懸念している状態にとりあえずならないので)。
「インストール済み」の場合。まず「基本情報」は、公開の意思とは無関係に取得可能です。…そもそもこの部分、公開制御が可能かどうかも知りませんが。
あえて突っ込むなら「血液型って基本情報なの？ プロフィールじゃないの？」って程度の部分なんだけど。
まぁいずれも「対してセンシティブな情報ではない可能性が高い」ので、一旦考察から外します。
問題は「ユーザのプロフィール情報」。ここには、前述のとおり「現住所、年齢、生年月日、性別」を含みます。
えと…まぁどんな理由かは問いませんが。
住まいの市区町村を「マイミクまでにしか知らせたくない」とか、生年月日について「マイミクまでにしか知らせたくない」って人は、実際時々いらっさいます。
で。
そゆ人がアプリをやると。
アプリ側ではその情報が「取得可能」なんですね… orz
これってどこかに書いてあるのかなぁ？
あるいは書いてあったとして「ちゃんと十全に認識できる場所にある」のかなぁ？
というのが、おいちゃんの疑問。
なので。
プロフィール情報で「全体公開/非公開」以外、つまり「マイミクまで公開」や「マイミクのマイミクまで公開」の項目がある人は。
それを漏らしたくないのであれば、もしかすると「mixiアプリは使わないほうがいい」、かも、しれない。
なんだろ…SNSって、もうちょっと(いい意味で)閉鎖社会だと思ってたんだけどなぁ。
その辺、どうなんだろ？
「未利用アプリのプライバシー設定」＆「外部サービスのプライバシー設定」？
先日、mixiさんで行われた(と推測される)仕様の変更に対する周囲の反応が比較的面白かったので、ちと考察ネタ。
まず前提条件として。
mixiの設定画面にこんなリンクが出てきて、こんな内容が書いてあったです。
未利用アプリのプライバシー設定
あなたのマイミクがmixiアプリに対して情報へのアクセスを許可したり、あなたが利用していないアプリの実行ページにアクセスすると、そのアプリは、あなたがmixi内で全体公開にしている情報にアクセスすることが可能になります。
このページでは、mixiアプリを通じて渡される情報について管理することができます。これはあなた自身が利用していないアプリに対する設定ですので、ご注意ください。
外部サービスのプライバシー設定
あなたのマイミクが外部のサービスに対して情報へのアクセスを許可したり、あなたが利用していないサービスの実行ページにアクセスすると、そのサービスは、あなたがmixi内で公開にしている情報にアクセスすることが可能になります。
このページでは、外部のサービスを通じて渡される情報について管理することができます。これはあなた自身が利用していないサービスに対する設定ですので、ご注意ください。
双方ともデフォルトonだったようです。…ようです、ってのにはわけがありまして。
おいちゃんの周りは、ヒアリングしている限りでは「未利用アプリのプライバシー設定」が全onだったようなのですが、おいちゃんは全offだったので。その辺が微妙に何がど〜なってるんだか不明。
「外部サービスのプライバシー設定」はきっちりonでした。
んで。
とりあえずこれを見たタイミングで、おいちゃんの脳裏に横切った思考。たぶん、所要時間的には１秒未満程度ｗ
・「外部サービス」がなんなのか予想しにくいのだけど(とはいえ近い仕事来てるからねぇまったくわからんわけでもないのですが)
・とりあえず、mixiに登録している「何がしかの情報」に対する、外部(mixi以外)からのアクセスの許諾を求めているっぽい
・アクセスを「拒否」したとしても、まず間違いなく、なんら不利益はこうむらないと予想(最悪でもアプリ使えない、くらいっしょ？
・弊害があれば、その時点で改めて「拒否しないかどうかを考察」すればいいかなぁ？
・アクセスを「許可」する場合、アクセス対象の項目やら範囲やらその他の検証があるからぶっちゃけめんどい。夜だから眠いし
・最近の、メアドだのアクティビティだのを見ていると、ちょっとmixiさんを「十全に信用する」には、不利な条件が多い
・っつわけで。「拒否」によるデメリットが０な上で、「許可」によるデメリットが「可能性として存在しうる」ので
・一旦拒絶して、後で落ち着いて考えてみよう ＆ マイミクさんにご連絡
という思考の流れのもとに、一旦拒絶＆マイミクさんに(日記で)ご連絡、という流れになったのですが。
それに関して「それは誤解なんじゃないか？」という話なども飛び交いまして。
でまぁ興味もあるので、ちと腰をすえて検証をしてみようかなぁ、と。
まず、どんな情報をどんな条件下において取得できるのかを考えてみます。
…で早速よぉわからんのが「外部のサービス」。まぁとりあえず「mixiさん以外」ってことで、その意味(情報がmixi社以外に流れうる、という点)において「他のアプリと概ね同様」とみなします。
で、改めて。
未利用mixiアプリのプライバシー設定
あなたのマイミクがmixiアプリに対して情報へのアクセスを許可したり、あなたが利用していないアプリの実行ページにアクセスすると、そのアプリは、あなたがmixi内で全体公開にしている情報にアクセスすることが可能になります。
外部サービスのプライバシー設定
あなたのマイミクが外部のサービスに対して情報へのアクセスを許可したり、あなたが利用していないサービスの実行ページにアクセスすると、そのサービスは、あなたがmixi内で公開にしている情報にアクセスすることが可能になります。
「外部サービスのプライバシー設定」の「あなたがmixi内で公開にしている情報」というのが、「全体公開」だけなのか「マイミクまで公開」も含むのか、というあたりが色々と微妙ではありますが。
この手の話なので、それぞれ考察をしてみたいと思います。
まずおいちゃんが気になるのは「あなたのマイミクがmixiアプリに対して情報へのアクセスを許可したり」「あなたのマイミクが外部のサービスに対して情報へのアクセスを許可したり」の部分。
つまり、自分自身の情報が、自分ではなく「マイミクさんの意思によって」アクセス可能状態になりえる、ということがわかります。
だとすると、おそらく議論のキモは
・どんな情報を取得可能なのか
って部分かなぁ、と。
で。「取得可能な情報」に関して、２軸。
まず片方の軸は「情報の種類」で、たぶん、割合に多くの人が「きしょい」と感じる部分。ただこの部分の感触だけだと片手落ちなので、あんまり結論を早まらないでくださいませ。
http://developer.mixi.co.jp/appli/spec/pc/permission_model
から予想される、たぶん取得用のAPIが公開されているのは、つまり「取得が可能である」と思われるのは、最低でもこれだけ。
ユーザーの基本情報（Person & Friends API）
（ニックネーム、プロフィールURL、プロフィール画像URL、血液型）
ユーザーのプロフィール情報（Person & Friends API）
（現住所、年齢、生年月日、性別）
ユーザーのマイミク一覧情報（Person & Friends API）
永続化情報（Persistence API）
「最低でも」っていうのは。もしかしたら「特定の企業にだけ出している、非公開なAPI」があって、そこではもっと多くの情報が取れる、かも、しれないから。
これだけを見ると「いろいろな業者ひゃほーい」なことを考えるのですが。
さすがにそれはなくて、ってのがもう１つの軸。プログラミングでいうところの「スコープ」とかいう概念。
取得可能な範囲は、おそらく、こんな感じ。
「未利用mixiアプリのプライバシー設定」の場合
・あなたがmixi内で全体公開にしている情報
「外部サービスのプライバシー設定」の場合
・あなたがmixi内で公開にしている情報(「公開」が何をさすのかがいまひとつ不明だよ、ってのをしつこく書いてみる)
一応制限はあるっぽいです。
で。
ここからが本腰入れた考察。
まず。
ざっくりと議論の行方を見ていると、なんとなく「チェック外さないと情報が駄々漏れ」vs「元々全体公開な情報だけなんだから無問題」という構図が見えてくるのですが。
この構図に関しては…微妙。
本来的には「元々全体公開な情報だけなんだから無問題」がtrueなのですが、付随する諸々を考えると、必ずしも「是」とも言いがたいかなぁ、と。
ひとつは「利用者の甘え」に属する部分なので考察は省略。「初めから取得可能な情報が、取得可能であると明らかになっただけ」vs「え〜、そんな話しらなかったし気づかなかったし。でも気づいちゃうとなんかいや〜」って感じか、と。
…ただ、これだけの規模のサービスになると、果たしてそれを本当に「At your own risk」の一言で片付けてよいのかどうかは若干疑問。せめて「きちんとした事前告知なり」があってもよいのではなかろうか？ とは思うですが。その辺の告知手順を踏んでいないあたりに少し疑問を呈してみたかったり。「今までだって十分普通に取得できているし公開情報だし」っていう状況下であることをわかった上で、なお。この辺は「ユーザの感情に配慮した系の問題」ですね。
もうひとつは「APIによって簡単に情報が取得できるようになった」というハードルのさがりっぷり。「情報が(なんとか)取得できる」と「情報が(容易に)取得できる」、あるいは「情報が(人間の手を使うか、それに近しい面倒を積み重ねれば)取得できる」と「情報が(API利用など、コンピュータ的に簡単に)取得できる」との間には、ある程度意味のある乖離があるんじゃないか、と、おいちゃんは思っているですよ。
で。その辺をまとめて考えると…トータルでは「微妙だなぁ」、っと。
ここについては、だから「各人の考え方次第じゃない？」程度。
で、もうちょっと微妙なのが「外部サービス」。
もう一度、設定んところの文章を引用してみませう。
あなたのマイミクが外部のサービスに対して情報へのアクセスを許可したり、あなたが利用していないサービスの実行ページにアクセスすると、そのサービスは、あなたがmixi内で公開にしている情報にアクセスすることが可能になります。
このページでは、外部のサービスを通じて渡される情報について管理することができます。これはあなた自身が利用していないサービスに対する設定ですので、ご注意ください。
まず。
・あなたのマイミクが外部のサービスに対して情報へのアクセスを許可したり
・あなたが利用していないサービスの実行ページにアクセスすると
これはどちらも「自分の明示的な意思によらない」可能性を、残念ながら、示唆しています。
「あなたのマイミクが外部のサービスに対して情報へのアクセスを許可したり」はがっつりと自分の意思ではないですし。
「あなたが利用していないサービスの実行ページにアクセスすると」も、比較的偽装されやすげなURIをclickしてしまえば一巻の終わりです。
業者が比較的真っ当なところであれば「諾や否や」と問うてもくれましょうが、真っ当でなければ問うてくれない可能性だって、もちろん考えられます。
って言うことは「意図に反して」外部サービスの実行ページにアクセスしてしまう可能性が、考えられます。
で、その場合に怖いのが
・そのサービスは、あなたがmixi内で公開にしている情報にアクセスすることが可能になります。
の部分。
もし「あなたがmixi内で公開にしている情報」が全体公開であるのであればまだ、というところではあるのですが。
もし万が一「あなたがmixi内で公開にしている情報」が「マイミクのマイミクまで公開」や、あまつさえ「マイミクまで公開」を含んでいる場合。
えと…例えば
・マイミクさんにだけ明かしている自宅の住所(市区町村程度までではありますが)
を、とあるURIをアクセスするか、あるいはマイミクさんのちょっとした勘違い/軽挙によって
・そのまま、外部サービスを運営している会社にもれる
ことになるわけで。
もしそうだとすると、少々ドンビキな状態になるわけです。
…とまぁここまで考察を重ねてみて。
前回の「emailによるユーザ検索という名の下のメアドゲッターな改悪」とは違い、直近かならずしも「全情報駄々漏れ状態」「プライバシー侵害」である、と断じるには、少々軽率な気もするのですがっていうかたぶん軽率な判断だとは思うのですが。
ただ一方で「だからぜんぜん無問題」と言い切れるほど白くもなくて、なんじゃないかなぁ、と。
イメージとしては…「今後の布石もかねた、若干黒よりのグレー」な感触を、おいちゃんはうけてます。
っていうか「公開してもなんのメリットもなくてデメリットの可能性は残っている」＆「公開しなくてもなんのデメリットもなくてメリットの可能性は残っている」状況下で、特段「onにしておく」理由もないので。
そゆ消極的な理由で、とりあえず今回の
・未利用mixiアプリのプライバシー設定
・外部サービスのプライバシー設定
に対しては、両方とも「offでいいんじゃないかなぁ？」と思ってるです。
＆
どちらかというと。
こういう「微妙な部分を含む変更」を、クリアな告知なしにやりはじめるようになってしまったmixiに対して。
ひとつは「利用をやめる」という選択肢と。もうひとつ、何がしかの理由で利用を継続するのであれば「それなりにアンテナを鋭くしておく」なり「あきらめる」なり、何がしかが必要なんじゃないかと思うわけです。
…まぁ。mixiさんも「ビジネス」なので。
必ずしも全面的に「おかしい！！」って糾弾しきれないんですがねぇ…(この辺、近々考察予定です)
気になる？
元ネタ
http://d.hatena.ne.jp/Sikushima/20101126/1290733753
えと…まず、このSQL
SELECT * FROM 社員 INNER JOIN 部課 ON 社員.部課ID = 部課.ID
つまり「部課テーブルの情報を含めた、社員さんの情報一式とってこい」なわけですよね？ やりたいことは。
これをOOPで一番ざっくり書くと、たぶんこうなるのですが。
$obj = new 社員全体を意味するクラス(); $list_all = $obj->get社員の情報一式();
「get社員の情報一式」の中で何をどうやっているのかはとりあえず隠蔽しておくんじゃないかなぁ、と。
そうすれば、何かがあったときに、それこそ最悪「インタフェースだけあわせてクラス総とっかえ」してもよいわけですし。
あぁ、ちなみにおいちゃんの一番の好みは、たぶんこんな感じのインタフェース。
$list_all = 社員さんを扱うutil::get社員の情報一式を無条件で();
戻り値は…MW的にはdata_clumpかなぁ。大まか「１インスタンスが１社員さん」なインスタンスの単純なvector的配列。
最もこんな「とりあえず全部の情報をとってきてから」なんていうメモリ負荷の高い処理、そもそも書きませんが B-p
で…以下の各プログラムが、「SQLのほうがOOPよりも優れいている、ってことを理解するためにサンプルとして付した、OOPなプログラミング」………らしい。
問題は「どこがなにがどのようにどうみたらどのへんが」OOPなのかが、ぜんぜんわからない orz
いち
for(Object row社員 : 社員){
for(Object row部課 : 部課){
if(row社員.部課ID == row部課.ID){
retSet.add(row社員); // LEFT JOIN のときには for の外に
retSet.部課名 = row部課.部課名;
}
}
}
return retSet;に
for(Object row社員 : 社員){
row部課 = 部課.seek(row社員.部課ID);
if(row部課 != null){
retSet.add(row社員);
retSet.部課名 = row部課.部課名;
}
}
return retSet;(そもそも、いちとにがよ〜わからん。なんで似たようなloopを別々に書いてあるんだろ？ つなげて使うのかなぁ？)
さん
Object set社員 = 社員.sort(部課ID);
Object set部課 = 部課.sort(ID);
Object row部課 = set部課.current();
for(Object row社員 : set社員){
while(row社員.部課ID > row部課.ID){
row部課 = set部課.nextRow();
}
if(row社員.部課ID == row部課.ID){
retSet.add(row社員); // LEFT JOIN のときにはifの外に
retSet.部課名 = row部課.部課名;
}
}
return retSet;
よん
Object setHashed部課 = 部課.hash(ID);
for(Object row社員 : 社員){
Object set部課 = setHashed部課.seek(row社員.部課ID.hash());
for(Object row部課 : set部課){
if(row社員.部課ID == row部課.ID){
retSet.add(row社員); // LEFT JOIN のときには for の外に
retSet.部課名 = row部課.部課名;
}
}
}
return retSet;
…うん、もし業務で「これが おぶぢぇくとしこうぷろぐらみんぐ、Da〜〜〜〜!!」とかいってこんなんしか出てこなかったら、絶望のあまり「OOPってなんて使えないんだ！！」って叫ぶかもしれない(苦笑
っつか。こんなもどき未満なものを提示されて「OOPが使えない」とか言われましても……… orz
あとついで。
http://d.hatena.ne.jp/Sikushima/20101124/1290571758
CAP定理のうち、分割耐性(Partition Tolerance)とのトレードオフ。
JOINも副次問い合わせもつかわなければ、とりあえず「割合簡単に、横にサーバを広げる」分割耐性が手に入るので。
もっとも「ンならNoSQL使えばいいぢゃん」という話に対しては…とりあえず昨今思考している限りでは「そうだよねぇ」としか言えない(苦笑
雇う人のスキルセットとかお値段の高低くらいかなぁ、あと気になるところとしては*1。
実際問題「RDBでなければまずい」シーンは結構少なくて、だから本格的に出番が減ってるんじゃないかなぁ？
*1:でも「お安い連中」数やとっても、ねぇ(苦笑
どう教えよう？ どうはかろう？
ちと思考実験に近い内容です。近いっていうか思考実験そのものなのですが。
なので、いつにもまして散らかりながら。…ちと小見出し入りでいきまふ。
で、実際どんな弊害があるの？
元ネタ
http://togetter.com/li/68853
http://kidsnote.com/2010/11/15/35or53/
http://blog.livedoor.jp/dankogai/archives/51550112.html
おいちゃんは端的に「どっちでもえぇやん」派。
NG派の人の、比較的真っ当だと思われるあたりの反論として「かける数とかけられる数は意味が違うし、それによって後で理解が困難になってくるから云々」というあたり、だと思っているのですが。
えと…実際にそれで弊害あるんでしょうか？ あったんでしょうか？
「かける数とかけられる数の混同による混乱と理解不能」がもし発生するのだとしたら*1、それが発生した時点で教えてあげればいいんじゃないかなぁ、としか思えない。
さらりと本音をぶっちゃけると。
「自分たちが"こうだ"と思っている規則」とずれているのが気持ち悪い、ってのが根っこにあって。
それを相手(今回の場合生徒)に押し付けるために理由を付けてるんじゃないか？ って、正直思えてしまうんですね。
類似ネタ
擁護派のやり取りを見てふと思い出したのが、以前に…OKWaveさんだったかな？ で見たやり取り。
確か、上述とある意味にている構図で。
質問者が「学校の試験でバツを食らったけどどうしても受け入れられない」という類の話。
選択肢がa,b,c,dとあったらしいのですが、選択肢はあっていたのにバツを食らって。理由が「問題文にはブロック体でアルファベットが書いてあるのに、あなたのbはブロック体ではなくて筆記体で書かれていたからダメ」とかいう類の話。
ここでもやっぱり、いわゆる「教員に属する」方々が擁護していて、曰く「そーゆーもの」なんだそうで。「問題ではちゃんと選択肢がブロック体で書かれているのに、それを筆記体で書くのはおかしい」と。
だとすると。ゴシック体で書いてあるところに明朝体で答え書いたらやっぱりダメなんですかねぇ？
いやまぁ「デザインの学校」でならありそうですが(笑
もうひとつ
以前にちょいとおいちゃんのほうでコメントを書かせていただいたネタ。
http://d.hatena.ne.jp/tonotonotono/20101017/1287268856
興味深いなぁと思ったのが、Blog主さんの以下の発言(コメントんところにありやす)。
冷静に見直すと確かにその通りだ！！
答えだけでなくて、前提も既におかしかったんだと目からウロコ。
前提条件を「疑ってかかる」のはおいちゃん的には基本てちうか本能なのですが。
そういえば「前提条件は前提条件として無条件に受け入れる」人って多かったなぁ、ってのは、もっぱらTRPGで現代近未来の陰謀モノ系をやってた時の感想。
で、ちょっと掘り込んだ考察
以前に、塾講師の経験のある友人にも話をしていたのですが。
えと…
現実は、あるいは少なくとも「うちらがお仕事として立ち向かう現実」は。
「唯一無二の正解」どころか「とりあえず正解らしきもの」ですら、あるかどうか限りなく疑わしくて、という身もふたもない混沌が広がってます。
ただ一方で、彼も以前にそうでしたし、思い返すに「ある程度真っ当な学歴を持っている」人ほどその傾向が強いように感じるのですが…意識のどこかで「きちんと正解が存在する(しかも大抵の場合、唯一無二の絶対解を想定している)」ことを前提に思考しているように見受けられるです。
若い子にも比較的増えたような気がしますねぇ。
自分であれこれ考察したりする前に「相手に正解を聞き出そうとする」姿勢。たぶんその根っこにあるのは「正解がある」という大前提を、無意識の中で持っていること。
これが中途半端にマガると「世界に一つだけの花」が咲いてきちゃう。んと…「絶対解」はないけど「明らかな間違い」はあるから。まぁこれは余談ですが。
で。
この「無意識に正解があると想定している」ってあたりが、初手の、いくつかの「散らかった話」につながっていくです。
たぶん、教師とかいう類の方のほとんどは「正解がないことを前提にした」教育を、正直、まったくといっていいほどやってくださっていなくて*2。
かくして、問題に対して「問題提出者が想定した以外の答えはNG」、もちろん「問題や前提条件に疑問をさしはさむなんてことはあってはならない」と。
で、そんな教師が「自分の考えに近しい子ほど優遇する」ような教え方っていうかぶっちゃけ調教を延々やっていれば、そりゃまぁ育たないだろうなぁ、と。生徒が学ぶのは「混沌たる現実と格闘して自分なりの答えを切り出していく」スキルじゃなくて「教師が"よし"と考えている正解を、文脈や顔色や空気から読み取る」スキルなんだし。
ただ一方で、現実は果てしなく混沌としているので。
「"正解なんてないかもしれないところ"が基点になり」「前提は疑ってかかる必要があり」「それでも一定の"答え"を、場合によっては複数導き出す必要がある」「前に、本当にそれは答えを出すべき問いなのか？ についてまずは考察する必要がある」わけです。
つまり。「答えを出すべき問題」が、実は「答えを出しちゃいけない」かもしれない可能性さえあるわけですね。前提条件木っ端微塵(笑
「顔色と文脈と空気を読む」ことが出来れば上位にいることができた世界観から一転「自力で答えらしきものを切り出す必要がある」世界。
そりゃ戸惑いもしますわな。
とりあえずの〆と、次に向けてのタネ
いわゆる官僚系とか大企業系とかに向いている性質の方に多いのですが。
彼らの前提には「規則と正解」があって。なので「規則に沿う形で唯一無二の正解を選択し続ける」のが、彼らにとっては最上の状態です。
近しいと思うのが、特にベンチャー系の、経営層の方々で(余談…でもないのですが。警察/検察はたぶんこっち側な気がしますねぇ)。前述の方々が「選択肢とプロセスを重視する」のに対して、経営層の方々は「結果(の一部)を珍重する」傾向にあるですね。
微妙に反動のような気もするのですが。前者が「プロセス重視」なのに対して、後者は「結果重視」というところでしょうか。
えと…例題。
例えば「(何かを売って)売り上げを伸ばし、結果として利益を出す」という目的を設置してみます。
前述の方々は「前例に沿ったやり方で」「マニュアルどおりに正しく売り歩くこと」が重視されます。
重視しているのは「何かを売って」の部分。大抵の場合「正しい売り方」というのが、暗示明示問わず、存在します。
正しくマニュアルどおりにやった結果として「売り上げが上がらない」場合、大抵は「どこか遵守しきれないところがあったであろう」と推測されます。時々「マニュアルどおりだったから責任は問わない」とかいう謎結論が、これはお役所系で見受けられます B-p
ちなみに「マニュアルに問題があったのではないか？」などという反逆な発言はトンデモハップンです。ちなみにこの辺がもうちょっと進化しますと、例えば警察とか検察とか相撲とかその他諸々の機関様の必殺技のひとつ「もみ消しによる組織防衛」に発展します。なにせ「上には逆らえないもの」ですから。進化するのはポケモンだけで十分におなかいっぱいなんですがねぇ。
幸せですか？ 市民。
後述の方々は「手段は問わずに売り上げを上げろ」と檄を飛ばします。この場合「売り上げという数字が１円でも高くなること」が正義です心理です唯一にして絶対の存在価値です。
重視しているのは「売り上げを伸ばし」の部分。利益じゃないあたりがひとつのポイント。ついでに言うと「短期的売り上げ」であって、例えば信用とかそういった類の「長期的視野に基づいた利益」でもないあたりもポイント。
売り方が強引になってきたり経費を鬼のように使ったりそれがリベートだったりちょっと塀の上ぎりぎりセーフだったりアウトだったり完全にグレーですらない黒だったり…なんていう風に転げ落ちてきます。
ちょっと亜流で「利益を出す」に焦点があたると。
まずは社員や派遣や外注をボロ雑巾のように使い倒しサービス残業当たり前とか軟禁状態とか下請法違反とか過労死寸前とか寸前ぢゃもはやねぇよとか。
さらにもうちょっとえげつなく、利益が「会社」ではなくて「社長(とかそこらへん)個人」になると。会社の金を持ち逃げしたりM&Aで自分だけ利益を得たり社員を(文字通り)売り飛ばしたりだましたり給料未払いだったりあんなこんななギガスラッシュ。
20代の若者が、“心のキレイ”な人を食い物にしている
http://bizmakoto.jp/makoto/articles/1011/12/news006.html
なんて記事を想起してしまいますねぇ、っと。
http://bizmakoto.jp/makoto/articles/1011/12/news006_2.html
1カ月ほど前に会った20代後半の男性を紹介したい。
「自分は、30歳前には会社やNPOを起業したい。いまの20代や10代は心がキレイなので、賃金が低くても文句はいわない。50〜60代などオールド世代はお金など低次元のものにしがみつくが、20代は自己実現の欲求など高次元のものを求める。だから若い人は地震があれば、そこに駆けつけボランティアに力を注ぐ。社会人になっても安い賃金で不満を言わずに働く。もし不満をいったら、辞めてもらう」
これはまだボランティアベースなので、ぎりっぎり可否が分かれそうな気もするのですが。
「自社っていうか自分の利益のために」同じセリフ吐く連中も、とりあえず「まったく見聞きしたことがない」わけでもないですしねぇ B-p
さて。例題ですが…ぢゃぁおいちゃんは何を考えているでしょうか？
もしかすると「売らないことが一番利益が上がる」可能性だって、実はあるんですよ、っという、そこらへん。
実際問題。「思い入れはあるんだけど、死に筋だし売れば売るほど後々の経費がしゃれにならないし売らないほうがマシ」な商品ってのは存在しているのですが。でも思い入れがあると管理系の方々は「売って来〜い」となる。
そこで「それ、売らないほうがええんちゃいます？」っていう答えを、どれくらいの人が出せるのかなぁ、と。
システムなら。
どんなシステムを作るかの前に「そのシステム、本当に必要ですか？」ってのを問う能力。
現場で「本当に」必要とされている能力って、そーゆーもんなんじゃないんでしょうかねぇ？ っと。
…で？
いやぢつは。
最近、資格試験について色々と考察する機会に恵まれまして。
で…考えていたですよ「どんな資格試験なら、おいちゃんが首を縦に振るのだろうか」と。特に、システムの設計と、その手前にある「ヒアリング/提案」部分。もちろんプログラミングだって一緒。
資格試験って、正直「正解がある前提」なのですが。でも現実は「正解なんてない混沌」で、っていうあたりがすでに「とことんまで乖離」してるですよ。
だとすると。
その溝を、どうやったら埋められるのかなぁ、と。
どうやれば、教えることが出来るのかなぁ、と。
あんど。
最近は「就職即戦力」とかいうのを求められるらしいのですが。ンなもんは一撃。
「社員さんで本当に"戦力"になっている人って何割ですか？ あるいは戦力になっていない人は何年くらい無駄キャリア積み重ねてますか？」
だとすると。新人さんたちを「どうやって教えていくのか」っていうのは、とても大切だと思うですし。
その指針なり目標なりのひとつとしての「資格試験」であるとするなら、それはそれで有意義なんじゃないか、って思ってるですよ。
で。
なんとなく…資格試験で「最低限の底上げ」をした後は。
それこそ丁稚奉公でもしていただいて「体で覚えてもらう」しかないような気もしていますが B-p
つまり。
まずは「基礎知識」を、これは多少詰め込みでもよいのでまずはある程度覚えてもらって(忘れてていいです必要なときに思い出せりゃ)。で、たぶんここが資格試験。必要なのは「一定の点をとって合格すること」"ではなくて"「その資格試験のための勉強をすること」。つまり「合格しなくてもよい資格試験」。合格することじゃなくて、そのために学ぶそのプロセスが重要、っていう観点。
んで、その後は「実地で学習」。試験の合格なんてせいぜいが「スタートラインに立てたかどうか」ってくらいなので。
必要かつ重要なのはその先。
だとすると。
「下手に習うと 下手がうつる」なんていいますし。…師匠とのめぐり合いのご縁次第、になっちゃうんですかねぇ？
