学習コストは初心者税の一種なのかもしれない

よく新しい技術に触れるときは、
学習コストを大きな要素として導入が検討されます。

この業界では、
どうもむやみやたらに学習コストが高く見積もられているような気がします。

本当に書籍すら出ていない最新技術ならかなり高いとは思いますが、
マニュアルが整備され終えた技術なんて大したことないでしょうに。

落とし穴も大抵は誰かがブログで愚痴っているので、
検索すれば対処法を学ぶことができます。

未だにSubversionすら学習コストが高いと言う人達は、
真面目に働いているのか疑問に投げかけずにはいられません。



おそらくこの認識の差は、
初心者税の一種なのではないでしょうか。

彼らの税率を下げるためには、
さぼっていた数百時間、数千時間の基礎学習が必要となります。

でも彼らは初心者税が高くて払えないので、
全力で払わずに済む方法をごり押ししているのではないでしょうか。

こんな人たちの存在自体は許容できるのですが、
一緒の仕事をしようものなら彼らに合わせるだけでこちらも税金を払う必要が出てしまいます。

自分は初心者税なんて極力払いたくないので、
一緒に仕事をしないように努めなければなりません。



こういう意味で、
少数の高レベル技術者と多数の低レベル技術者の編成は信用できません。

少なくとも、
同じプロジェクトでも完全に仕事を分けないとまずいのではないでしょうか。

高レベルの特権は、
初心者税の低さにあるのですから。

自分がFizzBuzzを採用に使うなら

FizzBuzzを入社試験に出したらどこを見るかを読んで、
自分ならどんな風に使うのかちょっと考えてみました。

こちらの想定は、
新入社員や中途採用の方向けを想定しています。
(分けて言わなきゃいけないことに違和感が…)

元の記事と前提が違うので、
違う結果になっていますが…まあそんな感じです。



まずは問題を２部構成ぐらいにしたいです。

1. FizzBuzz相当の問題を解かせる。
2. そこから何らかのお題を出してソースコードを変形させる。

でしょうか。

基本的にFizzBuzzは機械的にできなきゃ来るなと言って差し支えないレベルです。

採用したいレベルはさらにその上にあるので、

もう少しひねってやる必要があります。

じゃあなんで最初から難しい問題にしないのかというと、

ウォーミングアップとか、

頭をプログラミング用に切り替えるまでの準備とかです。

ではお題を出しましょう。

すぐに思いつくのは、

1. ここから抽象化してみてください。
2. ここからを高速化してみてください。
3. ここからを省メモリ化してみてください。

でしょうか。

通常は1ですが、

シビアなスペックを要求するなら2や3もありでしょう。

このときのポイントは、

考え方を説明してもらいながら変形してもらうことです。

その人のコーディングに対する姿勢の鱗片が見えると思います。

1として考えてみましょう。

とりあえず、

関数化なりクラス化なりしないのはかなりまずいです。

1～100の部分をRangeクラスにしようと考える人は、

相当にオブジェクト指向が至高の思考にどっぷりな人でしょうか。

そもそも数値が連続していないかもと考え、

コレクションで用意してやるような人もいるでしょう。

倍数の判定もn個あるかもしれないと考えた人は、

判定もループさせなければならないことに気がつくのかな？

そもそも倍数の判定以外も入れたくなるだろうから、

倍数判定の関数を引数で渡そうと考え出せば、

この人は関数型の考えに足を踏み入れたことになるでしょう。

ここらへんは、

その会社が求めたい人材に合わせて評価してあげてください。

大事なのは、

自分の会社に近いレベルを選ぶということです。

高すぎるのもアウトだと思ってください。

あまりにハイレベルな人にExcel方眼紙を書かせたりしてみなさい。

すぐに去ってしまうことでしょう。

それに一人だけ関数型を完璧に使いこなせたとしても、

回りがついてこられなければ同様に去られてしまうでしょう。

※例え仕事で使われることが無かったとしても。知っているだけで違うことが、確かにあります。

このレベルを要求するのが、

ごく少数の企業でありませんように。

何のために勉強するのか

技術者は何を目指して勉強しているのかにコメントを書こうと思っていたのですが、
アンチスパムフィルタに阻まれたので記事にすることにしました。

ネガティブな内容では無いと思うのですが、
該当箇所がさっぱりわかりませんでした。



んで何が言いたかったのかといいますと、
自分はどれに当てはまるのかな？って話です。

自分の発想はどちらかと言うと画家寄りで、
「自分の生涯の作品を完成させたい」が為に勉強している節があります。

既に基本構想や設計はできていますが、
今の自分には至らないところだらけです。

そんな壮大な夢を妄想しながら日々を送っていますが、
それで有名になりたいかと聞かれると必ずしもそうではないのです。

有名になるのはあくまで副作用であって、
作品を作り上げることそのものに大きな価値があります。

それに万人受けするものより、
むしろごく一部の人に強い感動を与えるような作品のようなものが好みです。

作品が完成すれば自分としてはほぼ満足ですが、
自分以外の誰か一人でも認めてくれたならそれはもう大満足なのです。



そんなことは綺麗事で、
本心ではどれかに当てはまっているのかもしれません。

ですが、自分はその綺麗事を通して生きて逝きたいのです。

才能とは何か

プログラマーは画家と同じように、
希少ではないにしろ才能を求められる職業です。

プログラマーに必要な才能の面白いところは、
既に目に見えて何段階かの才能のポイントが判明しているところです。

• 構造化プログラミング
• 順次
• ポインタ・参照(カテゴライズとして間違っていますがとりあえず)
• 反復
• 分岐
• オブジェクト指向
• オーバーロード
• 継承
• オーバーライド
• ポリモーフィズム
• 隠蔽
• 関数型言語
• 再帰関数
• λ計算
• カリー化(これも微妙ですがとりあえず以下略)

まあ色々羅列していますが、

簡単にまとめる抽象化に必要な技能だということです。

高い次元の抽象化には高い才能が要求され、

下の次元では分かったのに理解できないのでわめき散らす人が現れます。

これもピーターの法則の一種でしょうか。

その人は無能レベルに達したといえるので、

一段階下に降りてもらって上の次元に行ける人から離してあげましょう。

そうすればお互いが幸せです。

って、ピーターの法則の話がしたいんじゃありません。

じゃあ才能が無ければ諦めるしかないのかという話です。

ここがややこしいのですが、

才能がなくても適切な学習を行えば習得できる可能性はあります。

しかし、それがいつになるのかは誰にもわからないのです。

あまりに現実的でないため、

よほど高みを望む意思が無ければ別の道を模索するべきなのです。

どうせすぐに次の壁が登場するでしょうしね。

分かりやすく言うなら、

新たに習得したい技能に１００通りの方法があるとします。

(実際には無限に近い手法があるでしょうが、ここでは絞ります。)

パターンそのものは１００通りでも、

そのうちのどれで習得可能かに大きな個人差があると思ってください。

自分と相性の悪い方法を取ると、

習得に失敗します。

で、才能のある人は１００通りのうちの８０～９０通りくらいで習得が可能です。

よほどひねくれた習得方法を取らない限りは簡単に到達します。

普通の人は４０～７０くらいです。

運が良ければ一発で到達するかもしれませんが、

場合によっては何回も道選びに失敗することもあるでしょう。

才能が無い人は１～３０くらいです。

王道と呼ばれる方法では無理かもしれません。

もしくはまだ人類が発見していない方法でないと習得できないかもしれません。

たまにもの凄く運が良ければ、

壁を乗り越えて習得できるかもしれません。

また選んだ道によって、

他の技能を覚える通りが減ったり増えたりする点にも注意しないといけません。

何事もいくらでもやり直せるというのは間違ってはいませんが、

同じやり直しのように見えて実はルートが変化しているのには要注意です。

それまでは行けたかもしれない道が、

実は消えてしまっているやもしれません。

(COBOLの人がオブジェクト指向を覚えにくい割に、初学者はすんなり入るなど)

ああ、道に罠が仕掛けられている可能性もありますね。

悪書とか誤った知識を持った先輩や上司と最初にぶつかってしまった場合です。

悪書はまだしも、先輩や上司は己の不幸を呪うしかありません。

まとめます。

あなたの進みたい方向にある道は無数にあります。

才能のある人は適当に選んでも前に進めます。

普通の人は道をよく考えて選ぶ必要があります。

才能のない人は本当に進みたい方向なのかをまず考えてください。

才能が分からないのであれば、

あなたが選んだ道の中で、

誤ったと感じたものを挙げてみてはいかがでしょうか。

他の人と比べて転んだ数が多ければ、

ちょっと注意した方が良いのかもしれません。

でも習得の仕方によっては、

前の道が通行可能になることもあります。

あなただけの進み方を見つけるべきでしょう。

あれ？

結局大したこと言ってないですね。

バカになるオブジェクト指向プログラミング講座(ドラフト版)

※この記事を読んでも、OOPについて理解は深まりません。嘘だらけでバカになります。



序章　混沌の時代

その昔、
ソースコードに秩序は無く、
そこにあるのは混沌でした。

少しでも速く、
少しでも小さく、
そのために無数の“goto文”と“グローバル変数”が偏在していました。

このようなソースがそれこそ無数に…
【N88日本語BASIC (無茶苦茶な行数に飛ぶIF命令)】

【N88日本語BASIC (グローバル変数がいっぱい！)】


ああ今の時代、
“Hello, world!”をコンパイルしただけでも何KBになることか…！

“goto文”と“グローバル変数”はプログラマーの理解を阻害し、
ソースコードは誰にも触れないものと化していく…

そんな時代でした。



2章　“構造化プログラミング”の時代

混沌に一筋の秩序をもたらす者が現れました。
その名も、勇者“エドガー・ダイクストラ”。

彼はソースコードの中を、3種類の論理構造に分けました。
そしてその論理構造を意識してサブルーチン化すれば、
ソースコードは理解しやすいものになると発表したのです。

• 順次
  【C言語　(順次改善前)】
  【C言語　(順次改善後)】
  
  
• 反復
  【C言語　(反復改善前)】
  【C言語　(反復改善後)】
  
  
• 分岐
  【C言語　(分岐改善前)】
  【C言語　(分岐改善後)】

“goto文” と“グローバル変数”はサブルーチンという壁に阻まれ、

限られた場合でのみ使われるようになりました。

(後にこの一部は、“例外”とか“静的メンバ変数”とかに名前を変えて姿を現します。
まあ、それはまた別の話です。)

この働きにより、

ソースコードに構造化プログラミングという秩序が生まれたのです。

3章　状態と動作

構造化プログラミングが普及するにつれ、
小さな混沌が芽生えることになりました。

それは引数の数です。

何も考えずにサブルーチン(以降は関数を記載)化すると、

自然と引数の数が増えていくのです。

しかしそれは、大きな問題にはなりませんでした。

引数を構造体にまとめておけば、
簡単に引数の数を減らすことができたからです。

【C言語 (引数を減らすサンプル)】

そしてこの構造体が、
ある種の状態を指していることに気がつく人がいました。

【C言語 (犬サンプル)】

これにより構造体の意味がハッキリしました。

状態(構造体)と動作(関数)が手を取り合った瞬間です。

4章　“関数ポインタ”

状態と動作は、
関数の引数型によって結びついていました。

しかしこのままでは、
状態からどのような動作があるのかまではわかりませんでした。

出力できるのか、
入力できるのか、
はたまたどこかと通信するのか、
それは関数の引数をチェックしていく必要があります。

また動作から同じ状態を使う動作がどれだけあるかもわかりません。

せっかく同じ状態を使うにも関わらず、
動作と動作を組み合わせるにはその動作の存在を*知っている*必要があったのです。

【C言語 (犬サンプル改善前)】

しかしある人は気が付きました。

ある動作を行えることそのものが状態なのではないかと。

つまり動作も状態の延長線上として捉えることができると考えたのです。

関数ポインタを使えば、
状態の中に関数ポインタを入れて動作と一体化させることができます。

【C言語 (犬サンプル改善後)】

今度は、状態と動作が一心同体となったのです。

5章　“オブジェクト指向プログラミング”の時代

※ここからJavaで書く予定。

状態と動作はひとつとなり、
プログラミングに秩序の光が差し込みました。

でもこれはきっかけにすぎません。

これをさらに応用・発展していくことで、

新たな可能性が生まれました。

• オーバーロード
• オーバーライド
• 継承
• ポリモーフィズム
• デザインパターン
• 【とにかくいっぱいサンプルDA！】※優先度を決めてTOP5くらい出せばいいかな。

ここにオブジェクト指向プログラミングという抽象化は、
ひとまずの完成を見せたのです。

終章　そして“関数型言語”の時代へ…

オブジェクト指向プログラミングの抽象化は見事なものでしたが、
それだけでは上手く抽象化できない問題もまだ残っていました。

関数を呼ぶ順序がある程度決まっているものや、
ループ処理の中身だけ後から変更したい場合です。

データベースのオープン・クローズはほとんどセットと言ってもいいですが、
その途中の処理は多岐に渡ります。

オープン～クローズまでの流れを関数化するのは難しかったのですが、
仮にオープンとクローズの間の動作を関数の引数で渡したをしたらどうでしょうか。

今まで複数箇所にあったオープンとクローズが１箇所にまとまります。

オープンやクローズの問題に直面したら、
そこだけに注力すれば修正することができるようになるのです。

ループの場合も、
ループの中身を関数の引数で渡せたら…

仮に超高速ループを誰かが開発し、
中身を引数で渡すだけでその恩恵を受けられるとしたら…

何が言いたいか？

関数に関数を渡せるべきであり、
関数は関数を返せるべきだということです。

これを簡潔に記述できるならば…それが関数型言語の入り口です。

新しい秩序の光が、
あなたにも見えてきませんか？

終わり



※要望があればちゃんと書くかも。…誰もいないよね？

政治がソフトウェアの品質を上げることはあるのか

あるバッチファイルを作っていたときのことです。

そのバッチの要件で多重起動禁止があったのですが、
お客様から提示されたロジック(psで調べる)では満たせないことが分かりました。

(確かflockはまだ無いバージョンだったので)
mkdirで生成に失敗したら起動中のバッチがあるとみなすのはどうかと説明しました。

そのときのリーダーはそれを踏まえた上で、
お客様の面子をとってpsでの不完全な排他の実装を命じました。



いわゆる、
政治的事情による判断というやつです。

ソフトウェアの開発において政治が深く絡むパターンとしては、
論理的に正しいことを“無理が通れば道理が引っ込む”で捻じ曲げるために使われます。

ソフトウェアが論理的に正しくなくなるということは、
動かなくなるか品質が下がるということです。

確かに、
自分自身で使うものを作っているので文句を言うなというのは理解できます。

しかし、
大金を使って作っているソフトウェアの品質を下げてまで通す価値があるものなんでしょうか。



きちんと話せば分かってくれるという意見もありますが、
デッドラインを読み終えた今となっては信じられません。

世の中には自分の思い通りにいかなければ全てNGという人種がいて、
その人種が権力を持っている場合は逃げるか排除する以外の方法は発見されていません。

つまり政治がソフトウェア開発の問題になっている時点で、
そんな人種とぶつかっているということであり、
自分から見たら詰みの状態なわけです。



まとめると、
政治色が強ければ強いほど、
そこに対して開発するソフトウェアの品質は低下します。

パッケージを導入したとしても、
その使い方で政治が発生してパフォーマンスを低下させます、

官公庁に品質の良いソフトウェアを提供することができないのは、
彼らが政治で物事を解決しようとするからではないでしょうか。

エビデンスをいつとるか、今でしょ！

SIerが実施する試験には、
誰も見ずに終わるであろうエビデンスという資料を残す必要があります。

オーソドックスなのは、

• ログファイル(要：該当部分のみ切り取り)
• デスクトップ画面のキャプチャー画像
• データベースのテーブル情報

でしょうか。

まあたまに役に立つこともありますよ？

試験仕様書に操作方法が一切明記されていないアホな場合とか、
エビデンスが試験仕様書の補完になっていたりします。

…いや、これは試験仕様書側に寄せるべきなんですけど。

とにかく何が言いたいのかというと、
エビデンスで発生するコストに対してのメリットが薄すぎるわけなんです。

お客様の精神衛生の値段にしては高すぎないでしょうか。



自分ならもう少しコストが低く、
そしてエビデンスのレベルが高いものを提案できないか考えます。

例えば、アマレココを動かしっぱなしにして試験するなんてどうでしょうか。

これならまずデスクトップ画面のキャプチャー画像を取る作業を軽減できます。

そして常にどこかに時間を表示しておくようにしておくことで、
ログとの整合性を確保します。

試験仕様書に試験の開始時間だけ明記しておけば、
わざわざ切り取って加工しなくとも良いでしょう。

データベースの内容なんかは、
コマンドでSQL打ってデスクトップに表示させて終わりとします。

SQLを実行した時間が正確に分かって信頼性もアップです。



もっとも、
問題点だってあるにはあります。

ひとつはパソコンの要求スペックが跳ね上がることです。

最近のパソコンは性能が上がってきていますが、
前世紀のパソコンを出されるとちょっと…

次にファイルサイズがアホみたいに肥大化することです。

ハードディスクがギリギリの場合にこの方法は使えません。

最後はお偉いさんがなぜか高く見積もる学習コストでしょうか。

ただニコニコ動画のゲーム実況者さんがお手軽に導入するツールです。

ソフトウェア作ったり扱ったりでお金を貰っている自分たちにできない道理はありません。



本当はユーザーインターフェースの検証に使うのが良いのですが、
まあこういうことにも使えるってことで。

LiveTimeBoardで遊んでみた

めもりくりーなーでいつもお世話になっている株式会社クロノスさんから、
LiveTimeBoardなるものが登場しました。

このアプリケーションに対するメタファーとしては、
場所に左右されないホワイトボードって感じでしょうか。

使ってみた感じが以下の通りです。

正面のめもりくりーなーの絵＋ふきだしは自分が描いたものです。

感想としては、
機能をギリギリまでシンプルにした業務用お絵かきチャットでした。

文字の挿入すら無いのは、
そういう意図的なものを感じずにはいられません。

ちょっとでも絵心がある人とない人とでは、
まったく違う印象を受けるのではないでしょうか。

自社のサーバーにログイン機能付きのお絵かきチャットを追加するのとどちらが特なのか、
その辺をご相談の上購入すると損をしないと思います。



ここからは余談ですが、
欲しいのはホワイトボードじゃなくて付箋なんだという方にはTrelloをオススメします。

英語ですが日本語入力も可能です。

FogCreekは相変わらずいい仕事してますね～の一言です。



…そんなこんなでオフィスにある身近なものが、
どんどん仮想環境に進出してきています。

もしもビジネスチャンスをお探しであれば、
まだ仮想化していない何かを探してみてはいかがでしょう？

意外な成功が待っている…ようなそうでもないようなです。

政治をプログラマーらしく考えてみる

今の政治は、
素人目には停滞しているように見えます。

どんなアクションを起こしても抵抗勢力が現れて、
結局本来の効果が失われた状態で動き出しています。

前に進んでいる感じがまったくしないのです。

こういうの何ていいましたっけ？

鶏と卵の問題？

いや違う…

囚人のジレンマ？

なのかなぁ…

デッドロック？

お、これはいけるかも？

抽象化してみよう。

if (policy.hasDeadlock()) {
    for (Deadlock i : policy.getDeadlocks()) {
        Japan.releaseDeadlock(i)
    }
}
policy.execute()

なるほど、
これで考えると皆さんexecuteメソッドに気を取られすぎていませんか。

その前のデッドロックの除去を高速化する方に目を向けるべきじゃないかな？

少なくとも停滞する確率は下がると思います。

外部から最適解は得られない

「「淡路島の電車の運行状況を聞いた話」をシステム開発に置き換えてみる」に対する反応に対する以下略に対して、
あえて本筋から外れたことを記事にしてみます。

よく問題が起こったシステムに関して、

「○○はダメだ。」
↓
「じゃあ答えは何なんだ。」

という問答が繰り広げられることがあります。

おおよその場合、
結局その答えが出ることは無いでしょう。
(答えがあったら最初に答えを併記しているでしょうし。)

それは別に無知であるわけでも意地悪しているわけでもありません。

最適解を得るための情報が少なすぎるのです。

最適解を得るためには、
事細かな情報が公開されるか、
内部の人が気がつくしか無いと思います。

情報公開なんてまずされないでしょうから、
優秀な人が内部にいる必要があるでしょうか。

でも優秀な人が内部にいたら、
そもそも問題が起きないか、最小化されているはずです。

つまり問題を起こしたシステムの持ち主が答えを得ることはないわけです。
情報公開しない限りは…ですが。

ポカを繰り返している企業は、
結局これの堂々めぐりなんじゃないでしょうか。

やっぱり色々あるのかな

ここ最近この記事の閲覧数が妙に増えたな～と思っていたら、
JVNに乗ったことがニュースになっていたのですね。

もう今となっては過去の話なので、
こちらとしてはなつかしいな～というのが率直な感想です。

記念にもう少しつっこんだレポートでも上げたいところですが、
これが入っている派遣先から抜けたのでもう調べることができません。

…でもあの件はどうするのかな？

まだあの件が対応できそうなアップデート情報は見てないのですが、
派遣先から抜けて情報が入っていないだけかな？

派遣先にいる人に今後聞いてみましょうかね。



ヒント

バトルロイヤルだとなぜか勝利できる

遊戯王は2人対戦のゲームなのですが、
人数が中途半端なときはバトルロイヤルルールで遊んだりします。

公式なルールがあるわけではありませんが、
１順目は攻撃不可だったり、
１順目の最後の人だけ攻撃可能だったり、
そのあたりだけ決めれば結構遊べます。

それで何度か戦ったことがあるのですが、
自分のデッキはというと…

【倍プッシュ】
【気まぐれムズムズワンキル】
【マドルチェ(ハイランダー寄り)】

と相当なファンデッキです。

「無理だ…勝てるわけがない…」
と言いながらデュエルしてみたわけですが…



…なぜか勝ち残ってしまうんです。

序盤は弱くて相手にされず、
中盤も弱くて相手にされず、
終盤で一騎打ちになるとなぜか勝つ。

そんなパターンができあがっていました。

確か口八丁で自分へ攻撃するメリットの無さを説いて、
致命傷を避けていたような気がします。

つまり、
自分はデッキが弱いことで心理アドバンテージを得ていたわけです。

心理フェイズ最高！

心理フェイズを楽しみたいなら、
ぜひともバトルロイヤルルールで遊んでみよう！
※友情が破壊されても自分は責任を負いかねます

名著を読んでいないことがまずいわけではない

自分はこのブログにて、
名著を読むことをそれとなく薦めています。

ただ薦めてはいるんですが…
本当に大事なのは名著を読むことではないと思っています。



確かに名著には大事なことがたくさん書かれています。

しかしそれは読めるだけの頭があれば単純な知識であって、
知ってしまえばその応用は本人次第です。

名著を読むことそのものは、
有用な知識が少し増える程度でしか無いのです。



じゃあ何がまずいかと言うと、
自力で名著にまで至っていないところです。

インターネットで日々情報収集を繰り返していれば、
いずれは名著の存在に何らかの形で行き着きます。
(ハンターがいずれ念能力にぶつかるような感じ？)

そして名著を前提とした話に付いて行く必要性を感じ、
重要そうなものから順に手を付けていくわけです。



つまりそれができていないということは、
ろくに努力をしていない人間か、
努力の方向音痴をしている人間か、
そもそもまるで才能がない人間かのいずれかである可能性があるのです。

少なくとも、
条件反射でm9(^Д^)ﾌﾟｷﾞｬｰと言われるくらいには。



名著を読めとは強く言いません。

ですが、なぜ名著に行き着かなかったのかについては考えてください。

「今の業務では必要ないから…」は検討違いなのです。

これらは今使うものではなくて、
自分の地力を上げるものだからです。

それを否定することは、
スポーツ選手に筋肉は要らないと言っているようなものです。



お願いです。

まずはどんな名著があるのか調べてみてください。
※冊数の多さと本の分厚さに心が折れても責任は持てませんが。

フォームを見せずにLoadイベントを起こすには

VB6からVB.NETへの移行を行なっていたのですが、
VB6でできたフォームを表示しないでのLoadをどうしようかと考えることになりました。

Loadイベントの中身をコンストラクタに移動すれば良い気もしますが、
どうにも不安が拭えません。

ということで無理やりこんなメソッドを作りました。

Public Sub LoadHidden(ByRef target As Form)
    Dim tempLocation As Point = target.Location
    Dim tempStartPosition As FormStartPosition = target.StartPosition
    Dim tempShowInTaskbar As Boolean = target.ShowInTaskbar
    target.StartPosition = FormStartPosition.Manual
    target.ShowInTaskbar = False
    target.Location = New Point(-target.Width, -target.Height)
    target.Show()
    target.Hide()
    target.StartPosition = tempStartPosition
    target.ShowInTaskbar = tempShowInTaskbar
    target.Location = tempLocation
End Sub

動作としては、
画面の外で表示してすぐ消すことでLoadイベントを発生させています。

あらかじめ言っておきますが、
こんなメソッドには頼らない方が望ましいです。

m9(^Д^)ﾌﾟｷﾞｬｰ

と思って読むくらいが丁度良いですね。

自分が痛覚過敏ではないかと疑うエピソード

ちょっと乾燥したところで作業していると、
いつの間にか静電気が蓄積されていきます。
(表現がおかしいかもしれませんが、まあ置いといて。)

そしてドアノブをそのまま触れると手痛い思いをするので、
爪でドアノブを弾いてそれを回避しようとします。

爪には痛覚が無いので、
放電しても問題ないわけ…なんですけど。

自分の場合は爪の奥に衝撃が走って、
役にたっていなかったりします。

「アババババババ…！」

皆さんも同じであれば良いのですけど。

今度誰かに聞いてみましょう。

Wordの代替が無いからってExcelで文書を作らないで〜

前の記事でExcel方眼紙を話題に出して思い出しました。

ビジネス文書を作るのにExcelで作る異形の方々の存在です。

学習コストが高くなるのは間違っていませんが、
それ以上に保守性を下げている気がするのは気のせいでしょうか？

ExcelでWordよりも保守性を出せるような人もいるでしょうが、
それこそ学習コストがかかっているのではないでしょうか。

見出し関連の機能だけで自分の中ではExcelを作るよりずっと楽なんです。

目次の自動反映すらExcelではややこしくなるのですが…
(そしてExcel好きは自動反映すらせずに手入力しているという謎。)

それならメモ帳で全角スペースで整形していた方がマシではないでしょうか。

あ、画像を入れたいのか。

ならもうペイント使ってよ…

いや、
Excelで作るのはいいけどそれを押し付けないでよ…

新しいSIerの姿はアイマスのアイドル事務所みたいな形がいいのでは？

従来のSIerの形に対しての問題点については、
実に数多くの記事があります。

実力が低いほど利益が出る人月による見積り、
多重派遣構造による利益搾取、
「人月の神話」を完全無視したプロジェクト管理、
挙げればきりがありません。

どれだけ不幸を呼び込んでいるのかはわかっていても、
そのあたりを国が主導で実施しているので滅びない…

責任をなすりつけるのがうまい人だけが生き残る…

何とか既存のSIerを廃し、
新しいSIerを創造しなくてはならない！



ちょっと前までは滅べばいいとだけ思っていましたが、
需要が無くなることは無さそうなのもまた事実です。

つまり新しいSIerの姿を模索できなければ、
いつまで経っても不幸の連鎖は止まらないということです。

まったく新しいものを考えるのは難しいので、
とりあえず既存のものから相性が良さそうなのを輸入してみましょう。



そこで目をつけたのがアイドルマスターです。
(先に言っておきます。
自分の知識はアニマスとノベマスから来てます。
ゲーム版の方はそこまで詳しくありません。)

プログラマーの実力差を考えれば、
皆を一様に扱うのは不可能である現実に目を背けてはいけません。

そしてお客様が個人を指定できるのであれば、
自然とレベルの高いプログラマーに指名が集中するのではないでしょうか。




レベルの高いプログラマーはそこから仕事を選べます。

単価も上がります。

仕事が選ばれなかったお客様には、
なぜ選ばれなかったのかを説明すればお客様への啓蒙につながります。

Excel方眼紙を使うお客様には、
Excel方眼紙を嫌うプログラマーが寄り付かない方がお互いに幸せなのです。

逆にレベルの低いプログラマーは営業活動が必要になります。

仕事も選べません。

単価も下がります。

なのでレッスン(という名の勉強やプログラミング)をしてレベルを上げる必要があります。

プロモーションビデオ(という名のオープンソース)を作成するのもいいでしょう。

資格と取って受けをよくする手もあるでしょうが、
地力が無ければ次の仕事に繋がる人気は出ないことには気をつけましょう。



一緒に仕事をさせると相乗効果が発生するメンバーがいるのなら、
ユニット(という名のチーム)を組んで一緒に仕事を受けさせましょう。
※このあたりはデマルコの本でも読めばその大切さがわかります。

多分4〜5名くらいで、
きちんとしたリーダー(という名のプログラムマネージャー)が居れば完璧です。

ピンで仕事をさせるよりも、
ずっと成功率が高まることでしょう。



待遇に不満があれば移籍(という名の転職)をしましょう。

レベルの高いプログラマーは、
レベルの高いプログラマーが在籍する事務所に集まって仕事をするべきです。

というよりも、
レベル差が大きすぎると低い方が足を引っ張ってしまいがちなのです。

安くてレベルが低いか、
高くてレベルが高いかは明確であるべきです。



そんなプログラマーを活かすも殺すも、
プロデューサーのあなた次第です。

プロデューサーはプログラマーやプログラムマネージャーをどんどん売り込みます。

個人の見えない状況では単価や資格でしか売り込めませんでしたが、
個人であればアピールすべきポイントはたくさんあります。

ソースコードを見せるのもいいです。

過去の案件のエビデンスベーススケジューリング結果を見せるのも良さそうです。

あとはそう、
その人の周囲からの評価を集められる仕組みが必要です。

何と言っても、
新しいSIerはこの人やこのチームがいれば成功すると思われる「人気」さが一番なんですから。



プログラマー、
プログラムマネージャー、
プロデューサー、
この3種類の人材で回すのが新しいSIerの形です。
※おそらく１０：３：１くらいの比率が良いと予想しています。

SE(笑)なんて曖昧な言葉でお茶を濁さずに、
はっきりとした役割を与えて仕事をしてもらいましょう。

SIerに勤める多くの方が職を失うかもしれませんが、
健全な人数になったと考えましょう。

もし自分のレベルが足りずに職を失ってしまったら、
それはキチンを受け止めることにします。



…まあ、
それをやるために変えなきゃいけない箇所が多すぎるのが問題なのですが。

国外で立ちあげてから日本を侵略した方が早い気がします。

追記：アイマスで分かるプログラマがメタファーとしては同じかな？

自分が転職した理由

４月はほとんどブログを更新できませんでした…

というのも今までいた会社を３月いっぱいで辞めまして、
４月から新しい会社に移ったからです。

いわゆる引き抜きに相当するんでしょうか？

待遇面を上位互換にするから来てくれないかと誘われたわけです。

転職エージェントに愛想を尽かし始めていたので、
丁度よいタイミングだったと言えます。

ということで転職を決意したわけですが、
当然前の会社から色々を聞かれるわけです。

その中のお話で驚いたのは、
派遣先の引き抜きではないことを強く確認されたことです。

派遣先の関係ではなかったわけなんですが、
派遣先からの引き抜きは道義に反する行為なんだそうです。

人材も資本と同じように循環するべきだと考える自分としては、
まったく考えたこともない話でした。

よく親からは派遣先から誘われないのかと聞かれていましたが、
そういう事情が裏側であった…のかもしれなかったのかも？

…いや、それが言いたいんじゃありませんでした。
（いつもそんなこと言ってますね。）

その時に退職の理由を聞かれたわけなんです。

まあ単純に上位互換だったからなわけなんですが、
そう説明するには気が引けます。

その場は何か適当なことを言ってお茶を濁してしまいましたが、
自分の心情を整理する意味でもきちんと説明できた方が良いと考えなおしました。

前の会社で一番気に入らなかったところはなんだったのか…

やはりパフォーマンスレビューでしょうか。
　
あの仕組みはアメとムチ戦略の延長線でしかなく、
創造性を重んずるプログラマーとの相性は最悪です。

底上げはできるかもしれませんが、
天井も作ってしまっています。

天井に近い人ほど損をするので、
成長するき気なら天井に対して何らかの対策が必要になってしまいます。

そんなもののために労力を割くくらいなら、
始めから天井の無い世界にいたほうが効率的です。

前の会社では大したことのない目標のために、
プライベートの時間を精神的に圧迫されていました。

かといって本物の目標を使ってしまっては、
モチベーションが報酬に置換されかねないのでリスクが高過ぎます。

これは会社には優秀なプログラマーなど必要ないという、
強いサインの現れと言えるのではないでしょうか。

まあそれが会社の戦略というのであればそれもありだとは思いますが、
どうも会社がそのデメリットを理解していなさそうなのには一抹の不安を覚えます。

このあたりの話は「モチベーション3.0」がよく説明されていますが、
その話をして感覚的に理解されたことはありません。

創造性はそんなに世間からみて特異なものなんでしょうか？

少なくともプログラマーには大量に居てもらわないと未来が見えないのですが…