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

〇〇エンジニアの生存戦略 ~ 「【まつもとゆきひろ氏特別講演】 若手エンジニアの生存戦略」を聞いて

〇〇エンジニアの生存戦略

この記事は、
2017/05/20 「【まつもとゆきひろ氏特別講演】 若手エンジニアの生存戦略」 を聞いて、自分も発信してみたいと思ったことを感想とともにまとめたものです。

発信したいこと

  • 技術に目を向ける
  • やりたいこと
    • 学ぶ
    • 実践する
    • 発信する
  • 一人のエンジニアとして自立
  • 自立の先にあるもの
    • もう少し自由になれる
      • まつもとゆきひろさんの講演より
        • 理不尽を拒否
        • 鈍感になる
        • プログラミングを極める
        • 人間心理に興味を持つ
  • 〇〇エンジニアの生存戦略

技術に目を向ける

社内勉強会をやろうとしたことの理由です。
社外勉強会で高度な技術を持ち楽しんで発信している人がいる。
これを自分のいるところでもやりたいと思ったのです。

勉強会によって

  • 学ぶ機会を作り
  • 学んだ成果を実践し(これはお仕事)
  • 実践した成果を発信する

これを行うことによって、知識を広げたり深めたりしたいです。

自立する

私たちは勉強会をすることで、きっと、自立できます。
自ら課題を見つけ、解決策を導き出せます。

多くの組織では、新人研修を行って必要な技術力を身に着けていますが、それだけではなく、自ら問題を発見し、解決できるという意味の自立です。

自立の先にあるもの

「もうすこし自由になれる」

エンジニアとしての自立の先に、もう少し幸せな未来があります。

2017/5/20
「【まつもとゆきひろ氏特別講演】 若手エンジニアの生存戦略」

最近、まつもとゆきひろさんの講演を聞いてきました。
「若手エンジニアの生存戦略」についてのお話でした。

ちゃんとした要約は以下のブログが分かりやすいです。

zuckey17.hatenablog.com

この講演のさわりについてご説明します。

若手エンジニアの生存戦略

  • 理不尽を拒否
  • 鈍感になる
  • プログラミングを極める
  • 人間心理に興味を持つ

これは、若手に限らず、技術者が技術者として生存するために必要なことだと感じました。

理不尽を拒否・鈍感になる

Matzさんは、東京への就職を避けて浜松の会社に就職しました。
そこでスーツが嫌でジーパンTシャツ出社をやってみて、
揉めるだろうと踏んでいたが案外だれからも文句を言われなかったエピソードから、

  • 我慢に価値はない。理不尽は拒否しなければならない
    • 「結果よりも過程」
    • 「生産性よりも忍耐」→理不尽
  • 組織の上から下まで、勘違いしている。社会的圧力に対して鈍感になろう。
    • 労働は我慢ではない。
    • 報酬は苦痛の対価ではなく、価値を提供することの対価。
    • 雇用関係というものは、もっと対等なものである。
    • 社会的圧力が生まれてしまっている。

というお話をされました。

私は組織の中で生きているので、何かと我慢することはありますが、
これからは我慢する前に、それが本当に価値につながっているのか、
見直せるようになれればよいと思います。

また、この話をポジティブにとらえると、

  • みんながやらない、やってもいいことがある

ということで、それは「ずる」ではなく「裏技」と話していました。

この間、社内勉強会を、前例がない中思い付きでやってみましたが、
案外誰からも怒られませんでした。 やってもよいことは、実は身の回りにたくさんあるのだと思います。

理不尽を拒否する方法

理不尽を拒否する方法として以下の項目が挙げられました。

  • 価値観にアプローチ
    • しかし、他人は変えるのは難しい → 無理なら逃げる
  • 社会的圧力を自覚する
    • 他人を変えられないにしても、圧力を自覚すれば、変えるなり逃げるなり判断できる。
  • 理不尽に対して声を上げる
    • (プラカードをもって行進しなくてもいいでしょうけれど、できる範囲で行動する)
  • 選択肢はWin-Win か、取引しない
    • 両方に得るものがなく力だけを使う「綱引き」は無駄

最後の質問タイムでも、「勤勉に価値を置く上司を潰すには」という質問がありました。

  • 成果によって黙らせる
  • 成果でも黙らない上司には
    • 上司の上司に言う
    • 逃げちゃう

この流れの中で印象に残っている言葉が「価値観」です。
身の回りに様々な理不尽があるとして、
まずは「技術」という価値観を多くの人で共有して、それを物差しにして
理不尽なことを、必要に応じて拒否していければよいと思います。

また、その物差しを使って判断する力は、技術者としての自立ではないかと思います。
学び、実践し、発信し、そして学ぶ。その自発的な繰り返しによって得られる自立によって、
今我慢しようとしていることに価値があるか判断でき、
意思表示ができるようになると思います。

今、勉強会をやろうとしている理由は、単純な理由ではありますが、
「若手エンジニアの生存戦略」につながるものがあると思いました。

〇〇エンジニアの生存戦略

皆様

  • 技術者として幸せですか?
  • 今一度、技術に注目しませんか?
  • 技術という物差しを手に入れて、技術者として自立して、
    我慢をやめて、理不尽を拒否して、本当に生み出したい価値を生み出しませんか?

2つの分野を学び、相乗効果をいかにして出すか

ずっと、どうやったら「簿記」「プログラミング」の知識を生かすことができるか、考えて生きていました。

私は、中学で初めてプログラミングに触れ、商業高校に入り、簿記とプログラミング(COBOL)を学びました。

商業高校では当たり前のように簿記とプログラミングを学びますが、双方を学ぶことの意味は知ることができませんでした。なんとなく「会計ソフトなら作れそう」と思ったことはありましたが、周囲をみると、簿記とプログラミング両方を生かせる仕事に就いた人は少なかったように思います。

そして、商業高校から工業大学・大学院と進みました。

とても苦手だったはずの簿記を忘れ去ることができず、日商簿記検定2級を何度も受験しては落ちました。他学部の簿記の講義を聴きに行ったりと、理系の学生としては半端なことを続けてきました。何とか卒業までに2級に合格できました。

その後会計ソフトを作る会社に就職しました。

そこでは簿記の知識を少し使いますが、特に「1級取れ」といったことはなく、持っている知識で十分やっていけました。でも、今も簿記1級の勉強をしています。

 

今まで「簿記」「プログラミング」両方をやってきて、いろんな人にいろんなことを言われました。

  • 「エンジニアとして基礎技術を学んだほうがよい」(エンジニア)
  • 「簿記1級なんて言ってないで税理士試験に受かりなさい」(税理士)
  • 「簿記1級なんて取ってもオーバースペックじゃないの?」

勉強していても、仕事していても、なかなか2つの分野は繋がらないことを感じましたし、周囲からは意思とは異なる助言を多方から受けることもあり、どうしたらよいかわからなくなることもありました。

結局、「この組み合わせを生かすことができる人は、自分自身以外には存在しない」と感じました。 誰も、今ある仕事をできるようにすることしか、助言できません。

あまり見られない技術の組み合わせを真に生かすためには、自らその価値を作り出さなければなりません。黙っていては中途半端なプログラマか、中途半端な経理になるだけです。

大きなイノベーションは、分野と分野の中間地点で起きるといわれます。
(簿記とプログラミングに関してはすでにFINTECHでにぎわっていますが)
異なる2つの分野を追い求めることは、夢のあることで、楽しいことです。

 

分野の重なる部分にある、大きな何かを取りに行くのです。

 

今、商業高校生が何をしているか知りませんが、
商業高校を出てきた人には、その幅広い学びを最大限に生かしてほしいと思っています。どうか、誰かの声に正直にしたがってしまい、スケールの小さいことにとどまらないでほしいと思います。  

宝物は、ちょっとだけ学んだ個々の科目ではなく、それらを組み合わせたり掘り下げたりすることによって生まれる大きな成果です。

 

【参加レポート】.NETラボ 勉強会 2017年3月


dotnetlab.connpass.com

.NETラボ 勉強会に参加してきました。
少し年齢層が高めでまじめに参加できました。

マイクロソフトMVPアワードプログラムのご紹介」 Microsoft MVP for Windows and Devices for IT 木澤朋和 氏

自分には遠い世界の話に思いますが、マイクロソフトMVPの話でした。
制度が変わり、申請のチャンスが増えたそうです。

自分には遠い世界の話ですが、.NET 技術をこれからも地道に勉強したりアウトプットしたりしていきたいです。

「今こそMicrosoft Bot Frameworkを学ぼう」 中島進也 氏

「BotFramework と LUIS を使ったアプリの開発」 横浜 篤 氏

Azureを全く使ったことがなかったので、
Bot FrameworkもLUISも知らなかった。

でも、今回二人のお話を聞いて、簡単にBotが作れることがわかりました。
簡単に作れるとわかれば、できそうなことはいくつか思いつきます。

定型的だけどちょっと面倒なコミュニケーションの節約です。

ただし、ちょっと気を付けたいのが、組織内プライベートの利用を認めていないことです。
そこがむずかしいですね。たとえばサポートでBotを活用するという話をききますが、
直接お客さんとコミュニケーションさせるには物足りないということが考えられ、
内輪で使用したうえで、人間によるサポートに役立てたいという動機があると思うからです。

ともあれ簡単です。

「最近流行りのエンジニア田舎へ移住ってどうなの?」 藤原隆博 氏

田舎に移住ってどうですか?
支援制度を活用して兵庫県の田舎に移住しませんか?という話。

まあ確かに、東京で消耗するという面は少なからずある。

個人的には、例えば長野県で暮らすとかだったら、それも人生の見通しが立っているなら、
ありかもしれないと思えなくもない・・・。

西のほうなのでさらにハードルは高くなってしまうけれど、
魅力的な田舎のお話でした。

「進化するEdge! ~Creators Update版の新機能から既存機能までまとめて解説~」 日本マイクロソフト テクニカルエバンジェリスト さっくる 氏

Edgeってすごく進化しているらしいです。

進化するEdge! ~Creators Update版の新機能から既存機能までまとめて解説!~

特に気に入ったのがタブの保存機能。

Operaはタブのサムネイルを自由な大きさで表示でき、重ねてグループ分けできて好きだった。
それに似たことがEdgeでできるようになってしまう。

まさに最強伝説。

この他にもいろいろ機能が追加されます。

感想

私は .NETといっても WPFやXamarinでアプリ開発するだけだったので、Bot Frameworkなどの話は全く知らない情報でした。新しい情報を知ることで、視野が広がり、「あんなことができそう」だと思えました。

自分の無知さが恥ずかしくなったので、これからさらに.NET技術を勉強していこうと思います。

【参加レポート】今さら聞けないJSフレームワーク一挙入門!【React、Angular2、Vue.js】

今さら聞けないJSフレームワーク一挙入門!【React、Angular2、Vue.js】に参加してきました。
今回、初めて懇親会もある「勉強会」に参加したことになります。

内容

React、Angular2、Vue.js + phina.js の豪華4本立て。

最近は、jQueryではなくこのようなライブラリが出てきて、AngularがいいかReactがいいかと、一人で悩んでいました。それを解決するための良い機会となりました。

React、Angular2、Vue.jsと、3つのフレームワーク(ライブラリ)の概要を知ることができ、それぞれのフレームワーク(ライブラリ)の大体の雰囲気を感じることができました。

懇親会

コミュ障ですが参加しました。
危うく孤立しかけましたが・・・。

それでも同じテーブルの方々と名刺交換させていただきました。
セッションで基本的な情報をインプットし、あとは懇親会で語り合うような形でした。

Angular2 つよい

ReactもつよいけどAngularが最近頑張ってるようです。

TypeScriptという言語は馴染みやすいです。
javascriptは確かにC++とかJavaを使っている人にとってはなじみにくいです。
TypeScriptによって従来の感覚で書けるのは大きいです。

Reactの場合はその文化になじめるかどうかという点が気になります。
ルートをたどっての片方向バインディングとか、デザイナーとの分業がどの程度可能かとか。
それと、Reactを覚えたらReactNativeで知識を生かせるのもいいと思います。
(ReactNativeってどうなんでしょう)
これからもう少し深く知ってみたいです。

始めやすいのは Vue.js

React か Angular2かという悩みを抱えていましたが、
jQueryつかってきたひとたちの未来には、Vue.jsがよさそうです。

まず、ReactとかAngular2とかは重いフレームワーク(ライブラリ)であること。

Vue.jsなら、jQueryと同じ感覚で、読み込むだけで使用できます。
現実的に考えると jQueryを使っている現場はたくさんあるし、
そこからの現実的な次のステップとしては、Vue.jsが選択肢となるのでしょう。

ReactやAngular2に比べて学習コストが少ないので、
まずやってみる、ならばVue.jsのほうがいいかもしれません。

感想

集まってきた人たちはいろいろでした。
学生さんが多くいましたし、仕事帰りの人も多かったです。
でもスーツを着たひとはほぼいませんでした!

私の日常の仕事にはフロントエンドもサーバーサイドもなく、これといった魂はありませんが、 ここには確かに、フロントエンドという世界の雰囲気がありました。

これからのフロントエンド開発はどうなるかという話も聞けました。

あとは、モダンWeb開発にどう入っていくかという課題については、
どうしても最近の開発は大それたもので、実際必要としていたものはもっと小さいものだったりするし、
フレームワークやライブラリには、学習コストや、それぞれの規模があるし、相性もあるので、
トレンドをつかみつつ、流されず、まずは小さく始めていきたいと思いました。

未来はどうなるかわからない。3年前には予想もつかなかったし、3年後はなおさらわからない。
死んだ技術を数えてみればいくつも浮かんできます。

残らない技術をつかむとしても、それでもやっぱりたくさん作らなきゃ強くなれないと思います。
保守的は保守的でいいのですが、やっぱり、何かを思いつくなら作りたい。

作っても作らなくても技術の進歩は加速してしまいます。
Prototypeに乗り遅れ、jQueryにも乗り遅れ、
モダンWebにも乗り遅れるわけにはいきません。
作らねばなりません。

こういう懇親会のようなイベントでは、まだまだメリットを出しきれていない自分ですが、
諦めずにまた参加したいと思います。

DroidKaigi 2017 感想

DroidKaigi 2017 に参加してきました。

droidkaigi.github.io

Androidのことはほとんど知らないのですが、 開発全般の広範に渡り学ぶことができるため、参加してみました。

全体的な感想を書いておきます。

1日目のこと

pgcityblog.hatenablog.com

2日目のこと

pgcityblog.hatenablog.com

Material Design

いたるセッションで Material Design が取り上げられていました。それだけよい思想なのでしょう。
Material Designでなくても、何らかのデザイン思想に基づいてソフトを作るべきですが、周囲を見るとなかなかそうなっていない場合が多いです。 あと、どうしても、動きの部分については何も思想を持たず何もせず、いまいちの出来具合ということが多いです。 これからMaterial Designなどのガイドラインを見て、意図をもってUIを作っていきたいと思います。

  • まずはMaterial Design のガイドラインを読む。
  • 身の回りのUIについて考える。

MVVM

MVVMが多く取り上げられていました。 しかし、MVVMのセッションの前の話題提供で「MVVM使ってる人」という声に反応があまりなかったので、Androidの世界でどの程度普及しているのだろうと、疑問に思いました。

WPF, Xamarinだと、自然とMVVMできるんだからやろうという気になりますが、Javaの世界だとどうなのでしょう。しかし、いい考え方なのできっとこれから普及していくと思います。

  • XamarinでMVVMを学ぶ

開発の進め方

リファクタリングの話、プロジェクトの体制の話。 思ったことはAndroidアプリ開発のプロジェクト規模は小さく、短期間であることです。 エンジニア自分ひとり、みたいなところも普通にありそうですが、ちょっと寂しい感じもしました。 だからこそDroidKaigiの存在価値があるのかもしれません。

こんなスピード感がある開発はうらやましいです。

  • レガシーな部分でもなんとかスピードを上げていきたい。工夫する。

今回、いろいろな話を聞くことができ、私はAndroidエンジニアではないのですが、日常の学んだことを取り入れてみたいと思いました。 今度はAndroidでアプリでも作って、来年、より有意義な形で参加できたらよいと思います。

DroidKaigi 2017 ~ 2日目

DroidKaigi 2017、 2日目のセッションについて書きます。

1日目はこちら

pgcityblog.hatenablog.com

Xamarin.Android で始めるクロスプラットフォームモバイルアプリ開発 (@amay077 氏)

かろうじて触ったことがあるXamarinですが、
じつは・・・Xamarinって、Android大好きでバリバリ書いてる人には不要?
という話がオチにあって、まあそうですね。せやな。

Xamarin好きなので今後も勉強していきます。

Xamarin.Android で始めるクロスプラットフォームモバイルアプリ開発 #droidkaigi #droidkaigi1 // Speaker Deck

未熟なチーム開発 (@kgmyshin 氏)

未熟なメンバーのチームで、どうやって無事リリースまでもっていくか。

知識がある人が設計の部分でお膳立て。
新卒育成は守破離で。

秩序とスピードを生み出すこと。

よくあることで、共感しました。 よく、あれこれ話し合っている割には何も決まらないことがあるけれど、
その中でも「決める」ことを意識することが必要なのかなと思いました。

unskilled_team_development_for_droidkaigi // Speaker Deck

Data Binding で実現する MVVM Architecture (Kenji Abe 氏)

MVVMとは、Model View ViewModel の3つで構成されるアーキテクチャ。その根幹には、Viewの値とViewModelを結びつけるデータバインディングがある。Viewに値をセットする取得する追加する削除するという考え方ではなく、ViewModelのメンバの値をそのままViewで結び付けて表示すします。

今まで直接Viewをプログラムで操作していたころは、結構値のセット漏れとか、ちょっとしたことで、動きに一貫性がなくなったりしていましたが、ViewModelの値をそのまま使うならばもれなく与えたデータの通り表示できます。
一度MVVMをやってしまうと、もうデータの追加とか削除とかが面倒になります。
きっとこれから重要になってくると思います。

それとMVVMの源流は WPFらしいです。
.NETでMVVMを学ぶのはよいことなのかもしれません。

DataBindingで実現するMVVM Architecture // Speaker Deck

エンジニアが武器にする Material Design (瀬戸 優之 氏)

エンジニアがデザインをできるようになろうという話でした。
もちろん、「ガイドラインを読もう」という話がありました。

ソフトのデザインは単にアイコンを作ればよいわけではありません。動きを含むユーザー体験全体に責任を持たなければいけないのですが、デザイナーがアイコンをくれたから適当に表示して動けばOKと思ってしまいがちです。私は。
もっとアプリ技術者がデザインに責任を持たなければならないということです。

アプリ技術者の中にも、デザインセンスが優れた人がいるかもしれません。 「デザインエンジニア」という新しい枠ができたら、よりよいアプリを作れることでしょう。

エンジニアが武器にするMaterial Design // Speaker Deck

pgcityblog.hatenablog.com

DroidKaigi 2017 ~ 1日目

XamarinとAndroid Wearぐらいしか触ったことがなかったのですが、DroidKaigiに行ってきました。Androidというくくりなので、話題の幅が多岐にわたり、Androidのことも学べるし、開発全般についての知見も得られると思い、参加してます。

技術的に詳しくないことが多々あるので、きちんとしたレポートはできませんが、何か書いてみます。

まず、スライドのまとめ記事がありましたので、これを見ながら思い返してみます。

freelance.levtech.jp

逆引き マテリアルデザイン(荒木 佑一氏)

マテリアルデザインの話です。
デザインのことは全く素人なのですが、デザインのことを考える入り口として、マテリアルデザインを学んでみたいと思いました。

以下の内容が気になりました。

  • しっかりとしたガイドラインがある。 → 登壇した人みんなが読むことを勧めていたように思います。
  • タッチフィードバックを入れましょう → 自分は一切入れていませんでした。今までずっと、もっさりしたソフトを生み出していました。

まずはガイドラインをしっかり読みたいと思います。 WindowsでもMetro UIガイドラインはしっかりしたものがあるのか気になりました。

スライド 逆引き マテリアル デザイン

リリース自動化と効率の良いリリースフローを求めて(Ryo Sakaguchi氏)

Android特有の話はあまりわからなかったのですが、ためになりました。

  • ミス防止、属人化防止、そして本質的な業務に注力。
  • git push origin master したらリリース。というのが理想。
    Git-Flowが基本となる。そしてCIの紹介。

週1リリースしたいです。
その前に年1リリースを実現したいです。
小さくて速いモバイル開発の知見を、レガシーソフトウェア開発でもうまく取り入れられたら良いと思います。

スライド リリース自動化の導入と効率の良いリリースフローを求めて // Speaker Deck

大規模アプリのリノベーション(北村 涼 氏)

ためになりました。
古いアプリをリノベーションしていくことの実際を知ることができました。

ドメイン知識の獲得

  • 紙に印刷して画面を知る。あるべき名前に変えていく。

画面を洗い出して印刷することに共感しました。
調べてみると知らない画面がたくさん出てきますよね。
ほかにいい方法があれば知りたいところですが、こうするしかなさそうという感覚です。

設計

  • ライブラリを上げまくる
  • アーキテクチャ。守るのではなく、着くずし。
  • 「設計が確認できる程度のサンプルアプリを作る。」

サンプルを作るのは、いいアイディアだと思いました。
設計が確認できる程度というのが大事なのだと思います。

その後MVVMのようなモデルを採用した話になりました。 ViewModelは階層を持つようにしたという点。なんとなくそうなのかなと思っていたのでスッキリしました。

「見積る」ことが大事とのことです。 1~2週間ごとにリリースして様子見するとのこと。
短い間隔でのリリース体制はある程度前提かもしれません。

スライド droidkaigi-2017-renovation // Speaker Deck

Android アプリ開発の体力づくり(@operandoOS 氏)

初心者向けセッション。とはいっても DroidKaigi ですから、超初心者はほとんどいませんでした。 作りたいものを小さく早く作っていくのが大事ということなのですが、私はできていない。
早く何か形にしたいと思いました。

Material Design おすすめされていました。読みます。

Instant Apps というものがあるらしい。
インストールしなくても動くアプリとのことで “すぎょい”
だがしかし、勝手に未知の機能が立ち上がる未来を想像して、完全にそうなったらちょっといやかなとも思った。

スライド https://speakerdeck.com/operando/androidapurikai-fa-falseti-li-dukuri

ReactNativeはクロスプラットフォームモバイルアプリ開発の夢を見るか(中川 幸哉氏: @Nkzn)

ReactとReactNativeの話。

Reactを覚えると、似たような感じでReactNativeが使える。
Reactをまず知っている必要があり、Reactの世界に足を踏み入れる必要があるものの、入ったら結構まとまっていて、効率の良い開発ができるのではないだろうか。

Xamarinとは相容れない?
でも、どちらも知っておきたいです。

銀の弾丸はない」ということです。
クロスプラットフォーム界隈の人々は必ずそういいます。

React Nativeはクロスプラットフォームモバイルアプリ開発の夢を見るか #DroidKaigi