歓迎会をしていただいた。

先日、会社で歓迎会をしていただいた。管理職¥8000、管理職未満¥5000だったかな、結構高い金額を支払ってくれていて有難い。私は一銭も支払いを求められなかった。一応全員とは話したはず。今思えば翌日にお礼のメールを出すべきだったなぁと思う。


過ぎてしまったことは仕方がないので、今後はメールでお礼を言えるようにしておこう。なぜ今回メールを送れなかったか考えてみると、システム的にメールが非常に送りづらい環境があるからだと思う。どう送りづらいかというと、アドレス帳を自分で作成しなければいけないからというのが大きな要因になっている。会社としてアドレス帳くらい用意してくれればいいのに。


説明ブログ記事 近日公開予定!「Outlookでアドレス帳をエクスポート、インポート」



歓迎会の感想は一言でいうと楽しかった。様々な経歴を歩まれてきた方がいて面白かった。1/3程度は転職組なのだろうか、前職はほとんど転職してくる人がいなかったので新鮮だった。まったくの未経験の人はいないようだったか、スキルは低い人が多いようだった。これも私がなかなかの待遇で雇われた理由のようだ。


なぜこの会社を選んだのかの問いには困った。私はものつくりをしたくてこの会社を選んだのだが、実際に入ってみるとものつくりをしている人はほぼいない。ものつくりは協力会社に任せているのだ。確かに学ぶ能力の低い人物にものつくりを覚えさせるのは大変だ。それよりも管理の方法を覚えさせる方がだいぶ楽。


だから会社は手っ取り早くもうかる方の、管理を覚えさせているのだろう。そして、実際のものつくりはプログラム経験のある協力会社の人物に任せると。短期的に手堅く稼ぐのならば有効な方法だろう。このような会社にものつくりがしたくて入りましたっていうのはリスクが高いと判断し、曖昧な志望動機を話しておいた。


つまり、この会社の方向性と自分のやりたいことはミスマッチしていることとなる。それを偉い人は理解しているようだった。えらい人にその件について質問されたが「大丈夫ですよ、やりたいことやれてます」と言っておいた。しかし、実際のところはやれていないだろう。なぜ「やれてます」などと言ったのか、自分でも謎だ。わがまま言ってはいけないと思ったのだろうか。ファイアされるのを恐れたのかもしれない。


しかし、このまま管理だけの人間になるのは非常につまらないので機会を見つけてなんとかしようと考えている。社内改革なるものを実践していこう。そして転職、または起業または大学に行くのだ。不便に感じたこと、それに対処する方法をリストアップして提案していこう。このとき、間違っても一人で実践しないことが重要だ。会社に属している意味がなくなるし、孤立してしまう可能性が高いからだ。人を巻き込んで提案していこう。


でも実際、提案てどこにすればいいのだろうか。技術を管理している部署があるのだろうか。とはいっても、この会社にフレームワークはないと聞いたので技術を管理している部署があったとしてもとても機能してるとは思えないのだが。




相手の主張に流されない方法 自分の主張を納得させる方法

働くって大変だ。


課題認識出来てないって自覚できない人が見当違いな指示出したり助言したりするから、それは違うよって説明するのが大変。自分ひとりならば、こんな面倒なことにはならないのに。


さらに、上司がその見当違いな指示や助言を支持するもんだから、さらに説得が難しくなる。結局説得しきれなかったものは実施するしかなくなる。無駄だとわかってる作業をするのは実に億劫で嫌になる。


逆に、「相手に納得してもらう技術」の良い勉強機会になるかもしれない。この技術はどのような世界でも大切な技術だと思う。仕事結果で納得してもらう仕事ももちろんあるだろうが、口頭説明で納得させる今回のような件の方が多いと思う。


よし!勉強するいい機会になると思って楽しもう。失敗してもしょうがないと割り切って。失敗しても大丈夫なのは社会人の良いところだ、個人で失敗したら立ちなおすのにとんでもない労力が必要になる(資金的に)。


さて、相手の強引な手法に流されずに説得力を持って自分の主張に納得してもらうという能力を向上させていこうと思うのだが、どうしたらいいのだろうか。実はこの能力、以前の会社でも必要になっていて散々磨いてきたものである。ブランク期間にすっかり忘れてしまった。

以前の会社ではどのように向上させてきたかというと、すごく説明の上手な先輩がいてその方に教えてもらうことで自分の能力を向上させてきた。今でも本当に感謝している。ということで、先輩に教えてもらったことを思い出しながら納得させる技術について整理していきたいと思う。


思い出したことからリストアップしていこう。

納得させる技術
・ 出来ないと嘆くのではなく、どうしたら出来るのかを考えよう。
・ ゆっくり話そう。特に人前では早口になりやすいので、さらにゆっくり話す気持ちで。
・ 相手の気持ちになって考えよう。
・ 事実と自分の考察をきちんと分けて説明しよう。
・ 考察には根拠を併せて説明しよう。
・ まず結論を先に言おう。


とりあえず思い出したのはこのくらいかな。


今思えば、自分から発信することばかりなことに気付く。前職では変な指示を出す人は少なかったからなぁ、相手の主張に流されない技術というのはあまり必要でなかったのかもしれない。今回はこの「相手の主張に流されない技術」が非常に重要だ。これも今思いつく限りリストアップしておこう。

相手の主張に流されない技術
・ 主張の根拠は何なのか?の姿勢を持つ。
・ 主張は事実なのか、意見なのかを意識する。
・ 怖がらずに実際に聞いてみる。


こんなものかな。今のスキルが低いのが目に見える感じになりました。これから、伸ばせて行けたらいいかと思います。伸ばすにはどうしたら良いかなぁ、本を読んだり場数を踏んだり色々と方法はありそうですが、一個一個の事象に対して分析していく手法をとっていこうと思います。そうするとブログにも書けるので。


あぁ、それにしても眠くなってきた。自分が何を書いているのか意識がところどころ飛ぶ。


これではまずいので今日は寝ときます。それでは。



bloggerのカスタマイズ方法 すごい方の記事まとめ

先日、bloggerのカスタマイズについてまとまっている記事がないから書きますねと言いました。

bloggerテンプレート『Vaster2』の導入方法



しかし、記事がありました。しかも凄く綺麗にまとめられています。それが、こちらです。

bloggerのテンプレートをカスタマイズする方法


さすがテンプレート自作するくらいあってbloggerに精通している様子が伺えます。見やすいですね。このお方はbloggerのカスタマイズ方法についても記事にしてくれているので、これらの記事を見て私は勉強していこうと思います。


上記の他のカスタマイズ記事は次の3つのようです。

bloggerのカスタマイズに必須な条件分岐タグifのまとめ

[完全版]bloggerのsection、widget、includableについてのまとめ

bloggerの新しい独自タグが発表されたので紹介する


bloggerは独自のタグを採用しているようですね。それがとっつきにくくて利用者の伸びが今ひとつなのかもしれません。面白いおもちゃが増えたという気分で期限を決めずに気が向いたときに学んでいこうと思います。




応用情報技術者試験の対策 午前01 テクノロジ系

何から手をつけるべきかわからないので、とりあえず最初から手をつけていく。勉強していくうちに自分と相性の良い問題を見ることが出来ることでしょう。

まずは1週目なのでおおざっぱに勉強していきます。今回の勉強範囲は次のとおりです。


[午前試験]
テクノロジ系
1. 基礎理論
2. コンピュータシステム
3. 技術要素
4. 開発技術


それでは始めていきます。

1. 基礎理論

進数によるデータ表現

2進数、8進数、16進数いついて
0 ← 1ビット
00000000 ← 8ビット = 1バイト

基数変換

2進数から10進数などへ変換することを基数変換という。
なんでもかんでも10進数にしてから基数変換するのではなく、経由に適した基数がわかるようになると早く解ける。


補数による負数の表現

1の補数とは、元の数に足し合わせるとすべてのビットが1になる数
例:元の数 10001、1の補数 01110

2の補数とは、元の数に足し合わせると桁あふれする(最小の)数
例:元の数 10001、2の補数 01111

2. コンピュータシステム


3. 技術要素


4. 開発技術

bloggerテンプレート『Vaster2』の導入方法

bloggerテンプレート『Vaster2』を導入してみました。


今まではblogger提供のテンプレート使用していたのですけれども、どうも味気ないと感じるようになってきたので気分転換に変更してみました。やはり人が作成したものなので気になるところは多少ありますが自分で作成する手間を考えると十分満足できるものかと思います。

bloggerでデザイン変更するときに、参考になるサイトが少なかったのでまとめておこうと思います。bloggerはデフォルト広告も無く、表示速度も非常に速くて気に入っているので、使用者が増えてより便利なサービスになってくれると嬉しいです。

まずは次のサイトでテンプレートを入手します。※このお方がテンプレートを作成してくれた方です


ダウンロード

Vaster2|レスポンシブ対応済みのblogger日本語テンプレート
http://toumaswitch.com/vaster2/


バックアップ取得

次にダウンロードしたテンプレートを自分のブログに適用します。bloggerの設定画面からテンプレートを選択してください。


すると、上記画面が表示されますので、画面右上にある「バックアップ/保存」ボタンをクリックしてください。すると次の画面がポップアップ表示されます。


この画面で、まずは現在の画面のバックアップを取得しておきましょう。「テンプレートをすべてダウンロード」ボタンをクリックしてください。するとバックアップとしてxmlデータを取得することが出来ます。

テンプレート適用

さてそれではお待ちかねのVaster2デザイン適用です。上記ポップアップ画面の「ファイルを選択」ボタンをクリックしてVaster2のデザインテンプレートを選択しましょう。先ほどダウンロードした際にデフォルト名称で保存した場合『Vaster2-TD.xml』として保存されているはずです。

選択してしばらくすると、上記ポップアップ画面の「アップグレード」ボタンがクリックできるようになります。そしたらクリックです。これでデザインテンプレートの適用が出来ました。ブログホーム画面に行って確認してみてください。


ここでひとつ注意点ですが、このままでは上手く表示されていない可能性があります。私自身もレイアウトが崩れていました。これは、あらかじめ自分がカスタマイズした部品や他のテンプレートによる部品が残っているためです。好みに従って部品の削除なりをしていきましょう。

私はとりあえずVaster2のテンプレートどおりにしたかったので、作者の作成したDEMOサイトを確認しながら部品の削除をしました。デフォルトのテーマカラーは水色ですが、これは自分でプログラム変更することなく変更することが出来ます。テーマカラー選択ができるテンプレートなのです。私はとりあえずは水色でやっていきます。少しピンク系の色があると賑やかで良いなぁなんて思いますので、そのうち足していくかもしれません。

それでは、bloggerテンプレート『Vaster2』の導入方法でした。



面白そうなことしている企業を見つけた。 NICT 宇宙天気予報



おもしろそうな企業を見つけました。この企業では、宇宙天気予報などを行っているようです。

NICT (https://www.nict.go.jp/)

正式名称は「国立研究開発法人情報通信研究機構」と言うそうです。様々な研究や業務を行っているようですが、私の興味のあるのは次の分野です。

宇宙天気予報磁気嵐による被害の予防を目的として、磁気圏の状態を観測・予報する宇宙天気予報を行っている。また、電離圏世界資料センターとして、世界各地で行われている電離層観測や太陽活動観測などで得られたデータを収集し公開している。wikipediaより(https://ja.wikipedia.org/wiki/%E6%83%85%E5%A0%B1%E9%80%9A%E4%BF%A1%E7%A0%94%E7%A9%B6%E6%A9%9F%E6%A7%8B)

実はこの企業は大学のころに少しだけお世話になっているのです。当時の私は何もわかっていなかったので気にも留めていませんでした。社会に出て色々な仕事を目にするようになって、自分の勉強してきたことは少々特殊で、その特殊な分野に興味があることを気づきました。

その興味のある分野と、この企業の方向性は非常にマッチしている数少ない企業といえるでしょう。ここで私は宇宙天気予報をしたいです。(こちら現在の宇宙天気だそうです⇒http://swc.nict.go.jp/contents/index.php) そして、その宇宙天気予報がみんなの生活をより豊かで安全なものに出来たら幸せだと思います。研究利用で現在活用しているのは、ゲリラ豪雨の予測を行っているようです(https://www.nict.go.jp/press/2016/08/09-1.html) 気象関係に何かしらの携わりを持っている方ならよくご存じかと思いますが、ゲリラ豪雨は意外にもまだ予測できていないのです。

この転職活動にあたって懸念事項はいくつもあります。まずは大学院を出ていないと研究的側面の強い会社には入が難しいのではないか。官の企業ならなおのこと。あとは論文を書いたことがないのも少々気になります。

まずは、この分野で論文を記載してみることにしましょう。大学院については入らなければならないかも調べておく必要がありますが、今から入るのは骨が折れるしお金を稼げないので厳しい。学校に入り直すくらいなら医学部に行きたいという思いもあります。もし仮に大学院に入る必要があるなら、この企業への入社ではなく関連企業に入社ということでもいいかもしれません。民間企業ならば大学院卒業縛りは無いでしょう。

さて、論文を書くにあたって、知識がなければなりません。大学時代に勉強したことを遡りながら、今の状況を把握していく必要があります。ちょうど気象予報士の資格も取得しようとしていたのでちょうど良いでしょう。

大学時代の勉強は当時よく読んでいた本を再購入して読んでみることにします。絶版になってないと良いですが。業界の今の状況については、ニュートンでも読んで徐々に把握していきます。取り急ぎは、基礎知識として気象予報士の試験勉強をしていきます。1月に試験なのであと半年ですね、計画は情報処理などの他の試験と折り合いを見て計画を立てていこうかと思っています。

それでは。

最悪の失敗を経験した。入社4年目の日記より

今回の記事も、昔の日記を元に記載します。これは新入社員として入社して4年目のころに書いたものです。大学卒業してすぐ入社したので26歳のころですかね。




最悪の失敗をしました。わけのわからん女と関係を持ってしまったのです。もう最悪です。ただただ、気持ちが悪い。病気が怖い。(病気にならないよう防御的なものはしています)おおまかな教訓は、次の2つ。これは今後どんな良い女があらわれても、死守する。

 1.誘われたからといってすぐに関係を持たないこと。
  (相手の人間性をよく確かめてから)

 2.無理しないでありのままの自分でいること。
  (過度なリップサービスしない、自分凄い人アピールしない、卑下しない)


忘れないように感想と実際に起きたエピソードを書いておきたい。二度と同じ過ちはしない。

関係を持った次の日に電話したら、相手の態度が豹変。私が何かしらの地雷を踏んでしまったのでしょう。彼女の考えにまったく同意できなかったため、真っ向から反対したのも悪かったのかもしれません。ビジネスでもそうだけど、まずは肯定から入らないとね。

それにしても、人生観がまったく違ったわ。自分の会社や友達の会社はどこだのと社会的地位をひけらかしたり、自分はこんなに頑張ってるだの友達はこんなに凄い仕事で頑張ってるだの。最終的には死ぬんだから、地位も名誉もほどほどに道中楽しもうぜって考えにならないのかな。まったく死を意識できてない。何がしたいの?って感じだわ。もしかして認められたいのか。。。?

あとは大手大正義みたいなね。口ではやりたいことやってれば、大手じゃなくてもいいとか言っていた。だけど後輩が大手だとか、自分が大手に行って道を示したとか。で、大手行けなかった先輩を罵倒したり。とほほだよ。

この日記を書いたことでストレスをだいぶ発散できたので今日は眠る。続きは明日にでも。あの女!




要は女の子に振られたって話ですね。最後に書き捨ててますけど続きはありませんでした。情緒的に生きてましたね。ストレスを発散できたようで何よりですが。

ちなみに、この女の子の仕事がお薬関係のお仕事だったんですね。それでお薬業界の現状などを少し聞いて、興味をもったことも今後の人生選択にも影響を与えました。上記の日記にもありますように、当時の私は自分を大きく見せようとしたり相手の機嫌を取るために卑下したりしていました。若いころにはありがちなことでしょうが、相手との距離感がうまく取れていなかったころのように思います。

現在はだいぶ自然体でいることが出来ていると思います。自然体でゆるく楽しく生きていきたいなというのが今の思いです。


前職で考えてたこと(入社3年目~4年目)

昔の日記を漁っていたらおもしろいことが書いてあったので私の備忘録がてら公開しておきます。この日記は新入社員として入社して3年目のころに書いたものです。



仕事、相変わらずつらいです。何が辛いのか、上司に言われたこと、自分が言ったことが出来なくて辛いです。

上司も怖いけど、意味なく怒ることはしない。
言っていることも、まあまっとうかと思えるし。

たまに決めつけて話してるけど、違うと言うときちんと聞いてくれはする。
終わったことをぐちぐち言わないのも良いな。

なんか、結構良いな。
書いてみて客観的になれたけど、結構良い上司なのかもしれない。

ただ、レベルが合わないだけで。
おれがレベル低すぎて、それを見込んで仕事してくれる人でないと厳しいということか。

そんな神さまみたいな上司いるんだろうか。
わからないけど、自分に出来ることだけはしっかりとやろう。

今単体試験項目作成中だから、もう少しだ。



このころの上司は、技術的な知識は非常に高いのですが伝えるのがおそろしく下手でした。ですので、私には全く伝わらずに苦労した覚えがあります。それに加えて当時の私は素直にわからないと言うことが出来ませんでした。何をすれば良いのか見えてないのに、自分には出来るはずだと思い込んでいたのですね、それでどんどん苦しい状況になっていったのを覚えています。

その状況さえも良いものとして捉えようと努力しているのは上記の記事でわかりますが、アプローチの方法がよくないですね。状況を良いものとして捉えようとするのではなく、状況はそのまま捉えてどうしたら改善できるのかを考えると上手く乗り越えることが出来たのではないかと思います。

結局、このプロジェクトは完遂することが出来ませんでした。周りの人が見かねてはずしてくれました。はずしてくれて本当に感謝したのと無力感を味わったことを覚えています。ちょうどこのころ、システムエンジニアを辞めようと考え始めました。


次にこれは入社4年目に書いた日記です。ちょうど上記の仕事が終了して、違う仕事に配属されて右も左もわからずガムシャラに働いていたころでしょうか。



SEとして3年半働いてきたけれど、向いてないわ。きっと。
楽しくないもの。設計にしろ、製造にしろ。

その仕事終わったら達成感はあるけど、
仕事してる最中には楽しくない。

何してるときが楽しいのか、考えてみた。
それを仕事にしようと思う。

夢をかなえるゾウでも言ってたし、
人生一回きりだから、やりたいことやってから死にたいと思う。

■楽しいと感じること
・頼られると楽しい。
・人の手助けが出来たときが楽しい。
・自立出来てるときが楽しい。


逆に嫌な事は何だろうか。

■嫌なこと
・矛盾したこと。
・正直者が馬鹿を見るようなこと。
・媚びること。


ということは、医者か弁護士か!

もう少し!




最後のもう少し!は仕事中に日記を書いていたのでしょうか、それともプロジェクト終了まであともう少しだったのでしょうか。詳しくは覚えていませんが、上記の記事からわかるように私自身も伝える能力が低いことがわかります。

このころの仕事ではお客さんに現在の進捗状況とその計画を毎日報告する仕事をしていました。状況報告するために、情報をかき集める毎日だったことを覚えています。それまでお客さんの前に出て仕事をすることはなかったのでギャップ感を感じると共に伝える能力の欠落を実感していました。

当時の上司は、別プロジェクトで同じような業務内容のことをずっとしてきた人でやはりすごかったです。伝える能力がすばらしく高く、勉強させていただきました。しかし、私はもうそのころには気持がシステムエンジニアにはなく、別の業種に向いていたようですね。




応用情報技術者試験の対策 初めに(形式、出題数、範囲、試験時間)

2016年10月16日 応用情報技術者試験 に向けて勉強をしていくことを前回の記事(https://somegoro.blogspot.jp/2016/08/blog-post_30.html)で書きました。


一人で勉強しても味気ないので、ブログで説明しながら自分も学んでいくスタイルにします。今回はその第一回目です。


初めに、試験時間や問題数などの形式を確認してみましょう。IPAのサイトから引用して記載します。

題形式・出題数(解答数)

午前午後
試験時間9:30~12:00(150分)13:00~15:30(150分)
出題形式多肢選択式(四肢択一)記述式
出題数
解答数
出題数:80問
解答数:80問
出題数:11問
解答数:5問(*)
(*)平成27年度秋期試験以降


IPA:(https://www.jitec.ipa.go.jp/1_11seido/ap.html


基本情報技術者試験もそうでしたが、かなりの長丁場の戦いですね。休憩挟んで5時間の試験になります。これでは問題に説くことに一生懸命になっていたら集中力が持ちません。ですので、条件反射で回答できる問題をある程度多くしておかねばならないということです。


すなわち、問題を反復して身体に染み込ませることが大切ですね。それでは問題はそのようなものが出てくるのかを見てみましょう。


応用情報技術者試験 出題範囲 および 合格点

[午前試験 合格点 6割]
テクノロジ系
1. 基礎理論
2. コンピュータシステム
3. 技術要素
4. 開発技術

マネジメント系
5. プロジェクトマネジメント
6. サービスマネジメント

ストラテジ系
7. システム戦略
8. 経営戦略
9. 企業と法務


[午後試験 合格点 6割]
1. 経営戦略に関すること
2. 情報戦略に関すること
3. 戦略立案・コンサルティングの技法に関すること
4. システムアーキテクチャに関すること
5. サービスマネジメントに関すること
6. プロジェクトマネジメントに関すること
7. ネットワークに関すること
8. データベースに関すること
9. 組込みシステム開発に関すること
10.情報システム開発に関すること
11.プログラミングに関すること
12.情報セキュリティに関すること
13.システム監査に関すること


出題範囲としては基本情報技術者試験と変わりないですね。勉強しやすそうですね。ちなみに、午前試験で6割りに満たないとその時点で不合格確定で、午後試験の採点はされません。これは基本情報技術者試験も同じですね。ですので、まずは午前をパスしないことには何も始まりません。と、同時に午前をクリアできる知識が付いてくれば午後もすんなり通ることでしょう。詳しくはこれから、上記の項目を説明する形式で勉強していきます。


以上。次回へつづく。



これからの受験日程。まず応用情報技術者試験・TOEIC

さて、前回の記事(https://somegoro.blogspot.jp/2016/08/blog-post_13.html)では試験の受験計画を記載しました。今視野にある試験はこのとおりです。


・応用情報技術者試験
・TOEIC
・PMP
・気象予報士
・情報セキュリティスペシャリスト
・ネットワークスペシャリスト


次回の転職は半年後、4月入社したいと記載しましたが、上記すべての試験を取得するのは半年では厳しいです。というか情報処理試験は半年に一回なので、ストレートで合格しても1年半かかります。まずは応用取得して、その後の情勢を見ながら有用な資格を取得していくのが良いでしょう。


ということは直近で勉強すべきは情報処理と英語。他のPMP、気象予報士は試験の日程を確認しなければいけません。PMPに関してはどんな資格なのかも詳しくしりません。ということで今回の記事では、まず上記試験の日程を調査して記載しておきます。


・応用情報技術者試験(2016年10月16日)
・TOEIC (2016年10月23日、2016年11月20日)
・PMP (随時 要受験資格)
・気象予報士 (2017年1月29日)
・情報セキュリティスペシャリスト (2017年4月)
・ネットワークスペシャリスト (2017年10月)


調査しました。いい感じにばらけてますね。緊張感が続いていい勉強ができそうです。これらの試験のなかでも、気象予報士の試験は以前受験していて強い思い入れがあります。前職で気象予報士の先生に個人教育をしていただいた結果、合格まであと一歩のところまでいったのです。その先生の方のことは大変穏やかな方で品格があり人間的に大好きで尊敬していて、先日の定年退職祝いにも参加させていただきました。


その定年退職祝いの場で話にあがったのが、気象予報士が会社からいなくなってしまったということ。先生が会社で唯一の気象予報士で後継者を教育していたが、とうとう後継者を育てられずに退職になってしまったとのこと。それを聞いたときにバツの悪い気持ちになりました。


その場に来ていた人に聞きましたが、今も気象予報士教育をしているのだが、気象を好きな人はおらず試験に挑戦はしているが取得までにはかなりの時間がかかるだろうとのこと。おそらく今回の試験でも取得できていないでしょう。酔った勢いで次回は絶対合格しますと言っていましたが、勢いで合格できるほど甘いものではありません。能力的に勢いで合格できるほどの記憶力の持ち主ならば前回試験で合格していたはず。その退職祝いが今年の2月のことだったので、今回の試験勉強時間はおよそ半年間でしょうか。


次回の気象予報士試験(2017年1月)で私が合格したら前職に戻って教育を担当しても良いかななんて考えもあります。しかし、どうなんでしょう。自分はそれで良いのだろうか、恩返しとしてある程度は満足するかもしれませんが本当に望んだことなのでしょうか。医者になりたかったのでは?他の医者とは違うアプローチで精神疾患を治療するのではなかったのか。


ううむ。揺らぎます。


考えながら勉強しよう。勉強しないことには全てが絵空事になってしまう。


夏季休暇に入りました。就職活動振り返りと、これからの試験計画

夏季休暇に入った。夏季休暇と言っても一週間ほどの休みで、どこかに出かける予定も今のところ無い。というかお金が無い。


お金がないとこれほどまでに行動が制限されるのかということを今回再確認した。本当に早く就職できて良かった。実際には二月ころから就職活動を始めていたのだが、うまくいかず少々休憩して7月に再開、見事二週間ほどで内定が出た。


そして内定をいただいた会社に8月から勤務している。もう一社内定をくれそうな企業があったのだが、最終面接開始前に他社内定を受諾し最終面接終了直後に選考辞退をした。


主な理由は日程的なものだ。非常に良い企業だと感じていたし、オフィスも綺麗で立地も良い。今でも働きたいと思える企業だ。面接中にも明日にでも働けるように準備すると言ってくれていたが、その日の18時までには他社内定受諾しなければならなかったためだ。最終面接開始が17時。


致し方なかった。もし、その企業が事前に状況を詳しく聞いてきたのならば私は素直にその状況を答えただろう。しかし、転職エージェントに問い合わせるとそのような状況を素直に答えるのは失礼にあたるとのことだった。


ここらへんが本当によくわからない暗黙の了解というものなのだろうか。私は転職エージェントの言う通り、聞かれていないことは答えないことにして入らないことが決まっている最終面接に足を運んだ。


次回の転職活動では転職エージェントは使わないだろう。自分の思いと違う活動になることがわかった。それが良いように作用したことも十分にあったが、今回のように自分の思いとは離れることもあった。非常識だとしても自分の思うように就職活動をしたほうが自分と合った会社に入れるのではないかとも感じだ。


暗黙の了解を守って意味のない活動をするよりも、常識とは違くても意味のある活動をしていきたい。ただし、暗黙の了解とは互いの利害を最も効率よく高めるためのものとして出来たものだろうからないがしろにするつもりはない。できるかぎり従っていく。


今回で転職についての知識はだいぶ蓄えることが出来たので、次回は自分だけで大丈夫だ。案件紹介は転職サイトを利用するかもしれないが。おそらく半年後には転職活動を再開しているのではないだろうか。4月入社がやはり望ましいところだ。


少々転職が早い気もするが、その辺は転職市場との兼ね合いをゆくゆく考えていくとする。まずは自分の能力と実績作っていくことだ。自分の能力を示すものとして資格を取得しようと思う。具体的には次の資格に挑戦する。


■資格
・応用情報技術者試験
・TOEIC
・PMP
・気象予報士
・情報セキュリティスペシャリスト
・ネットワークスペシャリスト


資格によらない能力としては次のものを鍛えていく。
■能力
・こびないこと (こびた企業はすべからく落ちた)
・嘘つかないこと (嘘ついた会社はすべからく落ちた)
・遅刻しないこと (最終面接遅刻して落ちた ていうか道に迷った)
・余裕を持つこと (金の余裕、時間の余裕、立場の余裕が人間としての余裕を作り出す)
・自然にお話しできること (二月のころはまともに話ができなかった 会話体力とでもいうべきか)


こんなものだろうか。


長くなってきたので今回はこのあたりでドロンします。


見積手法の種類

見積もりがうまくいけば、9割がたプロジェクトは成功したようなものだ。


そんな言葉を聞いたことがある。(私の心の叫びか?)見積もりに参加する人はプロジェクト開始当初から参加しているごくわずかな人だけだ。


このほんのわずかな人数での作業が、これから参加する多くのエンジニアの命運を左右する。責任重大だ。だからこそ精度の高い見積もりが求められる。


さて、そんな見積もりだが、方法論は確立しているのだろうか。次の記事ではその方法論を記載している。ずいぶんと色々な手法(方法論)がある。一長一短があるのだろう、システムはどれも似て非なるものなので、色々な種類の見積もり手法があるのは当然とも思える。


しかし困ったもので、経験不足の私にとって、どの手法を用いていいのかわからない。これはだれかに相談だわ。この時点で私の存在する意味は皆無になるのだが、今後のために技術蓄積および経験蓄積として勘弁してもらうことにしよう。



Think IT  第4回:コスト管理の構造と見積手法
https://thinkit.co.jp/cert/project/1/4/2.htm


見積もりがブレるメカニズム
http://itpro.nikkeibp.co.jp/article/COLUMN/20080901/313837/?rt=nocnt


工程別基準工数比率
http://www.newspt.co.jp/contents/manual/yes/2_mi/3a02.html


ソフトウェア開発見積りの基本的な考え方
https://www.ipa.go.jp/files/000005398.pdf


WEBシステム開発の見積の出し方について考えてみました

機能設計書を自動生成

NEC、システム構築基盤ソフトにハイブリッド開発手法--機能設計書も自動生成



やっぱりNECはすごいなぁ。勉強になる。富士通も同じようなサービスを展開をしているので、そちらもチェックしてみよう。(富士通:http://japan.zdnet.com/article/35020479/?tag=mcol;relArticles


最近では設計書を作成しないプロジェクトも多いと聞きます。ですので、こうしたリバースエンジニアリングによるソースコードから設計書を作成したり、要求分析から設計書を自動で生成するサービスは売れるのではないかと予想できますね。


それにしても、NECの作成するドキュメントは相変わらず「ダサい&分かりやすい」だなぁ。好きだなぁ。こういう玄人向けのデザイン。



機能設計書の書き方

機能設計書を私は書いたことがない。

詳細設計書は書いたことあったかな?覚えはない。

いつもは基本設計書からプログラミングしていた。それは基本設計書作成をする人とプログラミングをする人が密接に連携できる環境にあったからだろう。基本設計書を作成した人がそのままプログラミングなんてことも多かった。

なにより、プログラミングする人はプログラムだけでなく、プログラムを組むため必要となる情報は自分で整理して資料を残していた。

しかし、世間ではプログラマーはプログラミングしかしないようだ。しかも誰がプログラムを組んでも同じようになるように設計書を作れということがあるらしい。そんなことするなら、設計書じゃなくてプログラム作ればいいのに。と思ってしまう。

私が働いていた環境では研究という側面もある開発だったからかもしれない。これらのギャップ感は否めないが、柔軟に対応していくより他はない。あまり根詰めずに、楽しんで仕事していこう。わからない部分はできないのだから、聞くまたは根拠に基づく予測で仕事をしていく。

とりあえず先立つものがないことには仕方がないので、機能設計書の書き方をわかりやすく記載してある資料を提示しておく。

サンプル例に見る機能仕様書の基本的な書き方&読みやすくする7つのテクニック
http://www.atmarkit.co.jp/ait/articles/1502/06/news013.html


デルファイのお勉強04

前回『https://somegoro.blogspot.jp/2016/08/blog-post_7.html』に引き続き、デルファイのお勉強をしていきます。今回も参考資料は次のサイトを使用させていただきます。

クジラ式 Delphi 資料
http://oto.chu.jp/a.oto.chu.jp/kujira/text/delphi/index.htm

それでは始めましょう。

■ループ処理

・while文でループさせる

while  条件式 do
  処理;

これは一般的な while の処理って感じですね。他の言語と変わらないでしょう。
条件式が true ならば処理を実行します。false ならば処理を実行せずに終了です。

・for文でループさせる

for  変数 := 初期値 to 終了値 do
 処理 ;

これは少々特殊な感じがしますね。初期値を変数に代入して、処理を実行します。
そして、変数が終了値になるまでループを続けます。
終了値になったら、処理を実行して終了します。最後に処理を do することが肝ですね。

・repeat文でループさせる。

repeat
  処理1 ;
  処理2 ;
until 条件式;

これは do while みたいな感じですね。まず最初に処理を実行する、その後に条件式によりループするかどうか判定する。

・Breakで、ループ処理から抜ける
・Continueで、ループ処理の頭からやりなおす。
・Exitで、プログラム自体を終了させる。

これらは一般的ですね。どれもループから抜け出す方法です。


■定数

定数は値の変わらない変数のことです。Java で言うところの final 型の変数、C や C++ では定数がありますね。書き方は C や C++ とほとんど同じです。

const
 TEISU = 10;

これで TEISU という名前の定数が出来ました。10 という値は変えることが出来ません。デルファイの変数宣言の仕方とは少々違うんですね。デルファイでいうと条件式に似てますね。


■関数
デルファイにも関数があるようです。2つのタイプの関数があってそれぞれ機能が異なります。

 ・procedure ←値を返さない
 ・function ←値を返す

それぞれ見ていきましょう。

・procedure

書き方はこのとおりです。これで Kansu_kun01 という名前の関数ができました。戻り値は無く、処理をするだけの関数です。

procedure Kansu_kun01 ( HIKISU_MOJIRETU : String );
 begin
 処理;
 end;

引数はセミコロンでつなぐことで複数指定することが出来ます。さらに呼び出すときには次のようにします。

begin
 Kansu_kun01( 'Hello_World' );
 Readln;
end.

このとき、呼び出す前に関数を宣言および作成しておかないと、エラーになってしまうようです。


・function

書き方はこのとおりです。これで Kansu_kun01 という名前の関数ができました。戻り値がありますので、処理をして値を返します。おそらく、Result に値を設定することで戻り値として吐き出せるのでしょう。

function Kansu_kun02 ( a : Integer; b : Integer ) : Integer;
 begin
  Result := a + b;
 end;

var
 test_kekka : Integer;
begin
 test_kekka := Kansu_kun02 ( 1, 2 );
 Writeln ( test_kekkakekka );
 Readln;
end.

こちらも、メイン処理にて関数を呼び出す前に、関数を宣言および作成しておかないと、エラーになってしまうようです。


・メイン関数

メイン関数は関数宣言せずにいきなり begin で始まり、end. で終了します。こんな感じです。

begin
 処理;
end.

上記でも度々登場していますね。

この辺で1000文字を超えてきたので一旦区切ることにします。

それではまた。

デルファイのお勉強03

前回『https://somegoro.blogspot.jp/2016/08/blog-post_6.html』に引き続き、デルファイのお勉強をしていきます。今回も参考資料は次のサイトを使用させていただきます。

クジラ式 Delphi 資料
http://oto.chu.jp/a.oto.chu.jp/kujira/text/delphi/index.htm

それでは始めましょう。

■型変換について
・IntToStr() は、Integer 型から、String 型に変換する処理。中身にInteger 型を入れれば、String 型で吐き出してくれる。

・FloatToStr()は、 Double型から、String型へ変換する処理。上記と同じ感じ。

・ Delphiには親切なヘルプが付いているらしい。どうやってみるのだろうか。

・Trunc( ) は、少数点以下を切り捨てる処理。

・Round( )は、 小数点以下を四捨五入する処理。
・Readln()は、ユーザーから入力を得る処理。中身の変数で入力を受け付ける。

・StrToIntDef( , )は文字列から整数に変換する処理。
二つの引数を指定する。最初に変換対象、次に変換できなかった時に吐き出す値。
すると、今まで変換できなくいとエラーとなって終了になってしまっていたものが、終了にならずに第二引数で指定したものが吐き出される。

■条件分岐について
・if 条件式 then 
  処理01;
 else
  処理02;

条件分岐処理は上記のように記載する。

・条件式は次のとおり
a = b
a > b
a < b
a >= b
a <= b
a <> b

・併せて書くとこんな感じになる

if a = b then 
  処理;

aとbが同値ならば配下処理を行う。
このとき、かっこがないのでわかりづらいけど都合よく次の処理を実行してくれる。
同値でないなら次の処理を飛ばして、その次の処理に行く。
else もふつうに使用できる。これもかっこは必要なし。
  
わかりやすく書くとこんな感じになる。(もちろんこれでも正常に機能する)
  
if ( a = b ) then 
  処理;

・and で、複数の条件式で判定する

このように書くと複数の条件で条件分岐処理を書くことができる。and は、「かつ」という意味です。一般的な言語と変わらないですね。

if ( a = b ) and ( a = c ) then 
  処理;

・or で、複数の条件式で判定する

このように書くと複数の条件で条件分岐処理を書くことができる。or は、「または」という意味です。一般的な言語と変わらないですね。

if ( a = b ) or ( a = c ) then 
  処理;


■ラベル
関数の名前みたいな感じでしょうか。ラベル名の下に処理を書きます。これもカッコなどでは囲わないので改行でまとまりの終了が判断されます。
ラベル名01
 処理01;
 処理02;

ラベル名02
 処理01;
 処理02;

こんな感じで書かれます。私を含め、今時の言語になれた人には違和感を感じますね。

・begin の前に宣言します。

・label NANTOKA_LABEL;
このように終了はセミコロン;です。

・label NANTOKA01_LABEL, NANTOKA02_LABEL;
2つ以上宣言したい場合はカンマ(、)で区切ってこのように宣言することができます。

・goto ラベル名;
これでラベル名の処理が実行されます。

さて、1000文字を超えたので、この辺で区切ろうと思います。

それでは。

デルファイのお勉強02

前回『https://somegoro.blogspot.jp/2016/08/blog-post.html』に引き続き、デルファイのお勉強をしていきます。今回も参考資料は次のサイトを使用させていただきます。

クジラ式 Delphi 資料
http://oto.chu.jp/a.oto.chu.jp/kujira/text/delphi/index.htm


それでは始めましょう。
GUIはコンポーネントをクリックするだけで画面上に対象のコンポーネントを表示させることができると紹介した。

ではもう一つのタイプのCUIはどうでしょうか。これはコンソールタオイプの画面ですね。図とかは表示させることはできません。しかし文字は表示させることが可能です。Windowsで開発の場合、一般的にはMS-DOSプロンプトを使うことになるでしょう。

このCUIは機能確認のときにあ便利らしいです。なぜかは今のところ、わかりません。それでは進んでいきましょう。


■コンソールについて
・コンソールの時も 処理はbeginからend.までの間に記載します。

・コンソール版でもエラーは出る。型が合わないものを入れたりしようとすると。
  どういう風にでるのかは不明。実際に試してみたいけど、これ(デルファイ)無料なのかな??


■処理について
・Readln;は、キーの入力待ちをする処理です。

・Writeln('ここに表示したい文字または数字を記載する。');という処理です。

・Writeln(この中では演算処理も可能);という処理です。

・演算子modは、割り算の余りを出してくれます。


■変数について
・変数は var Test : Integer; こうやって書く。
  この場合 var が変数宣言。Testが変数。Integer が型。

・変数宣言は一回書けば良い。だから2個の変数を扱いたいときは次のように書く。
  var
      Test01 : Integer;
      Test02 : Integer;

・変数はbeginからend.までの間には書けない。じゃどこに書くのっていうと、begin の前。
  宣言するみたいな感じですね。

・変数の代入の仕方  Test := 10000000000000; これで変数Tstに数字10000000000000を代入することが出来た。みづらいかもしれないから全角で書くと、:=となっている。

・デルファイは大文字小文字の区別をしない。
  だから変数書くときには要注意。文字検索では引っかからなくとも、実際には同じ変数というのがある。


・変数の種類
変数にはいろいろなものがありますが代表的なものです。代表的なものは他の言語と変わらないですね。

 Integer  整数
 Double  実数
 String  文字列
 Boolean  真または偽
 Char  文字型かつ半角一文字

・配列型変数

上記の方法では、変数を100個宣言するのは非常に大変ですね。そこで便利な宣言方法があるのです。それが配列型変数です。

HTest : Array [ 1..100 ] of Integer;

これで変数を100個作成することが出来ました。 HTest[1], HTest[2], HTest[3] という感じで、  1~100までの配列型の変数ができています。

また、こうすれば値も入力できた状態で変数を宣言することができます。

var
 kokugo : Array [ 1..5 ] of Integer = ( 10, 20, 30, 40, 50 );


・ローカル、グローバル

これも他の言語でお馴染みのものです。デルファイにもあります。

ローカル変数は、関数内で宣言したもので、宣言した関数以外の関数内では使用することが出来ません。

グローバル変数は、関数の外で宣言されたもので、プログラム全体で使うことが出来ます。



そろそろ1000文字を超えたので区切ります。
次回お楽しみに。(おもてなしする文章ではないですね(^^;))


デルファイのお勉強01

ここで唐突にデルファイのお勉強を始めます。

まずデルファイとは何なのか確認してみましょう。

Delphi
Embarcadero Delphi (エンバカデロ デルファイ) は、コンソール (CUI)、デスクトップ (GUI)、Web、モバイルアプリケーション開発のための統合開発環境 (IDE) である。

wikipedia(https://ja.wikipedia.org/wiki/Delphi)より


統合開発環境なんですね。言語じゃなくて。

じゃ言語は何なの?というと今のところ不明です。wikipediaには記載なしでしたが、このまま調べていけばわかることでしょう。

とりあえず今回はわかることをザッと書いていきます。

次のお方のサイトが非常に見やすいんじゃないかと思いましたので、確認するサイトはこれらを見ていこうと思います。

クジラ式 Delphi 資料
http://oto.chu.jp/a.oto.chu.jp/kujira/text/delphi/index.htm

Delphi入門
http://www.w-frontier.com/delphi/index.html


イメージとしては「C++ Builder」に近いらしいです。同じボーランド社発のものですし。


さて、お勉強にあたって引用記載はしない方針でいきます。(引用と記載することや引用箇所を明示すると、学習の流れの妨げになるためです。) 一般的なプログラミング手法で書きつつ、上記サイトで紹介されていることの要点をまとめる形式で備忘録的にブログを書いていこうと思います。

それではスタートです。

・早速出てきました。 言語はDelphi言語というらしいです。
・部品コンポーネントをクリックすることで画面を作っていく。
・F9で実行

・部品コンポーネントを置いただけでは表示されるだけ。実際の動作は自分でプログラムを記載しないといけない。

・ボタンコンポーネントをクリックすると、画面上にボタンが現れる。そのときのプログラムは次のとおりである。
 procedure TForm1.Button1Click(Sender: TObject);
 begin

 end;

この begin end 間にプログラムを書いていく。うん、今のところ実に簡単だ。

・ポップアップメッセージの出し方。先ほどの容量で次のように記載する。
 ShowMessage('ここにポップアップメッセージを記載する。シングルダッシュで囲ってる');

・テキストエディタの内容をポップアップ表示させる方法は次のように記載する。
 ShowMessage(Memo1.Text);

このとき、Memo1はおそらくテキストエディタのIDのことでしょう。IDは自動割り当てなのかな。記載していなかったけど。そのIDはどこを見れば確認することができるのだろうか。


この辺で1000文字を超えてきたので一旦区切ることにします。

それではまた。


上司がクソ野郎になってきた

上司がクソだ。 全然勉強していなくて話が通じなくてクソ REST知らないってどういうことなんだろう。弊社標準になってから久しいJavaをまともに組めないってのはどういうことなんだろう。 計画上では詳細設計フェーズが半分を過ぎようというときに要件定義できていないってのはどう...