読者です 読者をやめる 読者になる 読者になる

文字の洪水に溺れながら

人生初心者、でも人生のハードモードぐらいを生き抜きたい人間。

組織の中で評価されるコストパフォーマンスの良い課題

本記載の目的

MBOシートを書かなくてはいけなくなったので、 とりあえず頭の整理がてら何を課題とすべきかの 決定思考のポイントを一旦文章として整理する。

概要

コストパフォーマンスが良い課題は 「課題として顕在的で、解決が難しいと考えられていて、解決が簡単なもの」 「課題として潜在的で、解決が簡単なもの」 である。

詳細

組織で良い評価を出すために重要なものは課題だ。 知っての通り定常業務を回していても良い評価は出ない ※余談だが、成果と評価を混同してはならない。  今回はあくまでも評価を上げるためのテクニック論で、  組織に真に貢献する成果を目指すなら効果という観点が加わる。

課題には何個かパターンがある。

パターン分けをする観点は

 ・顕在的/潜在的

 ・一般的な困難度の感覚値

 ・事実としての困難度

つまり列記すると

1.課題として顕在的で、解決が難しいと考えられていて、解決が簡単なもの

2.課題として顕在的で、解決が難しいと考えられていて、解決が難しいもの

3.課題として顕在的で、解決は難しくないと考えられて、解決が簡単なもの

4.課題として顕在的で、解決は難しくないと考えられて、解決が難しいもの

5.課題として潜在的で、解決が簡単なもの

6.課題として潜在的で、解決が難しいもの

となる。

この中で評価値が高くなる順で記載すると

1=2≧5=6≧3=4

※属す組織によって5=6の場所は異なりえる。

更に問題の解決にかけるコストは2より1の方が少なくて済むし、 同様に事実としての解決難易度から4より3、6より5であると考えられる。

以上からコストパフォーマンスの良い順を定義すると 1≧5>2≧6>3>4

つまり

1.課題として顕在的で、解決が難しいと考えられていて、解決が簡単なもの

5.課題として潜在的で、解決が簡単なもの

2.課題として顕在的で、解決が難しいと考えられていて、解決が難しいもの

6.課題として潜在的で、解決が難しいもの

3.課題として顕在的で、解決は難しくないと考えられて、解決が簡単なもの

4.課題として顕在的で、解決は難しくないと考えられて、解決が難しいもの

となる。

ここでポイントとなるのは2つ。

1つめ:5の、課題として潜在的であるものは、アピール次第で1にも3にも転ぶ可能性がある。そのためオープンの仕方は気をつける。
2つめ:3に飛びつかない。解決が簡単だからといって飛びついても、そんなことより本業しろの流れに陥る。

自分自身の特性としては、あとは自分にとってその課題が真に課題であると腹落ちすることが必須だと思うが、 それはコストパフォーマンスが良いかどうかとは別の観点なのでまたの機会に記載する。

書くこと、読むこと、考える事

突然の復帰

2年ぶりにブログを書く。 理由はわからない。新年だし、この2年も色々とあったし、一度整理したいと思ったのかもしれない。 とにかく文章を書きたくなった。理由はいくらでも書けるけど、ただ書きたくなっただけだ。

この2年であったこと

結婚した、転職した、遊んだ、話した、実行した。 読んだ、旅行した、書いた、作った、苦しんだ。 もう色々とありすぎて1つの記事にするのが恐れ多い。 折を見て一つ一つの事実を丁寧に紐どいていきたい。 本当に日々記録しておかないと2年という期間はあまりに長すぎる。

それにしてもこの2年で歳を取ったと実感する。 大学生の時のあのハングリーさ、何でも出来るという全能感、 こんなはずではないというルサンチマンさは最近とても薄くなってきている。 やはり、まだ27にも関わらず守りに生き過ぎている。 人生ハードモードに挑戦したいという誓いはどこに行ってしまったのか。

2016年に心がけたい在り方

これはタイトルのとおりだ。 今年は 書くこと、読むこと、考える事 が心がけたい在り方としよう。 ちなみに去年は 話すこと、実行すること、遊ぶことが結果的な在り方だった。 webが情報源であるかぎり仕方ないが、去年は雑多な情報で享楽を得すぎた。 もう一度ハードに自分を追い詰めて骨太な芯の構築を試みる必要があるだろう。

  • 書くこと
    文章力が落ちた。人に魅力的と思わせる文章力が明確に落ちた。 特に長文の文章力の低下が著しい。 当たり前といえば当たり前か。 書くことは仕様書という名詞の羅列か、メールの定型文ぐらいで、 プレゼン資料も文章力ではなくキャッチコピーでのりきっているのだから。 目標は立てないが、昔みたいに思考をそのまま書き記して、 少しづつ書くことに対してリハビリをしていかないと。

  • 読むこと
    情報は摂取している。しかし、摂取している情報が良くない。 去年読みきった書籍はいったい何冊だ? 片手で足りるのではないだろうか。 時間は2年前と比べて明らかに増えたのにこの体たらくは酷い。 書を読むことの楽しみを忘れてしまったようだ。 読むことは楽しいという事実をもう一度思い出さないと。

  • 考える事
    ここは上2つと比べて難しい。 何故なら考えることよりも実行する方が効率的だと理解したからだ。 実行してFBを得ながら軌道修正する方が圧倒的に物事は上手く進む。 取らぬ狸の皮算用という言葉は思った以上に至言だ。 その意味で考える事は去年も日々していた気がする。 ただし、足りないと感じている考えることはもう少し違う。 腑に落とすほど考える、昔好きだった思考・論理・分析でいうところの 理解し切るため考えるこれが足りていない。 自分の脳の血肉とする感覚をもう一度味わいたい。 この飢餓感が考えるという行為の意味に含まれている。

とりあえず一旦こんなところで切り上げよう。 さて今年はどんな年になるのだろうか。

Java:StringUtilsのsplit関数を使う際に気をつけること

この間コードを書いていたら発生した勘違いを忘れないうちにメモしておきます。
簡単にいえば、splitのseparatorは複数文字は対応していないという事です。

import org.apache.commons.lang.StringUtils;

public class Split {

	public static void main(String[] args) {
		String tagert  = "ABCDEFG.ABCDEFG";
		String separator  = "FG.";
		

     System.out.println(”split利用時”);
		String[] argFromSeparator = StringUtils.split(tagert, separator);
		for (int i = 0; i < argFromSeparator.length; i++) {
			System.out.println(argFromSeparator[i]);
		}

     System.out.println(”splitByWholeSeparator利用時”);
		String[] argFromWholeSeparator = StringUtils.splitByWholeSeparator(tagert,separator);
		for (int i = 0; i < argFromWholeSeparator.length; i++) {
			System.out.println(argFromWholeSeparator[i]);
		}

	}

}

このコードの実行結果は以下のとおりです。

split利用時
ABCDE
ABCDE
splitByWholeSeparator利用時
ABCDE
ABCDEFG

splitの方は判定をcharで行うので、2つ目のFGまで切断子として認識され消えます。
一方のsplitByWholeSeparatorの方は、2つ目のFGは切断子としては認識されないため残ります。

問題なのはsplitで渡せる引数がStringなので
複数文字列を渡してもコンパイルができちゃうことです。
僕はsplitByWholeSeparatorの存在を知らなかったので、
下手な勘違いをして問題解明に思った以上の時間を使ってしまいました。

結論としては
「Utilを使うなら中のコードまでしっかり追いましょう」
という当たり前の事でした。

勘違い怖い。

Google App Engine をEclipseに何とか導入するの巻

最近、mac環境でずっとEclipseへの
Google App Engine導入に苦しんでたのだけど
やっとこさ成功したので記念メモ。

Eclipseへの導入はいっぱい参考資料があった
https://developers.google.com/eclipse/docs/download
https://developers.google.com/appengine/docs/java/tools/eclipse?hl=ja
http://www.mkyong.com/google-app-engine/google-app-engine-hello-world-example-using-eclipse/
その他日本語解説ページも多数

ちなみにEclipse4.2(juno)への導入の公式ドキュメントは
日本語はありませんが英語のドキュメントには存在しています。
https://developers.google.com/eclipse/docs/download

これら通りに行なって僕もGAE(GoogleAppEngine)を動かしてみるぞ−と息巻いていました。
最初は・・・。

困ってた症状:サンプルコードなのに動かない!?

ここから実際にプラグインを導入してサンプルプロジェクトを
立てるだけなのにビルドに失敗するという謎現象に苦しむことになります。

Exception in thread "main" java.lang.NoClassDefFoundError: com/google/appengine/tools/enhancer/Enhance
Caused by: java.lang.ClassNotFoundException: com.google.appengine.tools.enhancer.Enhance
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

過程は端折りますが色々とさまよい歩き、
結局、JRE環境変数がおかしいのではないかというあたりが付きました。

自分のmacは何のjre参照しているんだ!?

ひとまず自分のMacが利用しているjreのバージョンをチェックするためにコンソールで

java -version
javac -version 

を行なってみると"1.7.0_21"と表示されています。

しかし、問題はEclipseはどうやら別のjreを参照してしまっているらしいこと
プロジェクト右クリックからのビルドパス
MacOS DefaultのSytemJREをダブルクリック
>EditLibraryからAlternateJREの右側のInstalledPath
>PreferenceにてJVMcontentsのEdit
によって1.6系のJREを参照してしまっていることがわかりました。

つまりMac事態のJREEclipseMacOS DefaultのSytemJREが違うものになっていた事が問題だったようです。

(後々調べてみると、HD直下のライブラリの中のJAVAディレクトリと
 HD直下のシステム下のライブラリの中のJAVAディレクトリと2つ有ることが発覚しました。)

Eclipseの読み込み時の環境変数を書き換えよう

ということでEclipseの読み込み時の環境変数を書き換えることにしました。
http://d.hatena.ne.jp/MonteCut/20111121/1321885785
を参考にしつつ、読み込み時の環境変数も1.7.0_21(最新版)の方にPATHを通します。

この時はまったのが以下の表記
アプリケーション>ユーティリティ>Java Preferences

調べてみるとJava for OS X 2012-006から無くなったようです・・・。
https://discussionsjapan.apple.com/thread/10119956?start=0&tstart=0

代わりにシステム環境設定のJAVAコンポーネントを利用しました。

ついに動いた!!

そうしてEclipseをZIP展開からやり直し→JAEを再びインストールをすると
ついに念願のノーエラーでサンプルコードが動きました!!


とにかくコードを書くための環境設定が大変だと感じた今回の出来事
前から思っていたのですが、初心者がプログラムを自習するために一番問題になるのは
コードの動き方とかではなくて動かすために必要となる環境の設定ですよね。
簡単な事をするためにある程度の知識が必要というジレンマを何とかしたいものです。

とにかく、これで明日から憧れのGAEで開発が出来ます。

macでJava7をダウングレードする

GoogleAppEngineを試そうとしたら、
Java7だと対応していないとの旨を見つけてしまった。
既に入れてしまっていたよ・・・。
しかもmacだからあんまり情報上がってないだろうし・・・。

ということでダウングレード方法を探してみたらOracleの公式に有りました。
http://www.java.com/ja/download/help/mac_uninstall_java.xml

Java:排他制御がかからないと失敗するサンプルコード

必要にかられてせっせこjavaを勉強しています。

最近はマルチスレッドの学習を進めているのですが、
理解がイマイチなので今まで理解したところをメモ。
テキストは独習JAVA 9-3

テキストにはサンプルコードとして正しいものしか
書かれていないので理解に苦しみました。
なので駄目な方も書いてみたらだいぶ理解が進みました。
やはり詰まったら何事も手を動かすことは重要だね。

以下のコードでSynchronizedをつけたコメントアウトしてる方のコードは問題なく値は定まるが、つけていないほうで実行すると値は定まらない。

何故ならばdepositメソッドがロックが掛かっていないと、並列処理中に2回やったはずなのに1回分がなかったことにされる事が発生してしまうから。
詳細はパーフェクトJavaの図16.3で書かれている。

package main;


public class Account {
	private int balance = 0;

	void deposit(int amount){
		//	synchronized void deposit(int amount){

		balance += amount;
	}

	int getBalance(){
		return balance;
	}
}


class Customer extends Thread {
	Account account;

	Customer(Account account){
		this.account = account;
	}

	public void run() {
		try {
			for (int i = 0; i < 10000; i++) {
				account.deposit(10);
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

class BankDemo{
	private final static int NUMCUSTOMERS = 10;	
	public static void main(String args[]){

		//口座の作成
		Account account = new Account();

		//スレッドの作成と起動
		Customer customers[] = new Customer[NUMCUSTOMERS];
		for (int i = 0; i < NUMCUSTOMERS; i++) {
			customers[i] = new Customer(account);
			customers[i].start();
		}

		//スレッドの完了を待機する
		for (int i = 0; i < NUMCUSTOMERS; i++) {
			try {
				customers[i].join();
			} catch (Exception e) {
				e.printStackTrace();
			}
		}

		//口座の残高を表示する
		System.out.println(account.getBalance());
	}
}

いまいちまだわかっていないのはSynchronizedブロックを利用する際にどこのスコープでブロック指定を行えばいいのかという点。
たとえば、上記のコード内のmain関数を

	public static void main(String args[]){

		//口座の作成
		Account account = new Account();

		synchronized(account){
			//スレッドの作成と起動
			Customer customers[] = new Customer[NUMCUSTOMERS];
			for (int i = 0; i < NUMCUSTOMERS; i++) {
				customers[i] = new Customer(account);
				customers[i].start();				
			}

			//スレッドの完了を待機する
			for (int i = 0; i < NUMCUSTOMERS; i++) {
				try {
					customers[i].join();
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		}

		//口座の残高を表示する
		System.out.println(account.getBalance());
	}

とaccountをロックしていても値は定まらない。
だけどrun()の方を以下のようにSynchronizedブロックを行うと値が定まる。

class Customer extends Thread {
	Account account;

	Customer(Account account){
		this.account = account;
	}

	public void run() {
		try {
			for (int i = 0; i < 10000; i++) {
				synchronized(account){
					account.deposit(10);
				}
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

ここら辺を説明できるようにしておくこと

燃えよ剣(上)の読書感想 アンチ土方の立場から

燃えよ剣(上)

燃えよ剣〈上〉 (新潮文庫)
司馬 遼太郎
新潮社
売り上げランキング: 1841
正直な話をして、私は土方を好きになれない。
上巻のみを読んだ感想は素直にこのようなものだ。

この本を読まずして漢を語るのははばかられる。
そう思って齢24になって読んでみたが、
少々読むのが遅すぎたのかもしれない。

ファンの方には「この腑抜けもの!」
と馬鹿にされるのかもしれないが、
土方の暴力的で自分勝手、
自己のあり方に自信を持ち、
それが守られなければ殺人までもを
犯していく彼の心は理解しがたかった。
いや、正確に言えば理解は出来るが、
理解したくなかったというのが本音のところだ。

おそらくこのような感情を持ってしまうのは、
死というものをフィクションの中でしか感じられない
平和な日本で育ってきたからだろう。
短絡的(と私は感じてしまう)に、
国学者を胡散臭い人間として死の懲罰を与えていく
彼の姿は、不快感すら感じてしまった。

また個人的には土方には思想というものを
軽視していたことに憤りを感じたのだとも思う。

私は行動によってのみ生きていく生き方が苦手だ。
何事も先に理と利を考えてからしか行動できない。
そんな生き方を少なくとも四半世紀続けてきた自分には、
信念を持って人生を道具として生きていく彼の姿には
理解不能の恐ろしさしか抱けなかったのだ。

上巻までは土方無双だったのも気に入らない点だったのかもしれない。
どうしても私は夢想している人物にその理由を求めすぎる癖がある。
上巻まででの土方の描写では私の中では、
その強さの理屈が説明されているにいたらなかったと感じてしまった。
もっともこれもまた、単なる理屈の話でしかない。

下巻に入り彼の人間的魅力を再発見できるかどうかが、
この本を感情的に好きか嫌いかを分けるだろう。

彼の常軌を逸した自己の信念の強さの信奉といった
おそらく評価すべき点を全て無視した感情論を書いてしまった。
改めてファンの方には謝罪をしておく。

話は飛ぶ。

ここまで書いてきて、
なぜ、土方をここまで毛嫌いしながらも、
今までに読んできた似たような行為の人物は
私は肯定できていたのだろうか?

例えば桶狭間戦記で松平広忠を見殺しにした今川義元
例えば北方三国志曹操やFateZeroの切嗣
そんな彼らは自己の信じる信念のもとに、
数々の障害者を断罪し、殺害してきた。

いったい土方に感じているこの不快感とは何がちがうのだろう?

この部分は改めて自分の中で考えておくべきだとは思う。

今の私の落とし所は
・主体者がその行為は残虐なものだという自覚があるか
・主体者がその行為に自信を持ってしまっているか
の2点において違いがあるという思っている。

私が今まで、そのような信念ゆえに多くの悪を為した場合、
感情的な自己への嫌悪感を持ちながらも
信念のために否応なく実行せざるを得ないがために行なっているか
という点が胸を打つ大きな原因であった

平たく言えば悩んでいるのである。

しかし、(あくまでも上巻での)土方は全く悩まずに、
自分の信念のもとに邪魔なものを排除している。
ここが私の中の不快感につながっているように感じている。

この点はもう少し考えてみるべき題材だとは思うが今日はこのへんにしておいて、
明日からの下巻の内容に心を踊らせながら眠るとする。