休日出勤で不覚。

何というか、自由に振舞えないんですよ。で、どの辺が自由でないかというと、プロジェクトにとって良いと思われる方策をとれない。彼らは彼らなりのやり方があるのもわかっている。それこそ歴史ある大企業なんで、積み上げてきたノウハウも半端じゃないのもわかっている。だけど官僚的な上下関係によって、非効率になっている部分が目について仕方なくて。

sugar自身はそれを変える気もありませんでした。
が、sugarが主導的な立場に立ってプロジェクトを進めようとする時に問題が。。

sugarが育った土壌が彼らと違うのもあるのですが、彼らと全く同じ方法ではできない。だって、非効率ってわかっていることをするなんて、デスマるのが火を見るより明らかだし。

んでんで、それに対して「それなら相手にきちんと説明して理解してもらえばいいんでないか」というのが自然な流れだけど、それができない２つの理由があるのです。

まず第一に、自分自身が開発プロセスを熟知していないこと。漫然と「こうした方がいい」と思うことはあっても、そこに根拠を示せない。なぜ示せないかというと、自分がやろうとしている方法の論理的な裏づけを説明できる知識が無いからです。

第二の理由は、彼らの開発プロセスを熟知していないこと。これを知っていないと、そもそも自分の提案する方法と、彼らの方法を比較しようがない。なので彼らの「これこれこうすべきだ」という主張に対して「あぁそうですね…」としか言いようが無いわけで。

端的に「ここが駄目だからこうすべきでしょう」と指摘できても、プロセスの前後のつながりも含めて指摘できないことには、トータルでこちらの提案するプロセスが優れていることを理解してもらえない。結局、ストレスを感じつつも彼らの方法に従ってますが。

自分の感覚と相反する方法で仕事を進めるのは、非常にストレスを感じますが…ストレスの軽減という面でも開発プロセス…システム開発の知識は重要だということですね。

逆に言えば、自分の感覚に逆らわず開発をすることができたら…そんなstresslessな仕事はとてもhappyなのだと思います。それをするためには正しい知識と、それを相手が理解できるように説明できる能力が必要なのでしょう。

余談ですが、知識の無さをカバーするために詭弁を語ること（※１）、という一つの解決策があります。しかしそれは、その場は丸くおさまっても、長い目で見るとデメリットの方が大きいでしょう。

詭弁による説得は、相手に不信感しか与えられないからです。誠実ではない。これはさんざん詭弁で騙されたことがあるsugarだから分かるのですが…詭弁を語る人たちは相手に不信感を与えていることに気づいてるのでしょうか。。

※１　詭弁による説得は、悪い意味で、営業的とかＳＥ的とか言われたりもします。

追いたくなくとも追わねばなるまい

2005/7/26 2020/10/7 外勤先バトル

今回はソースコードを記述しているので、プログラミングと関係の無い方にはわからないと思いますが、ご容赦を。

追っ手から逃れるシステム（きしだのはてな）を見て。過去に、それらの逃げ手の手口にことごとくハマったsugarballですが、今回はsugarが遭遇した逃げ手の手口を紹介します。

■参考リンク
http://d.hatena.ne.jp/nowokay/20050702#1120324360
http://d.hatena.ne.jp/nowokay/20050706#1120597321
http://arton.no-ip.info/diary/20050703.html#p01

インデックスiとjで二重ループをまわし、要素jについて0～8まで別々の処理をしているだけなのだが…

for (int i = 0; i < dataNum; i++) {
if(i == 0) continue;
for(int j = 0;j < 8; j++){
try{
（絶対catch句に行くような
データが入ることがある処理）
}catch(NumberFormatException nfe){
if(j == 0){
（j == 0  の場合の処理）
}
if(j == 6 || j == 7){
if(条件Ａ？){
if(j == 6){
（j == 6  の場合の処理）
}else if(j == 7){
（j == 7  の場合の処理）
}
}else if(条件Ｂ？){
if(j == 6){
（j == 6  の場合の処理）
}else if(j == 7){
（j == 7  の場合の処理）
}
}
}
continue;
}catch(Exception ee){
System.out.println("例外です!!:" +
オブジェクトをtoString);
continue;
}
if(i > 7) continue;
if(j == 2 || j == 3){
if(条件Ａ？){
if(j == 2){
（j == 2  の場合の処理）
}else if(j == 3){
（j == 3  の場合の処理）
}
}else if(条件Ｂ？){
if(j == 2){
（j == 2  の場合の処理）
}else if(j == 3){
（j == 3  の場合の処理）
}
}
}else if(j == 4 || j == 5){
if(条件Ａ？){
if(j == 4){
（j == 4  の場合の処理）
}else if(j == 5){
（j == 5  の場合の処理）
}
}else if(条件Ｂ？){
if(j == 4){
（j == 4  の場合の処理）
}else if(j == 5){
（j == 5  の場合の処理）
}
}
}else if(j == 6 || j == 7){
if(条件Ａ？){
if(j == 6){
（j == 6  の場合の処理）
}else if(j == 7){
（j == 7  の場合の処理）
}
}else if(条件Ｂ？){
if(j == 6){
（j == 6  の場合の処理）
}else if(j == 7){
（j == 7  の場合の処理）
}
}
}
}
}

見にくすぎる。ツッコミ所を挙げるとすると
①条件Ａと条件Ｂの判定を何回やってんのよ？
②catch句の中で普通に処理すんなよ
③とゆーか、catch句に入るのが前提ってソレは…
④なんか似たような判定ばっかだ。まとめなさい。
⑤とにかく見にくい。というより醜い。

その後日、このロジック内で不具合が発生したので、偶然（というか必然）、sugarがこのコードを修正することになりました。まぁ、仕事でなければこんなコードはドブにでも捨てた方が世のためになるし、見るのも触るのも本気で嫌だったのですが、仕事だから直すしかないわけで。あぁ、サラリーマンはツライね。というわけで、修正したコードが下のやつ。

if(条件Ａ？){
processA();
}else if(条件Ｂ？){
processB();
}


…
…

////////////////////////////////////////
// 条件Ａのメソッド
private void processA(){
for (int i = 0; i < dataNum; i++) {
int j = 0;
///////////////////////////////////
// j = 0 の場合
（j = 0 の場合の処理）;j++;
///////////////////////////////////
// j = 1 の場合
（j = 1 の場合の処理）;j++;
///////////////////////////////////
// j = 2 の場合
（j = 2 の場合の処理）;j++;
・・・  j = 3～7 も同様  ・・・
///////////////////////////////////
// j = 8 の場合
（j = 8 の場合の処理）;
}
}
////////////////////////////////////////
// 条件Ｂのメソッドも同様に…
private void processB(){
…
}

まず条件Ａと条件Ｂで関数分けして、if…else…で分岐していた処理をインデックスのインクリメントで対応しました。わー、面白いほどスッキリ。

やはりこの前者のコードを書いたのもこのときの彼だったりします。で、sugarが後者のコードに修正すると彼は

「sugarさん、凝ったことしてますねぇ」

いや、シンプルにしただけなんで。

sugarが勤める外勤先ではその彼はJavaのスペシャリストとして他の会社に出向したことがあるらしく…この職場、大丈夫か？と思うsugarでした。いや、むしろ辞めたい。

とにかく、キレイなソースコードを書くことは大事なのです。そんでもって、ソースコードを整理するための指標としても使えるのがこの本。オススメです。ちょっと高いけど、値段に見合った価値はあります。

ガデュリン

自航惑星日記

休日出勤で不覚。

こっそり

移転、ほぼ完了

ストレスの無い開発

追いたくなくとも追わねばなるまい