面白そうな要約サイト

 

転職の思考法でbeing型とtodo型ってあったな~。

どんな内容だっけ?

本の内容まんまはでないだろうけど、要約しているブログとかあるかもな~

と思ってネットで検索してら出てきた。

 


自分を変える思考法

https://dofra.info/

 

 

 

最初はフムフムって読んでたけど、内容が要約ってよりはほぼまんまでは?

って思える感じ。

 

 

 

ある意味ありがたいけど、いいのだろうか?

 

 

 

ほかの記事を見るとメモの魔力っぽいのもあるし。

でも全体的に構成とかレイアウトがとても読みやすい。

 


更新頻度もそこそこ高いし、はやりのビジネス書籍の内容のチェックはこのサイトでいいのでは?

 


なんて思ってしまった。

 


次はmotoさんの本からまとめそうだな。

記事に対して出典をひたすらまとめるのも楽しそう

 

副業の記事

http://blog.howtelevision.co.jp/entry/2019/08/20/141417

 


エンジニアリングマネージャーやるにあたり別の会社で副業始めたらめちゃくちゃ良かったぞ、という話

 


トピック

 

 

 

エンジニアメンバーの給料を上げるためには

開発チームが事業インパクトの高い開発をして成果を出す
成果の出る開発をスピーディーに進められる開発チームを作る
個々人の技術スタックが増え、技術レベルが上がる
などが必要で、これらを実現することで最終的に事業成長に貢献できると考えています。

 


言語化

自分が関わることでこれが成果として見れるとこがいいよな

 


僕は転職するつもりが無くても面白そうな会社からメッセージを貰ったらカジュアル面談しに行くことがあります。

 


コミュ力高い!

 


副業に有用なスキルとは?

Goで書かれたWebアプリ開発のお手伝いをしています。

言語のスキルかーーーー!!

あとは、開発スキルだな

サービスを作るための設計スキルとか

インフラのスキルとか

 

SIでのソフトウェア開発経験、知識を副業にどう使おう

OSSには夢がある

誰かに雇ってもらうとか、買ってもらうなんてのを目的にしたら続かないんだろうけど。

 

やることで、土壌を耕すことにはなるんだろうな。

 

http://knqyf263.hatenablog.com/entry/2019/08/20/120713

 

https://www.google.co.jp/amp/s/employment.en-japan.com/engineerhub/entry/2019/01/25/103000%3famp=1

 

https://togetter.com/li/1148850

 

 

アウトプットを意識したインプットをする

メモるべきはインプットではなくアウトプット - Chikirinの日記

https://chikirin.hatenablog.com/entry/2019/08/18/メモるべきはインプットではなくアウトプット

 

 

トピック


「取材や講演など、誰かの話を聞いている時に、相手の言ったこと=インプットではなく、それを聞いて自分が考えたこと=アウトプットを、その場でメモる」

 


→メモの魔力と似てる

   アウトプット=自分で考えた事

    ってのは新たな概念だ。

 


どちかと言えば、その考えるキッカケとなった発言をメモっていた。

その理由は??忘れたくないから、

正しく覚えておかないと失礼だから?

なんとなく?

 


でも、考えてみたら。

アウトプットを主体にするなら、

インプットの正確性よりもアウトプットを出すための時間や出すことへ注力した方がいいよな。

 


インプットを大事に取っておいて、

自分の考えた事を忘れてしまったら本末転倒。

 


というかコレはアウトプットに対しての自信の無さの表れかもしれん。

 

 

 

 

 

 

「新しいインプットを入れれば、何か今までは考えたことがなかったような新しいことが考えられるんじゃないか。ワクワク!」と思うから本を読むわけで。

 


そしてその考えのアウトプットの1つがブログって事か。

 

 

 

スピードも大事だし、事前に自分の疑問や考えを整理しておくのも大事だと思ってる。

 


この事前にってとこで別の人がツイートしてくれてる、以下がわかりやすい。

 


https://twitter.com/sota_en_nikki/status/1162609733192126465?s=21

 

 

 

まんまだけど、スピードを速めるために

- 思考の棚を整理しておく

- 意思決定プロセスを明確しておく

- 頭の中にブランク資料を持っておく

というのは、自分も取り入れよう。

 


そして、単純な感想だけど。

この記事ってツイートを繋ぎ合わせてまとめたものなんだよな。

そうやってこまめにツイートしてあとで

まとめるってのも自分の考えを出す、

その生産性を上げる事に必要なんだな。

 


自分のアウトプット=考えた事

この概念を忘れてた。

 


自分で考えるってのをやれてなかったな。

 


コレもアウトプットだよね??

マネとは相手をリスペクトすること


「“マネ”とは、相手をリスペクトすること」25歳で年商20億円、塚本大地を変えたマネの極意

https://r25.jp/article/703817028470505927

 

 

 

トピック

小さな真似の積み重ねや組み合わせにほんの少しのオリジナリティを

加えることでサービスはできるんです。

 


まずはなにをどうやってマネをするのかを考えることこそが

オリジナリティの第一歩

 


→アイディアの出し方でも言ってたけど、既存の組み合わせで新しい物が出来る。

 ってことか。

 

 まずは、何の問題を解決したいか?なんのためのアイディアを考えたいか?

 を決めないとな

 

 

 

どんな相手でもまずはリスペクトして自分のなかに考えをインプットする。

 


特に自分と違う価値観に触れることは大事

「この人は合わない」と感じたとしても、その裏にあることを想像して

リスペクトできる部分を探すんです。

 


受け入れた価値観た意見・言動をマネの在庫としてとっておく

 


→マネの在庫とは面白い発想だな。

 人と話す=その人をリスペクトしてそこから真似ることを見つける

 そのスタンスだと人と接するのが楽しそうなので、真似る

 


 仕事していると、人から話かけられる=仕事を振られる(本来その人がやるべきことを肩代わりさせられる)

 って感じていたのでこれを改めよう。

 


インプット量を増やすためには、触れるものの絶対値を増やすか一度の吸収率をあげるしかない。

 


→この発想も面白い確かに、数をこなすか質を上げるかしかないよな

 

 

 

話の締めは、「リスペクトして共感ポイントを見つけられるかという姿勢」で人と接する

とのこと。

確かに、なんかむかつく人でもその言動や行動にはその人なりの

行動原理があるはずで、そこに学ぶべき点(自分にない視点)ってのがあるのだと思う。

 

 

 

及川卓也氏のインタビューを見て思う


ソフト開発で世界と闘った及川卓也氏が見た、日本の弱点と可能性

https://headlines.yahoo.co.jp/article?a=20190801-00010000-chuokou-bus_all

 


トピック

ハードからソフトへ変化の主体は産業のサービス化

 


サービスを提供するのに適した方法でアジャイルを提唱している。

 

アジャイル:小さなサイクルを高速で回す。

正解がわからない世界におかる開発は仮説を立ててそれを検証する作業を何度も繰り返す。

 


→みずほでもアジャイルしたって記事がどこかにあったよな。

小さなサイクルって元々大きな物を作るつもりだったのを減らす必要があると思う。

そこを意思決定出来る人がいるのだろうか?

 

 

 

自分の開発に当てはめると・・・・・。

SI二次受けなので、そもそも作る物の大きさを決める立場にいない。

仮にいたとすると、小ささボリュームを定義できるか?

やろうと思えばできそうだけど。

 


というか、新規で位置から構築ではないので、

やること=既存への改修と範囲が固定化される。

 


そこから、小さくするって機能を削ることになるよな。

 


ウォーターフォールからアジャイルにしました。

って世の中に出回っている例って

 


既存の大規模システムをアジャイル化ではなく

その周辺の1機能とか独立している部分をアジャイル化した話しかないような・・・・。

 

 

 

 


最近の戦いの座標軸はサイバーからリアルに

グーグル:自動運転

アマゾン:ホールブス・マーケットの買収

 


→自分のサイバー領域は制覇出来ただから、リアルによっているのか?

 

 

 

ソフトウエア開発は本来研究やナレッジワークなのです。

製造業は企画があって工場が設計図を基に大量に製造して販売に至る

工程をさかのぼることはない。

 


ソフトウェアはデジタルなので1つ作ればいい

ひとまずプログラムを書いてみて、ユーザーからの反応を踏まえて設計から1部見直すことがよくある。

 


→思ったのは、いま自分かやっているのはここで言えば工場を作る位置にいる

 企画はお客さんってことだな。

 いわゆるSIは同じような立ち位置なきがする。

 


 そこで思うのは、このユーザーからの反応ってを気にするレイヤと

 企画されたものを作るレイヤって別だよな。

 


 そして当然そこに求められる成果は別だよな、

 下請け工場売上は親の販売実績には直接的には影響しないって感じか。

 

 

 

アジャイル型の開発の本質

一度先に行ったものでもおかしいと思えば前に戻ってやり直すのが当たり前です。

ところが日本のプログラマは設計図に書かれたものをただ作るだけの存在になっている。

 


→ここでいうプログラマって単純にコードを書く人なのか?

 エンジニアも含めているのか?

 そして企業もアジャイルに慣れてないとただの手戻りだと思うきがするけど、

 そもそも。アジャイルウォーターフォールってトータルコストはどっちが高くなるんだろう?

 


 そしてアジャイルって期限って概念はあるのだろうか?

 小さくリリースするのはわかるけど、何回サイクルを繰り返すと完成になるのか?

 


グーグルにしろアマゾンにしろいかに多くの天才プログラマーを雇っているのか

人にこそ投資すべきとある。

 


→投資ってあるけど、たぶんこの投資って既存のデンソーの社員を教育するよりは、

 アジャイルに精通している人材を新たに雇いましょうって投資だと思われる。

 


 これよんで、さすがにだから自分は冷遇されたプログラマだ!!

 だから、時代が追いついて日の目を見るのでは???

 なんて解釈しないとは思うけど。

 


 旧世代的なウォーターフォール開発どっぷりなは自分はこのアジャイル出来ます。

 だから高待遇くれっていうにはどうすべきか考える必要があるな

 

 

 

まとめると

アジャイルについて知らないことが多いので、?が多すぎ!

でもこの辺の疑問は大事なきがするので、本でも読んでみよう。

そして、これからのエンジニア(プログラマ)として高いかねで雇われる人材になるには

どうしたらいいかな~~~?

そもそも市場ニーズの高いプログラマとはどんなスキルが要求されているのだろうか?

自分を特徴付けている強みを生かす(ビア強み診断テスト)

https://www.youtube.com/watch?v=ZxDPGrcFc8g
自分を好きになるための自己肯定感の科学

 

自分を特徴付けている強みを生かす(アピール)する
また、日常生活に生かす。

 

わたっただけで満足しない
それを新しいことにつかう日常的に使う。


ビア強み診断テストを受けた
https://xn--bckg8a9ab8bxc5fpjscf3i.com/shindan-test/via-is-shindan.html

 

1ユーモア
笑いやいたずらを好む。人に笑いをもたらす。明るい面を見る。
ジョークを考える(必ずしも口にしなくてよい)。ユーモアを強みとするあなたは、笑ったり、
いたずらしたりするのが好きな人です。あなたにとって人に笑いをもたらすのは大事なことです。
あなたはあらゆる場面で明るい面を見ようと努める人です。


2向学心
新しいスキルや知識体系を身につけることは、
独学でも正式な教育による場合でも明らかに好奇心の強みに関係しているが、好奇心の枠に留まらず、
既知の知識についても体系的に理解を深める傾向がある。
向学心を強みとするあなたは、授業でも、あるいは独学でも、新しいことを学ぶのが大好きです。
あなたは学校や博物館あるいは読書など、いつでもどこでも学ぶ機会を得るのが大好きな人です。


3公平さ
公平や正義という概念に従ってあらゆる人々を同様に扱う。
自身の個人的な感情が他者への評価をゆがめることを許さない。
皆に公平にチャンスを与える。公平さを強みとするあなたにとって、
あらゆる人々を公平に扱うことは揺るぎない信念の一つです。
あなたは自分の個人的な感情が他者への評価をゆがめることを許しません。
あなたは誰にでも公平にチャンスを与えます。


これを仕事と生活に応用するとどうなるんだろうな~。