普通の人はプロスポーツ選手のような卓越した技術力があるわけではないですし、普通の企業にはGAFAのような世界を変える技術があるわけではありません。
そんな普通の人や普通の企業が、特別な人や特別な企業に負けずに市場で生き残るための道を完結にまとめました。
１．ニッチな役割を果たす
特別な人や特別な企業はほんの一握りであるため、特定の人や特定の企業に対するきめ細やかなサービスは提供できません。
そこで、特定の人に感動を与える、特定の企業に特化したサービスを提供する、といったニッチな役割を果たすことが、生き残る道の一つとして考えられます。
例えば、町のおもちゃ屋さんとして近所の子供におもちゃで遊ぶ楽しみを提供する、特定の企業に対してオーダーメイドのシステムを提供する、といった具合です。
２．供給より需要が多い市場に混ざる
供給より需要が多く、常に人手不足になっている業界があります。
現在は、IT業界、建設業界、介護業界等で人手不足が深刻になっています。
そのような業界では技術に多少難のある人・企業でも育てて使わざるを得ないので、そのような業界に飛び込むことが生き残る道の一つになります。
単純に人手を提供するのみでなく、人手を削減できるシステムやAIを開発するという方法でも飛び込むことができます。
３．指導的役割を果たす
普通の人でも指導的な役割を果たすことはできます。
例えば、学校の音楽や体育の先生はトッププロではありませんが、生徒を指導し、技術を学ぶきっかけを与えることはできます。
生徒が師を抜いて特別な技術を持った人に成長することもありますし、そこまで行かなくとも一定の技術と技術を学ぶことによる感動は与えられます。
４．複数の技術を組み合わせる
例え100人中1人程度の技術でも、それが２つ組み合わされば10000人中1人の存在になれます。
特別ではないけど一定のレベルの技術を複数組み合わせることで、希少価値を高めることができます。
例えば、英語のスキル一本で翻訳業等の仕事をするのであれば厳しい競争を潜り抜けられる特別なスキルが必要ですが、英語のスキルとIT技術を組み合せる場合は、英語のスキルもIT技術も専門職としてはイマイチなレベルであったとしても、海外の技術者と意志疎通ができる技術者として重宝されます。
５．道案内的な役割を果たす
例え自分自身に特別な技術が無かったとしても、ある程度業界に精通していれば、特別な技術を持った人や企業を紹介することができます。
例えば、地元の医者は、自分の手に負えない患者に対しては、大手の病院への紹介状を書いてくれます。
この医者自身に特別な技術が無かったとしても、適切に道案内をすることで患者の病気を治すという便益を与えることができます。
ファジィ推論をjavaでやってみた
「ファジィ推論」とは、「高い」「重い」「暑い」等の数値では表せない感覚的なものを数値として表すことでコンピュータ制御を行うAI技術です。
現在は、洗濯機・エアコンといったの家電や、地下鉄の自動運転等に応用されています。
今回は、こちらのページで解説されているファジィ推論をjavaで実装してみました。
静岡理工科大学情報学部コンピュータシステム学科・知能インタラクション研究室 - ファジイ推論
http://www.sist.ac.jp/~kanakubo/research/reasoning_kr/fuzzy.html
実装に際しては、下記ページを参考にしています。
SoftComputing lab. - ファジィ推論
http://ix9.jp/softcomputing/fuzzy-rcpg.shtml
稚拙な実装となっていることを始めにお断りしておきます。
ただ、ごく簡単な実装でもファジィ推論は実現できるという意味で、参考になるかもしれません。
【ソースコード】
・FussyMain.java
public class FussyMain {
public static void main(String[] args){
// 実行時の引数から気温と湿度を取得
double temperature = Float.parseFloat(args[0]);
double humidity = Float.parseFloat(args[1]);
// 適合度の変数定義
// （「あまり暑くない」「かなり暑い」「湿度が低い」「湿度が高い」）
FussyMember fussyMember = FussyMember.getInstance();
double notHotDegree = 0;
double tooHotDegree = 0;
double lowHumidityDegree = 0;
double highHumidityDegree = 0;
// 適合度計算
notHotDegree = fussyMember.notHotCalc(temperature);
tooHotDegree = fussyMember.tooHotCalc(temperature);
lowHumidityDegree = fussyMember.lowHumidityCalc(humidity);
highHumidityDegree = fussyMember.highHumidityCalc(humidity);
System.out.println("■適合度計算");
System.out.println("・あまり暑くない："+notHotDegree);
System.out.println("・かなり暑い："+tooHotDegree);
System.out.println("・湿度が低い："+lowHumidityDegree);
System.out.println("・湿度が高い："+highHumidityDegree);
// 非ファジィ化の変数定義
// ルール① もし、かなり暑くて、湿度が高ければ、室温を下げる
// ルール② もし、あまり暑くなくて、湿度が高ければ、室温はそのまま
// ルール③ もし、かなり暑くて、湿度が低ければ、室温はそのまま
// ルール④ もし、あまり暑くなくて、湿度が低ければ、室温を上げる
UnFussyLogic unFussyLogic = UnFussyLogic.getInstance();
double rule1Degree = 0;
double rule2Degree = 0;
double rule3Degree = 0;
double rule4Degree = 0;
double toLowDegree = 0;
double toMiddleDegree = 0;
double toHighDegree = 0;
double temperatureCentor = 0;
// 各ルールの前件部の計算
rule1Degree = unFussyLogic.andCalc(tooHotDegree, highHumidityDegree);
rule2Degree = unFussyLogic.andCalc(notHotDegree, highHumidityDegree);
rule3Degree = unFussyLogic.andCalc(tooHotDegree, lowHumidityDegree);
rule4Degree = unFussyLogic.andCalc(notHotDegree, lowHumidityDegree);
System.out.println("■前件部計算");
System.out.println("・ルール①："+rule1Degree);
System.out.println("・ルール②："+rule2Degree);
System.out.println("・ルール③："+rule3Degree);
System.out.println("・ルール④："+rule4Degree);
// 各ルールの後件部の計算
toLowDegree = rule1Degree;
toMiddleDegree = unFussyLogic.orCalc(rule2Degree, rule3Degree);
toHighDegree = rule4Degree;
temperatureCentor =
unFussyLogic.centerCalc(toLowDegree,toMiddleDegree,toHighDegree);
System.out.println("■後件部計算");
System.out.println("・室温を下げるグレード："+toLowDegree);
System.out.println("・室温はそのままグレード："+toMiddleDegree);
System.out.println("・室温を上げるグレード："+toHighDegree);
System.out.println("・室温の変化値："+temperatureCentor);
}
}
・FussyMember.java
public class FussyMember {
// 適合度計算用クラス。Singletonとする。
private static FussyMember fussyMember = new FussyMember();
public static FussyMember getInstance(){
return fussyMember;
}
public double notHotCalc (double temperature) {
double degree = 0;
double lowLimit = 12;
double highLimit = 30;
// 温度が12度以下の場合は「あまり暑くない」の適合度＝１
if (temperature <= lowLimit) {
degree = 1;
// 温度が12度～30度の場合は「あまり暑くない」の適合度は０～１
} else if(temperature > lowLimit && temperature < highLimit) {
degree = 1 - ((temperature - lowLimit)/(highLimit - lowLimit));
// 温度が30度以上の場合は「あまり暑くない」の適合度＝０
} else {
degree = 0;
}
return degree;
}
public double tooHotCalc (double temperature) {
double degree = 0;
double lowLimit = 20;
double highLimit = 39;
// 温度が20度以下の場合は「かなり暑い」の適合度＝０
if (temperature <= lowLimit) {
degree = 0;
// 温度が20度～39度の場合は「かなり暑い」の適合度は０～１
} else if(temperature > lowLimit && temperature < highLimit) {
degree = 0 + ((temperature - lowLimit)/(highLimit - lowLimit));
// 温度が39度以上の場合は「かなり暑い」の適合度＝１
} else {
degree = 1;
}
return degree;
}
public double lowHumidityCalc (double humidity) {
double degree = 0;
double lowLimit = 0;
double highLimit = 40;
// 湿度が0％以下の場合は「湿度が低い」の適合度＝１
if (humidity <= lowLimit) {
degree = 1;
// 湿度が0％～40％の場合は「湿度が低い」の適合度は０～１
} else if(humidity > lowLimit && humidity < highLimit) {
degree = 1 - ((humidity - lowLimit)/(highLimit - lowLimit));
// 湿度が40％以上の場合は「湿度が低い」の適合度＝０
} else {
degree = 0;
}
return degree;
}
public double highHumidityCalc (double humidity) {
double degree = 0;
double lowLimit = 60;
double highLimit = 100;
// 湿度が60％以下の場合は「湿度が高い」の適合度＝０
if (humidity <= lowLimit) {
degree = 0;
// 湿度が60％～100％の場合は「湿度が高い」の適合度は０～１
} else if(humidity > lowLimit && humidity < highLimit) {
degree = 0 + ((humidity - lowLimit)/(highLimit - lowLimit));
// 湿度が100％以上の場合は「湿度が高い」の適合度＝１
} else {
degree = 1;
}
return degree;
}
}
・UnFussyLogic.java
public class UnFussyLogic {
// 非ファジィ化用クラス。Singletonとする。
private static UnFussyLogic unFussyLogic = new UnFussyLogic();
public static UnFussyLogic getInstance(){
return unFussyLogic;
}
// AND/OR演算メソッド
public double andCalc (double a,double b) {
if (a > b) {
a = b;
}
return (a);
}
public double orCalc (double a,double b) {
if (a < b) {
a = b;
}
return (a);
}
// 重心算出メソッド
public double centerCalc
(double toLowDegree,double toMiddleDegree,double toHighDegree) {
// 0.25単位（49段階）で離散化
double[] temperatureList = {-6,-5.75,-5.5,-5.25, -5,-4.75,-4.5,-4.25, -4,-3.75,-3.5,-3.25,-3,-2.75,-2.5,-2.25, -2,-1.75,-1.5,-1.25, -1,-0.75, 0.5,-0.25,0,0.25, 0.5,0.75, 1,1.25, 1.5,1.75, 2,2.25, 2.5,2.75,3,3.25, 3.5,3.75, 4,4.25,4.5,4.75, 5,5.25, 5.5,5.75,6};
double[] toLowList = { 0, 0.08,0.17, 0.25,0.33, 0.42, 0.5, 0.58,0.67, 0.75,0.83, 0.92, 1, 0.92,0.83, 0.75,0.67, 0.58, 0.5, 0.42,0.33, 0.25,0.17, 0.08,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0};
double[] toMiddleList = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.13,0.25, 0.38, 0.5, 0.63,0.75, 0.88,1,0.88,0.75,0.63, 0.5,0.38,0.25,0.13, 0, 0, 0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0};
double[] toHighList = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0,0.08,0.17,0.25,0.33,0.42, 0.5,0.58,0.67,0.75,0.83,0.92,1,0.92,0.83,0.75,0.67,0.58,0.5,0.42,0.33,0.25,0.17,0.08,0};
// ファジィ集合の定義
double toLowSet = 0;
double toMiddleSet = 0;
double toHighSet = 0;
double toSynthesisSet = 0;
// 重心の計算で使用する変数の定義
int stepNum = 49;
double sum = 0;
double den = 0;
double centor = 0;
// 重心の計算
for (int i = 0;i < stepNum;i++) {
// 頭切り
toLowSet = andCalc(toLowDegree,toLowList[i]);
toMiddleSet = andCalc(toMiddleDegree,toMiddleList[i]);
toHighSet = andCalc(toHighDegree,toHighList[i]);
// ファジィ集合の合成
toSynthesisSet = orCalc(orCalc(toLowSet,toMiddleSet),toHighSet);
// 重心の途中計算
sum = sum + (toSynthesisSet * temperatureList[i]);
den = den + toSynthesisSet;
}
centor = sum / den;
return centor;
}
}
【実行結果】 ※気温(第1引数)が28、湿度(第2引数)が70の場合
■適合度計算
・あまり暑くない：0.11111111111111116
・かなり暑い：0.42105263157894735
・湿度が低い：0.0
・湿度が高い：0.25
■前件部計算
・ルール①：0.25
・ルール②：0.11111111111111116
・ルール③：0.0
・ルール④：0.0
■後件部計算
・室温を下げるグレード：0.25
・室温はそのままグレード：0.11111111111111116
・室温を上げるグレード：0.0
・室温の変化値：-2.400324149108591
IT技術者にとってのExcelの重要性と初心者向けサイトの紹介
最近の新人はPCよりもスマホの方を良く使うためタイピング速度が遅い、という記事を昨日書いたのですが、PCに慣れていないということはExcelにも慣れていない可能性が高いです。
少なくともIT企業(SIer・ITゼネコン系)では、Excelを使わない現場は無いと言っても過言ではありません。
設計書や管理資料、簡単な説明資料・報告書といったあらゆるドキュメント作成でExcelは使用します。
（何でもかんでもExcelでドキュメントを作ることを揶揄する論もありますが、現実問題として何でもかんでもExcelでドキュメントを作る技術者・現場は多いですし、このような論もExcelを使いこなせることが前提です。）
Excelを用いた計算については、基本情報処理技術者の表計算で学ぶことができます。
情報処理技術者試験対策「表計算」
https://akira2kun.hatenablog.com/entry/2018/11/18/104105
しかし、Excelでドキュメントを作る上では、セルの結合やセルの挿入、グラフの作成といった基本操作も必要になります。
そのような基本操作は、以下のサイトで概ね紹介されています。
初心者にも分かるExcel・エクセルの使い方
使用頻度の高い・低いはありますが、このサイトで紹介されている操作は一通り必要になります。
Excelの操作に不安がある場合は、このようなサイトで勉強することをお勧めします。
IT技術者にとってのタイピング速度の重要性と鍛え方
最近の新人はスマホを多く使いPCに慣れていないため、タイピング速度が遅く、仕事に支障をきたすケースがあります。
仕事をしている限りは、IT企業(SIer・ITゼネコン系)ですら例外でないように感じます。
タイピング速度が遅いのは、IT企業で勤める場合は特に致命的です。
タイピング速度が遅ければコーディングできる量も減り、技術の習得速度や生産性が悪化します。
コーディング以外でも、設計書や管理表等のドキュメント作成やメール・メッセンジャーでのちょっとしたやりとりでもタイピングは避けられません。
もしもタッチタイピングもできないようなレベルなら、すぐにでも練習する必要があります。
今は、ゲーム感覚でタイピング速度を測れるサイトがあります。
国内で最も有名と言われているのが「e-typing」の「腕試しレベルチェック」です。
まずはそこで現状を知ることをお勧めします。
インターネットでタイピング練習 イータイピング e-typing ローマ字タイピング
このサイトで出てくるランクについて、以下のページで詳しく書かれています。
e-typingのランクレベル一覧！！一般人の平均タイピング速度はどれくらい！？
http://snow-onyx.com/archives/3084
IT技術者に最低限求めたい速度（複数の指でタッチタイピングしないとまず出ないであろう速度）で打ってみたところ、スコアは225前後になりました。
タイピングに自信がない新人はまずスコア225を目標とすることをお勧めします。
なお、参考までに、仕事でPCを使わず一本指打法の妻がスコア103、（恐らく）平均的なIT技術者の私がスコア356でした。
新人の中には妻とほとんど変わらない速度でタイピングしている人もいます。
IT技術者の場合はこの速度だと本当に仕事に支障が出て、評価が下がる一因にすらなるので、すぐにでも練習した方が良いです。
タイピングの速度を改善したい場合、以下のページが参考になると思います。
これぞ最速！ブラインドタッチ（タッチタイピング）の効率的な練習法。初心者にオススメな6つの上達のコツ アタリマエ！
https://atarimae.biz/archives/1673
また、練習する際は、課題を解くのも良いですが、モチベーションの維持のために趣味でブログやチャット等を始めて練習するのも手です。
私も特にタッチタイピングを鍛えたわけではありませんが、高校生や大学生の時に趣味でPCを使っていたため、社会人になる頃には今とほぼ変わらない速度で自然とタイピングできるようになっていたので。
ダイバーシティのメリットとデメリット
日本でダイバーシティという言葉が使われる場合は、「女性や障害者にとって働きやすい環境を提供して人手不足に対応する」という意味合いで使われる場合が多いと思います。
しかし、ダイバーシティの本質は、「多様な従業員を雇い、変化できる企業を目指す」という所にあり、性別や障害の有無のみでなく、国籍、学歴、家族構成や趣味・嗜好の違い等もダイバーシティを生み出す要素になります。
同質な従業員で構成される企業は、従業員同士で特別な配慮が不要なため、現在の事業が時代の潮流に乗っておりかつ事業を広げる必要がない時には高い効率性を示します。
しかし、時代の潮流が変わったり多角化を目指したりする時に、同質な能力・価値観を持つ従業員しかいないことにより、企業戦略を変化させることができずに一気に業績を落とすリスクが生まれます。
ダイバーシティのメリットとデメリットを端的にまとめると以下のようになります。
【メリット】
１．優秀な従業員を大量に獲得するチャンスが生まれる
採用活動を行う際に、候補者の母集団が広がることにより、優秀な従業員を大量に採用するチャンスが生まれる。
２．多様な能力を持つ従業員を確保できる
例えば、女性は調整能力に優れていることが多く、発達障害を持つ者はIT系の仕事に適性を示すケースが多い。
ダイバーシティを実現している企業は、多様な能力を持つ従業員を知らず知らずの内に確保できていることが多い。
例え今の事業では多様な能力を活かせないとしても、事業内容が変わる時に武器になり得る。
３．多様な価値観を持つ従業員を確保できる
例えば、居酒屋チェーンの「串カツ田中」は、ファミリー層をターゲットとする戦略を採っている。
具体的には、店を禁煙にしたり「今日はいい子だったからご褒美」と声をかけてソフトクリームをサービスしたりする等の工夫を凝らしているが、このような工夫は実際に子供と触れ合う機会が多い従業員がいないことには具体的には出てこないものである。
顧客に受け入れられるサービスを展開するためには、顧客の価値観と合う従業員が会社の中に存在している必要がある。
事業戦略の転換で対象顧客が変わる際、社内に多様な価値観が存在していれば、顧客の価値観を理解できる従業員がいないという事態を避けられる。
【デメリット】
１．ダイバーシティに対する理解が必要
ダイバーシティに対する理解が従業員にないと、能力や価値観の違いから衝突が起こり、最悪の場合は差別が発生する。
そうなると、ある能力・価値観を持っていない従業員が退職し、企業からダイバーシティが失われることにもなりかねない。
そうならないために、従業員を教育する必要がある。
可能なら、採用の段階からダイバーシティの考え方を受け入れられるかどうか確かめた方が良いだろう。
２．能力や価値観の違いに対する配慮が必要
例え人間関係的にダイバーシティが受け入れられていたとしても、能力や価値観の違いに配慮した仕事環境が整っていないと、各々の従業員の能力を十分に発揮することができなくなる。
例えば、日本語が不自由な従業員に対しては英語や多言語での対応や図を駆使した手順書の展開等が必要になるし、（一般的な業務が苦手なことが多い）発達障害の従業員に対しては障害の内容に応じた業務の割り振りが必要になる。
本番作業前の通しリハーサルの重要性
本番作業でヒヤリハット事例を起こしてしまったので、自分への戒めも兼ねて記事化します。
反面教師になれば幸いです。
守秘義務があるので、詳細な内容は書かず、一般論だけ書きます。
なお、このヒヤリハット事例については、既に対策（再発防止策）を策定しています。
【事例の内容】
開発者（私）は、本番環境でのテストを作業指示書でオペレータに作業指示を出すことで実施した。
作業指示書には、作業手順書と、作業時に使用するスクリプトが含まれているが、このスクリプトに誤った処理が記述されており、本番運用で必要なファイルが意図せず消えるようになっていた。
オペレータがスクリプトの誤りに気付き、訂正したことで、障害とはならなかった。
【作業ミスが発生した理由】
スクリプトは本番運用で使われているものを改変して作成したが、改変漏れがあった。
改変を手作業で実施していたため、作業が漏れてしまった。
【作業ミスを事前に発見できなかった理由】
開発環境で手順のリハーサルを実施していたが、作業開始から作業終了までの作業を通して実施していなかった。
スクリプト以外は過去に実績のある手順であるため、実績のないスクリプトのみ単独で動かしてリハーサルとしていた（処理が動くことのみを確認していた）。
後作業として本番運用で必要なファイルを使用する手順が存在していたが、通しでリハーサルを実施しておらずその手順をリハーサル時に飛ばしていたため、作業ミスに気付くことができなかった。
【類似の作業ミスの分析】
他のメンバーも本番環境での作業で類似の作業ミスを起こしていたため、チーム全体で分析を行った。
今回の事例では「作業ミスが発生した理由」として手作業でスクリプトを作成したことを挙げているが、類似の事例には当てはまらなかったり、当てはまったとしても対策が困難であったりした。
それに対して、「作業ミスを事前に発見できなかった理由」として挙げた「通しのリハーサルの未実施」は類似の事例にも概ね当てはまっており、本番環境で作業ミスを起こす主因として判断できるものであった。通しのリハーサルを実施することと、実施されたことを確認する仕組みを作ることで対策となるため、対策も比較的立てやすかった。
先読みできる技術者になるために
今は、知識や経験に差がある複数の技術者がそれぞれ似たような案件を受け持つような環境で仕事をしています。
その中で気付いたことがあるので記事にします。
どの案件も、顧客（要件定義者や上位の設計者）の要望に沿って設計・製造・テストを行うというものなのですが、知識・経験に長けた技術者の案件は比較的スムーズに進むのですが、そうではない技術者の案件は顧客との応対に時間がかかったり後工程で問題が見つかったりして、知識や経験に長けた技術者のカバーがないとスムーズに進まないことが多いです。
知識や経験に長けた技術者とそうではない技術者で仕事の進め方がどのように違うのかを見てみると、「先読みができるかどうか」という所に本質的な違いがあるように見えました。
知識や経験に長けた技術者であれば、今の時点から最終的にリリース・本番運用する所までの流れが読めるので、どのような所に気を配れば後々スムーズに進むのかを考えることができます。例えばコーディングでは、「ロジックが複雑でバグが出やすいから簡単なロジックに作り直した方が良いな」「後で影響調査する時のことを考えると変数名は○○にした方が良いな」といった所に気を配ることができます。
また、顧客との定例的な打ち合わせでも、「きっとこの人は現工程の進捗遅れが響いてリリース延期になるリスクを気にしてるな。後工程の作業を先取りしているから全体的に見て進捗遅れはないと言って安心してもらおう。」といった気配りができるので、顧客との応対もすんなり終わります。
顧客の要望に不足や誤りがあることも時にはあります。そのような時、知識や経験に長けていれば「○○をすることで性能改善をしたいという要望ですが、なぜ○○をすれば性能が改善すると考えているのでしょうか。」といった形で質問することができます。もしその中で誤りが見つかれば早期に対応することができ、後工程で問題となるのを防ぐことができます。
知識・経験に長けた技術者とそうではない技術者では一見同じように仕事を進めているようにも見えるかもしれませんが、知識・経験に長けた技術者はこのような先読みをしれっと行い、仕事がスムーズに進むようにしています。
良質な経験を何年にもわたって積んでいれば、上記のような先読みは「なんとなく、このまま行ったら後々ヤバくなりそうな臭いがする」という形で自然にできるようになります。
しかし、経験の量や質が不足している技術者にはそれはできないので、知識で補う必要があります。
知識と言っても、単に「○○の言語でコーディングができる」「エクセルでいい感じの設計書を作れる」といったスキル的なものだけでなく、各工程の作業内容に関する知識や開発管理の知識等の広範的な知識が必要です。
SIer業界(いわゆるITゼネコン)に属している技術者の場合、基本情報処理技術者試験と応用情報処理技術者試験から学ぶのが知識の底上げの手段としては手っ取り早いと思っています。この２つの試験では、どの職場でも通用する知識をバランス良く身に付けることができます。
（ただし、この２つの試験だけでは不足する知識もあります。そのような知識をこのブログで紹介・提供できたらと思っています。）
仕事のできる/できないの話になるとどうしても精神論的な話になりがちですが、少なくとも専門的な知識・経験が問われる技術者の世界ではそうではないと感じました。
