ぼくはラクしたい

ITエンジニアの備忘録…時々趣味

Developers Summit 2018 in Fukuoka 行ってきました

いってきましたので簡単に所感を書きたいと思います

Developers Summit 2018 FUKUOKA

所感概要

セッション全体の雰囲気

  • セッションのメインはやっぱりクラウドサービス系でしたね
  • ゴールドサポータがGoogle Cloud , AWS プラチナサポータがMSだったので
  • GCP, AWS, Azureの話が結構目玉だったのかなと
  • 私はWeb系じゃなくてがちがちのNative業務系アプリ開発よりなんであまりなじみなかったですが

個人的に印象に残ったセッション

  • 興味深かったのはGMOペパボさんのエンジニア教育に関するセッションです
  • GMOペパボカレッジ という第二新卒中途向けの短期集中型研修に関するものでした
  • 1年半前まで消防士で、現在はSSHサーバー作ってるって方が印象強すぎました(笑)

所感詳細―『スーパーエンジニアを「育て」られるか? - ペパボのエンジニア教育の挑戦』

https://event.shoeisha.jp/devsumi/20180906/session/1783/

短期集中ということ

  • 期間は1か月
  • 範囲は広い(マインド面、ツール、front/back end 、インフラ...etc)

第一線で活躍するメンバーを講義担当者にアサインする姿勢

  • 各分野のエキスパートが講義を担当するらしい
  • そういう意味もあって短期なのかも(インフラ構築・構成管理:3日!とか)

まとめ

  • 「現場の人が」、「短期で」、教え込んでいくというのがうちの会社と真逆だなと感じました
  • あとエンジニアとしてのマインドセットを育てる部分もうちに足りてないとこだと思います
  • 技術研修について「完全理解より地図を描くことを優先する」という目的を設定しているのは妥当だなと思いました
  • エンジニアは今どんな知識があるより、必要に応じて調べ、吸収していく力が重要だからです
  • 研修以外の話もあったのですが、普通に魅力的な会社だなと思いました

【画像処理学習】Pythonでフーリエ変換

はじめに

画像処理の勉強シリーズです。
画像のフーリエ変換を実装してみます。

概要

  • 言語:Python3
  • パッケージ:PIL, numpy

github.com

使い方

ROOT python spectrum.py XXX.png

fft_img.pngというファイルが出力されます

新人研修を終えたエンジニアの卵達へ(2)

みなさん、こんにちは。

 

前回に続き、エンジニアの卵達に向けたコラムです。

sosomax.hatenablog.com

概要

  1. ベースとして持つべき意識
  2. コーディング作法
  3. ドキュメント作成作法(★今回はここ)
  4. 報告・連絡・相談(★今回はここ)

前回述べていなかった項目3と4について述べたいと思います。

 

3. ドキュメント作成作法

大前提として、相手が読みやすいと感じる文章を書くことが大切です。

如何に素晴らしいツールを作ったとしても、

相手に伝わらなければ無意味なのがこの世界のお約束なんです。

では、「読みやすい」と思ってもらえる文章とは?

ずばり 誤解を生まない 素早く読める 文章です。

 

 

誤解を生まない―語句の意味が明確であること

機能仕様書や報告書など、いわゆる技術文書の中では、

その文書の中でしか使われない一般的でない語句がしばしば存在します。

そこで重要なのが、その語句はどういう意味であるかが、

その文書内で説明されていることです。

 ※説明を記述した別資料へのリンクでもよい

 

誤解を生まない―シンプルな言い回しを用いること

読み間違えを引き起こさないようにすることも重要です。

そのためには、可能な限りシンプルな言い回しを用いること。

二重否定やはっきりと言い切らない言い回しは×です。

 

 

素早く読める―結論ファースト

まず結論を述べる。詳細な説明はそのあとに書く。

なぜなら、背景は最悪省くことのできる情報だからです。

国語の用語で言えば、「結論は述語」「詳細説明は修飾語」といった感じかな。

ITエンジニアは日々膨大な情報を整理、管理する必要があります。

したがって、「重要なこと=結論だけは把握しておこう」

という意識が働く傾向にあります。(経験則ですが…)

 

 

素早く読める―一般的なフォーマットであること

一般的なフォーマットで記述すれば「あぁ、その形式ね」て感じで、

どこにどんなことが書いてあるのかが読む前からわかる。

オリジナリティ溢れるフォーマットの場合、その「先読み」ができない。

この差は大きいですよ。

単に読む速度だけでなく、読み手のモチベーションにも影響を及ぼします。

もし、一般的なフォーマットより上質なフォーマットを思いついたのであれば、

それを是非公開して広めていってほしい。

それができないなら、大人しく既存フォーマットに頼ってください。

 

 

4. 報告・連絡・相談

報告・連絡・相談は、新人研修で必ず聞く言葉です。

しかし、それが何故必要なのか分かっていない人が意外と多い気がします。

これらは自分自身で「報告しておきたい」「連絡しておきたい」「相談したい」

と感じたときにやるものではありません。

 

 

先輩はあなたのことを信用していません

あまり良い気分はしないかもしれませんが、残念ながらこれは本当です。

信用は実績を積み重ねることでしか生まれない。しかし、君には実績がない。

仕方ないことです。

 

 

信用していない後輩が作業を行う しかし責任は自分にある

先輩の気持ちはこんな感じです。

イメージしてください。

自分の大事な預金口座の管理を名前もよく知らない怪しい人物に託す気持ちを。

 

 

今は信用してもらえないが信用を積み重ねていく=報・連・相

預金口座の管理を託した人物、よく知らない怪しい人であることは

どうしようもありません。だって、今出会ったばかりですからね。

では、その状態から信頼を積み重ねていくにはどんな人物であれば良いでしょうか?

長い間通帳も見せてくれず、通帳やカードを貸してくれることもなく、

こちらから問いただした時だけ、

「大丈夫、ちゃんと管理しています!(´・ω・`)」

と言う人を信用できますか?

定期的に自ら通帳を見せてくれ、

それまでのお金の出入りをはっきりと提示してくれる人であれば、

幾分か信用を得られるのではないでしょうか?

 

 

報連相まとめ

これが報連相をする際の考え方です。

後輩の作業を常に把握しておきたい先輩を心配させない為の行為なんです。

常に把握しておけば、何か問題が起きたとき迅速に対応できるからです。

一つ付け加えておくと、信用を築き上げることができれば、

もう報連相をしなくてよくなる……という訳ではありません。

ここでは、新人にターゲットを当てて話しておりますので、

誤解を与えかねない表現になってしまいました。

 

 

以上、エンジニアの卵達へ終了です。

次は何書こうかな~

新人研修を終えたエンジニアの卵達へ(1)

みなさん、こんにちは。

 

今回は新人研修を終えて実務に入る(実質はOJT)人達に言いたいことをまとめました。

 

なぜ書こうと思ったのか

僕の後輩社員で、頭は非常に良いんだけど、少し残念なところがある子がいます

どういったところが残念かというと

  • 学生プログラムを脱却できてない
  • 人に伝わりやすい文章が書けない
  • 見通しよく仕事を進められない

みたいなところがある

そこらへんについて僕の先輩たちが、「彼は実に残念ですなあ」ってなことをぶつぶつ話していた訳です。

でも自分が新人だったころを思い返してみると、同じようにできていなかったなと思う。しかも、直属の先輩社員がかなりきつい人だったもんで、必要以上に糾弾された覚えがある。

 

実際のところ、僕の会社での話しか分からないけど、エンジニアとしての仕事のやり方の第一歩目って痛い目見ることでしか教われない環境にある。気がする。

大事なことなのに、体系的にされず、誰も教えようとせず、でも文句だけは言うみたいな。これって、個人的には好きな流れじゃない。

 

なんで、ここら辺を体系化しておきたいなと思った次第です。

これからの後輩たちに一つでも有意義なアドバイスができるようにするための僕個人としての覚書ってな感じなんで、気軽に書きたいと思います。

 

ターゲット

ターゲットは「メンテナンス開発(自社製品・受託問わず)」とします。

僕の会社では、実務入りたてホヤホヤのひよこちゃんは、メンテ開発に就くのが主です。すでに携わっている先輩がいるし、新規プロジェクトの立ち上げよりも安定している確率が高く、まあお勉強をしやすい環境にあるからです。

ちなみに、僕の会社では受託が多く、ウォーターフォールモデルのがちがち開発が主になっています。なんで、以降の話では、アジャイルやってる人からすると「そうかあ?」ってところが出てくるかもしれませんが、悪しからず。

 

概要

  1. ベースとして持つべき意識
  2. コーディング作法
  3. ドキュメント作成作法
  4. 報告・連絡・相談

 

1. ベースとして持つべき意識

 

漏れなく・必要・十分に

やるべきことを漏れなくやること(あ、忘れてた…は許されない)

やるべきことだけをやること(不要な成果物を作って時間を無駄にしない)

やるべきことを十分に網羅すること

 

全てのタスクには達成条件がある

全てのタスクは達成条件が決まっている(はずな)ので、

ゴールに向かってまっすぐ進め(上記の必要十分と意味が重なるが)

逆に、達成条件が決まっていないタスクはやっても意味がないし、

進捗報告ができない

 

証拠(エビデンス)ファースト

製品を作るということには責任が伴う。

学生時代に研究用に作ったプログラムなんかとは全く違う。

一つでも要求と乖離した仕様、仕様と乖離した動作があれば、大問題だ。

開発業務の中で、要求定義や機能仕様レビューなどで、

顧客からの承認をもらう場面がある。

そういったとき、確かにOKをもらったことを証明するものを残さなければならない。

不当に責められたときには、証拠が役に立つ。

 

2. コーディング作法

 

変数名・関数名の命名には全力を注げ

アルゴリズムのブラッシュアップなんてあとででいい

意味の分からない変数名はつけない

役割の分からない関数名はつけない

まずは、可読性を意識してほしい

先輩たちは、超高効率なメモリ管理や超高速な計算処理を作ってほしいなんて

これっぽっちも期待していない

先輩たちは、「読みやすいコードを書いてくれ」って思ってる

読みやすいコードを書いてさえいれば、その他の指摘(機能性・拡張性など)はいくらでもできるんだ。

 

関数やクラスを自分で新規作成するな

基本的に良いプロダクトであれば、君が作ろうとしているような関数は

すでに誰かが作っているものだ。もしくは、既存関数の組み合わせで実現できるものだ。もしかしたら、それらの既存関数が君の心情に合わないアルゴリズムかもしれない。でも作らないでくれ。

大事なのは、「テストしなければならない関数を増やさないこと」なんだ。

有名な言葉で、「バグを生まない方法は、コードを書かないことである」っていうのがある。