tchikuba's blog

Beer Driven Developer / Lean Engineerの徒然

【速報】RubyKaigi 2016初日参加レポート

聞きながらの自分用メモなのでちょっと正確でない点がありそうですが。

Ruby3 presented by matz

  • Typingの話
  • SmallTalk→Java→Ruby,JavaScript→Swift,Go→?
  • 近視眼的な判断で静的型付けを選択するのは危険
  • そもそも未来の型とは?
  • Duck typing: アヒルが歩くように。アヒルのように振る舞えばOK
  • Duckとは期待される振る舞い
  • プログラマのメンタルコストを下げたい
  • GoのStructual SubtypingはNominal Subtypingより良さ気
  • Rubyには歴史的にこれまで型指定がない
  • 動的型付けの欠点もある
  • エラーメッセージが親切じゃない
  • 型は絶対に書きたくない(会場笑) DRYじゃないし
  • Type Annotation,Mixed/Gradual Typingはダメなアイディア
  • 人にお願いするんじゃなくて技術で解決したいよね
  • 型推論は素晴らしい
  • インタフェース書きたくない
  • 型の名前を決めるのは結構なコスト。振る舞いがわかっていれば名前を付けたくない
  • 振る舞いを決める型のデータベースのようなものと型推論を組み合わせると80%くらいは推論可能では
  • オープンクラスとかで再定義しちゃうと型推論無効に
  • 型データベースをgem化して利用して型推論の精度向上とか
  • ダックタイピングを維持して型推論をRubyらしく行う
  • これらの構想はすべてRubyistが楽しく生産性を維持できるために検討していること
  • Ruby3はいつか? I don’t know.(会場笑)
  • 次の東京オリンピックの時にはRuby3あると良いなぁ
  • OSSコミュニティは前に進めないとつまらない。前に進めるためには何でもやる

dRuby presented by @m_seki

  • dRubyが生まれたのは1999年
  • dRubyはオーパーツ
  • shttpsrv: WEBrickより前のRuby製webサーバ
  • Rubyのように振る舞う分散オブジェクト
  • DRb.start_serviceだけでdRubyの準備可能
  • サーバーとクライアントが入れ替わる例
  • OOPっぽい感じ
  • Queueを使って待合せのデモ
  • dRubyはtwitterのプロトタイピングでdRuby/Rindaだったらしい
  • プロトタイピングとしての利用価値がある気がする
  • セキュリティ系メソッドは消してしまいたい。危ないものは危なく見えるべき

Welcome to haconiwa presented by @udzura

  • Drone.io
  • dockerらしいコマンドをしょっちゅう打ってた
  • Sqaleで使ってるLXC
  • haconiwaコマンドでRubyで書かれたプロファイル定義を実行とか
  • hacorbコマンドとかでmrubyスクリプトのコンテナ実行
  • cgroups的な
  • 最初はCRubyで実装
  • システムコール扱うのに色々嵌ったのでmruby実装へ
  • mrubyはコンテナが取り扱うシステムコールをサポートしてるので使いやすい

A proposal of new concurrency model for Ruby 3 presented by @ko1

  • 資料
  • Ruby 3に取り入れられたいと思う並列プログラミングについて
  • C言語のポインタと比較するとRubyはGCあるのでハッピープログラムできる
  • data raceやrace conditionが発生する例を通してスレッドセーフなプログラミングが如何に難しいかを知る
  • Mutexを利用して同期を取るのはバグと性能低下の狭間にある
  • Ruby 3ではGuild(ギルド)というスレッドにかわる新たな概念を提案
  • Guildは複数スレッドを含む上位概念的なもの
  • 複数のGuild間での可変オブジェクト受け渡しにはチャネルを使ってコピーするか移籍(transfer membership)という新しい概念で
  • Guild内のスレッド間はスレッドセーフが保証される
  • これらのGuildの概念でRuby 3で実現したい並列プログラミングのゴールをすべて満たす感じに
  • Guild概念導入でスレッドセーフが保証されないキモいコードを書けないようにする方向性

Isomorphic web programming in Ruby presented by @youchan

  • 去年はHyaliteの話をした
  • Menilite: クライアントサイドでもARとか使える的な(JS嫌いなのでw)
  • デモ、デモ、ひたすらデモ

Unifying Fixnum and Bignum into Integer presented by @tanaka_akr

  • Ruby 2.4ではFixnum,BignumクラスがなくなりIntegerに統合
  • 環境によってFixnumが扱えるサイズは異なる
    • 手元の環境(OS X Yosemite)だと(262-1).classはFixnum,(262).classはBignum
  • Fixnum,BignumはCommon Lispから来てる
  • 以下のコード無限ループになるけど許容するしか。 max = 1 max *= 2 if max.class == Fixnum puts max
  • 教育的に分かりやすい、数学的にも正しい、とmatzに押し込んだ

Scalable job queue system built with Docker presented by @k0kubun

  • coockpadでrails開発者の開発効率を向上する為の開発
  • RubyKaigiでrailsの話をすると怒られる
  • syoryukenってgemはSQSをジョブキューとして使うやつ
  • barbequeを作った
  • web consoleもあるよ(rails製)
  • kuroko2という社内のクローズツールが秀逸すぎたので本来ジョブキュー使うべきところでも出番なし
  • kuroko2はOSS化進めてる
  • ECSとAutoScalingグループでスケールを自動化

イベント「CTOだったNight」@dotsに参加してきました!

最近比較的よく行ってる渋谷dotsで行われた「CTOだったNight」というイベントに参加してきました! 主催はnanapiの元CTO和田(wadap)さん。 話の内容をメモっておいたんですが、思いの外面白かったのでブログ記事としてアップしておきます!

最初は自分用の箇条書きとして書いてたのでちょっと読みづらいかもですがご容赦を…

ビズリーチ/レイハウオリ竹内さん

はじめに

  • ビズリーチ最近CMやってるらしい
  • CTOを1年前に退任した理由
    • マネジメントの割合が大きくなる
    • エンジニアが自由に研究開発するのもお金がないと
    • そのための事業創造したい

うまくいくCTOとうまくいかないCTOの10の違い

  • (1)なんでも作れる技術力
    • 人間力があって技術力はそこそこだと超技術力があるエンジニアに尊敬されない
  • (2)技術を手段として使える
    • 技術を目的化した発言する人は経営陣が耳を貸さない
  • (3)経済のルールに争わない
  • (4)何よりも人を大切にできる
    • 5-10人くらいに増えるタイミングで引っかかるCTOが多い
  • (5)ビジネス人格
    • キャラ設定が必要
    • 人格とか
  • (6)本気で社長と対立しない
    • 社長が非エンジニアだとムカつくことしか言わない
    • 人間は動物だと思って悟りを開いた→社長が可愛くみえてくる
    • しょうがないしょうがない
  • (7)発信力
  • (8)外交力
  • (9)株/SOの交渉ができる
    • ちゃんと取らないとダメ
    • 最低5%は取らないと→希薄されても2,3%とか
    • 1%だったら辞める
    • 蓋開けるとCFOがいっぱい持ってたのが通例なのでCFOなんかに負けないように頑張りましょう
  • (10)何があっても辞めない
    • 辞めない、という前提に立つと価値観を変えないといけない場面がある

BASE藤川(えふしん)さん – モバツイでCEO/CTOをやってた頃の振り返り

CTOがエースエンジニアであり続ける問題

  • AWS運用で工数取られる
  • CTOは自分よりも技術的に優れた人間を探すべき
  • CTOが技術を触って良いのはコアコンピタンスだけに絞る
  • 人工知能系CTOとか育成問題に悩む

足回りと未来をつくるコンフリクト

  • 余裕がなさすぎてやるべきことを理解できてなかった
  • 現状維持バイアスを捨てるべき

BASEでは

  • コードを書かない宣言
  • 社長のビジョンを支える立ち位置
  • マイクロマネジメントの罠にハマっていないか
  • 港区には近寄らない(夜の街)

パネルディスカッション

CTOを辞めた理由

  • 営業が強くてエンジニアの立場がない
  • 新しい働き方や新しいサービスを自分でやってみたくなった
  • 社長と合わなかった、最後何かが切れる音がした感じ
  • エンジニアよりデータサイエンティストが大事でエンジニア育てる文化がなかった、頭の悪い経営陣

もしCTOをやり直すなら

  • もっと人を見る、リスクを負ってでも入れてくれるか、SOとか
  • 早目に人を入れればよかった
  • なんでも自分でやっちゃう、もっと優先度高い仕事できれば、採用をもっと任せればよかった
  • IPOとか長く続く会社とかやってみたいと思う、スポットライトは2年半で売却、IPO3%,10%,1/3とか

社長(経営)との関係性

  • CTOだったけどリードエンジニア的な振る舞いだった、あまり経営求められず
  • 営業系出身社長だと放任でコミュニケーションがとれず1on1入れたり、エンジニア出身だとマイクロマネジメントになりやすい、外部を入れると通じる
  • 飲み行く、はっきり言う関係性ができてれば良い、社長って人格に欠陥ある人多い、でも本気でいう
  • 社長が中途半端にコード書けると良くないからPHP以外の言語選んだり

これからCTOになる人に伝えたいこと

  • エンジニア的な論理はプログラミング以外のところにも役立つ
  • コミュニケーション、エンジニアだけじゃなくビジネスサイドの人とも、コミュニケーションを仕組化する、CTOは孤独だから相談する人を作っておく
  • 会社全体とかビジネスのことを考えるようになるから良い、営業の話も聞きながら技術的負債に向き合ったり
  • マネジメント系の本とか読むとか勉強してアウトプットできるようになる、マネジメントだけどコーチングできてないとか、お互いフィードバック貰って成長・学習する

所感

CTOに限らず、ビジネスサイドと近い立ち位置で仕事しているエンジニアの方なら誰もが共感できる内容だったかなと思いました。

私自身も経験に照らし合わせて非常に共感した次第です(笑)

大切なことは異文化コミュニケーションであることを受け入れつつも、コミュニケーションを諦めないで主張すべきは主張することかなと。

また、場合によってはみずからの価値観を見直す柔軟性も必要なことだなとも思います。

ある意味政治というか、相反する部分をいかに粘り強くコミュニケーションを取って折り合いをつけるか、という点が重要ですね。

イベント「dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言!~ 女性エンジニアとして長く働く秘訣 ~」に参加しました!

先日「dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言!~ 女性エンジニアとして長く働く秘訣 ~」 というイベントに参加してきました。 私の妻も私と同じエンジニアでdots.女子部の一員として運営に関わっています。 妻からこのイベントを企画していることを事前に聞いており、参加を楽しみにしていました。

参加した当日はノートPCを持っていくのを忘れていたので、スマホからひたすらtwitterで実況中継していました(笑) 備忘録的な意味も込めて、当日のtweetをtogetterまとめっぽくお届けします。


※遠距離恋愛の参考にしたいというdots.女子部メンバーの話を受けて

夫婦共働きで子供がいるってどんな生活リズム?

家事の役割分担とかどうしてる?

子供にはお金がかかるけど、どうやって踏ん切りつけた?

夫婦でエンジニアって同業のメリット・デメリットは?

地方移住とか考えたりする?

※リモートワーク的な文脈での話。

2人目ができると更にカオスって聞くけどどう?

どれくらい産休・育休って取ったの?

今後の夢とかは?

終了後の懇親会

オサレなケータリング

竹馬 力さんの投稿 2016年3月24日

他の参加者の方の感想


やっぱりエンジニア夫婦って(・∀・)イイネ!!

勉強会に参加して感じたことです。 同業だと問題もあるという話を聞いたりもしますが、ふたりともエンジニアである場合、メリットばかりが目についてデメリットってほとんど思いつかないです。 テクノロジーへの理解があるという点、非常に共感しました。新しい製品を買ったりするのに家庭内稟議は圧倒的に通りやすいんじゃないかとw

あと、今回登壇されたご夫婦2組とも、男性の優秀さもさることながら、女性の優秀さが凄いなと感じました。 なのでプログラマである私の妻にも、このご夫婦に見習って凄くなってもらおうと思います(笑)

エンジニア・チームのダイバーシティ向上を!

私は日頃から、ダイバーシティの観点から、あらゆる組織は男女比率がおよそ半々である方が良いと考えています。 しかしながら現時点では、特にエンジニアの世界では圧倒的に男性比率が高い状況があります。

たとえば、10代、20代の女性をターゲットにしたwebサービス開発エンジニアは全員男性で、女性が1人もいない、などのケースも比較的よく耳にします。 中長期的に続くことが前提のサービスにあって、手を動かすエンジニアがdog foodingできることは、成功する確率を高める最も大きな要因の1つだと思います。 その意味では、女性向けのwebサービスであれば女性エンジニアが手を動かした方が、より良いサービスを創ることができるのではないでしょうか。

今後もしエンジニアのチームを構成することがあるとすれば、できる限り男女比率を半々になるようにやっていきたいと改めて決意した次第です!

21世紀型のクリエイティブな働き方・思考・組織の新しいあたりまえ

この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。

私は現在IESHIL(イエシル)という中古マンション価格査定サイトのエンジニアやってます。 担当は雑用係です。 リブセンスに入社して約2年半ですがリブセンスでwebサービスの自社開発の文脈に身を置いて色々思うところがあるのでその辺をちょっと言語化してみます。

プロフィールとバックグラウンド

私はエンジニアになったのが2004年8月でした。 7年間フリーランスのエンジニアとしてお客さんのところに常駐して作業するという形で、所謂社畜フリーランスでした。 前半4年間は大手SIer、後半3年間はエンタメ系事業会社に常駐していました。

前半の4年間では小さいプロジェクトだったこともあり、ウォーターフォールで言うところの要件定義、基本設計、詳細設計、実装、テスト設計、 単体テスト、結合テスト、受入テスト、リリースなどソフトウェア開発の全工程を担当してエンジニアとしての基礎力を身に着けた時期でした。

後半の3年間では所謂「ステークホルダーと調整して設計書を書くSE」「ベンダーコントロールPM」的な立ち位置で 主に自分が手を動かさず人に手を動かしてもらう為の環境整備的なことをやっていました。 今思い返すと、この時期に所謂プロジェクトマネジメント的なところの基礎力を身に着けた時期だったと思います。

そうこうしているうちにより大きなやりがいと責任ある立場でやれる仕事をしたいと思い、新規事業のプレイングマネージャー的なポジションを探していたところ あの2011年3月11日が来て、人生短いんだからやりたいと思ったことをやるべきだと踏ん切りがついて前職となるPR会社の新規事業の開発マネージャーとして転職しました。 この時期に要求仕様の変化が激しい新規事業、所謂スタートアップ的な文脈ではウォーターフォール型の開発の行き詰まりを実感し、 アジャイルやリーンな開発(技術開発だけでなく事業開発含め)の手法を模索し貴重な経験をした時期でした。

開発マネージャーとして約2年間働いた後、現職のリブセンスに転職をして現在に至ります。 リブセンスでの強烈なエンジニア文化の中で、エンジニア含めた事業に関わる全ての人が効率の良さと気持ちの良さをどうやったら追求出来るかを最近良く考えます。

SIerから事業会社の文脈へシフトして感じたビジネスとエンジニアリングの関係性

自分のキャリアを振り返ってみると受託開発が主であるSIerから徐々に自社サービスを展開する事業会社へとシフトして行ったことになります。 私のキャリアの文脈が徐々にシフトしたのは単なる偶然な気がしますが、この経験があるからこそなのか、最近良く考えていることがあります。 それは、ビジネスとエンジニアリングは一体不可分であるということです。

ある意味これは最早当たり前の時代になってきたんだと思われますが、私が10年前にいたSIerの文脈だと実感として結構違っていました。 あくまでも受託開発では発注側のお客様がいて請負契約に基づいて予め定義したシステムを納品することが目的です。 出来上がったシステムがお客様が使ってみた結果、それがビジネス上価値を生み出すか否かは短期的には関係がありませんでした。

しかし事業が社内にあり内製出来るエンジニアチームを持っている文脈では事情が異なります。 当然ですが開発を行った結果ビジネス上無価値なものを作ってしまったとしたら基本的にその当事者が作り直す必要があります。 開発と運用が一体となっている文脈では、要件の変化に伴い柔軟にシステムを変更する必要がありまたそれに耐え得る品質を ソースコード上の保守性、DDD(ドメイン駆動設計)等を用いたビジネスドメイン設計、CI等で担保する必要があります。

これまでの私の経験上、感じていることをまとめると以下の様な図になる気がしています。

発注者と受託者という関係では、前者から後者へ金銭的な授受が行われる為、ビジネスパートナーといえど、構造上どうしても主従関係のような強弱がついてしまいます。 当然上手く行っている受託開発も存在しますが、経験上上手く行かないパターンを見ることが少なからずありました。

※ただ最近は一括請負契約の構造上の問題を解決する受託開発の手法の1つとして「納品のない受託開発」 を手掛けるソニックガーデンさんの事例は注目したいところです。

上記の図に表現した通り、時代の変遷と共にエンジニアリングの比重を相対的に大きくしていますが、これも実感としてあるところです。 昨今のビジネスにおいては「如何にビジネス上の営みをシステムに落とし込むか」という点の比重が徐々に拡大している気がします。 当然ながらビジネス上のシステム化とは、エンジニアリングの観点でのシステム化だけではなく、機械的に出来ることと出来ないことを選別した上で 人手でどこまで行うのか、人をどう配置するのか、関わる人に要求される職能は等、多岐にわたります。 しかしながらそれらの人が業務上関わる場所に全てシステムが介在することもまた事実であり、その範囲は時代を追うごとに拡大していると思うのです。

もっと言えばビジネスに近接する立場にある非エンジニアの日頃の業務にこそ、効率化の余地があることが多いとも感じます。 余談ですが最近日経の記事にコーディング・ブートキャンプの話がありました。

この記事から類推するに、非エンジニアが何らかのビジネス上の課題解決の為にコーディングを勉強する需要があるんじゃないかと思います。

いずれにしても現時点で痛感していることをまとめると、 ビジネス上1つのプロセスでしかなかったシステム化が、ビジネス上最も重要なプロセスの1つとなり、その後、ビジネスと一体化しつつある ということです。

これらのことは既に各方面の偉い人が唱えていることで、理論上は当たり前だと思うのですが、これを経験上私が感じれていることに スティーブ・ジョブズ曰くのconnecting the dotsを感じてちょっぴり嬉しいのです。 頭で理解したことと体験で会得したものでは実は雲泥の差だなと思いますので。

ゴール思考とシステム思考の融合

connecting the dotsのリンク先の記事に曰く、

点と点を繋げるということは、あらかじめ仕込むことは出来ないということです。 しかし、振り返ってみると「あの時のことが役立った」とか、「あそこで出会った人に、こんなタイミングで助けられた」といったことって意外とあるものなんですよね。

とあります。

私も自分の経験を振り返ってみて思うのですが、その通りだなと。 これ実はある意味「システム思考」だな、ということを最近しみじみ感じます。 少なくとも予め仕込むことは出来ないという点においては、ゴール思考とは遠い気がします。

私実は11年間エンジニアやる前、1年くらい超ブラック企業と言われた某営業会社で営業をしていた時期が(一応)ありました。 この企業が物凄い体育会系ノリだったのと超絶ゴール思考的で理系出身だった私には全く考え方が合わず辛い思いをした苦い経験でした。 既に亡くなった(笑)会社でもう時効だから書いちゃいますけど、当時の上司から2回辞表書けって言われて書いたりして(笑) 1回目の辞表なんて「まだ辞めたくないけど上司に辞表書けって言われたので辞表書きました」という内容の辞表だったりして(笑)

今でこそ笑い話ですが、この経験が実は比較的ネガティブな原体験として、極端なゴール思考では歪みが生まれて持続可能な発展でなくなる ということが自分の中に焼き付きました。その後も若干紆余曲折あったんですが、この体験が元になってエンジニアリングを1から勉強してエンジニアになろうと思えました。 当然ながらこの時はシステム思考なんて言葉も知る由もないんですが、振り返ってみれば、目の前の課題解決を積み重ねるアプローチを欲していたんだと思います。

また、実はゴール思考も適切な範囲であればモチベーションコントロールとして有効であることも体験していることも重要です。 システム思考だけだとビジネス上実現したいビジョン等から外れてしまっても暫く気付かないケースがあるように思います。 個人的にはゴール思考とシステム思考の融合を目指したいと考えています。私の体験上でもそれは理に適っていると思われるのです。

ヒエラルキーとホラクラシー

このような文脈にあってもう1つ私の中で良く考えることがあります。それはクリエイティブな組織の在り方についてです。 私はその1つの解としてホラクラシー型組織の構築があるのではないか?と考えています。 ホラクラシーとは、マネージャーの存在しないセルフ・マネジメント型組織のことで、ザッポスが導入したことで有名です。

最近のハーバード・ビジネス・レビューにホラクラシーに関する記事がありました。

この記事に曰く、

ホラクラシーの大部分は、優れたマネジメントによく見られる要素を単に体系化していると気づいた。 ホラクラシーの導入にまつわる細部にとらわれず、それが何に対処するためのものなのかを掘り下げて考えれば、見えてくることがある。 問題は、ヒエラルキーそのものがいかに正当性を失ったかではなく、速まっている世の中の動向に対してヒエラルキーでは動きが遅れることなのだ。

とあります。

確かにヒエラルキー型組織で優れたマネージャーは、出来るだけ現場に裁量を与えて信頼し、問題が発生した場合だけ出来るだけ迅速に対応し 問題の責任を取るタイプが多い気がします。極論、成功は部下の功績とし、失敗は上司(自分)の責任とするタイプですね。 まぁ体験的には大体ヒエラルキー型組織だと中間管理職層は人間が腐っていく例を良く見てきた気がしますが(笑) 私が開発マネージャーだった際にこういう優れたマネージャー像を目指して奮闘してましたが、理想像からは程遠い感じだったような気がします(汗)

いずれにしてもスピード感を持って変化に対して対応していく為には現場でコトに当たっている当人が誰かに判断を仰ぐことなく 自分の判断で臨機応変に行動することが出来てしかもその判断が正当であれば(結果がどうあれ)最も正しいと思います。 まぁ逆に振り返って判断が正当でないように第三者からは見えても、結果がマズい方向ではなく良い方向であればヨシとすることもあるかもしれません。

私は、クリエイティブな仕事に携わる人々が関わる組織が今のところ最も上手く行く方法論としてホラクラシーを捉えています。 逆に1ヶ月ほど前にバズってた、CIAのスパイマニュアルの記事がヒエラルキーの問題点を端的に表していると思いました。

曰く、

会社内での組織的位置付けにこだわる。 これからしようとすることが、本当にその組織の権限内なのか、より上層部の決断を仰がなくてよいのか、といった疑問点を常に指摘する

これとかまさに先ほど書いた現場の臨機応変な判断を阻害する真逆の論理で一見正当性が見えるので厄介なんですよね(苦笑)

「不二」という視座から垣間見る21世紀のスタンダード

ちょっとここまで書いた所で息切れしてきましたが(笑)そろそろ結論めいたことを書きたいと思います。 結局のところ私の体験という文脈の中でしか実感を持って判断出来ないと思っていまして、その意味では至極主観的極まりない話だということが前提ですが。 現時点での私の文脈(コンテキスト)では、これら一見相反するように見えるものが実は一体不可分である、ということです。

まず、ビジネス上使われる一部に過ぎなかったエンジニアリングが、経営の中心となりつつあります。 次に、極端なゴール思考の行き詰まりや矛盾から、持続可能な発展を考慮したゴール思考によるビジョンに基づいたシステム思考の重要性に気付きました。 最後に、ヒエラルキー型組織の矛盾の中でキラリと光るマネージャーを垣間見たり、理想像目指して奮闘したりするも、 マネージャーとなってコードを書かなくなったらエンジニアとして終わりなんじゃないかと自問自答して、 私自身の手でエンジニアのホラクラシー型組織を実現したいと夢見て現実と奮闘していたりします。

私の体験としては実は予期せず元いたコンテキストがあったからこそ、気付きを得たと言えますし、 対立しているように書いたことも実は存在意義が多分にあり一体不可分なのだと思えるのです。 これを代弁する考え方に仏教の用語で「不二(ふに)」という言葉があります。

曰く、

対立していて二元的に見える事柄も、絶対的な立場から見ると対立がなく一つのものであるということ。

前述のような見方が絶対的な立場か否かは分かりません。

ただ、ヒエラルキー型組織でウォーターフォール型開発を一通り経験出来たからこそ、その長短を体得することができたのだと思います。 ビジネスと遠いところで開発をしていたからこそ、ビジネスに近接するところで開発する際の違いを痛感し開発プロセスを多少なりとも改善してきました。 そもそもホラクラシー型組織を上手く回す為にはセルフ・マネジメントが出来る優秀なメンバーのみで組織を構成する必要がありそうです。 職能的にジュニアクラスのメンバーは一向に力を発揮出来ないことになりそうですが、敢えてヒエラルキー型組織で力を付けるという選択肢もあるかもしれません。

これらを踏まえた上で、私自身の経験に即して、これからの時代以下のような流れになっていくのかなと考えています。

  • 事業会社の内製化により下請けも含めたSIerは斜陽産業化する。
  • 事業会社がweb企業・インターネット企業となるのが当たり前になる。
  • 新しいビジネスを起こす人はエンジニアの素養のあることが当たり前になる。
  • エンジニアの素養のある人が起業するので、エンジニアの評価がよりまともになり、まともなエンジニアがよりHappyになる。
  • 非エンジニアの職種では徐々に人工知能や機械学習による自動化が進みよりクリエイティブな仕事をせざるを得ないようになる。
  • 日頃ルーチンワークが辛いと言って仕事がつまらない思いをしている人は少なくなっていく。(仕事自体がなくなるので)
  • プログラミング教育が官民共に爆発的に広まる。
  • エンジニアの仕事はコーディングによってビジネス上の価値を創造することが評価のポイントになる。
  • 世の中の複雑性は増していく一方で先が簡単に読めなくなり、反復型アプローチが問題解決の主流になる。
  • ある一定の人々に共感される極めて倫理的なビジョンを有するテックドリブンな企業が緩やかに受け入れられ世界を変えていく。
  • 急進的なスタートアップより、持続可能な発展を掲げるスモールビジネスが大量に浸透していく。
  • 副業やリモートワークがより普及して組織力は弱まり、クリエイティブな個人がクローズアップされる。
  • 自律した働き方の出来るクリエイティブな個人が集まり、プロジェクト単位でギルド的集団を形成し、質の高い仕事を成し遂げる。
  • 自律した働き方が出来るまでの職業訓練が比較的安価で受けられる教育的な仕組みが出来ていく。

私自身はこれまでの経験を踏まえてやりたいことが比較的明確になりつつあるのですが、 キーワードはITと新規事業と教育ということで一応一貫しているつもりなのでこの方向性は常に持ちつつ、 これまでのエンジニアとしての技術的な方向性から、更にビジネス・経営的な方向性で社会貢献出来る人材になろうと決意しています!

この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。

「ECMAScript6勉強会」HappyHalloween JS 祭!!に参加してきました!

2015年10月31日(土)に行われた「ECMAScript6勉強会」HappyHalloween JS 祭!!に参加してきました! ハロウィンということで仮装して参加すると参加費が半額になるというちょっと変わったイベントでしたw

※リアルタイム更新してました!

『Good evening, ES6』byよしこ氏 @yoshiko_pg

  • 発表スライド
  • var –> constで変数の上書き禁止が可能に
  • Template Strings
  • 関数のDefault Parametersが使えるように
  • Rest Parametersで…argsで引数がarrayで取れるように
  • Spread operator(スプレッド演算子)でapplyメソッド使用せずに配列を展開出来るように
  • yoshiko氏の年齢がサンプルコードで暴露されてる(笑)
  • Destructuringで変数の入れ替えの為のtmp変数が不要に
  • Effective ES6(slideshareのスライドがオススメ)
  • ES6をES5に変換するBabelを使うとES6で書くことが出来る
  • Scratch JS(chrome拡張)入れるとES6をコンソール上で試せる
  • gulpfileをv3.9.0以上ならES6で書ける

『Promises』by矢倉 眞隆氏 @myakura

  • 発表の様子
  • 非同期処理について洗濯機とかお風呂とかの例
  • JSでの非同期処理だとコールバックヘルに陥りがち
  • thenで非同期処理を実行することが可能。メソッドチェーンで繋げることが出来る。
  • Async functionでコールバックパターンから開放される方針。try,catchで書ける。MS EdgeやFirefoxで実装される予定。

『Function and Class』by川田 寛氏 @_furoshiki

  • 発表の様子
  • Arrow Function
    • 朝起きたらクリックイベント書きたくなる(笑)CoffeeScriptであるやつ(–>, =>)
    • function,selfを書かなくて済むようになる
    • 引数は括弧を省略可能
  • ES6クラス
    • ES5まではclassなのにfunctionだしprototypeとか謎の宣言が必要だったがES6からclassが使えるように
    • extendsも使えるように

『ブラウザで今すぐES6を使おう』by林 優一氏 @frontainer

  • LIGのCTOやってる人
  • ES2015のブラウザ実装状況はIE10で10%,Chromeで65%程度
  • WebPack
    • Module Bundler require();したものの依存関係を解決してまとめる
    • webpackコマンドで1つのJSとして合体して出力してくれる
    • webpack.config.jsで設定を定義しておくとwebpackコマンドのみでいける
  • Browserify?
  • Loader
    • 読み込んだファイルに何かしらの処理をさせる
    • html-loader
    • babel-loader
  • babel-runtime
    • ファイルサイズに注意だが使った分だけ増える
  • frontplate
    • gulp + webpack + babelをまとめたやつを林さんが公開

『Years with JavaScript.Next』by dynamis氏 @dynamitter

  • 発表の様子
  • FF1.0の日本語担当で死んだ思い出
  • ECMAScript4はYahoo!とMSの猛烈な反対に合い陽の目を見ず
  • FirefoxOSでES6書こう
  • 佐藤徹平さん(@teppeis)イチオシ
  • FxDevCon キャンセル待ちだけど参加してね

QA

  • エディタ
    • vim, webstorm, atomとか。Visual Studio Codeも使いやすいかも
    • FirefoxのScratchpadが便利でオススメ
    • ES6に一番対応出来てるのはFirefoxじゃなくてEdge13(96%ぐらいES6対応が完了)
    • プラグインでESlintとか入れればどのエディタでも使える

「dots.2周年記念パーティ」に参加しました!

2015年10月30日(金)に行われたdots2周年記念パーティーに参加してきました! rubyのパパことmatzの話が聞けるということで楽しみにしてたイベントでした。 またdotsは渋谷のイベント・コワーキングスペースを2015年8月から運営しており、運営に関わっている人が知人でもあり、ちょこちょこ利用させて貰ってます。


※リアルタイム更新してました!

まつもとゆきひろ氏

  • PHPで出来てるdotsにあまり関係ないruby開発者のまつもとゆきひろです(笑)
  • スライドタイトルにデザイナってつけたのは渋谷でお洒落感出したかったからむりくり。
  • ひろゆきの方が圧倒的に多い名前で2ch作った人ですよね?って間違えられた。
  • 同じように西村博之氏がruby作った人ですよね?って間違えられたことがあるらしい。
  • プログラミングなんて教育出来ないですよねーとか言って嫌がられる。
  • 昔のスパコンは今のiPhone5と同じCPUパワー。
  • 言語が進化することで脳の限界で出来なかったことを出来るようになった。
  • 本質を理解すればバズワードではなくなる。
  • C10K/C100K問題
  • 変わらないものが大事。数学・アルゴリズム・コンピュータ基礎・基本プロトコル・人間・インタフェースの原理
  • matzが尊敬するデイブ・トーマス
  • 中学の時にプログラミングやったらコンピュータが思う通りに動いて「カワイイ」と思ったのが原点
  • basic言語の辛みからプログラミング言語に関心を持った高校生時代。Pascalの本とか。
  • 未来はコンピュータと直接インタラクションするようになる。スタートレックのコンピュータみたいな。
  • reactとか面白い。

パネルディスカッション

  • エンジニアの働き方とか
  • ビットジャーニー代表井原さん:なんで呼ばれた感満載で技術分かんない
  • VASILYのCTO今村さん:かっこいい写真
  • クラウドワークスCTO大場さん:娘と一緒に登壇
  • クックパッドCTO舘野さん:本日のモデレーター

未来に必要な技術とは?

  • スティーブ・ジョブズ見たらクズだった。クズさが必要by大場さん
  • ベースになる技術が必要
  • 好きなモノを突き詰めてる人に任せたいと思う

未来に繋がる考え方は?

  • 何の為に学ぶかをしっかり持つ。信念が大事
  • 仕事してても好きな仕事を優先してたまつもとゆきひろさん。クズ感出てきましたねby大場さん
  • 人の能力の総量は桁が違うということはない。あとはパラメータの問題。なので何か1つのことに振る方が集中出来る。byまつもとさん

どう働くべきなのか?

  • エンジニアが得意なことを1つの会社が囲うのは勿体無い。会社もオープンソース化すべき。by井原さん
  • 毎朝保育所に子供をデプロイ(笑)して出社するとか、全力出せる時間が少なくなる。生活も子供中心。労働のオープンソース化までやりたいby大場さん
  • 朝来ないからと言って全力を出せないとは思っていない信頼感がある。エンジニアはパフォーマンスを出せる時間に集中することby今村さん

今後のオープンソースの動向

  • 欲しいOSS
    • クラウド・ビッグデータ等のOSSは既にあるよね。hadoop,sparkとか。2世代目に凄いの来るかも。byまつもとさん
    • meteorとかactive value?コンセプト。リアルタイムでデータを出力し続ける。データバインディングに革新が起きればSPAが画期的に変わってくる可能性。byまつもとさん
    • 口に出すの恥ずかしいソシャゲを登壇中にやるまつもとゆきひろさん(笑)
    • TreasureData, Elasticsearchとか、更に運用を楽にしてくれるOSSがもっと出てくるかも。by大場さん
    • hashicoop製品使い始めたところ。決定版はまだまだなので欲しい。マーケティングオートメーション的なOSSとか。意思決定を支えるOSS。サービスレイヤーに近いOSS。by今村さん
    • kaizen platform的なものとかあるけどミドルウェアが違うので各社自社で実装している。by舘野さん
    • 製品を半オープンソースにして製品のコードを使っている会社のエンジニアがプルリクエスト送ってくるみたいな。企業のありかた。レベニューシェアとか。by井原さん
  • 注目される開発コミュニティ
    • 黎明期のOSSコミュニティは自身の影響度が大きいのでエンジニアとしてはやりがいがある。by舘野さん
    • 日本人がいないコミュニティに入ると国際化対応とか日本人しか分からないところで貢献できるよねby大場さん
    • 開発コミュニティの敷居を下げるような活動とかOSSとかが必要。最初の一歩を手伝うような活動とかby今村さん
    • コードレビューすらしていない会社もたくさん。OSS以前の問題で底上げが必要かもby井原さん
    • 大体動くけど隙があるOSSは他の人がコミットしてくれる。OSSに必要なのは炎上力だ!byまつもとさん
    • DHHとか敢えて目立つ発言して炎上させてる節がある。あれもOSS運用力の一つかもby舘野さん
    • コミュニティへの帰属意識が変わってきている。github時代は様々なOSSにコミットするように変わってきているbyまつもとさん
  • 質問
    • 好きなことに全振りすれば良い。サポートにはサポートの、新技術を開発する人にはその人の意味があるbyまつもとさん
    • ダブルクリックというユーザーインターフェースが悪い(笑)by今村さん
    • ハードウェア系もArduinoから始まるオープン化で組合せでやりたいことが出来るようになってきたby舘野さん
    • toC向けのハードウェアサービスレイヤのイノベーションはこれから起きるんじゃないか。mrubyとかも2020年とかにもっと爆発的に広まるんじゃないかby舘野さん
    • 新しいことが生まれる時は未知との遭遇から。ハードウェアエンジニアとウェブエンジニアだと摩擦が起きるけどそれを乗り越えたらイノベーションがbyまつもとさん
    • 時間の使い方や優先順位を伝えるのも重要だがノンバーバルな部分が伝わるのでちゃんと朝・晩は一緒に娘と飯を食うように自分にルールを課したbyまつもとさん

「Jubatusハッカソンwith読売新聞」に参加してきました!

先月8/23(土)、8/24(日)の2日間で歌舞伎座タワーのドワンゴ本社を会場として行われた Jubatusハッカソンwith読売新聞に参加してきました! 読売新聞の記事の写真にバッチリ写ってましたw

ちょっと遅くなってしまいましたが参加レポートをば。

Jubatusは「ユバタス」と読み、Preferred NetworksNTTソフトウェアイノベーションセンタが開発した オンライン機械学習向け分散処理フレームワークです。 ※公式HPの受け売りですが(笑)

今回のハッカソンはピンで参加したのでその場で即興でチームビルディングしました。 以前から知人で選挙ドットコムCTOの佐藤さん 率いるチームで「2030年の日本の首相を予測する」というチャレンジング?(笑)なテーマに挑戦しました。 大枠やったことを書くと、1985年時点での各政治家の当選回数、世襲か否か、得票数、選挙区の都市などを説明変数として 2000年の閣僚経験数が一番多い政治家=首相を推定する 回帰モデルを5年毎に作って2015年時点から2030年を推定する、という感じです。 説明変数のデータは主にwebクロールしてきたものを利用しました。

私の担当は前回参加したハッカソン同様、この辺のクロール周りだったんですが やはり時間がかかって思ったより大変でした。(前処理大事) 収穫としてはDBpediaの存在を知ったことです。 SPARQLというSQLライクな言語でデータの関係性を含めてデータ取得出来ます。 例えば安倍晋三だとprop-ja:内閣を参照すると閣僚経験数が分かります。 ※SPARQLって難解で使いづらいんですがw

で、肝心の結果なんですがこれが面白かった(笑) 以下、首相に最も近い順の予測結果です。

  1. 亀井静香
  2. 甘利明
  3. 前原誠司
  4. 石破茂
  5. 岡田克也
  6. 枝野幸男
  7. 林芳正
  8. 安倍晋三
  9. 藤井比早之
  10. 大畠章宏

ホントはチームメンバーみんなで「小泉進次郎」とか期待してたんですが全くかすりもせず(笑) 1位の亀井静香は2030年には94歳だし(笑) ちょっと悔いが残ったのはJubatusのオンライン機械学習の良さを全く活かせてなかったりwebインタフェースがなかった辺りでした。 ただ今回のようにかなり具体的なデータで機械学習を応用すると話題としては面白いものが出来るなぁということが改めて実感出来たのは収穫でした。

以下は発表会の様子です。

発表会はどなたもかなりガチの内容で非常に刺激を受けました。 その中でも特に印象に残っていたのがドワンゴの小田桐さんの発表でした。 ニコニコ動画のコメントをChainerによるディープラーニングでカテゴライズや次のコメントを予測する、 みたいなことをやってそのモデルをtwitterに応用しても結構使えるよね、という内容でした。 スライドが公開されていないかググってみたんですがちょっと見当たらず残念ですが・・・

ちなみにこのChainerもJubatusを開発したPreferred Networksが開発したディープラーニングフレームワークです。

「Jubatusハッカソンwith読売新聞」参加レポート

Jubatusと自然言語処理

同じチームメンバーの方がまとめたQiita記事が分かりやすいです。 自然言語処理を行う際に避けて通れない前処理が機能としてJubatusに備わっているので便利ですね。

オンライン(機械)学習とは

オンライン機械学習はJubatusの最大の特徴とされています。「機械」を省略して「オンライン学習」とも呼ばれます。 オンライン学習について分かりやすい解説は以下のNTTデータの記事です。

以下の記述がオンライン学習について端的に言い表しています。

オンライン学習は機械学習モデルにおける学習アルゴリズムの1つであり、データを1つずつ読み込んでモデル更新を繰り返すことで学習を行う手法です。反対に、データを全て読み込んでから学習する手法をバッチ学習と呼びます。

バッチ学習のデメリットとオンライン学習のメリットについては以下の記述が分かりやすいです。

通常、機械学習で作成したモデルは運用していくうちに徐々に精度が低下するため、モデルの精度維持のためには定期的に新たなデータを加えたモデル更新が必要となります。この時、バッチ学習では過去のデータと新しいデータを合わせてモデルを1から作り直す必要があり、多くの計算時間が必要になります。オンライン学習を用いれば、新たなデータのみを既存のモデルに取り込む逐次更新が可能になるため、モデルの精度維持がわずかな時間で可能になります。これを推し進めて、発生したデータをその場でモデルに反映すれば、モデルの精度低下を意識する必要すらなくなります。

このオンライン学習が迷惑メール判定ロジックに利用されていることを考えるとオンラインであることのメリットが分かりやすいですね。 常に迷惑メールの対象は増えていくのでバッチ学習で学習したモデルを運用してもすぐにそのモデルは古いものになってしまって 新しい迷惑メールを判定出来ないことになってしまいますよね。 そういう意味で特に変化の早いビジネス上では、IoTの絡みも相まってオンライン学習は今後拡大していくだろうと思います。

機械学習周りの勉強法

私自身、機械学習周りのインプットをし始めたのはここ半年くらいです。 インプットを初めて痛感するのは、統計学、機械学習、人工知能などの情報をググっても断片的な知識ばかりであまり体系的にまとまっていないので 初学者が体系的に知識をカテゴライズすることの難易度が高いという点でした。 体系的に知識を学ぶにはネットで楽しないでちゃんと本読めよ、というのが王道ではあるのですが、、 そう言っては身も蓋もないので何か良い方法はないかなと。

そこで個人的に最近良くお世話になっている銀座で働くデータサイエンティストのブログを書かれている Takashi J. OZAKIさんの以下の記事がオススメです。

ここで出てくる「落下傘方式」とは

「必要になった時に必要な項目だけ学び、覚えたらとにかく実践してみる」

という定義だそうですが、この勉強法はwebエンジニアとの親和性が高いんじゃないかと思います。 ググッたらちょっと古い「Rubyのパパ」ことmatzの記事がヒットしました。OSSのコードを読む場合の戦略の一つとして紹介されてました。

特に私の場合は機械学習アルゴリズムそのものを研究する訳ではなく、既に確立された機械学習アルゴリズムを利用するユーザーの立場なので、 実際にJubatusを触ってみたりpythonの機械学習ライブラリのpandasscikit-learnを 実データで利用してみた方が理解が進んでいる気がします。

pandasの参考になった入門記事

scikit-learnの参考になった入門記事

Chainerの参考になった入門記事

参考書籍

イベント「人工知能ハッカソン」に参加してきました!

最近、人工知能について非常に興味関心があります。 ロジスティック回帰による数値予測や機械学習、特にニューラルネットワーク・ディープラーニングへの興味関心が発展して最近では専ら人工知能についての話題に釘付けです。 そんな折に丁度タイミング良くサムライインキュベートさんからのメルマガで「人工知能ハッカソン」 が開催されることを知り、応募してみたところ見事参加抽選に当選したので過日(2015/5/23-24)参加してきました。

(当選時の喜びの声)


ハッカソン当日の模様

1日目前半にアイディアソンやって1日目後半、2日目に開発をやるというガチなハッカソン自体、 初参加でしたので良い経験になりました。今回のハッカソンでは基本ハスラー、ハッカー、デザイナの3つの役割の人が各チームに均等に割り振られるルールのようでした。 私がいたチームはハスラー2名、ハッカー3名(サーバサイドエンジニア2名、インフラエンジニア1名)な構成でした。 やはりデザイナかフロントエンドエンジニアがいないとプロダクトの見栄えが・・・な感じでした。。

ネタとしてはうちのチームでは「みんなのカイシャ(仮)」というタイトルで開発を行いました。 過去の判例の情報解析を手掛けるUBICさんが用意した自然言語処理系の人工知能APIを使って 選択肢に企業理念を候補として出力して選択していくと企業理念が似通った企業を推薦してくれるというものです。 クローラによるデータの収集や前処理に時間をかけすぎて肝心の人工知能APIバックエンドの実装が中途半端だったのが悔やまれました。

(2日目の成果発表の様子)

以下の通り、優勝したのはダイエット家庭教師等を手掛けるFiNCのインターンの方がいたチームでした。

ハッカソンに参加して感じたこと

参加して思ったのはハッカソンは(アイディア出しよりは)開発メインでテック寄りな方が良いかなという点です。 アイディア出しに注力するならハッカソンじゃなくてアイディアソンとして別枠でやった方が時間的な制約で中途半端にならずに良いかなと思います。 開催する側のメリットとしても2点あると思っていて、1点目はAPI提供側が開発時にストレスなく組み込めるか温度感を見る点、 2点目は提供したAPIが具体的な課題解決にどのように応用されるかアイディアの幅を見る点。 この2点の検証が盛り込まれた今回のハッカソンだったと思うのですが、提供されたAPIがシンプル過ぎてちょっと拍子抜けした参加者もいたようで 両方の検証がUBICさん的に十分に出来たのかはちょっと疑問が残る内容だったかもしれません。

ところで今回のハッカソンのメンターがトレタ増井雄一郎さん東京大学准教授の松尾豊さんだったのも参加理由の一つでした。 増井さんのお話を1年前のデブサミ2014で聞いたことがあり、 スタートアップ的な考え方からのツッコミが聞けそうだなと思っていたところ まさに想像通りのフィードバックがあってその視点が非常に参考になりました。

また、松尾豊さんは人工知能の専門家で 人工知能は人間を超えるか (角川EPUB選書) という有名な本の著者だということを知っており一度お会いしてみたかった方でした。 (この書籍は後日読んで興味深かったので次回のブログ記事のネタで書こうかと思います) ハッカソンの中間と発表時にチームへのフィードバックをいただいたのと、ハッカソン終了後にご挨拶して 日頃の興味関心事等について色々意見交換が出来たのは収穫でした。

ハッカソンで実際に何を作るのかという以上に、ハッカソンのテーマ(今回なら人工知能)に興味関心が近い人と繋がれる、 という意味でハッカソンに参加することは有意義だなと思いました。 初日にハスラー2名と私の3人で飲みに行って意見交換したんですが、参加者やメンターの方と直接会って意見交換するのは貴重な時間だと思います。 私は常日頃人が会うことで生じる「場のエネルギー」を信じているところがあり(別にオカルトという訳ではなく) 共通の指向性を持った人同士が出会う場としては相当良い場ですね。

人工知能ハッカソンの記事

参加者の方のレポート

td-clientを使ってHiveより早いPrestoクエリを実行する方法をrakeタスクで

最近、Hadoop(Tresure Data)と格闘してます。

td-clientを使ってTresureDataからデータを取得するrakeタスクを書いててHiveクエリだと遅いのでPresto使いたいなと思うことがありました。 td-clientのREADMEなど公式情報をざっと確認したところ見当たりませんでしたが、 td-client-rubyのソースコードを見たら案の定クエリタイプを指定するインタフェースがありました。

https://github.com/treasure-data/td-client-ruby/blob/master/lib/td/client.rb#L182

client.rb#L182付近gist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  # @param [String] db_name
  # @param [String] q
  # @param [String] result_url
  # @param [Fixnum] priority
  # @param [Fixnum] retry_limit
  # @param [Hash] opts
  # @return [Job]
  def query(db_name, q, result_url=nil, priority=nil, retry_limit=nil, opts={})
    # for compatibility, assume type is hive unless specifically specified
    type = opts[:type] || opts['type'] || :hive
    raise ArgumentError, "The specified query type is not supported: #{type}" unless [:hive, :pig, :impala, :presto].include?(type)
    job_id = @api.query(q, type, db_name, result_url, priority, retry_limit, opts)
    Job.new(self, job_id, type, q)
  end

上記の通りqueryメソッドの第5引数にoptsというハッシュで指定するオプションがあり、 type: :prestoな指定をするとHiveではなくPrestoでクエリが発行されます。

以下、rakeタスクでのサンプルコードです。

rakeタスクでのサンプルコード
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
namespace :execute do
  desc 'download treasure data by presto'
  task presto: :environment do
    apikey = 'your api key'
    db = 'your_db_name'
    query = 'select count(*) from your_table_name'
    client = TreasureData::Client.new apikey
    job = client.query db, query, nil, nil, nil, type: :presto
    until job.finished?
      sleep 2
      job.update_status!
    end
    job.update_status!
    p job.result if job.finished?
  end
end
実行
1
bin/rake execute:presto
結果
1
[[100]] # your_db_name.your_table_nameの件数

上記のように単純なクエリの場合、Hiveだとパフォーマンス的にwebアプリ等から動的に取得するのが 現実的に時間がかかりすぎたクエリでもPrestoであれば動的にデータ取得可能なので利用の幅が広がりますね。

合わせて読みたい

好きなことを仕事にするという論調を何故批判する向きが多いのかふと疑問に思った

私はちょっと前にこのブログ記事を読んで凄い共感しました。 記事のコメント欄を読むと比較的肯定的な意見が多いようです。 一方、はてブのコメントだとかなり批判的な意見が多いように思います。 コメントも合わせて読んで色々思うところがあったのでちょっと自分としての考えをブログにまとめておこうと思いました。

個人的には自分が正しいと思う価値観や信念に素直になって自分の仕事を選んで行こう。 何も規模や効率化だけを選ばなくても食べていける選択肢はある、って解釈しました。

この記事の方に対する嫉妬が邪魔するのか、単に価値観が違うのか、理解できない向きもあるようで、 それが個人的には不思議だったんですよね。一般的には好きなことを仕事に出来ていない人が想像より多いのかな?と。 そこでちょっと好きなことを仕事にするという切り口で色々な考え方を調べてみることにしました。



否定的な意見



肯定的な意見



中立的?な意見



その他



私見

上記の通り色々意見がありますが、職業を選択するときははなんだかんだ言って好きか、 好きになれそうかを基準にした方がこれからの時代にはマッチしていると改めて思いました。 で一度選択したら多少何があっても好きになれるまで修行だと思って踏ん張ってみて、 その仕事を好きになって自他共に認められるようになったら次のステージを検討しても良いのかなと。

あと学生を卒業したばかりの新社会人や第二新卒などのジュニアクラスの人は修行だと思って、 選択した仕事を好きになる為に一定の努力をするのは必要ってことでしょう。 といっても所謂ブラック企業でただひたむきに働き続けるのはブラック企業に加担することになってしまうので良くないので、 そういうケースに該当するかも?って思ったら経験豊富な人に相談した方が良いですけどね。

一番重要なのは、好きな仕事でどうやったら継続的に稼げる(少なくとも食っていける)ようになるかを 真剣に考えて行動していくということ。 そして個人的にはよりクリエイティブな仕事を選択すると好きな仕事で継続的に稼げる可能性が高いと思っています。 好きな仕事って1つじゃない可能性もあるので、もし色々好きになれそうで1つに絞れないって人は よりクリエイティブな仕事を選択すると幸せになれると思います。