読者です 読者をやめる 読者になる 読者になる

たごもりすメモ

コードとかその他の話とか。

おぺかじの話のはなし

Operation Engineers' Casual Talks というイベントが行われます。で、そこで話すことになってます。

Operation Engineers' Casual Talks | イベントアテンド [ATND] でイベント作成・チケット販売・参加者の出欠管理

開催が12月中旬の金曜夜なので、定員100人に現状107人となってますが、たぶん余裕で3〜4割はドタキャン出ると思います。普通に師走で忙しい人が多いだろうし、これから忘年会が入るひととかいるだろうし。だから補欠枠をがつんと広げた上で補欠の人は全員来るくらいでいいと思いますね!

とはいえ詰まらない話しかしないのに人がいっぱい来て残念でしたということになってもアレです、が、自分の話はともかくfujiwaraさんの話とかトークセッションとか面白いことは確定しているようなものなので、みんな来るといいと思います。

「ほげエンジニア、の定義について」

ところでこのようなタイトルにしておいたんですが「わからん」「わからん」「何の話だ」とたいへん好評をいただいてます。多少分かるように、先日内容(の案)を書き出しておいたものから簡単に抜粋しておくと、以下のような話になる予定です。だいぶモヒモヒしく語ります。本番は4以降ですね。

時間の制約もあるので全部話せるか、一部削るかは分かりませんが、意識高くいきたいと思いますのでみなさまもぜひ意識を高めてご参加ください。面白い話にできるといいなーと思ってます。

1. 言葉の定義を確認しよう

言葉の意味は使う人によって異なる、プログラマとデザイナーと企画でも違う可能性がある、それを常に意識しておくべき

2. 誤解の余地の少ない言葉を使おう

別の職種の人と共通して理解できる言葉を使おう

3. 言葉の原義と一般的な意味を大事にしよう

「エンジニア」の定義について

4. 自分のことをどう呼ぶかを大切にしよう

自分のことを何と呼ぶか、は、自分が何をする人なのか、という自意識に影響を与える、無意識の内に縛る
「インフラエンジニア」という言葉を使う人は「UIを書かない人」だと思っていないか? 「コードを書かない人」だと思っていないか?

世の中の似た職種の人が何と自称しているか、を真似て自分の役職を決めるのはやめよう

自分が何をどう解決する人なのかを考え直してみよう

5. コンピュータシステムスタックを意識しよう

あなたはどこをやる人?
・いわゆる基盤部分の人は物理面に近いところ(はエンジニアリングじゃないかも)からサーバサイドアプリケーションまでやれないと駄目
UNIXの基礎やらネットワークプロトコルやらまで知ってないとダメ
・(社内システムなどを作る場合に)UIを作れないとダメ

分業はできないと思わないといけない

何でも相手にしろ、泣き言は誰も聞いてくれない、覚悟を決めろ

6. プログラムを読めること、書けること
「ソフトウェアエンジニアリングの力」=「プログラマブルに物事を解決できる力」それ以外は全て余技といってもいい

Chef等の運用ツール、Fluentdプラグインなどのコード、いろいろあるけど、結局はプログラミングの恩恵をあずかる範囲を広げただけ

自分のやる範囲が広過ぎることは分かっているんだから、プログラミングの力を最大限に使って対抗するしかない、今も昔も

コードを読め、コードを書け、問題はコードで解決しろ

7. なんかキャッチーな結論