技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

プログラミング言語のスキルチェンジのコツ

COBOLからJavaのスキルチェンジは苦労すると良く聞きます。
サーバーサイドCOBOLからフロントエンドJavaへのスキルチェンジの場合は言語の違い以外にも色々覚え直さないといけないことがある(Webサーバの仕様やHTTP通信の仕様等)のでまた別の話になるのですが、単純にCOBOLからJavaというだけでも苦労するそうです。
 
個人的にはCOBOLからJavaというだけでは特に苦労しなかった、というよりプログラミング言語の違いは自然言語の方言の違いぐらいにしか思っていません。
私の前職はメインフレームCOBOLやJCL)のエンジニアが多い職場だったのですが、COBOLやJCL以外の言語でコーディングせざるを得ない時もあります。
(C、BashシェルスクリプトJavaWindowsバッチ、アセンブラVC++…)
そのような場合、プログラミング言語の違いにあまり抵抗感のない私がアサインされることが多かったです。
 
なぜプログラミング言語の違いに抵抗感を感じないのかと考えてみたのですが、私の場合は未経験者時代の基本情報処理技術者試験の勉強で出題される全言語を勉強したことが大きいと思いました。
実務に入る前から、疑似言語のアルゴリズムアセンブラ機械語チックなアルゴリズムCOBOLで良く使われるマッチング処理等のロジック、C言語のポインタの概念、Javaオブジェクト指向の概念を学んでいたので、様々な言語に対応できる応用力が身に着いたのだと思います。
ちなみに、私は「プログラミング未経験者のための基本情報技術者 午後[プログラム言語〕」という本で午後試験対策を行いました。基本情報処理技術者試験で問われる全ての言語について最低限必要な解説がされており、各言語の概念を広く浅く学ぶには最適な本です。
 
プログラミング未経験者のための基本情報技術者 午後[プログラム言語〕 _ 矢沢 久雄, ITアシスト _本 _ 通販 _ Amazon
https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E6%9C%AA%E7%B5%8C%E9%A8%93%E8%80%85%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%9F%BA%E6%9C%AC%E6%83%85%E5%A0%B1%E6%8A%80%E8%A1%93%E8%80%85-%E5%8D%88%E5%BE%8C-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E8%A8%80%E8%AA%9E%E3%80%95-%E7%9F%A2%E6%B2%A2-%E4%B9%85%E9%9B%84/dp/4822282899
 
ちなみに、この本は2006年の古い本なので、表計算の解説はありません。それ以外の言語も、もしかしたら今の午後試験では通用しない部分があるかもしれません。
時々書店で情報処理技術者試験の参考書を立ち読みすることがあるのですが、最近は各言語の仕様を広く浅く解説した本は残念ながら見かけません。午後試験対策本はアルゴリズムに特化した本や表計算に特化した本が主流で、あとはアセンブラCASLⅡ)に特化した本があるぐらいです。
効率的に合格するだけならアルゴリズム表計算に特化するのが一番良いとは私も思うのですが…後々のことを考えると、早いうちに各言語の概念を簡単に学んでおいた方が良いのでは、それをサポートする本が1冊ぐらいあっても良いのでは、と思っています。

「GitHub」と「GitLab」、「Bitbucket」と「GitBucket」は別物

Gitリポジトリを管理するツールとして、「GitHub」や「Bitbucket」というツール(サービス)があります。
これらのツールでは、GitをCUIで操作することが可能で、チームのコミュニケーションを円滑にする機能(チケット管理等)も搭載されています。
特に「GitHub」は広く用いられているツールで、個人が他のエンジニアに向けてネット上にソースコードを公開する時は大抵このツールが使われます。
以下、公式ホームページです。
 
GitHub
 https--github.co.jp-
 https://github.co.jp/

 
・Bitbucket
 Bitbucket - チーム向け Git コード管理ツール アトラシアン
 https://ja.atlassian.com/software/bitbucket

 
GitHub」や「Bitbucket」とよく似た名前のツールとして、「GitLab」や「GitBucket」といったツールも存在します。
これらのツールの存在が今回の記事を書こうと思った動機なのですが、「GitLab」や「GitBucket」は「GitHub」や「Bitbucket」の打ち間違いではなく、本当にこの名前のツールが存在します。
「GitLab」や「GitBucket」の説明は以下のページに記載されています。
 
GitHubのようなサイトを独自に運用できる「GitLab」や「GitBucket」を使ってみよう さくらのナレッジ

https://knowledge.sakura.ad.jp/3005/

 
「GitLab」や「GitBucket」の大きな特徴として、チーム(企業)の開発で使用する場合にも無料という特徴があります。
GitHub」や「Bitbucket」は規模や使用するサービスに応じて費用が発生するのですが、「GitLab」や「GitBucket」にはそれがありません。
 
GitHub.com・BitBucket.org・GitLab.comの月額料金比較 + α - Qiita

https://qiita.com/hiroponz/items/c1ed4d6c10484233bf88

 
上記ページの料金比較には「GitBucket」の説明がありませんが、「GitBucket」は竹添直樹氏という個人が開発しているツールであり、このツールも有料サービスはありません。

Excelで縦持ちのリストを横持ちにする

例えば、

hoge foo
fuga foo
hoge bar

という縦持ちのリストを

fuga foo
hoge foo,bar

という横持ちのリストにしたくなることがあります。
1項目目(hoge,fuga)を一意にしたい場合にこのような需要が生まれます。

これは、Excelを用いることで簡単に実現可能です。
コントロールブレイク(https://akira2kun.hatenablog.com/entry/2018/10/06/150330)をExcelに応用することで実現可能になります。

【手順】
1.A~D列にタイトルを入れ、フィルタを入れる
2.A列~B列に縦持ちのリストを入力する

f:id:akira2kun:20190501122647j:plain

 

3.キーを昇順にソートする
4.C2セルに「=IF(A2=A1,C1&","&B2,B2)」と入力し、C列にオートフィルする
5.D2セルに「=IF(A2=A3,"","○")」と入力し、D列にオートフィルする

f:id:akira2kun:20190501122951j:plain

 

6.D列を「○」でフィルタリングする
7.B列を非表示にする

f:id:akira2kun:20190501123000j:plain

 

報連相が必要な理由

報告・連絡・相談は、組織で働く者には欠かせないスキルです。
IT業界は内向的な人が多く、報告・連絡・相談が苦手な人が少なくない業界です。
(私も正直あまり得意ではありません)
それだけに、報告・連絡・相談ができる若手は、たとえ技術力に多少の不足があっても企業の中で重宝されます。
 
今更言うまでもないかもしれませんが、「報告」「連絡」「相談」とは以下のような意味です。
・報告…上位者から指示された作業の進捗状況や結果を知らせる
・連絡…周囲の者に事実を知らせる
・相談…判断に迷うことがあった時に、上位者に指示を仰ぐ
 
組織では、上位者が大局的な判断を行い、その下に属する作業者が実作業を行います。
作業者は、上位者が正しい判断やそれに基づく指示を行えるように、適切にコミュニケーションを取ることが望まれます。
「報告」や「連絡」は上位者に判断に必要な情報を与えるための手段ですし、「相談」は上位者の指示が不足している箇所について追加で判断・指示を受けるために必要な手段です。
これらのコミュニケーションが欠けてしまうと、上位者から正しい判断・指示を受けることができなくなり、全体の仕事にも影響してしまいます。
細かいテクニックはグーグルで検索すればごまんと出てきますが、「上位者が正しい判断・指示を行えるようにする」という本質を抑えることが肝要であることは間違いありません。
 
慣れてきたら、上位者が行っている判断を作業者自ら行うようにすると、上位者の負担が軽減してよりスムーズにコミュニケーションが取れるようになります。
また、その作業者も「この人は上位者になっても仕事ができる」と思われるようになり、出世の足掛かりになります。
しかし、勝手に判断して動くのはそれはそれで問題なので、「~と私は判断したので~をしたいのですが、それでよろしいですよね?」といった形で念押しすることが重要です。
 
報告・連絡・相談がうまくできない内は、上位者に負担をかけてしまい、怒られてしまうこともしばしばあります。
しかし、報告・連絡・相談自体がなければ、結局仕事が上手くいかなくなり後で余計に怒られてしまいます。それよりは、報告・連絡・相談が下手で怒られる方がはるかにマシです。
障害発生時等、緊急性の高い状況ではそもそも報告・連絡・相談を上手くまとめあげる時間すらありません。そのような時は、とにかく何かが起きてることをいち早く関係者に知らせることが重要になります。緊急時の連絡のことを前職では「騒ぐ」と呼んでいましたが、この表現は言い得て妙だと思います。

登竜門としてのITパスポート

IT企業に興味のある人、IT企業の内定者、IT企業に未経験で入社して間もない若手がITパスポートに興味を持ったり合格していたりしている姿を見て、改めてこの資格は良くできた資格だと思いました。
 
ITパスポートがどのような資格なのかはIPAのホームページの以下に書かれています。

https://www3.jitec.ipa.go.jp/JitesCbt/html/about/about.html

引用すると、
「iパスは、ITを利活用するすべての社会人・これから社会人となる学生が備えておくべき、ITに関する基礎的な知識が証明できる国家試験です。」
という資格です。
決してIT企業でバリバリ開発している人向けの資格ではなく、業界を問わない社会人に向けた資格です。
 
しかし、入門的な難易度に抑えた資格だからこそ、IT企業に興味がある人に向けて気軽に受験をお勧めできるという一面があります。
出題分野は、コンピュータに関する知識のみならず、開発手法、マネジメント、経営全般の知識も問われ、ITに関わる知識が広く浅く網羅されています。
浅くと言っても、アルゴリズムに関する問題は簡単なトレースができないと解けない問題であったり、データベースに関する問題は主キー・外部キーを理解していないと解けない問題であったりして、IT企業で働く上で役に立たないとは言えない良問が揃っています。
合格率は50%程度かそれより少し高いぐらいです。イラストや漫画でわかりやすく書かれた参考書を読んで、過去問を解けば、誰でも合格を狙える試験です。私の周りを見ても、しっかり勉強した人はITパスポートに合格しています。
選択式問題のため、答えを暗記してしまえば合格できるという現実はあるのですが、合格して成功体験を積むという意味では決して悪いことではないと思っています。設問で問われている意味は後から理解するでも良いと思っています。
仮にIT企業の空気に合わずに他の業界に移ったとしても役に立つ、というのもお勧めできる点の一つです。
外部のITベンダーに開発を依頼する、自社のオフィスにパソコンやソフトウェアを入れる、作業効率化のための簡単なマクロを作る…といったことはどの業界でもある作業なので、そのような場面でITパスポートで学んだことが役に立つはずです。
 
逆に、ITパスポートよりもレベルが一つ上で、ITパスポートと同じく登竜門とされている基本情報処理技術者試験は、興味があるという程度の人や開発に携わって間もない人にはあまり気軽にお勧めできる資格ではないです。
特に午後のアルゴリズムの試験がIT企業の実務レベルに近く難易度が高いですし、合格率も20~25%程度です。実務で担当者として活躍しているような人でも、受からない人は本当になかなか受かりません。
また、IT以外の業界に務めている人にとっては、実務レベルに近いアルゴリズムを読み解く必要があったりSQLやプログラム言語の知識が必要になったりして、不必要に難易度が高いと思います。
元々センスがある一部の人は別ですが、多くの人はいきなり基本情報処理技術者試験から入ったら挫折しかねないのではないのか、という難易度です。
ITパスポートに合格した人や実務に携わってから1~2年経った人であれば合格を目指してほしい資格ではあるのですが、初めのうちはITパスポートからチャレンジした方が無難ではないかと思っています。

障害事例は宝物

金融システムのようなミッションクリティカルなシステムの開発では、ミスは許されません。
自分が起こしたミスから学ぶのはもちろんなのですが、他者が起こしたミスから学ぶというのも大切な姿勢になります。
 
どのようなミスが障害につながるのかは障害事例を見れば勉強できるのですが、他社が起こした障害事例の詳細が表に出ることはよほど大規模な障害でなければ滅多にありません。
しかし、自社が起こした障害事例であれば、細かい障害であってもその詳細を見ることができる場合があります。
もし、自社の障害事例を見ることができるのであれば、是非見て学んでほしいというのが個人的な意見です。
 
私も前職の時、特に新人の時は暇を見つけては自社の障害事例を読んでいました。
すぐに思い出せる範囲で、ここに書いても差し支えない範囲で障害の原因となったミスの内容を書き出すと、
・小数点以下切り捨てが発生するタイミングの認識誤り
・境界値付近の条件分岐の記述ミス
・条件式の単純ミス(等号・不等号の誤り)
・計算式の単純ミス(符号や分子・分母の誤り)

といった原因で障害が発生していました。
これらはコーディングに関するミスなのですが、他にも連携先システムの仕様の認識誤りや運用ミス等の原因によっても障害は発生していました。
これらの事例を数多く学ぶことで、障害が発生しそうな雰囲気というか、そういったものがなんとなくわかるようになってきますし、重点的にレビューやテストをするべき箇所もわかってきます。
 
私が前職で障害事例を読んでいたのは、意識が高いからというよりも単に知識欲から読んでいたのですが、今思えば障害事例から学んだことは貴重でした。
繰り返しになりますが、自社の障害事例を見ることができるのであればぜひ見て欲しいと思っています。

機械学習を始めるきっかけになる(かもしれない)プレゼン資料

AI(機械学習)には興味があるけど何から始めたら良いのかわからない、という方向けに、AIプログラミングを始めるきっかけになればと思って作ったプレゼン資料です。
「用意されているライブラリを使えば、統計的な分析を簡単に始められる」ということが伝われば幸いです。
 

https://1drv.ms/p/s!AivF3bzWXOzuhUJXk5hscKYqkLkM