業務システム開発の次の言語としてのKotlinの可能性
いつもながらの、雑感。Javaの次の言語としてのKotlinについて考えてみる。
上記みたいなこと、いろいろ考えていた。
もう、オープン系業務システム(エンタープライズ)の開発言語としては、長い間、UNIX系プラットフォームだとJava,Windows系だと、C#って感じでずーっと続いていたと思う。(Windows系はある種独自の世界なのとよく知らないので、ここでは割愛。)
その間、何度か、新しい言語の波が来ていて、Javaの次が来るって期待があったと思う。
RubyとRuby on Railsの衝撃
自分の記憶にあるのは、Ruby on Rails(以下RoR)の衝撃。
簡単なDBのCRUDアプリを作るのにも、ものすごい金と時間が掛かっていたStruts1全盛の時代。あっという間にWebサイトが作れてしまうのは衝撃的だった。『JavaからRubyへ』みたいな本が書かれた。
楽天市場のサイトがRubyで開発されたのって、象徴的と思う。
SIの世界でも、一部でRuby/RoRが使われるようになったし、Javaの過去資産を活用できるJRuby、そして、Javaとの連携を強く意識したgroovy/grailsが出てきて、動的言語が注目を浴びていた。
ただ、主流はやはりJavaで、言語よりフレームワークでRoRを強く意識して、同程度の生産性を出そうと頑張っていたと思う。
Javaも5になって、ジェネリクスやアノテーションが出来て、いいフレームワークを作れるようになってきていた。
Springは、RailsLikeな開発ができるSpring Rooをリリースしていたし、日本では、SAStrutsが色んな企業の業務アプリ開発に使われるようになった。
この動きっていうのは、Webアプリケーション開発/アーキテクチャのベストプラクティスが確立され、Webアプリ開発がボイラープレート的なコードの記述になっていったことを示しているんだと思う。
RoRはボイラープレート的なコードをほとんど0にしたし、それに刺激を受けたJavaフレームワークもその方向で進化した。
言語の動的性質っていうのは、インパクトの小さな部分だったのではないかな、と振り返ってみると思える。
ただ、多くの人がRubyやGroovyに触れることでそこに表現されていた関数型プログラミングの概念が業務アプリのエンジニアたちに広まったのは結構大きいと思う。
Scalaの台頭
動的言語とそのフレームワークが注目されている中、やっぱりコンパイル時のチェック、そして、何より静的言語のパフォーマンスいいよね、でもJavaいけてないよねってことで、Scalaが台頭してきた。
頻繁にクジラの画面を表示させていたTwitterがバックエンドをRoRからScalaに切り替えた、というのがその象徴的事件。
Webアプリとしてのフロント側だけでなく、Hadoopなどのパフォーマンスが必要とされるバックエンドでの大量データ処理の必要性が出てきたのも背景にあると思う。
ただ、技術的なチャレンジとしてScalaが注目、方々で採用されている中、Javaもしぶとく生き残っている状況がある。
Scalaの膨大な言語仕様や、コンパイル時間の長さ、バージョンアップ時の互換性の軽視あたりは、採用に二の足を踏むチームも多かったんじゃないかなー。
個人として、最初かなりScala面白そう、と思ったのだけど、実際書いてみると色々辛い。。。年寄り文系の自分には難しすぎるんだよね。Scalaは。。。
下記みたいな話もある。まあ、パフォーマンス問題は過去の話と思うけどねー。
今の言語の進化の方向は、静的型付けがある中で、どれだけ手軽にプログラミングできるか、を模索していると思う。Go言語とかもね。
(ざっくり言い過ぎと思うが。。。)
Kotlinの位置付け
KotlinはIDEベンダであるJetBrainsが開発したJVM上で動作する静的言語。(JavaScriptにコンパルすることもできる。)
まだ、リリース前のベータ版だけど、もうすぐリリースとのこと。Android開発ではもう結構使われているっぽい。
基本的に、KotlinはAltJavaであるC#,Groovy,Scalaあたりの良いところ取り。そして、Javaプログラマが多く従事している業務アプリの現場での課題解決を強く意識していると思う。
下記は自分がいいな、と思ったところ。
- 静的言語であり、コンパイル時チェックが効く
- 文法がJavaプログラマにとってとても学びやすい
- Null Safety/Optionalが言語レベルでサポートされて、Java8のOptionalより分かりやすい
- 関数型プログラミングが言語レベルでサポートされ、Java8より分かりやすい
- 演算子オーバーロードや拡張メソッド(Scalaのtrait)などDDDに都合の良い機能が豊富
- 困った時はJavaで書ける
- 返り値を複数とるような感じで、書ける
Java8への移行との比較
個人的には、Java8のラムダやメソッド参照、Optionalなどは、かなり無理矢理詰め込んだ感があり、相当使いにくい。
複雑なロジックになった時、StreamAPIを下手に使うと、可読性が低下する気がするし、Optionalの使い方も徹底できる気がしない。そこら辺、どうしてもプログラマの規律に依存しなくてはならないと思う。
ある程度の規模のプロジェクトになると、これらを全面的に導入して、学習コストに見合うメリットが出るとは思えない。
(技術自慢のプログラマー集団なら、新しいチャレンジにもなるし、ありかと思うけど。)
個人的にそこにコストをかけるんなら、ValueObjectとか、仕様クラスみたいなDDDのやりやすい所をやっていった方がプロジェクトに対してはメリットが大きいと思う。
対して、KotlinはJava8の新機能がやろうとしていたことを遥かに効果的に実現していると思う。とにかく分かりやすくて、Javaプログラマには学習コストが低い。
ちゃんとした研修コンテンツを作って動画配信してあげれば、プロジェクト全体に導入することも大したコストなくできると思う。
@masatsugumatsus 結局、技術的に苦労するのってフレームワーク側だから、機能開発に限っちゃえばkotlin導入のリスクって殆どない気がするなあ。SIのプロジェクトなんて、どうせJavaもよく分からず使っている人ばかり、って場合も多いし。。。
— 松下正嗣 (@masatsugumatsus) 2015, 11月 23
技術トレンドについての一考察
こんなブログ記事があったので、
「自分は技術トレンドを追う時にどう考えているのか」を考えてみた。
- 目的:技術力や問題解決力の向上。肥やしになる、と思っているので、その技術を使えなくても問題ない。(自分は研修屋だからなおさら)
- 勉強対象の選定:新しい技術のうち、問題解決のアイデアが面白そう、と思ったもの、大きな業界のトレンドに関わりそうなもの、を選んでいる。
- 深さ:ちょこっとやって、飽きたらやめる。
まあ、こんな感じだから、プレッシャーとかないよなー。
書評『変革を生む研修のデザイン―仕事を教える人への活動理論』
- 作者: ユーリアエンゲストローム,Yrj¨o Engestr¨om,松下佳代,三輪建二
- 出版社/メーカー: 鳳書房
- 発売日: 2010/12
- メディア: 単行本
- クリック: 9回
- この商品を含むブログ (5件) を見る
原著は『Training for Change』
Training for Change: New Approach to Instruction and Learning in Working Life
- 作者: Yrjo Engestrom
- 出版社/メーカー: International Labour Org
- 発売日: 1999/04
- メディア: ペーパーバック
- この商品を含むブログを見る
今の所(2015年11月)、絶賛レビューが存在しないので書く。
簡単な紹介については下記の記事を参照
NAKAHARA-LAB.NET 東京大学 中原淳研究室 - 大人の学びを科学する: 「変革を生む研修のデザイン」と「人間科学のための混合研究法」を読んだ!
研修屋には耳の痛い話
本書の冒頭でも触れられているけど、本書では、何の理論化(モデリング)や目標指向の指導を経ることなく、「経験」を経れば、学習が起こる、という一部の「経験学習」や「アクションラーニング」の論者の考え方に異議を唱える。
また、ディスカッションや演習、ダイアローグといった、教授手法の外面的特徴にフォーカスした研修が、生徒の内面的学習プロセスを無視しては全く意味がないことも主張している。
個人的にはインタラクションや演習は重視するし、学習効果は高いと思う。ただ、研修業界では、学習効果ではなく、受講者を飽きさせない、とか、満足度を上げることを理由にさしたる効果もない楽しい演習を入れる場合も多々あるので、これは重要な指摘と思う。
学校教育で「アクティブラーニング」が実施されようとしている今、広く読まれ、考えられなければならないんじゃないかと思う。
インストラクショナルデザインとの関係
一般的な研修設計手法として知られているのは、所謂インストラクショナルデザイン(ID)。開発プロセスとしては、「ADDIEモデル」になるのかな。
ADDIE Model - Wikipedia, the free encyclopedia
通常、学習目標となる行動を特定して、スキル分析をして、「〜ができる」って形で学習項目を挙げていく。
個人的にはとても優れた手法だと思うし、実践的。
特に「カスタマーサービスがマニュアル通りに実施する」、みたいな単純なスキルのトレーニングに関してはある程度モデル通りに設計していけば研修ができる。
- 作者: ウォルターディック,ジェームス・O.ケアリー,ルーケアリー,Walter Dick,James O. Carey,Lou Carey,角行之
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2004/08
- メディア: 単行本
- 購入: 1人 クリック: 13回
- この商品を含むブログ (19件) を見る
ただ、もう少し複雑で高度なスキルとなると、色々と工夫が必要で、そこは当該専門分野の知識のほか、講師経験や研修開発経験を生かして研修に盛り込むしかない。
というのは、IDそのものは特定の学習観とか教授手法からは独立した、スキルの外形的分析手法の定義とプロセス定義だけを行っているものだから。
エンゲルストロームの本書は、このIDで空っぽだったコンテンツ開発の手法を提示していると言っていいと思う。
その手法はとても実践的で有用。自分がいろんな失敗を経て、こうじゃないか、と考え、ある程度うまくいっている持論がより洗練された形で説明されている、という印象。
本書のビジョン
エンゲルストロームの教授理論の素晴らしいところはそのビジョン。
人が実践コミュニティの中で自ら学び、既存の自分の認知的枠組みを問い直す「拡張的学習」を行うことのできる能力を育てることを視野に入れている。
教えられただけでなく、それを問い直し、乗り越えることを見据えている。
教え子が教えた内容を乗り越え、教師を超えていく、というのは、多くの教育者の目標だろう。
本書はそれを達成することを手助けしてくれる。
指導の黄金律
本書の終章にて、提示された指導の黄金律。それぞれ、最初の一行だけを抜粋。
- カバーする主題事項は少なくし、よりよく、徹底的に教えること。
- 脱文脈化された「出来合いの」事実や技能を教えることに満足しないこと。
- 生徒の中に実質的な動機付け(主題事項の使用価値への興味)を喚起すること。
- 主題事項の本質的な原理を明らかにする方向づけのベース(Orientation basis)を作り出すこと。
- 探究的学習のサイクル(動機付け、方向づけ、内化、外化、批評、統制というステップを含む)を目指すこと。
- 充分な配慮をもって教授計画を立てること。
- 生徒に多くを求めると同時に、生徒を尊重すること。
その他、引用ツイート
「より深い説明を行うには、現象やパフォーマンス全体の源泉、創発、進化の説明、すなわち検討中のシステムの説明が必要になる。」ユーリア・エンゲストローム
— 松下正嗣 (@masatsugumatsus) 2015年11月3日
「教授内容は、区分けされた記憶すべき知識の固まりというよりも、包括的な実践を習得するための柔軟で可変的なツールキットとして捉えられるべきだ、ということである。」ユーリア・エンゲストローム
— 松下正嗣 (@masatsugumatsus) 2015年11月5日
「その理論は、固定した定義として提供され、後に教えられるような実践的応用や技能とは切り離されていることが多い。だが、このような内容は理論的と呼ぶべきではない。むしろ、学校教育的と読んだ方がいいだろう。」
— 松下正嗣 (@masatsugumatsus) 2015年11月5日
「真の理論の本質的特徴は、実践的事柄や活動を習得するのに役立つという点にある。仮にこの本質的特徴を教授のなかで作り出せていないのであれば・・・教えられている理論というのは、おそらく、根拠のない見せかけの言葉を撒き散らしているだけなのである。」ユーリア・エンゲストローム
— 松下正嗣 (@masatsugumatsus) 2015年11月5日
「最も成功している教師は他の教師に比べ、極めて難度の高い課題を用いているということが明らかになっている。...難しさというものは、早く進みすぎる教授とは全く別物である。...同様に、難しさは不明瞭や指示の不味さとも別物である。…こうした人為的な難しさは教師倫理にそぐわない。」
— 松下正嗣 (@masatsugumatsus) 2015年11月7日
研修フォローアップに対する一考察
例によって、整理しないで、たらたら書く。
研修フォローアップの大切さ
下記のようなツイートをした。
研修のフォローアップについて、自分なりの感覚と考えをまとめとこうかな
— 松下正嗣 (@masatsugumatsus) October 29, 2015
きっかけは中原先生のところのフィードバック研究会で、フォローアップが少し議論になったこと。
論文ではエクゼクティブコーチングと360度フィードバックの明確な効果が実証的に確認できた、とする。ただ、コーチングの対象となった項目についてしっかりとしたフォローアップを実行している。
研究会では議論のなかで、この結果は「ある意味、当然だよね。」という議論がでた。フォローアップのなかで、実際の行動を行うようにフォローするのだから、360度フィードバックの結果が改善されるのは、当たり前。
コーチングに限らず、研修効果の研究では、やはり、フォローアップの大事さは強調されている。
NAKAHARA-LAB.NET 東京大学 中原淳研究室 - 大人の学びを科学する: 「研修のエンドレス化」と「誰も実行しないアクションプラン」!?:
ちと、記憶が定かでなないが、研究では、エクゼクティブコーチングは「効果が出るけど、長続きしない」傾向にあるというのが、言われているそう。
ここでも、きちんとフォローアップをすることが大切、という結論になるのかもしれない。
研修フォローアップの目的は何か?
さきの中原先生のブログ記事を引用すると、
「アクションプランを創らせること」が研修ではなく、「アクションプランを実行させるまで寄り添うこと」が研修の仕事という認識が広まっていくのだとしたら、関係各所で、さまざまな見なおしが必要になってくるものと思います。「役割」の見なおしなのか、分担の見なおしなのか、仕事の再定義なのか。それはそれぞれの会社で違うでしょう。
個人的な考えでは、研修の終わりは「自ら研修で学んだことを実行し、それを土台にさらに高度な学習を始めることができる状態をつくる」ことであり、それができてはじめて「学んだ」と言えるのだと思う。
つまり、「フォローなくして、行動できない」のであれば、それは「研修の失敗」を意味する。フォローアップに意味があるのは、それが「行動をさせる」のではなく、「フォローなしでできる」状態を作ることに資するものでなくてはならない。
具体的には「できるようになっていることの定着」か、「研修で最近接発達領域まで向上した学習内容を、フォローを伴う実践を通じて自力でできるようになる」ことあたりを目的にするのだろう。
これはいわゆる行動変容というやつで、真面目な教育担当者や講師・コンサルタントといったプロフェッショナルは当然考え、目指しているものだと思う。
個人的には、「フォロー」を実施して、当然の結果として指標が向上することをもってフォローが大切というのは不誠実だと思う。測定上、研修内容の品質よりも強い相関がでるのは当たり前。無理やり「やらせている」のだから。
そのフォローアップが本当に「学習」に意味があるのか、フォローアップ後の成果が「学習」を測定しているのか、ということは注意するべきだと思う。
※コーチングや、アクションラーニングなどは研修本体とフォローの区別が付かないものもある。その場合でも、「学習」の成果を測定するタイミングは気をつけるべき。
「効果の出ない研修」との戦い
研修フォローアップは、教育担当や教育プロフェッショナルにとって、ある意味「救い」になる。「役に立たない」、「福利厚生」とされていた研修に、低リスクで効果があると、説明することができるから。
でも、今まで述べてきたように、研修フォローアップによって作り出される成果は「学習」の成果では必ずしもない場合がある。注意しないと自己欺瞞に陥ってしまう。
(もちろん、短期的な成果をあげるための「業務支援」としては正当な成果としてあり得る。でも、それは「教育」ではない。)
もちろん、短期的な研修のようなもので本当に「不可逆」な効果を出すことは難しい。
でも、自分は新人のときに受けたCTIのコーチングワークショップ(12日間)でコミュニケーション能力、特に傾聴力に劇的な改善を得た経験があるし、新人研修のときのビジネスゲームで得た学びは今も残っていて、自分の核になっている。
ワインバーグの著書を読むことで得た問題解決力は読む前と同じレベルにはもうなれない。
(人間という複雑系を相手にした時、変化を求めすぎたり、成果を過度に強調することが逆効果になる場合も多々有る。というのは留意すべきだけど。。。)
限られた時間の体験が不可逆な変化を起こすことは可能だし、自分自身でも幾つかの成功体験もある。
研修やワークショップでなければ身につけられないもの、もしくは、それを通じてだと圧倒的に効率的に習得できるものは確かにある。
また、CTIの品質を知っている身としては、グローバル企業でのリーダーシップ開発は、あれと同等のものがあるはず。いつまでも「福利厚生」、「所詮は研修」って感覚で時間と金を無駄にし続けていると、追いついていけない。
高度成長期を経て成熟し、成長機会を業務の中で豊富に提供できる事業が減っている多くの企業では、高品質の教育を整備し、武器にしていかなきゃいけないと思う。
教育・研修屋の仕事は「効果のでない研修」との戦い。安易な「フォローアップで効果でました。」は敗北以外の何物でもないと思う。
教育のビジョン
中原先生のブログ記事に触発されて
自分はよく、「喋っただけで、教えてない状態」と呼ぶ。学んで初めて教えた、という。
「誰も学べていない」のに「教えた!」というのなら!? http://t.co/Dg3EZrZ0SG @nakaharajunから
— 松下正嗣 (@masatsugumatsus) October 5, 2015
元のブログ記事にかの有名なデューイの言葉が引用されている。
「教えること」や「学ぶこと」は、「売ること」と「買うこと」に似ている。「誰も学んでいない」のに「わたしは教えた!」と言うのなら、「誰も買っていない」のに「売った!」というのと同じだ。
(Dewey, J. 1910 How we think, p29)
特に教育に携わる人にとっては、心しておくべきことだと思う。
一方で、教育を求められるままに答えを教えるビジネスと捉えることは弊害も生む。
ある程度OJT,Off-JT問わず、人材教育の経験を持つと、大抵の人は多分すぐに「教え過ぎてはいけない」ということに気づくと思う。
学び手を消費者と見立て、知識と答えを求められるがままに供給していると、すぐに彼らが自ら現実や経験から学ぶ力と意欲を失ってしまうことに気づくから。
師匠が「背中を見て学べ」というのは、弟子に自ら学ぶ力が必要であることを伝える意味で合理性がある。
大切なのは、最終的にどういう人に育って欲しいか、というビジョンだと思う。人から与えられた知識で満足するような人材になって欲しいと望む人や組織はほとんどいないだろう。
教育においては、自分たちが提供しているものが、「自ら学んで自分の人生を切り開いていく人たちの成長に寄与しているいるのか」、ということが問われなくてはならないのだと思う。
抽象と具象の間:Goはなぜ気持ちいいのか。
goが何故こんなに気持ちいいのか分析してみよう。最初は微妙な仕様と思ったけど、使うと味が出てくる感じがする。。。
— 松下正嗣 (@masatsugumatsus) September 7, 2015
てなわけで、思うところをつらつらと書いてみる。ポエムだから、意味はあまり理解しようとしないほうがよい。
Go言語とは
手続き型のコードは分かりにくいのか?
→簡単な問題をとく場合は分かりやすい。コンピュータに対して、何をさせているのかが明確。ただし、複雑な問題を解く場合は分かりにくい。複雑な問題を解く場合は、詳細な情報が脳の処理能力を圧迫するから。複雑な問題を分かりやすくするために人間は問題を抽象化して、情報量を圧縮する。
オブジェクト指向や関数型は分かりやすいのか?
→オブジェクトや関数は手続きが抽象されたもの。抽象化された語彙に習熟している人にとっては分かりやすい。逆に、ある分野の初学者がいきなり抽象的な理論、専門用語を使って何かを説明されてもわからないようにその抽象を理解できないものにとっては分かりにくい。
オブジェクト指向や関数型のプログラムを理解しやすい、と感じる人は、オブジェクト指向や関数型が解決しようとしている問題を良く理解している人。抽象化は進めば進むほど、エキスパートにとってははるかに難しい問題を解くことが可能になる反面、問題領域の初学者にとってハードルを上げることになる。
人の問題と解決策の理解を促進するものは、抽象的な理論そのもの(オブジェクトや関数)でも、問題や解決策の赤裸々な記述(手続き)でもなく、抽象と具体を行き来するプロセスだと思う。
Goに備わった簡便な抽象化の仕組みであるインタフェースは手軽に問題を抽象化するが、具体的なコードと非常に近いところにある。
例えるなら、Javaが高校数学、Scalaが大学レベルの数学を駆使して問題を解けるようにするのに対して、Goは中学レベルの数学を利用して問題を解かせようとしている感じ。
その意味で、分散処理プラットフォームみたいな、高度な技術にJavaやScalaが好まれる、というのはわかる。
自分が最も尊敬するワインバーグの言葉に「小学校4年生が解けるより難しい問題を解こうとしているなら、何かが間違っている。」っていうのがある。
大抵の実践プログラマたちにとって、学術的で高尚な問題をとく、というよりも日常のありふれた問題を解くのが仕事だろう。
go言語の仕様には、ともすると問題を難しく考えすぎる自分らに対して、地に足のついた問題解決を促すメッセージを多分に含んでいる気がする。
「シンプルに考えよう。これで充分でしょ!」って。
新卒入社は大企業か、ベンチャー(中小企業)、どっちがいいのか?
(2019/04 更新)この記事は少し古くなっている。現在では色々事情は違う
下記のような記事があったり
まあ、こんなツイートがあったりする中で
ベンチャー企業で優秀な人が敢えて働く事は間違いだとは思わないけど、新卒者は大企業でビジネスの基礎を身に付けてからにした方がいいと思う。
— ボヴ (@cornwallcapital) 2015年9月6日
あと新卒キップを使わずともベンチャーは入社できるけど、大企業はそうは行かないからね。
大企業のブランド力や組織力は、殆どのケースでベンチャーの小回りや柔軟性を圧倒してるのに、例外的にベンチャーが大企業を破ったケースが過大に喧伝されてる気がする。
— ボヴ (@cornwallcapital) 2015年9月6日
プロ野球選手で大成功した1人の陰には挫折した千人の選手がいるのに、後者は無いものとする現象と同じで。
思うところと、上から目線で新入社員へのアドバイスを少々。
自分の経験
- 中規模企業の教育子会社(小規模)に入社→BtoBの研修屋で、中小、大企業の若手育成でなんとなく、状況を察する。
- 大企業の教育子会社→親会社に出向。大企業の中で仕事する。OJTトレーナーとかもやった。
転職のしやすさについて
転職活動の経験も踏まえて
- 中小→大企業、大企業→中小も当然0ではない。
- 中小では、多くの企業が未経験者歓迎のポテンシャル採用やっている。大抵、実績とくに関係なくコミュ力と地頭でいける。
- 大企業では、一時期氷河期の採用抑制を調整するため、第二新卒採用が活発になったこともあったけど、季節もの。離職率も低いので、狭き門と思う。
- 中堅では、中小でも会社によるけど、経験を重視した専門家、マネージャ募集とかはあると思う。また、BtoBでは大企業が顧客である場合が多く、大企業経験が求められる場合はある。
- 大企業ではマネージャ採用は少ない。一部スペシャリストとか、実績を買われて、とかはある。IT系は今はPM含めてかなり募集しているみたい。
→ざっくりいうと、大企業行った方が、選択肢は広がりやすい、というのは多分確かと思う。ただ、それも3年目ぐらいまでで、それ以降は、実際の経験が問われるから転職のしやすさは職務次第になってくる。
成長について
自分自身はどうなのか、は棚上げするけど、大企業で全然成長できない例も、ベンチャーで残念な感じになる例も知っている。成長に適した環境かどうかも大企業、中小企業それぞれで色々ある。
大企業でしか学べないものがあるというより、ベンチャーで学びにくいもの、大企業で学びにくいものが色々あるという印象。
また、会社の規模や成長フェーズというよりも、会社の文化や戦略に依存する場合もある。とはいえ、これは学生が見抜くのは相当難しいと思う。
仕事をしているだけでは成長できない場合は、色々自己啓発に励む必要があり、それを仕事に生かすよう頭を使う必要があるのは大企業、ベンチャー問わずある。
原則として成長の環境としては大企業/ベンチャーではどっちもいい部分、悪い部分があるとしか言えない。
ただ、若手はどこも体力勝負だと思うけど、
結論
個人的には、「迷ったら、大企業」でいいと思う。理由は選択肢の広さ。また、入社前とギャップは常にあることを覚悟すること。3年くらいは色々悩んで、方向転換してもいいと思う。
大企業へ入社した人への参考意見
大抵の場合、自分の実力以上の給料と評価を世の中からもらうことになる。大企業のブランドや地位がない自分がどの程度なのか、お金はどこから来ているのか、は常に意識した方がいい。また、自分が死ぬまでに、業績が悪化してリストラが行われることは前提でキャリアを考えること。
ベンチャー/中小企業へ入社した人への参考意見
運が悪いと社内に手本となる人が見当たらない場合も十分ありえる。その場合は社外の勉強会や読書を通じて、勉強すること。できればメンターとなる人を探すこと。(でも変な自己啓発系にひっかからないように。。。)
組織に問題があるのであれば、組織を動かしやすいメリットを生かして、若手であろうと、自分が先頭を切って組織を変えるつもりで動くこと。
新入社員への参考意見
- 組織がどれだけサポートするかはどもかく、成長の責任は自分にあることが大前提であることを意識すること。
- 基本的には、若手は量をこなさないと仕事が分からないと思うから、量をこなすことを拒絶しないこと。その上で、自分の体力、精神力の限界を見極めること。
- 失敗、そして怒られることを恐れないこと。1年仕事して、こっぴどく怒られることが一度もなかったなら、多分それはリスクをとってない=仕事していない。