つかぱい.com

つかぱいが思ったことを書いています。

少しだけ音楽を止めて、立ち止まってみると少し違う景色が見えた

来年はこの長い通勤をなんとかしようと模索しているのだけれど、なかなかうまくいかない(とりあえず何度も自宅脱出は試みるものの様々な要因に阻まれ出れない)

実際には月の半分も家にまともに帰ってはないけど

春先になったら多少痛みは伴ってもこの状態は何とかすると多少の希望的観測を持ちながら毎日電車に乗ってる。

ふと電車に乗ってる時に音楽を止めて、外を見回してみたらほとんどの人が寝てるかスマホをいじってたなーと思った。

別になんてことないことだったけど、半分働く人が乗るこの電車には楽しく電車を乗るという人が皆無だったんだなと改めて感じた。

ということは皆嫌々仕事をしているのだろうか?

行きたくもない都会の会社に行って、人間が詰め込まれたオフィスに缶詰の状態になりながら毎日を過ごすことに慣れきってしまっているのかもしれない。

Twitterを見ればもう冬場なのでボーナスがない、長時間労働だ、辛いの文字がたくさん並ぶし

友達からも「お前も大変なんだろ?」と言われて少しズキッとした。

別に普通で当たり前のことを言っているはずなのに、なんでだろうと考えた結果

あぁ今自分はやりたいことをやってるんだなと思った。

しかも楽しいし定時に帰りたいと思ったら帰れるし不満がそんなにないんだなということもに気づいた。

プログラマーには昔からなりたかったし、ブラックだとか言われても振り切ってこの仕事に入ってみたら案外そうでもなかった。

単純な違いは、効率化すると安月給だから給料が安い、ダラダラ残業したいという人がいるということだった。

でもどうしてズキっとしたのだろう?

多分今まで仲良しだった友人や周囲の人たちが大人になって共通する価値観の輪の中に入れなくなってきているのだということに少し戸惑いを感じているんだと思う。

とにかくみんなは大人になった自分は忙しくて大変な人間なんだと認めて欲しいのだ。

暇な人間は何もしてないやつで自分とは違う、自分の方がたくさん働いて偉いということを示したいということなのだろう。

ただその先には何も待ってはいないと思った。

どんなに頑張っても競合がいれば永遠にそのチキンレースをするだけですり減りながら勝ち取った椅子に座った瞬間過去の人になってしまう。

少なくとも自分は一回そうやってお金も時間も気力も限界まで使い果たしてとった結果そう思ったことがある。

なんだこの程度なのか、まだ上がいる、もっと頑張る?こんなに限界なのに?

だから僕は一生懸命という四文字熟語も人に期待するということも辞めた

例え親であってもそうなんだと思う。

残ったのはやりたいことをやるために必要か?そうでないか?

それは今すぐにやり切れるか?

という判断基準だけになった。

価値観とかではない、ただアルゴリズムのようにそうしてるだけ

それがいいかなんてわからないけど、少なくとも学校という枠の中で生きていた頃よりも自分らしく行きてるし結果もついてきてると思う。

好きなことをしてる、それに仕事の約束さえ守ればあとは自由だ

だから、音楽を止めて少し周りを見渡したって怖くない

周りが大変そうにしても自分は大丈夫

やりたいことをやっていいのだ、ただそれだけなんだから

何事もデザイン、プログラムも絵も音楽も

自分が開発の現場にいてふと思ったことですが、プログラムを書く、絵を書く、音楽を書く(作るかな)ってどれもデザインが必要でそこが一番大事な部分なんだなーって漠然と思いました。

なんでこんな突然とかありますけど

最近デザイン思考とかデザインに関する本を読んでいるのですが、最終的にはここにたどり着くなと

ある意味問題やテーマを表現したものが一般的にデザインと言われているもので

本質的にはどれもどんな設計をするか?という部分になっていくのだなぁって

なのでデザインってイコール設計ができるってことなのかなと思いました。

またそれってあってるのかまだよくわかってませんが

ちょっとそう思っただけ

Atomのシンタックスハイライト、miku-blue-syntaxを作ってみたよ

【Release Notes】

atom.io

今回コソコソと作っていたシンタックスハイライト、miku-blue-syntaxが完成しました!

Atom

Settings>Install>Themes を選択して”miku-blue-syntax”と検索すると出てきます。

今回はギークカラーな2015年版マジミラミクさんのカラーパレット構成

まだマイナーバージョンで至らぬ点があると思いますがぜひ使って見てください。

個人で使いたいがために作ったものですが改善要望等あれば随時やっていきますのでフィードバック大歓迎です。

【読書ログ】ニューエリート グーグル流・新しい価値を生み出し世界を変える人たち

booklog.jp

ちょうどWAONがいい感じに溜まっていたのでちょっと買ってみました。

孫泰蔵さんに一回会いたいな−と思ってるんですけど、今のところはまだチャンスが来ていないので自分の技術とアイデアをストックして機会が巡ってきたらペラペラ喋ってみたいななんて思います。

ピョートルさんも人事の人なんですが価値観はGoogle流な人なので見ていて面白いなと思いました。

本書の主張: アプリと同じ様に常に自分をアップデートしていこう!

この本の全体的な主張としては、今世界が常にオンラインでつながっている時代になりオールドエリート(つまり古き良き会社員エリート)の常識はどんどん通用しなくなってきている。

では、2020年以降の新しい世界で必要なエリート、人材とは何か?

それは常に自分から積極的に学び、成長し続ける人材ニューエリートが台頭してくる。すでにGoogleや世界的に先端を走り利潤を獲得している企業では特にこういった人材を求めている。

というのがこの本の主張かなと思います。

要素1:ニューエリートとは?学び続ける人材って?

では具体的にニューエリートと呼ばれる人材はどんなものを指しているのか?

簡単にいうと、自分の興味のある得意分野を追求しつつ、得意分野と違う領域を結び続けるイノベーション人材ということらしい。

いきなりすべての人がイノベーションできるかというとそれは難しいかもしれないけれど、一つの分野にこだわらずに他領域、異業種の人とと積極的に関係性を持つことは可能だと思います。

要素2:他者を変えることは難しい、では自分を変えるためには何が必要?

自分がニューエリートになるにはどうしたらいいの?という話

表面上の話をすれば直感で何でも決めて開発もアジャイルでーなんて話になりそうですがそういうわけではありません。

では何が重要かという話ですが、重要な要点は以下のような部分です。

1. 仕事をゲームの様に楽しむスタンス
2. 積極的に外部とつながろうとするコミュニケーション能力
3. 取り入れたインプットを自分なりに噛み砕いてアウトプットする力

要はドラクエとかワンピースみたいな少年漫画的なストーリーを自分に当てはめていけるかという部分ががどんどんと重要になってきているイメージです。

ちなみにこの手の話でおすすめの書籍として「定価5,500円のTVゲームに、面白さで負ける人生を送って、いいのか!?」というキャッチフレーズでインパクトのある@junzooooooさんの「人生ドラクエ化マニュアル」があるのですがこれがオススメです。

あと誤解のないように主張をしておくと、必ずしも成功する人が外交的な人格である必要はありません。ひねくれようがなんだろうが、そういう前向きな人のいる環境にいてちゃっかり参加してしまえばいいだけの話なので、そのへんは自分の特性を考えて最適化すれば良いと言うのも良いポイントだと思います。

要素3:イノベーションを生み出すチームの特徴と日本の企業に足りない部分

日本の企業はなぜうまくいかくなったのか?

バブル崩壊後数十年に渡り冬の時代と言われて久しい日本の社会ですが、一体何が海外と違うのか?という部分に対してはこの本はこういった主張があります。

「働きがい」はビジネスの結果に繋がります。「働きがい」がビジネスに与えるインパクトは大きく、例えば生産性は21%アップ、利益は22%アップするというデータもあるほどです。 では日本の企業にはどのような問題点があるのでしょう。まず共通するのは「経営目標を達成する手段として従業員いる」という点。そういった企業は典型的にピラミッド型組織構造、企業活動がクローズド型で閉じている、指揮命令がトップダウン、商品重視(ユーザー無視)などの特徴が挙げられます。

確かに一般的な組織構造としてはこれが最適とされてきたファクトリーベースな組織体制が浸透しているのは事実と思います。あとは、上の人が決めてくれるから自分は指示に従うだけで良いという風潮についても

ただそういった組織が今機能しているからと言って、今後もそういった企業が生き残っていけるのかは少し疑ったほうがいいのかもしれません。

また、これから仕事を始める学生に対しては「あなたはストームトルーパーになりたいか?」という新卒一括採用に対して疑問を投げかける章もあるので、こちらはオススメです。

イノベーションを生み出すチームはどのようなことを大事にしているの?

ここまでは今までの古い組織の体質からくる負の側面が大きいという話でしたが、では逆にイノベーションを起こしていくチームはどのようなものかについてもこの本にはいくつか主張があります。

大まかな部分は他のビジネス書でも見られるようなチームビルディングの話が多くありましたが、この本では「自己効力感」が重要であるという部分が非常に印象的でした。

「自己効力感」というのは簡単に言えば「自分はできる!」という自信の部分です。

ちなみに筆者はGoole出身なのでGoogleで自己効力感も持たせるために組織として行っていた事例を紹介しています。

では、自己効力感とはどんなことをすれば得ることができるのか?ということについてこの本では以下のように紹介されています。

  1. 達成経験:自分自身が成功した体験
  2. 理経験:自分以外の他人が何かを達成・成功したことを観察すること
  3. 言語的説得:自分に能力があることを説明されること、言語的な励まし
  4. 創造的体験:自己や他者の成功体験を想像すること

個人的には4の創造的体験という部分は非常に重要だなと感じました。

理由としては、業務になれできるようになればなるほどにこういったイメージをする時間よりも、目の前の問題解決に駆り出されてしまうことが挙げられます。

いわゆる「大人は大変・忙しい・辛い」というネガティブなイメージを吹き飛ばすような快活な大人像を持っている人が非常に少ないのはおそらくこの部分に絡んでくるのではないかなと思います。

皆さんはどう思います?

ざっくりとした感想

まあ、組織を変えるのは難しいけど、勝手に自分が変化する分には咎められることもないので今自分が取り組んでいる「ハイ・アウトプット」のテーマは続けていこうと思いました。

あとは、学生の時ほど自由に出歩けない場面が多くなってきたので「社外の人と絡む」という部分は少し見直していかないとなと感じています。

新しい世界で自分がどんどん挑戦できるというのは自分にとっては非常にチャンスなのでこれからもどんどんやりたいこと、夢、頑張っていることなんかは積極的にアウトプットしていこうと思います。

世の中的にはふりがなプログラミング本が流行ってるらしい

今日Googleのトレンド検索をしていたら検索キーワードで急上昇中のものに「ふりがな プログラミング」

というのがあってちょっと気になった

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

ググって検索してみたところどうやらプログラミング言語のエラーとか構文の解説にルビをつけてる入門書みたいで実際に書店で中身を見たら、どんなエラーなのか、どうやってこの構文は使うのかが優しく書かれている本で非常に良かったです。

英語はわからない、けどプログラミングはしたい人がいる

自分たちにとっては英語のドキュメントを見ることも、コーディングのコメントを英語で表記するもの割と当たり前になっているのでこれはいい発見だなと思いました。

確かに最初の一歩を始めるときは近くに同じエンジニアなんていなかったし、拙いコード(今でもそんなに書けるわけじゃないけど)を書くのにも一人でググったり英語も一生懸命に翻訳してました。

それでもプログラミングの前提知識だとかは全然わからなくて四苦八苦した記憶があります。

そういった人向けの本としてはこういったイラスト付きで読むことのできるこういう本はとてもいいと思います。

初心忘れるべからず

だんだんなれてくると、初心者の人にプログラミングってどうなの?って質問をされると

「あ、また来たこの質問」という感じになりがちですが

自分もそもそも特別に情報処理の学校に言ったわけでもなくかと言って理系でもなかったので、この手の質問は自分の最初の頃を思い出すのには毎回いいきっかけになっています。

今は職業エンジニアですが、そもそもはパソコンを弄ることが好きでその延長線上なので

それに、そういった専門的なことが何もわかっていないただ楽しいだけの状態を定期的に思い出すのは大事ですね。

そこがプログラミングが好きでいるためには大事だと思います。

まずは一歩進んでみてそれから考える

あとこの手の話が出てきたときは必ず小さくでいいので初めて見ることが大事ですね。

苦手だったらそれでもいいので、見たけどやらないではなく、やるという習慣を見につけるといろいろと見えてくる世界が違うんじゃないかなーと思います。

GitHubで出たセキュリティアラートに対応する。

Qiita記事を書いたのでこっちにも記録

GitHubで出たnpmのセキュリティアラートに対応する。 - Qiita

まだプロトタイプなので気にはしていないのだけれども、ずっとアラートが出っぱなしなのは嫌なので、ちょっと対策をしてみようと思いました。

f:id:ferrari458tukapai:20181105073817p:plain

こんなやつ

簡単に調べたところ、package.jsonに依存パッケージのアップデートを盛り込んで置けばいいみたいなので、こんな感じに修正しました。

"dependencies": {
    "mime-db": {
@@ -202,7 +202,7 @@
        "finalhandler": "0.4.0",
        "finalhandler": "0.4.0",
-       "fresh": "0.3.0",
+       "fresh": ">=0.5.2",
         }

ちなみに実際に修正したコミットはこんな感じ。

GitHub - fix security problem

npmとか結構依存モジュールが多いので定期的にこういったものは検証やアップデート対応が今後必要な気がします。

自分以外メンテナンスする人がいないので、めんどくさいと思う半面、自分で脆弱性対応を調査しなくてもいいというのは便利な機能でした。

参考にした記事

GitHubから通知されたセキュリティ上の脆弱性を解決する