読書「シンプルに考える」
元LINE CEOの森川亮さんの著書、「シンプルに考える」、この本を知ったのは書店で何気なく立ち読みしていたときでした。
そのとき最初の数ページをめくっただけでしたが、語られている内容がなんの抵抗もなく入ってきて、不思議と気になった一冊でした。
かなり時がたった最近、ふとしたきっかけでこの本を手に入れたので、また手に取ってみました。
すごい人が求めているのは、お金でも地位でもなく、他のすごい人と働くことだ。
あ、これだ、と思いました。
というのは、以前採用について疑問に思ったことがあって、このブログで書いたことがあったからです。
すごい人、というのは仕事の好きな人、と置き換えてもいいかもしれません。
LINEのような世界の最先端を走っている企業であれば、本当にすごい人がたくさん集まるかもしれませんが、普通の企業にいる人のほとんどは普通の人です。ですが、同じ普通の人でも、仕事に対する興味・熱意でその成長に大きく差が出ます。
こういうタイプの人は、話すとすぐにわかります。こういう人々は時に厳しいことを言ってくることもありますが、自分たちの仕事をよいものにする、という熱意からくるものだということがわかってしまうので、言われたほうも反発心がそれほど湧いてこないのです。
プロジェクトがうまくいかないのは、目的が「プロジェクトの成功」ではなくなっているだけ。
プロジェクトがうまくいっていないのに、その原因を取り除こうとしないのはおかしい、と著者は言っています。それはそうだ、と思うのですが、じゃあなぜそんなおかしなことが放置されているのでしょうか。
それは、原因が人にあるケース。実力不足、そのポジションに不適などの理由で、ボトルネックとなっている人を交代させることができていない、と本書では言っています。できないのは、その問題の人に対しての「情」が絡んでしまっているから。
本来ビジネスの場は仕事を成功させるか否かなシンプルな目的であるはずなのに、そこに人間関係、自分への甘えなどの要素を絡めて複雑にしてしまっているということです。これはおそらくほとんどの企業でいえることなのではないでしょうか。余剰人員をいとも簡単に解雇する、超外資気質の企業ですら、こういうことはあると聞いています。
読後に思いましたが、この本を気になったときにすぐ買っておけばよかった、ととても後悔するくらい、本当に突っかかりなく読める、シンプルな本質のみで書かれた内容でした。
いろいろなノウハウはあるかもしれませんが、まずはここに書かれていることをベースに、ぶつかった自分の問題と照らし合わせつつ、目の前のことに取り組んでいくのがいいのではないかなと思います。
映画「奇蹟がくれた数式」を観て
中田さんのYoutube大学でも紹介されていましたが、インドの天才数学者を基にした映画ということで、その天才ぶりがどのような雰囲気であったかを知りたくて視聴しました。
数式は、神が舌の上においてくれた
天才数学者ラマヌジャンがどのようにして数式を発見したのか、という時のセリフでした。ただ、これは和訳なので、実際何と言っていたのかが知りたくて、英語のWikiサイトなどを見ていたのですが、近いものはありませんでした。(映画の脚色で付け加えられた言葉なのかもしれません。)
舌、と言ってしまうと、何かしゃべり言葉の状態で思いつくのかな、と考えたのですが、きっと「Outputできる状態になった」ことを示しているのでしょう。Outputできる=意識的に描ける、ということは、Outputできない領域=意識的に描けない状態が存在するわけで、ラマヌジャン的にはそれが神の領域、だったのではないでしょうか。
前から見ようと思ってた、「奇跡がくれた数式」を観た。
— しげ@元プログラマ (@sigeo5) 2020年7月23日
インドの天才数学者ラマヌジャン、彼の頭の中を想像するに、無意識の部分で緻密な計算をし続けて、ある時ふっと公式が意識の方に現れるってタイプだったんだろうな。
閃きと同じ原理だけど、その過程を言語化=証明するのは難しいんだろうなぁ…
また、映画中にも出てきましたが、神に関する発言として、こちらは英文がありました。
"An equation for me has no meaning unless it expresses a thought of God."
”神の考えを表現するという他に私にとって方程式の意味はない。"
すべての正の整数は彼の友達
ラマヌジャンを招聘したイギリス人数学者ハーディの同僚で、同じく数学者のリトルウッドのセリフです。
"Every positive integer was one of Ramanujan's personal friends."
”すべての正の整数がラマヌジャンの個人的な友人の一人だった"
正の整数、とあったので、そうなのかな?と思って英文も見たところ、「positive integer」とあるので正しいみたいですね。
ここでどうして整数なんだろう、と思ったのですが、小数ってある意味終わりがないんですよね。いくらでも作れてしまう。0.4以上はある、でも0.5にちょっと足りない、なら0.45かな?とか。
こういうことを考えていたら、数字の性質とは、「量」ではなく「番号」なんだろうな、とふと感じました。例えば、リンゴが2個あって、1個目のリンゴと2個目のリンゴは全く同じものではないはずです。形も、重さも、味も、全く一緒ということはおそらくあり得ません。だけど、この2つは、1、2と数えられるわけです。1個目は300g、2個目は200gかもしれないのにです。
先ほどの小数はどちらかというと「量」を表したいがための数値で使われることが多いです。10.25g、2.3kmとか。なので、「量」だけでなく「番号」を表すことができる整数は、特殊な性質なんだろうな、と素人目に感じました。
もしラマヌジャンに聞くことができたら、当たり前だといわれるかもしれないですね。
ただ、個人的には、頭のいいインド人の方々は説明が大好きという印象なので、延々と教えてくれるかもしれません。
Powershell 関数(計算式)作成・削除
Powershellについて、どうしてWindowsを長いこと使ってきたのに知らなかったのだろうと自分にがっかりしたので、気軽に試せる内容をメモすることにしました。
PowerShell(パワーシェル)は、マイクロソフトが開発した拡張可能なコマンドラインインターフェイス (CLI) シェルおよびスクリプト言語である。
(wikipedia引用)
Windows7からWindows Powershellを標準搭載しているようなので、Windows7、10のユーザーは何もインストールせずに使用可能です。
使用環境:Windows10, Windows Powershell5.1
Powershell立ち上げ
Windows Powershellを選択し起動。
Powershellが起動しました。
関数(計算式)の登録
>Function 関数名 { 登録したい計算式 }
今回は、「2+3」をさせてみたいので、下記を打ち込みます。
これでsum1という関数に、「2+3」が登録されました。
関数呼び出し
>関数名
sum1と打つだけで、登録した関数の結果が得られます。今回は「5」が得られました。
さらに・・引数を与えた関数の場合
引数を与えて関数を作成する場合は、$args[0], $args[1]...という変数を使います。
>Function 関数名 { $args[0]...を変数として使った計算式 }
今回は、「引数1 * 引数2」という掛け算を「sum2」として登録してみます。
登録したら、sum2を実行してみます。
>関数名 引数1 引数2
今回は引数に5と8を与えてみます。
「40」が得られました。
関数の削除
いらなくなった関数は削除しておきます。
>Remove-Item Function:関数名
で削除できます。
登録済み関数の一覧
自分関数がちゃんと登録されているかどうかは、
>Get-ChildItem Function:関数名
で確認できます。関数を削除した場合も、ちゃんと削除されているか確認するのが良いと思います。
登録されている場合の表示
登録されていない場合の表示
注記:
公式ページでは、関数名は
動詞-プレフィックス+名詞 (例:Get-PrivData)
のようにつけることが推奨されていました。プレフィックス(上記例だと「priv」、privateの意味でつけてみました。)をつける目的は、ほかの関数との競合を避けるためだとのことです。
Windows Powershellは、もう一つのPowerShell Coreと合流して今年2020年に、「Powershell 7」となり、こちらが主流になっていくようです。
PowerShell 7はWindows Powershellと共存可能で、MacやLinuxでも使用可能とのことでした。下図OSシェアのようにAppleの追い上げはありますが、企業ではまだまだWindowsが主流なので、Powershell、注目してみたいと思います。
OSシェア(PC)
Source: StatCounter Global Stats - OS Market Share
sig-nai.hatenablog.com
sig-nai.hatenablog.com
読書「AIまるわかり」
最近AIに関する記事をたまに覗いているけれども、全体像を理解していないと思ったので、この本を手に取ってみた。
2017年の本だけれども、初心者で基礎知識も何もない自分にはちょうどよかったかもしれない。これまで誰かがネット上で触れていた興味深い話題もところどころ出てきた。
そもそも、これまでの機械学習とディープラーニングの違い、言葉はよく聞くが具体的にどう違うのだろうか。
これについて、おぼろげながらこの本で概要が理解できた。
これまでの機械学習は、あくまで人間が、インプット・アウトプットの例とともに、AIが判断するためのルールを与えていた。これをディープラーニングでは、大量のインプット・アウトプットの例を与えることで、AIのニューラルネットワークと言われる解析ロジックを適切に整え、これに基づいて判断させる。要するに、人間がディープラーニングを使うには、大量のインプットとアウトプットを与えるだけ。これまでの機械学習のように、ルールを人間が考えるよりもハードルは低く、コンピュータの性能が飛躍的に高くなった今では、処理にかかる時間も待てないほどではない。
ディープラーニングは、人間の脳の一部を再現したもの、というように感じる。
また、AIの様々な使用例があったが、聞いたことのない言葉は時々調べながら読み進めた。
これからも刻々と変わるAIのニュースに、アンテナを張って理解していく手助けになると思える一冊だった。
Python Jupyter lab
Jupyter Notebookの次はJupyter Labらしい。
雰囲気はJupyterNotebookと変わらないように見えますが、Jupyter Labはよりシンプルで見やすくなっている気がします。
入手方法については、Anacondaをインストールしたときに自動で入っていました。
起動方法は下記が簡単です。
ーAnaconda Navigatorから起動
ーAnaconda promptから起動
注)Windows環境の場合、コマンドプロンプトを使わず、Anaconda promptを使うのが無難。(私はコマンドプロンプトで起動できるように設定したら、次の日なぜか使えなくなってました・・・。Anacondaのインストール時にもコマンドプロンプトの設定は”NOT RECOMMENDED"とあります)
統計学超入門
同じ著者、高橋洋一さんの別の本を読みたいなと思っていたのですが、こちらがAmazon Prime Readingにあったので、さっそく読んでみました。
基本の偏差、分散
立方体のサイコロを30回振る場合
グラフ(ヒストグラム)に結果を表してみると、
- 横軸 = 階級値 = サイコロの目1,2,3,4,5,6
- 縦軸 = 度数 = 各目の出た回数1~10
となる。
この時、3の目が9回出たとすると
- 回数(度数)/全回数 = 相対度数 = 9/30
となる。
30回振ったときのサイコロの目の平均が、3.53だったとすると、
- 各階級値(各サイコロの目) ー 平均値 = 偏差
なので、階級値3での偏差は 3 ー 3.53 = -0.53となる。
この偏差のばらつき度合いを知るための「分散」は以下で求められる。
- 分散 = 1の目の(偏差2*相対度数) +2の目の (偏差2*相対度数) .../ 全回数 = (-2.532*相対度数)+ (-1.53)2*相対度数)+ .../30
ここで偏差の値が2乗されているのは、符号(-/+)をなくして絶対値で判断したいため。(平均値を基準としてどのくらい差があるかなので、-は不要。)
分散の値が大きいとばらつき大、また分散の値が小さいとばらつきが小、ということになる。
分散を√掛けすることにより、標準偏差を得ることができる。
- 標準偏差(standard deviation) = √分散
正規分布
正規分布とは、グラフにすると左右対称の山のような形になるが、傾向として
とあった。
正規分布をとったデータのグラフを見ると、山の中心が平均値となり、
となる。
二項分布
サイコロの目が1~6のどれが出るか、ではなく、「1が出るか、それ以外が出るか(成功か失敗か)」に着目する。(ベルヌーイ試行)
3回振った内の1回だけ1が出る確率を例にとると、
考えられるパターン数は、下記3つとなる。(成功:1の目が出た、失敗:1以外の目が出た)
- 1回目:成功 ⇒ 2回目:失敗 ⇒ 3回目:失敗
- 1回目:失敗 ⇒ 2回目:成功⇒ 3回目:失敗
- 1回目:失敗 ⇒ 2回目:失敗⇒ 3回目:成功
また、サイコロの目は全部で6つなので、
成功する確率:1/6
失敗する確率:5/6
となる。よって、3回振った内の1回だけ1が出る確率は、
- 1回目:1/6 ⇒ 2回目:5/6 ⇒ 3回目:5/6・・・このパターンが起きる確率は25/216
- 1回目:5/6 ⇒ 2回目:1/6 ⇒ 3回目:5/6・・・このパターンが起きる確率は25/216
- 1回目:5/6 ⇒ 2回目:5/6 ⇒ 3回目:1/6・・・このパターンが起きる確率は25/216
を合わせた、75/216となる。
これにより、成功確率=p、失敗確率=1-pとし、n回振ったとすると、
- k回成功する確率 = (n回中k回成功した場合のパターン数)*pk*(1-p)(n-k)
=nCk*pk*(1-p)(n-k)
という式となる。
また、2項分布での平均値、分散は
- 平均値=np
- 分散=np(1-p)
というシンプルな式で表すことができる。
とりあえず、高校生時代にやった記憶はほぼ抜けていたことがわかりました・・・。
追記)
上記をイメージでもっと理解したい方には、gaccoの「社会人のためのデータサイエンス入門」がおすすめです。
数式に抵抗ある人でこ、馴染みのある政府統計のデータを用いているので、イメージが湧きやすいです。
JQuery resize/load/scroll
JQueryで、ウィンドウサイズを変えたときに動作を発動したいケースを調べていました。
resizeを使う、これだけでした。
ちなみに、画面を更新したとき、スクロールしたときに動作を発動させたいならそれぞれ下記。
また、上の3パターンのうちどれかが発生したときに、同じ動作をさせたいなら
今回、一番びっくりしたのは、↑のコードをVSCodeから直接見た目を変えずにコピーペーストできたことです。。。
CSS animation作成
CSSでアニメーションを付ける方法です。
下記例では、四角の枠が斜め下に動きながらバウンドしたような動きになっています。
CSSプロパティのanimation, keyframes, transform, translateの使い方がわかります。
@keyframes 関数名 {
from { transform: translate(最初の位置(x,y));}
50% { transform: translate(中間の位置(x,y));}
to { transform: translate(最後の位置(x,y));}
}
div {
animation: 動作時間 動き方 動作遅れ時間 動作回数 動作方向 関数名;
}
下記はサンプルコードと実行結果@CodePen
See the Pen 200517_animation by しげ@元プログラマ (@sigeo5) on CodePen.
Gitとの出会い
GitHub、巷ではとてもメジャーだとのことですが、実際使ったことがなかったので、興味もあり、UdemyのGit入門を受講することにしました。
Gitとの出会い・・?
本当にトレンドについていけていないのが悲しいですが、かなり昔から「Git」というバージョン管理システムがあることは一応、知ってはいました。
ちょうど仕事に適したちょっとしたバージョン管理システムが欲しくて、いろいろ無料ツールを調べていたところ、Gitってなかなか使いやすそうだな、ということで知ったのがGitとの出会いです。その時は何かのGUIで動かしてみただけだったのですが、社内で話が上がっていた、Subversionより使いやすそうだな、という印象でした。
そのころ、Gitのことをずっと「ジット」と読むものだと思っていました(笑)(正しくは「ギット」らしいですね)
今日、Gitのことをいろいろ調べていた時に、その時の記憶がよみがえってきてほっこりしました。
Gitが生まれたとき
Udemyの教材で、GitはLinux開発者のために作られた、とあったので、Gitの使い方を学ぼうとしていたつもりが、そちらのほうへ興味が移っていきました。
そして興味深かったのが、下記の記事。
Linuxカーネル開発者、Linus Torvalts氏の手によって、Gitが生まれる瞬間の生々しい現場の様子を、Gitメンテナの濱野純 氏が伝えてくれています。
Linusさんがこういうバージョン管理システムが欲しい、とサンプルを作り、それがメーリングリストにながれてきたので、濱野さんが見てみると、
彼が書いたコードをダウンロードしてみたら,
1,244行しかなくて。
弾:全部Cですか?
濱:そうですね。
。。。 神ですか。そのソースコード、ぜひ拝見したいですね。。。
GitとGitHubは別物?
上の記事によると、GitHubは、もともとあったGitコミュニティとは別のところで作られたもののようです。それはGitがLinux開発者に使われていたのに対して、GitHubはRubyの開発者で使われるようになったからじゃないかとのこと。
それで同じ「Git」だけれども、お互いが疎遠だった時期もあったようです。でも今はそうでもない様子、ということは、優れたシステムは、たくさんの優れたエンジニアにとって関わらずにはいられないものだからなのかもしれません。
「Git」が優れている、ということをLinusさん本人が自信をもって語っている、下記記事も注目です。
本の虫: gitの10周年を記念したLinus Torvaldsへのインタビューの翻訳
gitは基本的に俺の要求を満たすために設計されて、結果はご覧のとおりだ。
「俺の作業」とは、Linuxカーネル開発における、面倒で難しい作業のことです。
Gitとは・・・
従来あったバージョン管理システムと比較して、劇的に変わったのはそのファイルマージ方法にあるそうです。
私の理解では、
あるファイルAを3人で別々に編集し、ファイルA-1、ファイルA-2、ファイルA-3ができたとする。。
(従来)
それぞれが各ファイルを傍流にUpload。ローカル環境でマージした後、マージ後のファイルを本流としてUploadする。
(Git)
それぞれが各ファイルを待機ステージにUpload(commit)。待機ステージでマージした後、マージ後のファイルを公開サーバーにUpload(push)する。
という理解ですが、間違っていたらこっそり教えて下さい。。。
2万円以下で性能の良いノートPCを買う方法
しげです。今回はノートPCを格安で手に入れるやり方について書いていきます。
ノートPCの購入場所。
ここのところ、PC、タブレットはもっぱらフリマサイトで購入しています。
なぜかというと、
- メーカーサイトは最近のモデルしか売っていないため、値段が高い
- 店頭で現品を見なくても、スペックがわかればよい
- 個人でPCに詳しい人が、PCを改造して、格安で売っていることがある
からです。
以下はWindowsのノートPCの探し方です。
自分が欲しいスペックを考える。 CPU/画面サイズ・・・
私が求めるノートPCは以下です。
- インターネットでWebページを快適にみることができる
- プログラミング学習用にいくつものソフトウェアをインストールできる容量がある
- 電源をいれてからの起動が早い
- どこでも作業できるよう、バッテリーの持ちがそこそこ良い
- 2万円以下
上記以上の要望があれば、それに応じたスペックを考えていただく必要があります。
私の希望に合ったスペックは、以下です。
- 画面サイズ
11~14インチ - CPU
Intel Core i5以上が望ましい (実際のHzは要確認) - OS
Windows 10 (Macは高いので) - RAM
8GB以上 (Windows10の場合はこれくらい) - ストレージ
SSD 128GB以上 (SSDは起動が早い) - バッテリーの持ち
6時間以上が理想 - DVDドライブ
重くなるのでなくてもよい - USBポート
1つ以上(マウス用)
割と普通ではないかと思います。でもこれくらいだと、たまに2万円以下で見つかります。太字は絶対にほしいスペックです。
フリマサイトでの効率の良い探し方
わたしはメルカリかラクマをよく使っています。
探すときは「ノートPC 14 SSD」など、ほしいキーワードで検索をかけるとよいです。(14は画面サイズ。)
検索して出てきた商品の一覧から、さらに値段で絞り込み(例:2万円以下)を行います。
絞られた商品の中で、新しいものから順にスペックをチェックをしていきます。下記がその一例です。
上の商品だと、気になるのはCPUとRAM容量(メモリ)です。
CPUはGoogleに名称を入れて調べてみましょう。この場合だと1.7GHzとかなのでちょっと遅いですね。。。2G以上は欲しいところです。
メモリも4GBなので、動くには動きますが、もう少し欲しいですね。
こういったスペックについて、出品者がよくPC改造している方であれば、交渉するのもありだと思います。出品者のほかの出品物をみて、いくつもPCを出品していたり、メモリなどの自作用PCパーツ類を出品していれば、よく改造されている方だと思います。
あと、上記写真にはありませんが、バッテリーの持ちも確認しましょう。できれば、PC画面に出てくる、バッテリー残り残量の写真を見せてもらうのがいいと思います。(実物との多少のずれはあるとは思いますが・・・)
フリマサイトを探すコツ
注)Amazonを確認したら、上の型は中古のみの販売のようです。
読書「1%の努力」
自分にとっての「大きな岩」は何だろう
大学の講義で、先生が大きな壺に岩をいっぱいに入れて、生徒に「この壺は満杯か?」と尋ねる。生徒が満杯だ、と答えると、先生は砂利や砂を取り出してきて、壺に入れると入ってしまう、という話。
実は頭の中には工夫すればたくさん入るんですよ、ということを示したかったのかと思うと、逆の発想で、先に砂利を入れてしまうと大きな岩は入らない、という教訓だった。
ここでの大きな岩は自分にとって重要なもの、砂利はその他の重要ではない何かである。自分にとってそこまで重要でないことばかりに人生の時間を使っていると、大きな岩はもう入らないよ、ということだ。
大きな岩は、ひろゆきさんにとっては睡眠とのことだ。寝たい、という気持ちを一番の優先事項として、それがたとえ誰かの誘いを断ることになっても、後で謝ればいいやくらいの気構えでいる。
そう気づくと、私たちの時間はそれこそたくさんのそこまで重要でないことで埋め尽くされている気がする。社交辞令としての飲み会、惰性で開かれる会議、見返すかどうかもわからない説明資料・・・といった仕事上の無駄から、掃除、料理、洗濯・・・といった日常の家事まで。そういったことに忙殺されていると、いや忙しくなくてもなんとなくそれしかやっていないと、本当に大事なことに時間を割けなくなってしまう。そうして、不満だらけの日常になってしまうのだ。
これって遺伝子なのか、環境なのか
ひろゆきさんは子供のころの学区は公営団地の人が多かったとある。公営団地への入居は一定以下の年収が条件なので、お金持ちはいない。仕事をしていない人もいれば、ギャンブルに給料をつぎ込む人もいるだろう。別にそれでも団地の家があるから生きていける。
逆に裕福なエリート家庭の生まれだったらどうだろうか。お金には困らないだろうから、学校は私立が当たり前だし、親の援助で留学したり、就職も有名どころの企業に入社したりするかもしれない。
このあたりのことは、自分も地方の出身なのでなんとなく想像できる。特に、エリート家庭の多い関東の人々に会うと、地方とのギャップを感じずにはいられない。
海外に行くと差はもっと大きい。世界の貧困層の子供が大学まで通える確率はほぼ0だろうと思う。下手をすると、大学、というものすら知らないかもしれない。それだけをとっても、日本に生まれたということは、かなり環境に恵まれているということだ。
生きていくこと自体は少なくともこの日本では、イージーモードなはずだから。
「1%の努力」は、今の状態に疑問を持っている人に、新しい見え方を教えてくれる。
読書「なぜ、あなたの仕事は終わらないのか」
元マイクロソフトでWindows 95の生みの親、中島聡さんの著書を読んだ。
ソフトウェアエンジニアの端くれとして、感動する場面がたくさんあったのだけれども、特に心に残った点を書き留めたいと思う。
「未完成でいいからまずはプロトタイプを」
時間をかけて完璧なものを作ることを目指すより、未完成でいいからプロトタイプをまず作れ、と言われている。
今でも根強いウォータフォール開発の最中に、ソフトウェアとしてプロトタイプ開発指向、ひいてはアジャイルな開発スタイルを取られているのがとても先進的だと思い驚いた。
基本的に、開発者はまだ未完成なプログラムをリリースしたくない。
時間が経つにつれ、大きな問題に気付いたり、仕様変更のために大幅修正したくなるかもしれないから、しばらく温めておくのが面倒が少なくていいのではないかと考える。
そこをあえて、とりあえずソフトウェアリリースを一旦行い、市場からのフィードバックを待つ、というのが潔ぎよいと思う。それは、ユーザーが本当に欲しいソフトウェアを作るには必要なマインドで、そういった環境に身を置いてこそ、厳しいフィードバックを受けるために、更なるレベルアップも早いのだと思う。
もちろんプロトタイプを出すには、最低限の機能をなるべく正確に盛り込む必要がある。肝心のフィードバックが欲しいポイントが作り込めてないと、誰に見せても役に立つフィードバックはもらえないことになってしまうから。
「ロケットスタートするメリット」
ロケットスタート、すなわち決められた開発時間の最初に全力を注ぐ、というやり方。こうすることで、締め切りを守れる、と言うのはもちろんあるけれども、それ以上に毎回100%の力を出す習慣をつける、というのは案外大事だと思う。
人は普段70%、80%くらいの力しか出していないと、結局100%以上の力は出せなくなるからだと聞いたことがある。人間は慣れる生き物なので、常に100%を出すようにしておけば、徐々にそれ以上の力が出せるようになる。これで更なる成長につながる。
「好きなことをやることが幸せにつながる」
実際は色んな人が言っていることだけれども、中島さんのような方がこの言葉を言うと、とても説得力がある。ただこれまでは、他の人の幸せにも繋がるのだろうか、ただのわがままじゃないか?とも内心は思っていた。
ここで気づいたのは、中島さんのMicrosoftのチームは、
「なんとしてでも最高の製品を世に生み出す」
という志を持った人の集まりであったことだ。そこで中島さんがこれまでの中で最高に楽しく充実した仕事ができていた。
全員がその方向で一致していました。思いは一つだったのです
これはすなわち、周りも中島さんと同じくらい幸せな状態にあるということになる。なぜかというと、同じチームのみんなが、幸せだと感じる状態=幸せの価値観が同じだったからだということに他ならない。
自分の好きな仕事をしていれば、同じ幸せの価値観が似通う人が、同じ職場に集まるようになる。この状態では、自分が好きなことをしているだけで周りを助けることにも繋がり、お互いが幸せということになる。
私たちはこんな職場をいったいどれだけ作れているだろうか。仕事が嫌だな、会社に行きたくないな、あの職場の人と合わないななどと思いながら仕事をしていないだろうか。そんな思いを続けていたら、自分も、その一緒に働く仲間も不幸にする結果になるに違いない。
ここで著者の中島さんにお礼を言いたいです。
昔、自分がアルバイトをして初めて買ったPCのOSがWindows95です。Windows 95のおかげでPCがより庶民の身近になったということは後から知りました。なので自分の初めてのOSがWindows95というのは別に不思議なことでもなんでもないのは分かっています。
でもあの時買ったWindows95がなかったら、PCの世界が遠すぎて、私が今こうしてソフトウェアの仕事に就くことは出来なかったのではないかと思っています。
ソフトウェアの仕事に就いてから、朝仕事に行きたくないと思うようなことはなくなりました。本当に好きな仕事に就くのは大事だと、Windows 95に出会ったときからの自分の経験で教わったように思います。
フィンテックをあらためて読んでみた。
2016年発行、著者:柏木亮二氏
今となっては銀行内のIT改革も進んだそうで、数年前とは比べ物にならないほどサービスが便利になりました。(近年よく銀行が不定期に土日ATMを止めたりしていましたが、システムの入れ替えが大変だったんでしょうね。)
本の概要
近年起こっている、金融業界を揺るがす新しい技術を整理しながら認識し、既存企業が生き残るにはどうしたらいいかを提案する。
- 本人確認=KYC(Know your customer)の規制が強化されてきたため・・・・
→Trunomi/CONTEGO(本人確認用の顧客情報シェアサービス) - お金のやり取りを安全に行う必要があるため・・・
→ApplePay、FIDOアライアンス(生体認証の技術標準化団体) - 支払いをより簡単に・・・
→SUICA、LINEPayなど(電子マネー)、Paypal(オンライン決済)、Square(モバイル決済) - 個人の様々なお金のやり取りを管理するため・・・
→マネーフォワード、zaim(個人資産管理モバイルアプリ)
- 資金決済:銀行口座振込→Paypalなど
- 資金集め・投資(小口):銀行融資→クラウドファンディングなど
- 海外送金:口座間の送金→Transferwizeなど
従来の企業が新しいイノベーションに立ち向かうには
【価値基準を変える】
利益率、シェア、市場成長率、顧客満足度に価値を置く⇒破壊的なイノベーションを生み出すことに価値をおく
【プロセスを変える】
顧客ニーズ、利益、株主を優先としたプロセス⇒失敗、損失を許容し、素早い意思決定を行える組織体制
-
外部組織の買収
外部組織の価値基準とプロセスを手に入れる。自分たちの組織の価値押し付けはNG
(過去の例:買収した会社でネクタイ着用を義務化→社員の離職率増加) - 組織の意識改革
自分たちの組織の価値基準とプロセスを変えていく。
懸念点:既に成功している価値基準とプロセスを捨てて大企業を維持するのは困難 - 新たな別組織の設立
破壊的イノベーションに適した価値基準とプロセスを新たに別組織として持つ
金融業界の話、と思いきや、根本的なところは他の業種も同じ問題を抱えているな、と改めて思いました。
むしろ金融業界は持っている資源が現金、銀行店舗、従業員くらいですが、既存の工場や設備などを大量に抱える製造業などは、かなり動きが鈍くなっていて当然だと思います。
そのせいか、他業種ではいまだ変われていないところが多いように感じます。