【読書ノート】才能の正体

きっかけ

安売りしてたから

感想

「才能」とは何か？

才能＝能力ではない。
能力が高まっていくと、やがて、才能として認められる。

メモ ：つまり、才能＝能力では？いきなり矛盾しているように見えたのだが、俺の気のせいかな？思うんだけど、才能とか天才とかって、そう呼ばれる人たちの鍛錬を想像できない人が使いがちな言葉だと感じてる。写輪眼とか、あきらかに努力で手に入れなれないものを持っているなら分かるけど、現実には、そんなものないからな。

才能がある人達＝全員努力している。
すべての人が、優秀と言われる可能性を、もともと持っている。

周囲の評価は、結果だけをみて評価する。
人は、結果からしか判断ができない。
結果がでると、過去の記憶は、改ざんされてしまう。

メモ ：何かの能力使いみたいだな。記憶の改ざんは、意外と簡単に起きるのかもしれない。

人は、結果から遡って物語を作ろうとする。
結果を作る物語の大きな要員になっているものが、才能。

メモ ：才能ですべて丸く納めてるってことか。歴代の英雄たちは、それに近いかもな。。。

人は、認知で行動が変わる。
自分にもできそうなことなら、行動する。
逆に高すぎるハードルは、諦めてしまう。

メモ ：認知って言われると、ペルソナ５を思い出してしまう。

「やればできる」は、結果至上主義。結果が出せないと分かった瞬間、やることそのものを辞める。
正しくは、「やれば伸びる」。

物事を分析する手法として、Ｗｈｙ型／Ｈｏｗ型がある。
Ｗｈｙ型：結果から、理由を作る。→ 能力が伸びない
Ｈｏｗ型：過程での変化を見る → 動機付けが向上しやすい＝やれば伸びる

メモ ：激しく同意。ＩＴ業界って、よく、なぜなぜ分析しろと言われるが、何かがおかしいと思っていたが、やっと理由が分かった。結果しか見てないから、糾弾みたいになったり、変な方向に議論が波及していくと思う。犯人探しをしたいんじゃないって言うけど、「なぜ？」の時点で、結果ベースで物事見ているから、犯人いる前提だろうって思う。

人間＝何歳になっても後悔しているもの。
後悔を断ち切るには、「やらなかった」を失くしていくしかない。

メモ ：やっちまって後悔するパターンは、いいんですかね？オナラを出そうとしたら、実が出ちゃったとかは、やってしまった後悔だと思うんですけど、トイレに行くことをしなかった後悔になるんですかね？

才能ある人＝結果を出せる人＝洞察力が高い人
先の展開を予想できた方が、結果をコントロールしやすい。

能力を才能へ

守破離を意識してスキルを磨く。
このとき、できる人を師にしてはいけない。なぜなら、助言をもらっても、難易度が高すぎることが多い。
当たり前のようにこなしていることが、実は難しいこともある。
やるなら、行動を真似る。

どんなに優秀でも、継続しないと伸びない。
他人が努力しているときは、邪魔せずに見守る気概が必要。

続けるには、自分にあったやり方を見るけるしかない。
教師／上司が、成功体験をもとにアドバイスしてきても、必ずしも適用できるとは限らない。
なぜなら、その人固有の成功談であるから。たまたま合ってしまう場合もある。
鵜呑みにせず、それが自分にあてはまるのか、よく考えて適用する必要がある。

技：詰め込み。
術：考え方を覚える。
スキルアップしないのは、技と術が混同しており、使い分けができていない。

成功体験は、不要。
それをこれから作り出す。

「才能」のマネジメント

人に伝えるには、前提の共有と概要が大事。
どちらも、話に惹きつけるために必要になる。

フィードバック＝無意識に改善したくなるもの。
改善意欲を削ぐフィードバックは、間違ったフィードバックをしてしまっている証拠。
フィードバックをする際は、中立的なものを行う。
中立的なものは、なるべく事実をベースにするといい。
相手をコントロールしようとしたり、威圧的に価値観や感情を伝えるのはメリットなし。

チームは、目的と、目的を達成するためにもっとも効率的な作戦は、何かを考えて動ける。

JJUG CCC 2019 Spring 参加報告

公式サイト

JJUG CCC 2019 Spring - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

参加セッション

• Oracle Keynote Valhalla, updates and future
• Catch up Java 12 and Java 13
• ドメイン管理サービスにおけるJava活用のご紹介
• 入門: 末尾呼び出し最適化
• ソフトウェア設計の教育工学的な分析と育成へのアイデア
• Project Loom - 限定継続と軽量スレッド
• Functional Spring Cookbook

感想・まとメモ

Oracle Keynote Valhalla, updates and future

• 内部クラス -> JVM上では別クラス
• JEPの名前は、変わることもある
• 二仕様物語は、笑うところ
  • たぶん、笑わないのは元ネタが分からないから。二都物語とかけているらしいが、読みが似ているだけで、内容が揶揄しているのか、よく分からなかった。。。
• Java11より前は、内部クラスから外部クラスを呼ぶときにBridgeMethodを経由して呼ばれる
  • 開発者は作ってないが、スタック上に出力されてしまう。。。
  • やろうと思えば、外部からBridgeMethodにアクセス可能
  • Java11でなくなった
• ValueTypes
  • Minimal Value Types プロジェクト(MVT)
    • タイプの種類
      • LQRU
        • なんか、エヴァのタイトルに出てきそうな英字だな。。。

BridgeMethodは、一回、試してみたい。
確かに、Java8使っているときに、見覚えのないメソッドがスタックトレースに出てきた経験がある。

Catch up Java 12 and Java 13

Catch up Java 12 and Java 13 from Yuji Kubota

www.slideshare.net

Java12

lts のあとなので、大きな変更はない。
とはいえ、ツールとか入ってきた。

JEP 189

• GCが7種類に
• Shenandoahは、一回の GC は一定だが、頻度が変わる。

ShenandoahのJEPのサマリを見たときは、「そんな、バカな！」と思ったけど、やっと意味が分かった。
最初見たときは、一回のGCで全部回収して、実行時間も一定みたいな意味合いに見えてしまったが、違うのね。
参照の切り替えで済むから一定で、頻度は違うかもってわけか。。。
思ったんだけど、これの発生タイミングが重複してしまったら、どうなるんだろう？

JEP346

• Java がメモリを返すようになった
• これが可能になることで、常駐プロセスが作りやすくなったはず。
• GC 改善は続いている。

JEP325

• switch -> preview 版
  • 即使うのは待った

イマイチ、これは、便利になったのか？って疑問符が湧く。
switch文が嫌いなのだが、JDKのコミッターにswitch文好きがいるのかな？
それとも、デカい回収のための何かなのだろうか？

JEP341

• 起動時間の短縮

JEP334

• 定数の遅延処理

String#transform

• ラムダ式でアクセスの逆順で書けるようになる。

かなり便利そう。
これは、Stringだけなのかな？
他のオブジェクトでも使いたいケースがありそうな予感。
内部の仕組みを確認しておきたい。

java13

• socket 一新される
• Loomは桜庭さんのセッション参照

かなり駆け足だった。
４５分で振り返るのは、無理があったのだろうな。。。
興味持ったところだけしか、メモは取れなかったが、コンパイラの話は、かなりスッキリした。
あとは、String#transformが、かなり気になる。

ドメイン管理サービスにおけるJava活用のご紹介

• TLD -> top level domain
• ドメインはオークションで落札する必要がある。そこから色んな会社を経由して利用者に渡る
• ドメインの最高落札額は、１５０億円くらい

ICANNと聞いて、最初にICANを連想してしまった。。。
ICANNって、ビジネス的にウハウハなんじゃないかな？って思ってしまった。

入門: 末尾呼び出し最適化

speakerdeck.com

末尾呼び出し最適化ってのは、後続の処理がないことに目を付けているわけね。
処理をスタックトレースに積まないことで、メモリ消費を抑えていると。
後々、疑問に思ったが、問題が発生したときにトレースできなくなるのでは？と思ったが、どうなんだろう？
同じ処理の繰り返しだから、スタックトレースは不要という考えなのかな？
分岐があったら死にそう。。。

あと、スタックってのは、遊戯王で言うところのチェーンを積んだ状態と一緒だなって思った。

ソフトウェア設計の教育工学的な分析と育成へのアイデア

speakerdeck.com

やっぱり、現場に出てない講師もいるんだ。。。
なんか、セミナーとかは、現場に出てないやつが出ているのではないかという疑惑が心の中にあったが、やっぱり、ものによっては、現場から追い出されたやつが講師しているケースもあるのね。。。

分からない箇所が本人の説明と違う箇所にあるってのは、よくある話。
俺も、新人の頃は、分からない箇所を教えてもらっても、しっくりこないことがよくあった。
それを理解して接してあげないと、精神攻撃になってしまうから、教える側は注意が必要かもね。

Project Loom - 限定継続と軽量スレッド

Project Loom - 限定継続と軽量スレッド - from Yuichi Sakuraba

t.co

• safe habor statement -> 信じるなの意
• 並列／並行処理＝難しい
• 並列処理がスケールしない＝ CPU が遊んでる

待ちを譲るって聞くと、js の Promise だな。
JavaでjsのPromiseをやるには、スレッドを上手く使うしかないと思う。
wait-notifyAllでも実現はできるのか。。。

どうも、スレッド周りの話は、難しい。
ExecutorServiceが理解できてないせいかもしれない。
時間を見つけて、本腰入れて勉強する必要があるかも。
できれば、Fiberが来る前にやっておきたい。

Functional Spring Cookbook

docs.google.com

Spring Fu???
eclipse cheにインスパイアされてそうな命名に感じる。
ただ、FuはFunctionであることは、なんとなく予想できる。

Springにも関数型の概念が入ってきているのか。
Spring webfluxを早めにキャッチアップしておきたい。

全体通して

やっぱり、人が多い。女性の割合がかなり増えた印象がある。
あと、初参加者は、毎回、一定数いるんだなって感じた。

主流はmacだが、サーフェス使いも増えてきた気がする。

String#transform が、かなり気になった。
最初にやりたいことが、一番最後に記述するはめになるのを、どうにかならないものかと考えていたので、とても画期的に思えた。
応用が効くのか、試したい。

タスク・課題

• String#transformの確認
• BridgeMethod
• ExecutorServiceを調査する
• Spring webflux

Vue.jsをvue-cliで試してみる

きっかけ

UI周りの実装が楽にならないか探して、vue.jsを知ったので試してみる。
react.jsも試したことはあるんだけど、覚えることが多くて辞めた。

環境

バージョン: 1.33.1 (system setup)
コミット: 51b0b28134d51361cf996d2f0a1c698247aeabd8
日付: 2019-04-11T08:27:14.102Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

詳細

nodeはインストールした前提で始める。

Vue cliのインストール

とりあえず、公式にあるとおりにインストール。

npm install -g @vue/cli

グローバルに入れるのは、プロジェクト作成のツールであるため。
vue create my-project とすると、my-projectの中にnpmのプロジェクトができるので、自分で作ってローカルにインストールすると、二重にできてしまうから。

プロジェクト用意

先に書いてしまったが、下記のコマンドで用意

vue create my-project

結構、長い。。。
気長に待つ、

とりあえず実行

インストールが終わると、npm run serve で起動できるらしいので、作られたmy-project配下に移動して、コマンドを叩く。

 $ cd my-project
 $ npm run serve

serveって、serverのことかな？

http://localhost:8080/で起動したよ的なメッセージが出てきたので、ブラウザでアクセスしてみる。
そうすると、vueのサンプルページが見えるはず。

バインディング

App.vue と HelloWorld.vueの連携はわかったんだけど、index.htmlとApp.vueの連携がよく分からなかったので調べた。

紐付をしているのは、main.jsの下記の実装

new Vue({
  render: h => h(App),
}).$mount('#app')

appにApp.vueを設定している。

下記の記述と同価

new Vue({
  el: "#app",
  render: h => h(App),
})

render関数は、業が深そうなので、こうすると描画されるんだ程度で辞めとく。

感想

vueファイルとあるが、内部は、css/html/jsだから、素直に読めるのがいいと思った。
イベントハンドリングや文字列の埋め込みは、別の機会に。

Visual Studio Code で WSL

きっかけ

windows10で、dockerとかvirtual box入れなくてもlinux動かせるようになったが、visual studio上でやりたいと思ったので情報探したので、メモ書き

詳細

VisualStudioCode insidersを入れる

ちょっとタイトル詐欺があります。。。
現時点(2018/05/11)では、visual studio code(以下、vscode)では、ターミナルにWSLを指定できません。
visual studio code insiders(以下、vsinsiders) をインストールしてやる必要があります。
vsinsiders は、 vscodeの実験的な意味合いでビルドされたもので、普通に使う分には、vscodeと大差はないと思う。(たぶん。。。)

Download Visual Studio Code Insiders

自分の実行環境は、下記の通りだった。

バージョン: 1.34.20-insider (user setup)
コミット: 57b550c559b945eb9d871dbf2b2e4cb9e31e2551
日付: 2019-05-10T17:36:45.765Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

WSL有効化

自分は、これする前にしてしまったので、下記のサイトを参考に設定を変えてください。

Windows10でWSLとVSCodeを使ってC++環境を整える - Qiita

忘れずに、update／upgradeをやってね。

拡張機能

Remote WSL ってやつを入れる。

設定の変更

公式にあった設定を、そのまま適用

Integrated Terminal in Visual Studio Code

{
    "terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe"
}

ここまでできたらターミナルを開くと、wslに接続されるはず。

感想

まだ使い込んでいないので、なんとも言えないが、linuxの学習環境構築としては、とてもいい気がする。
vscodeは、markdown補助の拡張機能もあるし、メモ取りながらコマンドをバシバシ打っていけるがいいと思う。
linuxのコマンドやviとかをwindows上で使える恩恵が、ものすごいと思う。
試しにvi操作でwidnwso上のファイルを編集したけど、widows上で他のエディタで見ても編集できてる。
これからは、linuxの恩恵がwindows上で得られるのは、画期的に感じる。
ちょっと前までは、cygwinとかがそうだったけど、ちょっとクセがあるから使いづらい印象。

雑記

最近、ジョジョの奇妙な冒険 黄金の風のOPの裏切りのレクイエムを、食い入るように聞いてる。
今回も、準備しながら聞いてた。
なんか、中毒性が高い。

参考サイト

VSCodeのInsiderの拡張、Remote WSLを使ってみたよ - 味噌汁を飲みます

Windows10でWSLとVSCodeを使ってC++環境を整える - Qiita

【読書ノート】ドラッカーさんに教わったＩＴ技術者のための５０の考える力

きっかけ

セール品の中で、たまたま目に止まった。
最近、思うんだけど、平時から技術者としてどうあるべきか考えを持ってないと、優秀には成れないと思い始めてきた。

まとめも

基礎的な考え方を身につける

成長のための考え方

• 時間管理
• 貢献の仕方を考える
• 強みを伸ばす
• 重要なことを集中的に行う
• 効果的な意思決定

上記の全ては、実践の中で磨かれる。磨かなければならない。

メモ：つまり、奴隷的な考えはアカンよってことかな？考えて作業してないと、成長はありえないってことだろう。

知識労働者であることを自覚する

ＩＴエンジニア＝知識労働者
幅広い知識を利用し、考えて作業を行うべき存在。
仕事を単純労働にするのは、己自信。考えて働くことを辞めたら、それは知識労働者ではない。

考えることを辞める阻害要因

• 手順書・マニュアルが整備されてしまっている
• ネット上の情報を安易にコピペ

メモ：でもさ、とりあえずやることって重要じゃない？そこから考えるネタが見えてくることもあると思う。やってみて、考えとは違う結果に成れば、それはそれで、いいことだと思うんだよね。闇雲にとりあえずやるはダメだとは思うけど。。。考えても埒が明かないとか、考えられることは考えたなら、とりあえずやるは、有効だと思う。

考えることが仕事

考えることは、強制されることは少ない。
だからこそ、考える力を伸ばさなければならない。

考えて仕事しているかのチェックリスト

1. 手順を追うだけの仕事をしてないか？
2. 工夫することはないか考えているか？
3. 単純コピペしてないか？
4. 誰かの奴隷になってないか？

メモ：俺風の言葉に直した。特に、「奴隷になってないか？」は、自分でも自画自賛したいくらい秀逸な文言だと思う。

成長の責任を負う

研修制度がある≠成長できる
成長の責任は、自分で負うべき。

メモ：素晴らしい言葉だ。だいたいの人は、成長を他責にしようと思っている感がある。配下メンバーと話すと、そう思うことが多い。なぜ自分の責任で学習しようとしないのか、ものすごく疑問に感じる。逃げの一手であるような気がしてならない。かと言って、叱責したところで状況は変わらないと思うんだよね。だから、話すたびに相手に考えさせることをしないと思う。

能力向上の２つの方法

• 改善
• やり方を変える

メモ：日本は、改善が得意だけど、やり方を変えるは下手。両立ってできないものなの？

改善とイノベーションの両立

改善は常に行う。その先に、イノベーションがある。
上手くいっているときに、新たな取り組みを行うことが必要。

自分の成長に責任を持ったら、いまの自分が上手くいっているのが見つめ、改善と新たな取り組みの２つの目標を立てる。

自分の軸を考える

改善とイノベーション = 外なる成長 誇りと自身をつける = 内なる成長

よりよく行うことを目指す

コントロール不可な現実

• 時間が他人に取られる
  • 抵抗するのは不可能
  • 時間の使い方が大切になる
• 定常業務に追われる
  • 重要なことができなくなる
  • いたずらに知識と能力を浪費してしまう
• 組織にいる
  • 自分一人が頑張っても成果にならないことがある
  • チームで成果を出すつもりでないと、己の成果もあげられない
  • 外部に与える影響が見えない場合、成果が上がっているのかも分かりづらい。

上記の阻害要因があるので、意識して努力しない限り、成果をあげられない。
流されて仕事をすることをやめ、一流を目指して仕事をしなければならない。

学び方を工夫する

学び方は、千差万別。学校や塾で教わった学び方が、自分にあっていない場合もある。
自分が得意な学び方で学ぶことを心がける。

時間をマネジメントする

新しいことを学ぶ前にすべきこと

1. 時間配分を知る
2. 効率が悪いものを見つける
3. 時間をまとめて、大きな自由時間を作る

時間を記録する

成果をあげるためには、まず時間配分を記録することが必須。
後々、どこで時間を使っていたのか、分からなくなる。

記録した時間をもとに、辞めるものを検討する。
もしくは、時短の方法を考える。

フィードバック分析

フィードバック分析を行うことで、下記の効果が得られる。

1. 強みの強化
2. 傲慢を正せる
3. 成果の妨げが何か知ることができる
4. 人への接し方の改善
5. できないことをしない
6. 無駄な努力の削減

その日の目標を作る

客観的に分析するには、何かに対して、できたこと／できなかったことを知る必要がある。
目標があることで、分析が容易化する。
どう改善していくかときめること＝フィードバック分析

上手くできたことは覚えていない

失敗は覚えているが、上手くできたことは覚えにくい。
上手くできたことに対して、喜びが感じられていないためかもしれない。
フィードバック分析の一番の目的は、強みを見つけて活かすこと。
失敗を覚えることも重要だが、同じくらい、上手くいったことを覚えることも重要。

目標があると分析がしやすい

目標を決める＝それに向けて行動する＝成功率が上がる。
成果として見えるので、上手くいったことを忘れずに済む。

原因を３つ考える

振り返り＝必ず記憶を取る。
記憶があることで、学習効果が高まる。

振り返りのポイント

なるべく３つ原因と要因を考える。
１つだけだと、短絡的思考になり、次に繋がらない。

深く考える

成果があがる／あがらないの差は、才能ではなく、習慣的な取り組む姿勢と基礎的な方法を身につけているかどうか。
取り組み方は、人によって千差万別。

メモ：トヨタのなぜなぜ分析は、使い方を間違えやすいとは、長年思ってた。方向性を見失っていると、意味ない方向に飛ぶから、ある程度、議論の方向性が見える人が必要だとは思う。

ロジカル問題解決のフレームワーク

Where／Why／Howの観点で、振り返りをする。

感情を区別する

記憶＝感情も残る。
フィードバック分析を行うためには、論理的に行う必要があり、事実の記憶が必要。

感情と理論

感情的に考えるのは、人間の特性。
論理的に考えるには、感情的に考えることを受け入れること。
感情を持つことは、人として当たり前なので、それ込みで分析する。

感情ではなく行動に注目する

重要なのは、その感情になった結果、何をしたのか？
それを振り返ることで、次回から対策を考えられるようになる。

判断力を高める

意思決定をする = 知的労働者にとって成果をあげるために必要な能力

判断のプロセス

1. 問題の種類を知る
2. 条件の明確化
3. 是非
4. 行動

問題の種類

• 経験則で解決可能な問題
• 一般的問題
• 新種の問題
• 例外的で特殊な問題

いつもと同じでいいかを考える

• 同じように行えるようことは、手順化・ツール化して省力化
• いつもと違うところをみつけ、それの解決に集中する

人のやり方を真似る

分かった気になる＝失敗に繋がりやすい。
判断を下す前に、十分な情報を入手して、実際に試してみてから判断したほうが良い。

意識して判断する

調査しながら判断＝目的がすり替わる可能性が高い。
推測のまま進めなければならない箇所が出てくるため。
それが積み重なった結果、大問題になる。

ミッションを元に判断する

自分のミスを疑う

本当に例外的な問題は、稀。
実は、操作ミスなど、多角的に見ると、たいしたことない問題であることもある。
例外的な問題と判断する前に、よく調べてから問い直す。

メモ：作ったのを動確してると、だいたいは、己のミスであることが多い。

コミュニケーションを工夫する

メモ：コミュニケーションって言葉、もう辞めませんか？何いってもコミュニケーションで済ませるから、このワードを見ると腹が立ってしょうがないんだよね。

聞くことからスタートする

信頼関係を作る

人→聞くより話す方が好き。
話しやすい環境を作ることが、信頼構築の第一歩

期待を知る

相手の期待を知る＝有利に物事を進めることができる

用意してからアウトプットする

インプットからスタートしない

アウトプットが想像できない場合、インプットした情報・知識から作り始めるため、体系的な説明ができにくい。
アウトプットを決めていると、何をすべきかが明確になるため、必要な情報を集中して集めることができる。

短い文で伝える

受け手の言葉を使う

受け手が分からない専門用語を使う＝野卑
相手が理解できるような言葉を使って会話する必要がある。

メモ：でもさ、相手が分かるかどうかって、相手からの反応がないと分からなくない？逆に、受け手が分からない前提で離したら、愚弄されてると受け手が感じることもあると思う。

短い文で伝える

メモ：短すぎるのも問題と思うが。箇条書きの羅列で前後関係が破綻すると最悪。意味のまとまった単位で最小の文を作るが、正解だと思う。

結論から伝える

話が長い＝受け手にストレスがかかる

言いにくいことでも、端的に述べる。
言いにくいことは、何かしらの背景がある。
それを明確にしたほうがいい。

感情を伝える

仕事＝感情抜きでもできる。信頼に対して敬意があれば、仕事は成立する。信頼関係構築のために、相互理解を計るべき。
感情を無くせというわけではない。
感情が存在するのは、人である証拠。
抑え込もうとするのは、逆効果で、受け入れる方が、楽になる。

周囲の評価は、感情では決まらない。
行動に対して、評価が決まる。

感情と事実と考えを分ける

事実と考えは違う。
妄想が報告された結果、最終的に大事になる。
伝えるときは、それが事実なのか、考えなのか、感情なのか、受け手にとってわかりやすいように話す。

上司をマネジメントする

上司＝成約ではなく利用できるもの
部下の役割は、上司に成果を出させてあげること。

部下・上司、お互いをよく知ることで、仕事は成功しやすくなる。

成果を上げる思考力

判断しているかを見つめる

先延ばししてしまった場合、その判断理由が何かを明確にする。
反射的にやっている場合、先延ばしがなくなることはない。
理性的に判断する習性をつける。

感情を記録し、受け入れる

今さら自分は変えられない。
それを受け入れ、解消するための行動を起こす必要がある。

何も決定しない選択は、選択としてはあり。
ただし、行動を起こさない結果、自体が悪化するのなら、行動しなければならない。

やらないことを決める

先延ばしは、重要ではないことに時間を使っていることが大半。
だから、やらないことを決める。
必要なことで辞めることができない場合は、作業を他人へ移譲することも考える。

やりたい気持ちを大きくする

仕事に意味を加え、貢献方法を明確にする。
最終的に後回しを回避することにつながる。

仕事の種類を知る

• 成果が質を意味する仕事
• 質と量の療法を成果とする仕事
• 質が前提で、成果の殆どが量で定義される仕事

やる種類によって、注意すべきポイントは変わる。
どの種別の仕事をやっているのか意識し、仕事をやることで成果を上げることができる。

リスクを考える

リスクがない仕事はない。
リスクを予め想定して段取りをするべき。

リスクを発見したら、できるだけ早い時期に最小化するための対策を行う。

仕事が終わったあとでも、リスクの検討について振り返りをする。
どのようなリスクがあるのか考えることは、次に活かせる。

ネガティブになっていることに気づく

ネガティブな状態になったときに行う考え方

• 無視する／否定する
• 「自分の仕事ではない」と考える
• 責任の押し付けあい
• 混乱／判断を仰ぎ、責任転嫁
• 言い逃れ
• 様子見

メモ：漫画で出てくる敵役がやりそうなことだな。。。

被害者意識に陥ると、なりやすい。
さらに、被害者意識は悪循環を呼び、抜け出せなくなる。

メモ：でもさ、原因分析って、大抵の場合、悪者探しになるじゃん。

貢献と目標を意識する

貢献を意識すると、主語が組織やチームになる。

メモ：貢献は、ようするに圧倒的な当事者意識がありますか？ってことだろう。言霊主義の日本では、有効かもね。

目標を意識すると、チャレンジの考えが芽生える。
ただし、高すぎても、低すぎてもダメ。

メモ：俺は、会社の目標には従わない。自分の中で目標はすでにあるので、会社には、聞こえがいいように自分の目標を伝えて、経営方針のことをいかにも考えているような感じで伝える。

ルールを変える

ネガティブになるきっかけ

• 誰かの感情に引っ張られた
• 叱責／非難
• 正義感に引っかかる

ネガティブな感情は、伝染する。
社会的な機能として備わっている。

メモ：他人の幸福を見ると、壊したくなるんだが、これも、人の社会的な機能ですかね？ メモ：おかしいな。俺は負の権化なはずなんだが、職場がネガティブになってくれない。

普段から、不平不満を撒き散らしている人やグループといると、感情も引っ張られる。
グループがそうなりそうな場合は、距離をとるなどを考えてみる。

メモ：な、なるほど。不平不満を言う相手がいないから、職場がネガティブにならないのか。。。

ルールを変える

ネガティブな反応はなくせないので、反応を制御する。
ネガティブな反応がでそうなときは、意識の切り替えを考える。

信念を見直す

信念は、誰でも持っている。
ただ、信念が元になってネガティブな感情になることもある。
その場合は、信念を少し変えてみる。

自分を伸ばす思考力

自分の強みを発見する

強みを知る方法＝フィードバック分析しかない

強みが活きる行動をリストアップする

強み＝成果を生み出すもの
強みを活かせるところを見つけることで、より評価が高くなる。

強みを活かせる関係を築く

人的ネットワーク＝強みを活かせる場を提供してもらえる機会がある。
知的傲慢は、人的ネットワークで得られたチャンスを失う可能性があるので、言動には注意が必要。

自分の持っている知識、自分の行動を見つめる

人に教える＝知識や技術をより明確に理解している必要がある。

人に教えることができるようになるためには、下記を行う必要がある。

• 知識の整理
• 知識の不足点を補う
• 知識の体系立て
• 自己の行動が、どのような根拠や目的に即してやっているか明確にする

知識を伝える

伝えるには、価値観、欲求、目的に合致していると理解が進む。

メモ：講義を聞いたりするけど、ダメな講義は欲求が満たされない気がする。講義は選んで受けるので、目的や価値観には大幅なズレはないかな？

知識を伝えるのは、限界がある。
何かの知識と複合して自分の知識になるケースもある。
だから、伝えるべきは、効率的に学べるように伝える。

行動を教える

知識だけ、手順だけを教えていては、理解は深まらない。
技術は、知識と能力を複合することで発揮される。
伝える際は、具体的な行動と判断基準もセットで教える。

補助輪付きで走らせる

最初から、教えたことが実践できるとは限らない。
成果を出せるように働きかける必要がある。

教えたことを効率的に身につけるためには、フィードバック分析を支援してあげる必要がある。

補助輪を外す

いつまでも補助輪をつけるのは、成長に繋がらない。
どこかの時点で、責任を持たせる。

自分で判断する

自ら判断しない＝責任を持たず、できるかどうかを深く考えていない。失敗しても他責にしようとする。
自ら判断＝責任を持って、成功するためにどうしたらいいかを考える

目標達成のプロセスを考える

理想の状態と評価基準を考える。
プロセスを考えるためには、必要。

自己目標管理のために、以下の基準に気をつける

• 具体性
• 測定可能
• 達成可能
• 重要性
• 達成期間

具体的な計画に落とし込む

目標を設定したら、まず、現状とのギャップを分析する。
その後、ギャップを埋めるための行動を決める。
行動を定期的に測定し、チェックする。

コーチングの進め方

1. 話をする環境を作る
2. 目標を決める
3. 行動を決める
4. 目標達成の基準を明確にする
5. 定期的に測定する

感想

さすがに、５０は、最後まで読むのがダルくなる。。。

ドラッカーさんの言うことには、概ね同意何だが、現場が複雑化しすぎて適用できない気がするんだよね。。。
適用するにしても、人が人間的に優れていないとダメなんじゃないかとも思う。
ＩＴの現場って、ゴミみたいな人間が多いから。。。

読んでて思ったけど、たまにツイッターで流れてくるいい話的なやつって、ドラッカーさんの言うことを親子を例にして説明しているだけな気がしてきた。

Mahoutでレコメンドを試し実装

きっかけ

Spartの動きがなんとなく分かったので、次の機械学習へ。

環境

IntelliJ IDEA 2019.1 (Community Edition)
Build #IC-191.6183.87, built on March 27, 2019
JRE: 11.0.2+9-b159.30 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

intellijって、開発環境を簡単に出せるのか。。。
知らなかった。
メニューバーの Help → About で表示できる。

いっつも、コマンド打って転記してたけど、今度からこれでやったほうが早いな。

実験

build.graldeと実行ソース、データセットを晒しておけば十分かな？

build.gradle

plugins {
    id 'java'
}

group 'rssCollector'
version '1.0-SNAPSHOT'

sourceCompatibility = 11

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    // https://mvnrepository.com/artifact/org.apache.mahout/mahout-core
    compile group: 'org.apache.mahout', name: 'mahout-core', version: '0.9'

}

data.csv

1,1243,3.3
1,1240,0.3
1,1242,1.2
2,1242,1.3
2,1243,1.9
2,1241,2.8
2,1245,4.3
3,1240,0.6
3,1242,1.0
3,1241,2.3
3,1245,3.0

sample

本当は、先頭大文字にすべきだけど、多めにみて。。。

import org.apache.mahout.cf.taste.common.TasteException;
import org.apache.mahout.cf.taste.impl.model.file.FileDataModel;
import org.apache.mahout.cf.taste.impl.neighborhood.NearestNUserNeighborhood;
import org.apache.mahout.cf.taste.impl.recommender.GenericUserBasedRecommender;
import org.apache.mahout.cf.taste.impl.similarity.PearsonCorrelationSimilarity;
import org.apache.mahout.cf.taste.model.DataModel;
import org.apache.mahout.cf.taste.neighborhood.UserNeighborhood;
import org.apache.mahout.cf.taste.recommender.RecommendedItem;
import org.apache.mahout.cf.taste.recommender.Recommender;
import org.apache.mahout.cf.taste.similarity.UserSimilarity;

import java.io.File;
import java.io.IOException;
import java.net.URISyntaxException;
import java.net.URL;
import java.util.List;

public class sample {
    public static void main(String[] args) throws IOException, TasteException, URISyntaxException {


        URL url = ClassLoader.getSystemResource("data.csv");
        DataModel model = new FileDataModel(new File(url.toURI()));

        UserSimilarity similarity = new PearsonCorrelationSimilarity(model);

        UserNeighborhood neighborhood = new NearestNUserNeighborhood(2, similarity, model);
        Recommender recommender = new GenericUserBasedRecommender(model, neighborhood, similarity);

        // ユーザID：1の人に３件レコメンド
        List<RecommendedItem> recommendations = recommender.recommend(1, 3);

        recommendations.forEach(System.out::println);
    }
}

実行

実行すると、下記みたいなのがでるはず。

RecommendedItem[item:1245, value:3.65]
RecommendedItem[item:1241, value:2.55]

3件指定したけど、２件しか出てこないのは、データが少なすぎるせいらしい。

感想

sparkなくても、レコメンドとかできるのか。。。。
すごく楽にレコメンドとか実装できてしまって、hadoopの実行環境作るのに悩んでいたのは何だったんだと思いたくなる。

他のサイト見ていたけど、 UserSimilarity similarity = new PearsonCorrelationSimilarity(model); のところで、 PearsonCorrelationSimilarity 以外のアルゴリズムを適用させて、いろいろ分析方法を返るみたい。
当然、後続で利用するクラスも変わるわけだが。。。
利用するアルゴリズムは、統計学の知識がないと、よく分からなかった。
体系的に統計学を学ばないと、ググって調べた程度の知識量では、汎用的に使うのが難しそう。。。

あと、調べてると、やたらとscalaが出てくる。
時期的に見ると、Java8リリース前だから、JVM言語が出始めてきた頃だな。
Java8リリース前は、JVM言語の方が盛り上がってた印象がある。
Scalaは、なんとなく読めるけど、やっぱり、違和感はある。

そういえば、機械学習とかするときって、前処理が大変とよく聞くが、アルゴリズムを適用させるために、決まったデータフォーマットにするために大変ってことだろうか？

課題

• 統計学を学んで見る

参考サイト

Mahoutでレコメンドを作ってみよう！ | Atlas Developers Blog

mahout をとりあえず動かしてレコメンドしてみる（動作確認程度） - Qiita

低スペックな頭の僕がJavaの機械学習ライブラリmahoutを動かしてみる。 - regtan’s TechNote

Spark試し実装

きっかけ

本当は、hadoop使ってビックデータ処理がどんなものか探る予定だったけど、環境構築で挫折。。。
あまりにも面倒だったので、sparkでアプローチしてみようと思い、記事を書くに至る。

環境準備

macで実験。
Homebrewをインストールした前提で話をする。

OS

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.4
BuildVersion:   18E226

Homebrew

$ brew -v
Homebrew 2.1.1
Homebrew/homebrew-core (git revision 858af; last commit 2019-05-01)
Homebrew/homebrew-cask (git revision 606f3; last commit 2019-04-30)

インストール

$ brew install apache-spark
$ brew install scala
$ brew install sbt

Sparkの設定

export Spark_HOME=Spark_HOME-/usr/local/Celler/apache-spark/x.y.z

x.y.zはインストールしたバージョンを指定。
自分は、2.12.8だった。

$scala -version
Scala code runner version 2.12.8 -- Copyright 2002-2018, LAMP/EPFL and Lightbend, Inc.

実験

参考サイトを参考に、環境を生成。
ディレクトリ構造を間違えて、かなり迷った。。。

ディレクトリ構成

WordCount/
  build.sbt(ビルド方法を定義するsbtファイル)
  input.txt(ワードカウントする対象の入力ファイル)
  project/ (sbtの追加設定を入れるファイル)
    assembly.sbt
  src/
    main/
      scala/
        jp/
          excite/
            news/
              WordCountApp.scala

build.sbt

name := "WordCountApp"
version := "1.0.0"
scalaVersion := "2.11.8"
resolvers += "Atilika Open Source repository" at "http://www.atilika.org/nexus/content/repositories/atilika"
libraryDependencies += "org.apache.spark" %% "spark-core" % "2.1.0"
libraryDependencies += "org.atilika.kuromoji" % "kuromoji" % "0.7.7"
assemblyMergeStrategy in assembly := {
  case PathList("javax", "servlet", xs @ _*)         => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".properties" => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".xml" => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".types" => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".class" => MergeStrategy.first
  case "application.conf"                            => MergeStrategy.concat
  case "unwanted.txt"                                => MergeStrategy.discard
  case x =>
    val oldStrategy = (assemblyMergeStrategy in assembly).value
    oldStrategy(x)
}
mainClass in assembly := Some("WordCountApp")

assembly.sbt

resolvers += Resolver.url("artifactory", url("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.6")

WordCountApp.scala

package jp.excite.news

import java.util.regex.{Matcher, Pattern}
import scala.collection.convert.WrapAsScala._
import org.apache.spark.SparkConf
import org.apache.spark.SparkContext._
import org.apache.spark.SparkContext
import org.atilika.kuromoji.Tokenizer
import org.atilika.kuromoji.Token
 
object WordCountApp{
def main(args: Array[String]) {
    //スパークの環境設定
    val sparkConf = new SparkConf().setMaster("local[4]").setAppName("WordCount App")
    val sc = new SparkContext(sparkConf)
    //kuromojiのトークナイザ
    val tokenizer = Tokenizer.builder.mode(Tokenizer.Mode.NORMAL).build()
    //テキストファイルから1行ずつ読み込み。名詞を配列に分解する。
    //テキストファイルからRDDオブジェクトを取得する。
        val input = sc.textFile("input.txt").flatMap(line => {
        val tokens : java.util.List[Token] = Tokenizer.builder().build().tokenize(line)
        val output : scala.collection.mutable.ArrayBuffer[String] = new collection.mutable.ArrayBuffer[String]()
        tokens.foreach(token => {
            if(token.getAllFeatures().indexOf("名詞") != -1) {
            output += token.getSurfaceForm()
        }})
        output// return
    })
    //ワードカウントを行う。数える名詞をキーにし、キーを元に加算処理を行う。
    val wordCounts = input.map(x => (x, 1L)).reduceByKey((x, y)=> x + y)
    val output = wordCounts.map( x => (x._2, x._1)).sortByKey(false).saveAsTextFile("output")
    }
}

参考サイトだと、wordCountsが重複して定義してあったので、削除したのを上記にのっけた。

実行方法

sbt run

実行すると、WordCount/output に出力される。
part-0000xに出力される。

感想

hadoopでいろいろやろうとしたが、環境準備でダメだった。。。
その点、sparkは簡単に試せた。

scalaの構文は全然知らなかったけど、kuromojiは、知っていた。
何となくでも読めた。
ただ、sbtのscalaのビルドがどうなっているのかで、ちょっとハマったけど。
問題は、spark使うメリットが良くわからなかったことかな。。。
もうちょい、深く使ってみないと、わからないかもしれない。
もしかして、StreamAPIが入ったことで、並列処理がStreamAPIでもできるから、Javaでメリット薄いように感じるのだろうか？

ハマったこと

ディレクトリ構造を読みまちがて、java.lang.RuntimeException: No main class detected が出てしまったこと。
最初、WordCountApp.scalaを、src/jp/excite/news/WordCountApp.scala に配置してしまって、scalaのソースとして参照されていなかった。
src/scala/jp/excite/news/WordCountApp.scala が正解。パッケージ名にscalaなんて入ってこないから、相当悩んだ。。。
scalaのディレクトリ構造は、srcの下にscalaがあるのが正解だって気づくまで、かなり悩んでしまった。
これは、Javaとscalaを共存させるために、こうなっているのだろうか？

これからの課題

• SparkとStreamAPIを比較してみる
• Scalaを学んでみる
• sbtを調べてみる

参考サイト

「Apache Spark」×「Scala」で分散処理入門 : エキサイト公式 エンジニアブログ