なおこの記事の前提ですが、私はこれまで業務でPythonをゴリゴリ書いた経験は乏しく、読んだりデバッグ&修正のような感じの経験が多かったので、そもそもあまりPythonの言語仕様について詳しくありません。
今回の書籍レビューを通して、Pythonに関して体系的に知識を整理する良い機会となりました。
山田さんの書籍全般に通じることですが、プログラミングが初めての方でもちゃんと歴史的な背景を学ぶことができるよう、丁寧にイントロダクションが記述されている印象でした。
プログラミングが全く初めての方でも、独学が得意な方であれば、これ1冊でPythonやプログラミングの基本的な概念を理解することができると思います。
私のように体系的にPythonを理解できていない方にとっては、特にPython特有の記法や概念をおさえることができて良かったです。
参考までに私がちゃんと理解していなかったものを列挙しておきます(Python特有のものではないものも含まれています)。
//
基本的にはPythonを学ぶ上で最初の書籍であることを想定しているからだと思いますが、オブジェクト指向の解説はちょっと駆け足かなと思いました。
Pythonでオブジェクト指向を本格的に学ぼうとする場合、決定本ってなんだろう?と思って軽くググってみましたが簡単には判別つかず😓
もしかしたら「オブジェクト指向設計実践ガイド」とかのが良いのかも?(Rubyだけどw)
この書籍でも触れられていますが、 Pythonは多重継承を許容しています。
多重継承を許容しているプログラミング言語、他にはC++が有名ですが、その他って何があるんだろう?ってふと疑問に思いました。
言語仕様として多重継承はマイナーで、私がこれまで経験してきたプログラミング言語(主にC/PHP/JavaScript/Ruby)は許容していないこともあり、ちょっと気持ち悪いと感じてしまいますね😅
「妻クラスが恐竜(クラス)」ってなんか凄いものを見てしまった感じがしました😭
「妻クラスが恐竜」ってパワーワード😎
— 竹馬力@366日後に死ぬ訳にはいかないpodcast(CEOFM) (@tchikuba) July 28, 2020
「独習Python」P444よりhttps://t.co/IVnW9rQFVz pic.twitter.com/TEuqsuCIeO
レビューは以上です。
私のように、その他のプログラミング言語の経験がある人が、体系的にPythonを学び直すのにもちょうど良さそうな1冊かと思いました。
気になる方はぜひ手にとってみてください😃
]]>タイトルにもある通り、CEO.FMは「クリエイティブが輝ける組織をエンジニアリングする」番組です。 番組名の「CEO」は、いわゆる最高経営責任者の意味ではなく、以下の頭文字の略称です。
私は、リブセンスでエンジニアリング・マネージャー(EM)、副業で技術顧問を複数社経験しています。
その中で、エンジニアをはじめとするクリエイティブ職種が力を発揮できる環境(組織)には、一定再現性があるのでは?という仮説(というかどちらかというと確証に近いもの)が湧いていました。
様々な現場で奮闘しながら出会ったのが、ティール組織という書籍。
衝撃。私がこれまでの経験から感じていた課題感や前述の仮説と見事に一致していたからです。
4年ちょっと前のリブセンス・アドベントカレンダーで書いたブロク記事「21世紀型のクリエイティブな働き方・思考・組織の新しいあたりまえ」でも、自律的に働くこと/ホラクラシーについて言及していたり、昨年(2019年)5月に行われたGotanda.EM #2でのLTでは、従来の管理型ではない新しいマネジメントに注目していることに言及しています。
私にとって、ティール組織の在り方は、「クリエイティブが力を発揮できる組織には再現性があるのでは?」という問いへの、1つの答えでした。
私はティール組織の実践者でありたいと強く願っています。
組織論について空理空論を振りかざして実践例や具体例に乏しい状態は、私にとって好ましくない。 現実の世界で、クリエイティブがよりクリエイティブらしさを保障される仕組みづくりに貢献していきたい。
そういう想いで、まずはCEO.FMを始めてみました。
ところで、リブセンスVP of Engineeringの@notoと以下のやり取りしてました。
実は私も一緒だったりしますw
— 竹馬力 (@tchikuba) January 31, 2020
文字起こし作ってくださいw
— noto (@noto) January 31, 2020
ツイートの通り、私も動画/音声コンテンツはあまり見聞きする方じゃないんですよね。テキストの方が、思索しながら熟読したりなど、自分自身で情報のインプットのスピードをコントロールしやすくて。
そこで私や@notoのような方のために😁、CEO.FMエピソード#10までの企画案を公開しておきます。配信前にざっとメモしている内容なので、実際は話が発展しているエピソードがあったかも。
まぁ配信の雰囲気は感じて頂けるかなと思います。 もし興味関心が湧いた方がいましたら、ぜひ聴いてみてください!
ちなみに10回目の配信でご褒美としてAmazonでポチったマイクはこちら。
#ceofm 用の🎤が早速届いた😆
— 竹馬力 (@tchikuba) February 2, 2020
10回目の配信のご褒美😊 pic.twitter.com/xjS8xmpDlN
12回目の配信からこのマイク使って収録始めました🎤
ちなみにCEO.FMのハッシュタグは#ceofmです。 感想/ご意見などあればTwitterアカウント@tchikubaまでぜひ!
内容について共感頂き、かつ応援したいと思われた奇特なそこのあなた。
ぜひこちらのpaypalから善意の投げ銭をw
]]>久しぶりのブログ更新はいつもとは全く違う毛色でお届けします。
プライベートなことなんですが、比較的最近、中古マンションを買って引っ越しました。
フルリノベーションされたマンションなので、当然バリアフリーで段差がなく。
子供いない夫婦2人でちょっと広めの1LDK。共働きで比較的公私共に忙しい2人なので家事の分担はこれまでの賃貸住まいでもちょっとした問題でした。
ちなみに私は、家事を自分たちでしなくても今どき都内なら家事代行サービスたくさんあるのでそれで手を打ちたかったんですが、嫁はプライベートな空間に第三者が入るのに抵抗がありました。
賃貸時も1LDKでしたがちょっと広くなったのでひとまず掃除が面倒だなぁと思っていたので、ルンバi7+を購入したら思いの外、快適で費用対効果抜群だったのでルンバちゃんを褒め称える記事ですw
なんとなく値が張る家電って、できるだけ店頭で見て買いたいみたいな思いがあったんですが、エンジニア目線で見て妙にブランディングがしっかりしているiRobot社とかダイソン社とかはAmazonでポチっても問題ないよね感あり、Amazonでポチりました。
マーケティングなのかもですが、こういうマーケティング/ブランディングって海外のプロダクトのがちゃんと立ち位置築いている感じがする。
これが日本製のロボット掃除機買おうとすると「違いがよくわからん」ってなって、まず下調べするところから始まって面倒な時間が取られちゃうんですよね。
実際、ルンバのあと、縦置きの洗濯乾燥機も古くなってたのでSHARPのドラム式洗濯乾燥機(ES-W111)を買ったんですが、これは家電量販店のノジマに店頭で色々聞いて買いました。
その前にメーカーによる製品の違いを理解するために、ググる時間で2時間とか取られたので時間の使い方もったいない。そんな暇じゃないのだよ、こちとら。
という訳でなにが言いたかったかというと、iRobot社のルンバくらいブランディングの立ち位置があるとその辺の時間削減されてユーザー的にも幸せが訪れるということ。
とはいえルンバも色々と種類があってピンきりなので調べたところ、i7+が最上位モデルで以下あたりが特徴でした(認識違ってたらツッコミください)。
個人的には特に最初のクリーンベースが気に入ったので迷わず最上位モデルのi7+の購入を意思決定しました。クリーンベースがないモデルだと、基本的に毎回本体のダストボックスを掃除してあげる必要があるみたいです。クリーンベースがあれば、30回分はそこに溜められるので1日1回の作業(本体の掃除)が1ヶ月に1回で済むので時間の節約になります。
実際に2ヶ月くらい毎日使ってみて、実はまだ一度もクリーンベースの交換用紙パックは交換していません。中を確認してもまだいっぱいになってないからですが、共働きなので一般的な家庭よりは自宅にいないからその分ホコリとかは少ないのかもですね。
1ヶ月ちょっと経って一度だけルンバ本体の掃除はしました。それほど必要なかったような気もしますが、一度メンテナンス手順を確認しておく意味でやりました。クリーンベースの紙パック交換もルンバ本体の掃除も、3ヶ月に1度くらいの頻度で良さそうかなという印象です。
要はメンテナンスにもほとんど手間暇かかりません。
アプリもよくできてると思います。気になる点は、起動後にルンバに接続するまで少し時間がかかるというのと、ルンバが汚れを検出した時に重点的に掃除する「ダートイベント」の「詳細を確認する」のリンク先がオンラインヘルプになっているんだけど、ずっと「ご利用できません」ってなってることくらいかな(関係者の方なんとかしてくだせぃ)。
一部スクリーンショットを紹介します。
まずアプリトップ。
中心にあるでかい「CLEAN」って丸いところをタップすると、アプリから手動でも掃除を開始できます。厳密にはタップした後に全部屋か部屋を指定するか選べます。
続いて「お手入れ」をタップした画面。
これはルンバ本体のメンテナンスが必要かどうかを表示するところ。このステータスは自動というわけにいかないので自分で選択してそれぞれのステータスを管理する必要があるっぽい。
ちなみにそれぞれを選ぶと「ステータスのリセット」が選択できるんだけどこれがやたらと時間かかっていたのも気になった点かも。
続いてトップから「履歴」をタップした画面。
これはスクショの通り直近30件の掃除の一覧ですね。ここからそれぞれの履歴の行をタップすると以下のように掃除についての詳細が見れます。
初期は「清掃が完了し、ダスト容器が空になりました!」のところは閉じている状態です。スクショはそれをタップして開いたところ。
この通りうちの1LDKだとだいたい40分ちょっとかかります。
続いてトップから「スケジュール」をタップした画面。
こんな感じで清掃のスケジューリングを予め登録しておけば、その時間になれば自動で起動して掃除してくれます。エンジニア的に言えば要はcronジョブですね。意味が分からない人はスルーしてください。
続いてトップから「スマートマップ」をタップした画面。
これ凄いなーと思ったのが、最初何度か掃除を繰り返すと自動で部屋の区分を提案してきてくれて、足りないところは自分で部屋の境界線を指定して部屋を定義できるところ。日々の掃除自体も部屋の形状を記憶して人工知能的な掃除効率化がなされているっぽい(日常的な掃除の動きを見ているとようわからんですが)。
ちなみにAlexaに個別の部屋を掃除するよう指示できるんですが、この部屋の名称を指定しないといけないので、「リビングルーム」と登録してるのに「居間」と言っても認識してくれませんので悪しからず。
リビングルームってアプリがサジェストしてくれた名前を指定したんだけど居間のがAlexa経由で使う場合は短いから便利かもしれない。まぁ「Alexaで」「個別の部屋を」掃除する利用シーンがそれほど発生しないんだけど。
こんな感じで、細部はツッコミどころありましたけど、アプリもなかなかによくできている印象です。
ここが一番言いたかったことです。
クリーンベース付きのモデルならメンテナンスコストはそれほど高くないので無視できるレベル。
自分で掃除機かけるよりちょっと時間かかる印象ではありますが、ソファなど家具の下に入り込んでまでちゃんと掃除してくれるので自力でやるより行き届く部分もあります。
仮に自分で掃除するのが半分の20分と仮定すると、我が家にルンバがやってきて2ヶ月なので、
1/3時間(20分)×2ヶ月(60日)×時給単価(m)=20m
という数式が成り立ちます。
本体価格が凡そ14万なので、
20m≧140,000
という不等式を解くと
時給単価m≧7,000円
が導けます(数学が日常生活で役に立った瞬間)。
つまり、自分の時給単価が7,000円以上あると思えるなら たった2ヶ月で初期投資回収できちゃう ということです。
時給単価そんなに高く思えなくても、例えば家事代行サービスの時給単価が東京だと2,000-2,500円なので約1/3と仮定しても、 6ヶ月、つまり半年で初期投資回収できます。
あとそもそもお金に換算しなくても、毎日20分「自分で掃除機かける」というタスクがなくなるので、 1ヶ月あたり10時間、時間をあけられるというのはプライスレスですよね。
ちなみに私はエンジニアなので、ある程度自宅でリモートワークする機会もあるんですが、ルンバのおかげで自宅の快適さが増してよりリモートワークしやすくなったのもプライスレスでした。
時間に追われるそこの奥さん!でもご主人でもなんでも良いんですけど、マジおすすめです。当然バリアフリー物件じゃないと導入しづらいってのはありますが。
話はちょっと変わるんですが、ルンバで生活改善みたいな流れって、以前読んだファクトフルネスって書籍を思い出すんですよね。
ファクトフルネスについての詳細は割愛します。簡単に言えば「世の中を事実としてちゃんと正しく認識しようね。それから、世界はよりよい方向に発展しているから無駄にネガティブにならないように気をつけよう」みたいな内容の素晴らしい書籍です。正しい国際感覚を身に着けたい人には必読の書。
この書籍に、世界の人々の暮らしは、1日換算の生活費によってレベル1から4までの四段階に分類できるということが書かれています。
例えば歯ブラシなら以下みたいな感じです。
掃除に関して言えば、ルンバが起こしたイノベーションって最早レベル4を超えてレベル5なんじゃないかと思うんですよね。
ITの急速な発達により、「これまで人間がやるとされていた仕事が自動化されて仕事がなくなる」ってイノベーションがもろ実現している。
こういうプロダクトって純粋に凄いなーって思います。
そういうイノベーティブな仕事に携わっていたい。
ちなみに余談ですが私の残りの人生をかけての使命は 「クリエイターを世の中に増やすこと」 につい最近決まりました。
そもそもこういう「イノベーティブな仕事ができる人」をもっと増やしていくことに、今後の人生の時間を使っていこうと決意しています。
]]>私はプログラミング教育には関心が高いのですが、どちらかというと現状は社会人向けの方にコミットしています。
TechAcademy [テックアカデミー]という社会人向けのプログラミングスクールでwebアプリケーションコース(Ruby on Rails)の講師(メンター)をやっていたりします。
が、過去、小学校の教員免許状も取得したこともあり、学校教育におけるプログラミング教育にも将来的には関わっていきたいなと思っています。
NPO法人のみんなのコードは、本業のリブセンスでのご縁もあり、以前から知っていましたが、今回のイベントに知人のFacebookエンジニアである安藤さんもパネラーとして参加されるというので、同日行われていたMeguro.rbの参加を見送って、このイベントに参加することにしました。
最初にアイスブレイクで2人1組になってトランプ5枚のカードを大きい順に並べ替えるゲームで和みました。 ソートアルゴリズムを特にIT機器を通さずに体験するゲームということで、広く言えばこういうものも、プログラミング教育の一環とも言えるのではないかと思いました。
その後、利根川さんからみんなのコードが目指す世界についてアナウンスがありました。 一応紹介しておくと、NPO法人みんなのコードは、プログラミングを教える人を教える活動を行っています。 つまり、教員の方を中心にプログラミング教育の教え方を教えるような感じです。
ご高齢ながらプログラミングを独学で習得して一躍有名人となった若宮正子さんなどのストーリーを通して、コンピュータを用いて何らかの課題解決をしている事例を紹介されていたのが印象的でした。
私が話を聞きながら疑問に感じたポイントは、プログラミング教育以前に、学校のような比較的伝統ある古い組織において、ITを導入することでより効率的に物事を進めたり、人とつながったりなど、ITの恩恵を受ける体験に実は乏しく、ITが持つ力の大きさみたいなものを教員が実感する必要があるのでは?ということでした。
そのような趣旨で質問してみたところ、プログラミング教育がきっかけになって、学校側のITリテラシーがあがる、という事例も実際に出てきているそうです。
後半からは、以下のパネラーの方々の簡単な自己紹介の後、プログラミング教育に関するパネルディスカッションが行われました。
詳細と見出しには書きましたけど、ここからは議論が面白くて前のめりに聞くのが中心だったのであまり網羅的にメモできていませんが、個人的に印象に残った議論とその所感を中心に書き起こしておきます。
福田さんは元先生で、現在はみんなのコードで全国を飛び回って、先生のためのプログラミング教育について研修をされているそうです。いわゆる「プログラミング指導教員養成塾」的なものをされています。
福田さん曰く、全国を回った所感として、「3つの格差」について話をされていたのが印象的でした。
教育に関して、地方は東京から3年くらい遅れて広まっていくところがあり、「公教育の犯罪」とまで言及されていました。
以前からも流行り廃りみたいなものは、東京から広まっていくのはあったと思いますけど、単なる流行はSNSなどインターネットが普及する昨今では、地方に広まっていくのもかなりのスピード感あるなぁという印象があります。恐らく、インターネットの恩恵を享受しにくいサービスみたいなものは、やはり東京一極集中というのはある気がします。
学校の先生方にプログラミング教育の必要性を訴えるには、求められる背景の理論武装が必要だけど、一度理解してもらえればちゃんと堅実に推進してくれるという話は印象的でしたね。私もその昔、小学校に教育実習に行ったことがありますが、確かに教育の現場って理屈っぽい先生方多かった印象ありますね。理屈っぽいという意味では、エンジニアも同類項ですがw
プログラミングで求められる自発性みたいなものがあり、たとえば、アイルランドから始まったCoderDojoでは、あまりトップダウン的なアプローチで何かを強制的にさせることは行いません。あくまでも子どもたちの自主性にまかせてやることを決めるので、一人ひとりの個性が大切にされます。
同じような流れで、一度プログラミング教育を経験した子どもたちが、プログラミング教育以外の分野でも、ボトムアップ的なアプローチで色々と試行錯誤し出す、ということがあり、これは大きなメリットの1つであると小池さんが言ってました。
本来、「教育とは子どもたちの個性に合わせて行われるべき」というのが持論ですが、どこかで横並びの画一性みたいなものが管理上求められる部分もあるので、この矛盾とどう戦って行くのかが重要だなと個人的には思いました。子どもたちに合わせるなら、個人指導みたいなのがベストだけど、現状の公教育は集団授業前提なので、なかなか子どもたちそれぞれに合わせていられない部分はあると思います。
公教育にはほぼすべての大人が子どもの頃に経験したもので評価してしまうけど、実は最新の公教育がどうなっているのか?という実態を把握している人はそう多くないです。だからこそ、安藤さんはプログラミング教育についても「知ったかぶりする人が多い」という表現をされていたのが印象的でした。
安藤さんは前述のCoderDojoでも子どもたちに教えた経験があります。教育の現場として、「IE(ブラウザ)を開くのに15分かかる」「キーボードで入力すると急激にハードルがあがる。”こんにちは”と入力するのに1分かかったり」と事例はなるほどなぁという感じでした。
個人的にはいい加減、キーボードに変わるより直感的な入力デバイスが必要な気がしていますが。誰かベンチャーでやらないかなw現状だと音声入力の精度がかなり向上している感ありますが、どうもプログラミングの入力となると記号などが多いので難しそう。音声入力専用のプログラミング言語とか作れば良いのかしら。
話が逸れました。
いずれにしても、公教育におけるプログラミング教育は、そのハードルをかなり下げる必要があるという主張は共感できました。確かに、野球やサッカーの競技人口の裾野は広がっていますが、だからといってみんながプロの選手になる訳ではないです。プログラミングも同様で、職業エンジニアに求められるハードルと混同してはいけないと思います。
「議論のすれ違いー」
このように安藤さんは表現していましたが、私もまったく同感で、ポジショントークによるものが大きい気がしています。産業界ではいわゆるホワイトカラーの仕事が増えていて、かけた時間と成果が一致しない類の「質」が求められるようになってきています。この流れの中で、プログラミング的思考が求められることが少なくありません。それでなんとなく一斉に「これからはプログラミング教育の時代だー!」みたいな温度感高めの人たちが一定増えているのが現状かなとも思います。
この話を書いていて思い出したのが、サイバーエージェント系列のCA Tech Kidsの代表とCA藤田さんとの対談のこの記事です。この記事の後半に出てくるのですが、プロ野球と同じように、高校生向けのドラフト会議のエンジニア版をやるというのが興味深いなぁと。こんな感じで、エンジニアとしてのエリート教育もあって良いと思います。大事なのはダイバーシティですね。野球でもサッカーでも、だいたい日本代表レベルで活躍する人って、地域のリトルリーグとかそういうのやってましたよね。ガチ勢は意外と学校の部活とかやんない感じでした。そんなノリでプログラミング教育も浸透すると良いのかなぁと思います。
公教育におけるプログラミング教育のハードルを下げる取り組みとしてみんなのコードとして取り組んでいるのが、プログルです。これはプログラミング教育における定番Scratchっぽいものですね。
イベント当日は、自治体別アクセスランキングなどを見せてもらいましたが、全国からアクセスされて使われていました。
Scratchもそうですが、これ系のやつって子どもたちにやらせるとみんな総じて「楽しかったー!またやりたい!」ってほぼなるんですよね。この満足度はやりがいあって良いなと。うがった見方ばかりしかできない大人にはならないように気をつけましょう(違)。
既に所感もあわせて記述したのでその通りですが改めて。
どの目線で話をするのか、というのが一番大きいですね。やはりプロのエンジニアになるためのプログラミング教育と、プログラミング的思考を養ったり、プログラミング教育の出会いの場を提供するという公教育では役割が違って当然です。2020年小学校教育でプログラミング教育が必修化されるとか、センター試験で科目化されるとかの時代の流れもあって、このあたりの棲み分けが現状カオスになっている印象はあります。
何事も活動が広まっていくプロセスにはカオス期というのは避けて通れないので、あと5-10年くらいかけてもっと洗練されていくのかなと思います。公教育の体育の授業でソフトボールや野球をやるのと、リトルリーグに所属した人がプロ野球選手になるプロセスに文句いう人がいないように、プログラミング教育が自然になっていく時代がやってくるのは間違いないでしょう。
私はエンジニアなので、日本が少子高齢社会の中で高い生産性を保ってより高い価値ある仕事を創造していくには、プログラミング教育は何かしら必須であると考えています。そのうち時代がやってくるさ♪という傍観者ではなくて、何かしらプログラミング教育へのコミットメントを増やしていきたいです。
頑張ります!
]]>それぞれの本についてレビューをば。
※関係者の方々、対応が遅くなり申し訳ありません。。
超入門書なだけあって、そもそもwebサイトがサーバーに設置されていてブラウザなどのクライアントからアクセスして読み込むものだ、的な基礎的な部分からちゃんと解説されています。 また、技術的側面だけでなく、webサイトを設置する目的やどう設計するか?についてもちゃんと触れられている点が素晴らしいです。
超入門書といえど、headerタグやfooterタグなどを通してセマンティックwebについて早い段階でちゃんと解説されています。
CSSの発展の歴史を紹介していたり、HTMLタグをwebページの装飾目的で使うことを戒めたりなど、経験あるwebサイト制作者の方の言葉が散りばめられている辺り、好感が持てる印象でした。
あと、私自身はサーバーサイドエンジニアなのでHTMLとCSSはなんとなくのフィーリングで理解しているところもあったので、例えばボックスモデルなどは恥ずかしながらmargin, border, padding辺りの違いについての認識が甘いところがあります。その辺りがちゃんと体系的に再確認できたのは良かったです。
同様の理由で、段組みレイアウトの辺りの解説もまた、何がブロックレベル要素で何がインライン要素なのかとかあまり意識できてなかったり、フロートレイアウトなどもフィーリングで理解していたところがあったので正直勉強になりました。
最近では必須のレスポンシブデザインに対応しており、具体的にはスマートフォン対応する具体的な方法についても解説されています。 私自身、メディアクエリとかちゃんと理解できてなかったところがありました。。
本書を一通りなぞれば、コーヒーショップのレスポンシブなホームページのサンプルを制作することができます。 本書を足がかりにすれば、読者は基本的なwebデザインのうちHTML・CSSコーディングができるようになると思います。
その意味で本書は良書だなーと思いました。
また、私みたいにサーバーサイドエンジニアが本業なんだけど、フロントエンドはそこまで詳しくないけどちゃんと体系的にイチからインプットしたい、というモチベーションがある人には刺さるかもしれません。 とはいえフロントエンドもある程度できるエンジニアにはちょっと物足りないかもしれませんが。
余談ですが、「本業サーバーサイドエンジニアに贈る基礎から学ぶフロントエンド」的な書籍があったら実はニーズあるんじゃないかと思いましたw
超入門シリーズ本にはおなじみですが、ターゲット読者層がプログラミング未経験者なので、そもそもwebアプリケーションってなんだっけ?とかサーバーサイド、クライアントサイドの違いみたいな基礎的なところから解説が始まります。
執筆者の立場として個人的に思うのですが、このあたりの解説ってすんなり説明するのが意外に難しいところだったりします。 どこまで歴史的な背景やバックグラウンドを説明するのかとか。
このあたりの部分、前半部分での説明が超入門者向けにも過不足なく非常に分かりやすいのではないかと思います。
また、JavaScriptでできることの幅が広がりつつある昨今ですが、その辺りにも触れつつ、本書でカバーする範囲をクライアントサイドのwebアプリケーション機能開発に特化していると明記していることもわかりやすさを担保することに繋がっている気がします。
超入門者向けでも、JavaScriptによるwebアプリケーションの基礎としてイベントドリブンモデルについて解説されています。 本書はwebアプリケーション前提なので、JavaScriptを語る上で密接に関わってくるイベントについて1つの章を割いて解説を加えているのかもしれません。
後半の章では、Flickr APIを用いて画像検索するアプリ作成を行っており、より実践的な内容になっています。 更に、Webstorageについても触れられており、こちらもAPI同様、より実践的な内容かなという印象です。
これも超入門シリーズ本全般で辛いところではありますが、環境構築でWindowsを前提とするツラミはちょっとあるかなと。 webアプリケーションにおけるJavaScriptというところで、Apacheのインストールは避けられなかったかもしれませんが。
超入門者にとって、前半の早い段階でオブジェクトという概念がいきなり出てくるのでちょっとギョッとするかもしれません。 JavaScriptの性質上、しょうがない側面も大きいかなと思いつつ。。
全体的にプログラミング言語としての側面からJavaScriptを論じるというより、より実践的なwebアプリ開発を行う手段としてのJavaScriptを紹介した書籍という印象を受けました。
プログラミングを全く学習したことのない人向けにしては、プログラミングの基礎的な部分、例えば3大制御構造などについて体系的な解説がそれほど多くなかった印象だったので注意が必要かもしれません。
逆に、JavaScriptを使って具体的にどういうアプリが作れるのか?という点にフォーカスしたい方にとっては良書と言えそうです。
超入門向けらしく、半角スペースをなくすとコンパイルエラーが発生するなど超入門者向けの内容がちゃんと解説されています。
nullは英語では「ナル」と発音するそうです。nullの紹介のところでコラムとして「正しく発音しましょう」って紹介がありました。 ちなみに私は普段「ヌル」と発音してます。スミマセン!
プログラミング初心者にとって最もつまづきやすいのがループと言われます。 ループを取り扱う章の最後に、本書ではループ処理がネストしている二重ループについて取り上げられています。 これはプログラミング初心者にとっては有り難い解説かもしれません。
同様に、配列の章の後半で配列とループ処理、ループ処理と条件分岐の組み合わせについても取り上げられており、二重ループ同様、プログラミング初心者にとってはプログラムが複雑になる過程をちゃんと説明してくれていて理解の助けになりそうだなと思いました。
クラスの基礎について1章分、クラスの利用について1章分を割いており、クラスに関する解説はかなりページ数を割いている印象です。 このあたりはそもそも扱っている内容が重いせいか、その他の章の解説に比べて超入門者がページをまたいであちこちに行ったり来たりして理解を深める必要があるように感じました。
このあたりをプログラミング初心者に分かりやすく解説できる自信は正直私もないのですが(汗)
総合的に見て、プログラミングが全く初めての人にとって、Javaを学習する目的で本書は向いていると思います。
ただ、個人的にはそもそも「オブジェクト指向」という概念がプログラミング初心者には分かりづらい気がするのでその点をどうフォローするか、というのはある意味プログラミング教育の永遠のテーマと言えるかもしれません。
]]>こっから先は話聞くのをメインにしてたので細かくはメモとってなかったので気になる所だけ…
久々サムライインキュベートなう pic.twitter.com/H9RSzbhKfQ
— Tsutomu Chikuba (@tchikuba) 2017年7月18日
私はエンジニアで本来参加対象者って感じではないんですが、参加した目的は以下でした。
目的は概ね達成できたかなと思っています。 参加者の中で実際にニーズを持っていそうな人・ペルソナが特定できなかった部分はちょっと課題。
OFFICE DE YASAIというサービスを運営している 株式会社KOMPEITOのCEOの川岸さん(登壇者)と話して感じたんですが、 ある程度ステージが進んだエグゼクティブだとより短期的な成果を求めるのでどこまで何が良くなるのか? ということを提示できないとニーズを掘り起こすのが厳しそうだということ。
また、その意味ではよりアーリーステージの起業家の方がニーズがあるのかもしれないと思いました。 ただ、アーリーステージ起業家の場合だと、本人がプログラミングスキルそのものを身に付けるという話なので、 その意味では私が想定するエグゼクティブ向けプログラミング研修とは違うかも。
全体的にエンジニアの私にとってはそれほど真新しい話はなかったんですが、 サムライインキュベートが支援するようなサービス開発のベンチャーは基本的に起業家がプログラミングできることか チームにエンジニアがいることが支援の条件でやはりアメリカ同様プログラミングスキルに対する ビジネス評価の温度感は高いです(当然か)。
あとは以下、昨晩のメモと感じたことを箇条書きで記しておきます。
女性向けサービス開発を行う上で女性の感性が必要なので女性がプログラミングスキルを身に着けて起業家になる女子校があるそう。 嫁に運営やらせたら面白いかも?とちょっと思いました。 こういうニッチに特化した方が集客しやすい側面がありそう。
登壇していたG’sアカデミーも起業家向けのプログラミング教育を行ってますが、 むしろエンジニア界隈で最近主流になってきているプロダクトマネージャーの流れで、 エンジニアを起業家にする方が筋が良い場合があるのでは?と思いました。
その延長線で、エンジニアを起業家にする教育を施す起業家養成学校をやったらニーズはありそうな気がしたんですがどうでしょう。
最低限動くモノづくりができるというプログラミングと、より良い設計やコードといった高度なエンジニアリングとは分けて考えている、 ということ。 CEOはプログラミングはできるべき、エンジニアリングまでは必要ない、とのこと。この主張は分かりやすく共感できた。
直感的に経験からの重い言葉と理解しました。 個人的にはスクール立ち上げの経験がないので実感としてはまだ分からないですが、 恐らくスクールに参加しようと思わせるマーケティングが必要だということと理解しました。
現在少しずつ実験的に開発を進めているプログラミング教育メディアの構想は筋は悪くなさそうという感触は得られました。ただ、ターゲットとなるペルソナは今回のイベントの参加者とはちょっとズレがあるのでその点は考慮が必要で引き続きヒアリングを進める必要がありそう。
]]>ここ最近、友人から紹介されてWINGSプロジェクトという技術書執筆者のコミュニティに属して、色々と執筆を行っていたりします。 たとえば、CodeZineで「サンプルコードで学ぶRuby on Rails 5実践入門」という連載中です(もうすぐ連載終了予定ですが)。
さて本題ですが、このWINGSプロジェクトの主催者である山田祥寛さん著「Ruby on Rails 5 アプリケーションプログラミング」という技術書を献本頂いたのでレビューを書きます。
全体的にRailsの機能をまんべんなく解説しています。 たとえばDBから動的にセレクトボックスを生成するoptions_from_collection_for_selectビューヘルパーなど、かなり広範囲にカバーされている印象でした。 また、ActiveRecordのlock_versionカラムによるオプティミスティック同時実行制御についても触れられています。 さらに、フロントエンドの開発のところで、CoffeeScriptには三項演算子がないなど、CoffeeScriptの基本的な文法まで触れられているのでRubyしか触ったことがない人にとってもこれ1冊でRailsの基礎を身につけることがある程度できそうです。 あとscss -iでSCSSがインタラクティブモードで起動できるとか実は初めて知ったことも書いてありましたw
専属テクニカルライターとしてキャリアの長い山田さんならではの分かりやすい解説が特徴かと。 Rails初心者が読んでも非常に分かりやすいと思います。 また、ところどころで差し込まれている解説図が直感的に理解しやすいもので感心しました。
NOTEとしてRails5以前だとどうだったかの解説があります。 たとえばStrong Parametersの解説など、3系・4系のバージョンと絡めてRails5への理解を深める解説が散りばめられています。
右側が本文、左側の余白に様々な註釈があり、知識を補強する解説が掲載されています。 結構かゆいところに手が届く感じの註釈が多い感じで表層的な理解に留まらず背景知識も深く理解できそうです。
環境構築がWindowsとLinux両方をサポートしているのですが、Railsをガチで開発する場合結構Macで開発することが実際多いかなと。 Macでの手順の記述がないのはちょっと残念な印象です。 また、Railsも直接gemをインストールしていますが、実践的にはrbenvでRubyをインストールしてbundler経由でRailsをプロジェクトローカルにインストールすることがほとんどなので、その辺のデファクトが分かっていない人にとってはちょっと注意が必要かなと。 まぁ、そもそも上級者向けの書籍ではないのでその辺は当初から割愛しているのかな、とは思いますが。
Rails5の目玉機能の1つにAction Cableがあることはサラっと触れられているのですが、残念ながら詳細の解説がないです。 この辺はページ数の関係で省略したんでしょうか。まぁこれちゃんと説明すると結構面倒なんですよねw
個人的には網羅性と分かりやすさの観点で、初心者を脱却しつつある方が体系的にRailsを捉え直すのにちょうど良い書籍かなと。 全くの私見ですが個人的にはパーフェクトRuby on Railsより分かりやすい印象ですw
]]>最初は自分用の箇条書きとして書いてたのでちょっと読みづらいかもですがご容赦を…
CTOに限らず、ビジネスサイドと近い立ち位置で仕事しているエンジニアの方なら誰もが共感できる内容だったかなと思いました。
私自身も経験に照らし合わせて非常に共感した次第です(笑)
大切なことは異文化コミュニケーションであることを受け入れつつも、コミュニケーションを諦めないで主張すべきは主張することかなと。
また、場合によってはみずからの価値観を見直す柔軟性も必要なことだなとも思います。
ある意味政治というか、相反する部分をいかに粘り強くコミュニケーションを取って折り合いをつけるか、という点が重要ですね。
]]>参加した当日はノートPCを持っていくのを忘れていたので、スマホからひたすらtwitterで実況中継していました(笑) 備忘録的な意味も込めて、当日のtweetをtogetterまとめっぽくお届けします。
#dotsgirls 夫婦エンジニア系勉強会なう/【満席御礼☆増枠!】dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言!~ 女性エンジニアとして長く働く秘訣 ~ https://t.co/adjBw1WsRX pic.twitter.com/aPFt6UVTge
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
遠距離恋愛の参考になるのかw #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
※遠距離恋愛の参考にしたいというdots.女子部メンバーの話を受けて
6,7時に起きて1930以降に娘を迎えに行く。無認可保育園で22時夕食付き。週に1回土曜ヘルパーさんに掃除してもらってる。子供に生活リズム合わせて貰ってる感じ。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
週に1度くらいは自炊する。妻の飯はうまい #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
1930に迎えに行く。市立の保育園。仕事は自宅でも出来る感じ。最短で22時に寝室に連れて行くがなかなか寝ない。自炊は好きな方で週3,4は自宅で食べるよう努力してる。子供生まれる前は2330くらいまで仕事でコード書いてた。早く帰れないと思ったが何とかなってる #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
育休産休半年とったのがリセットになったかも。子供出来る前は昼前に出社して終電で帰るとかだった #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
子供出来る前の行きつけの店は子供出来てからは行けなくなった。ウニ、白子ポン酢の離乳食はいける #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
マネージャーになったんでコーディング以外の仕事も増えたが、それが子供出来てからは良かったかも。デバッグしてるとなかなか手を止められない #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
家事は分担してるが出来る限り家事を発生させない。ヘルパーに頼む。ヘルパーに抵抗あっても使うと便利で離れられなくなる。お試しもできるのでじっくり選べば良い。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
ルンバで自動化。だけど片付けしないと使えない。食洗機使う。メンタルコストが小さい方がやる。旦那の方が家事やってるかも。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
子供を病院に連れて行くとか分担難しい。授乳期は女性。風呂入れるのは男性とか。子育てのフェーズによって役割も変わる。病児保育使うケースも。大学の先生は暇じゃないけど休校という必殺技が #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
小学生になると大変。学童とか、週3日在宅ワークで外部サービス使うとか。出来なくなったら働き方変えるとか。保育園は凄いところ。保育園行ってるといつの間にか橋持てるとか。小学生だと急にサポートが手薄になる。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
子供欲しいから必要コストだし、投資信託を始めよう的な。スマホ買うタイミングに似てるかも。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
同業だと理解がある。実際に助けて貰える。コミュニティも広がる。パソコン見てるだけでは仕事してると思われない。twitterで公開処刑される辛み。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
英語のabstract書いて貰ったり、自宅ネットワーク調整して貰ったり。家庭内稟議が通りやすい。テクノロジーに対する不信感がない。子供手当が年収高い方に付く、拮抗してると入れ替わったり。コードレビューしたら怒ってた。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
地方移住はあまり。仕事は東京やりやすい。子育ては地方かも。教育に対する意識は東京高い。米国への移住は考えたことあり。大学の先生は地方が良いかも。2人揃って移住はタイミング難しい。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
東京はサービス充実してる。夜遅くまでお店やってるし。沖縄に子供2人いる女性でリモートワークしてる人もいる。仕事の幅は変わる。どの区を選ぶか子育てには重要。千代田、港、文京は良い。認可保育園は質が担保、コストは圧倒的に安い。無認可寛容。高いけどサービス充実 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
家でも普通に仕事してる。子供は気を引いてくるし自宅だと難しい面も。テレビ会議中も泣いてる子供が映り込んだり。youtube便利、広告スキップを1歳半で覚えた。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
※リモートワーク的な文脈での話。
2人目は厳しいかな。保育園2名同じとこ入れられないとか。周り見てると2人いると大変。発熱が交互に来るので休みがちに。俺が俺がな30歳頃だと厳しい感じかも。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
生まれる3ヶ月前に休んで3ヶ月で復帰。旦那は1週間育休取った。産休入ってすぐ生まれた、6ヶ月育休。旦那は転職したてて育休取れず。保育園行けるかは死活問題だが分断がある。Googleは男性もほとんど1ヶ月育休取る。 #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
成長の過程をnohanaで子供の写真を両親に共有。60歳になってもコーディング出来るの示す。妻が偉くなって。プログラマの多様性が低いのが謎。偉くなること。子育てでも謎な性差別が多い。当たり前が当たり前になる世の中。子育ては男性が言うと受け止められ方が違う #dotsgirls
— Tsutomu Chikuba (@tchikuba) 2016年3月24日
オサレなケータリング
竹馬 力さんの投稿 2016年3月24日
本日はwomen techmakers様にスポンサードして頂いております!この後は懇親会♡ #dotsgirls pic.twitter.com/2D1w15ZvN6
— dots. 女子部 - 公式アカウント (@dotsgirls) 2016年3月24日
女性向けの話を男性に聞いてほしいってのはとてもわかる。今日参加者に結構多いのはとても嬉しいし、まじでパネラーの旦那様お二方が素晴らしいし、本当にビデオ撮って見せつければ良かったって後悔してる。 #dotsgirls
— ちゃんとく (@tokutoku393) 2016年3月24日
今日は貴重なお話をありがとうございました!私の彼氏がすごい楽しんでました。参加して良かった«٩(*´ ꒳ `*)۶» #dotsgirls
— なほ (@LaurierPetit) 2016年3月24日
今日楽しかった〜〜。なんか漠然とした不安はいつでもありますって言われて、その言葉になんか安心した。#dotsgirls
— りほ (@rllllho) 2016年3月24日
帰宅! 楽しかったです、ありがとうございました。最後の皆さんの感想が割とみんな「(二組とも)いい旦那様だな〜と思いました」だったのがちょっと受けたw #dotsgirls
— Kinuko Yasuda (@kinu) 2016年3月24日
勉強会に参加して感じたことです。 同業だと問題もあるという話を聞いたりもしますが、ふたりともエンジニアである場合、メリットばかりが目についてデメリットってほとんど思いつかないです。 テクノロジーへの理解があるという点、非常に共感しました。新しい製品を買ったりするのに家庭内稟議は圧倒的に通りやすいんじゃないかとw
あと、今回登壇されたご夫婦2組とも、男性の優秀さもさることながら、女性の優秀さが凄いなと感じました。 なのでプログラマである私の妻にも、このご夫婦に見習って凄くなってもらおうと思います(笑)
私は日頃から、ダイバーシティの観点から、あらゆる組織は男女比率がおよそ半々である方が良いと考えています。 しかしながら現時点では、特にエンジニアの世界では圧倒的に男性比率が高い状況があります。
たとえば、10代、20代の女性をターゲットにしたwebサービス開発エンジニアは全員男性で、女性が1人もいない、などのケースも比較的よく耳にします。 中長期的に続くことが前提のサービスにあって、手を動かすエンジニアがdog foodingできることは、成功する確率を高める最も大きな要因の1つだと思います。 その意味では、女性向けのwebサービスであれば女性エンジニアが手を動かした方が、より良いサービスを創ることができるのではないでしょうか。
今後もしエンジニアのチームを構成することがあるとすれば、できる限り男女比率を半々になるようにやっていきたいと改めて決意した次第です!
]]>私は現在IESHIL(イエシル)という中古マンション価格査定サイトのエンジニアやってます。 担当は雑用係です。 リブセンスに入社して約2年半ですがリブセンスでwebサービスの自社開発の文脈に身を置いて色々思うところがあるのでその辺をちょっと言語化してみます。
私はエンジニアになったのが2004年8月でした。 7年間フリーランスのエンジニアとしてお客さんのところに常駐して作業するという形で、所謂社畜フリーランスでした。 前半4年間は大手SIer、後半3年間はエンタメ系事業会社に常駐していました。
前半の4年間では小さいプロジェクトだったこともあり、ウォーターフォールで言うところの要件定義、基本設計、詳細設計、実装、テスト設計、 単体テスト、結合テスト、受入テスト、リリースなどソフトウェア開発の全工程を担当してエンジニアとしての基礎力を身に着けた時期でした。
後半の3年間では所謂「ステークホルダーと調整して設計書を書くSE」「ベンダーコントロールPM」的な立ち位置で 主に自分が手を動かさず人に手を動かしてもらう為の環境整備的なことをやっていました。 今思い返すと、この時期に所謂プロジェクトマネジメント的なところの基礎力を身に着けた時期だったと思います。
そうこうしているうちにより大きなやりがいと責任ある立場でやれる仕事をしたいと思い、新規事業のプレイングマネージャー的なポジションを探していたところ あの2011年3月11日が来て、人生短いんだからやりたいと思ったことをやるべきだと踏ん切りがついて前職となるPR会社の新規事業の開発マネージャーとして転職しました。 この時期に要求仕様の変化が激しい新規事業、所謂スタートアップ的な文脈ではウォーターフォール型の開発の行き詰まりを実感し、 アジャイルやリーンな開発(技術開発だけでなく事業開発含め)の手法を模索し貴重な経験をした時期でした。
開発マネージャーとして約2年間働いた後、現職のリブセンスに転職をして現在に至ります。 リブセンスでの強烈なエンジニア文化の中で、エンジニア含めた事業に関わる全ての人が効率の良さと気持ちの良さをどうやったら追求出来るかを最近良く考えます。
自分のキャリアを振り返ってみると受託開発が主であるSIerから徐々に自社サービスを展開する事業会社へとシフトして行ったことになります。 私のキャリアの文脈が徐々にシフトしたのは単なる偶然な気がしますが、この経験があるからこそなのか、最近良く考えていることがあります。 それは、ビジネスとエンジニアリングは一体不可分であるということです。
ある意味これは最早当たり前の時代になってきたんだと思われますが、私が10年前にいたSIerの文脈だと実感として結構違っていました。 あくまでも受託開発では発注側のお客様がいて請負契約に基づいて予め定義したシステムを納品することが目的です。 出来上がったシステムがお客様が使ってみた結果、それがビジネス上価値を生み出すか否かは短期的には関係がありませんでした。
しかし事業が社内にあり内製出来るエンジニアチームを持っている文脈では事情が異なります。 当然ですが開発を行った結果ビジネス上無価値なものを作ってしまったとしたら基本的にその当事者が作り直す必要があります。 開発と運用が一体となっている文脈では、要件の変化に伴い柔軟にシステムを変更する必要がありまたそれに耐え得る品質を ソースコード上の保守性、DDD(ドメイン駆動設計)等を用いたビジネスドメイン設計、CI等で担保する必要があります。
これまでの私の経験上、感じていることをまとめると以下の様な図になる気がしています。
発注者と受託者という関係では、前者から後者へ金銭的な授受が行われる為、ビジネスパートナーといえど、構造上どうしても主従関係のような強弱がついてしまいます。 当然上手く行っている受託開発も存在しますが、経験上上手く行かないパターンを見ることが少なからずありました。
※ただ最近は一括請負契約の構造上の問題を解決する受託開発の手法の1つとして「納品のない受託開発」 を手掛けるソニックガーデンさんの事例は注目したいところです。
上記の図に表現した通り、時代の変遷と共にエンジニアリングの比重を相対的に大きくしていますが、これも実感としてあるところです。 昨今のビジネスにおいては「如何にビジネス上の営みをシステムに落とし込むか」という点の比重が徐々に拡大している気がします。 当然ながらビジネス上のシステム化とは、エンジニアリングの観点でのシステム化だけではなく、機械的に出来ることと出来ないことを選別した上で 人手でどこまで行うのか、人をどう配置するのか、関わる人に要求される職能は等、多岐にわたります。 しかしながらそれらの人が業務上関わる場所に全てシステムが介在することもまた事実であり、その範囲は時代を追うごとに拡大していると思うのです。
もっと言えばビジネスに近接する立場にある非エンジニアの日頃の業務にこそ、効率化の余地があることが多いとも感じます。 余談ですが最近日経の記事にコーディング・ブートキャンプの話がありました。
これはマジその通り。特に非エンジニア領域での需要があると実感してる/米で進む大学離れブートキャンプでITの即戦力|日経カレッジカフェ via #Kamelio https://t.co/AsAnCWjYXE
— Tsutomu Chikuba (@tchikuba) 2015, 12月 2
この記事から類推するに、非エンジニアが何らかのビジネス上の課題解決の為にコーディングを勉強する需要があるんじゃないかと思います。
いずれにしても現時点で痛感していることをまとめると、 ビジネス上1つのプロセスでしかなかったシステム化が、ビジネス上最も重要なプロセスの1つとなり、その後、ビジネスと一体化しつつある ということです。
これらのことは既に各方面の偉い人が唱えていることで、理論上は当たり前だと思うのですが、これを経験上私が感じれていることに スティーブ・ジョブズ曰くのconnecting the dotsを感じてちょっぴり嬉しいのです。 頭で理解したことと体験で会得したものでは実は雲泥の差だなと思いますので。
connecting the dotsのリンク先の記事に曰く、
点と点を繋げるということは、あらかじめ仕込むことは出来ないということです。 しかし、振り返ってみると「あの時のことが役立った」とか、「あそこで出会った人に、こんなタイミングで助けられた」といったことって意外とあるものなんですよね。
とあります。
私も自分の経験を振り返ってみて思うのですが、その通りだなと。 これ実はある意味「システム思考」だな、ということを最近しみじみ感じます。 少なくとも予め仕込むことは出来ないという点においては、ゴール思考とは遠い気がします。
私実は11年間エンジニアやる前、1年くらい超ブラック企業と言われた某営業会社で営業をしていた時期が(一応)ありました。 この企業が物凄い体育会系ノリだったのと超絶ゴール思考的で理系出身だった私には全く考え方が合わず辛い思いをした苦い経験でした。 既に亡くなった(笑)会社でもう時効だから書いちゃいますけど、当時の上司から2回辞表書けって言われて書いたりして(笑) 1回目の辞表なんて「まだ辞めたくないけど上司に辞表書けって言われたので辞表書きました」という内容の辞表だったりして(笑)
今でこそ笑い話ですが、この経験が実は比較的ネガティブな原体験として、極端なゴール思考では歪みが生まれて持続可能な発展でなくなる ということが自分の中に焼き付きました。その後も若干紆余曲折あったんですが、この体験が元になってエンジニアリングを1から勉強してエンジニアになろうと思えました。 当然ながらこの時はシステム思考なんて言葉も知る由もないんですが、振り返ってみれば、目の前の課題解決を積み重ねるアプローチを欲していたんだと思います。
また、実はゴール思考も適切な範囲であればモチベーションコントロールとして有効であることも体験していることも重要です。 システム思考だけだとビジネス上実現したいビジョン等から外れてしまっても暫く気付かないケースがあるように思います。 個人的にはゴール思考とシステム思考の融合を目指したいと考えています。私の体験上でもそれは理に適っていると思われるのです。
このような文脈にあってもう1つ私の中で良く考えることがあります。それはクリエイティブな組織の在り方についてです。 私はその1つの解としてホラクラシー型組織の構築があるのではないか?と考えています。 ホラクラシーとは、マネージャーの存在しないセルフ・マネジメント型組織のことで、ザッポスが導入したことで有名です。
最近のハーバード・ビジネス・レビューにホラクラシーに関する記事がありました。
ホラクラシーに懐疑的な視点。確かに現状の組織形態では合わない場面もあると思うけどクリエイティブな仕事は移行出来ると思う/管理職を置かない組織が理想なのか? 導入前に自問すべき4つの質問 https://t.co/YY3L0RCtGn @dhbr_japanさんから
— Tsutomu Chikuba (@tchikuba) 2015, 12月 3
この記事に曰く、
ホラクラシーの大部分は、優れたマネジメントによく見られる要素を単に体系化していると気づいた。 ホラクラシーの導入にまつわる細部にとらわれず、それが何に対処するためのものなのかを掘り下げて考えれば、見えてくることがある。 問題は、ヒエラルキーそのものがいかに正当性を失ったかではなく、速まっている世の中の動向に対してヒエラルキーでは動きが遅れることなのだ。
とあります。
確かにヒエラルキー型組織で優れたマネージャーは、出来るだけ現場に裁量を与えて信頼し、問題が発生した場合だけ出来るだけ迅速に対応し 問題の責任を取るタイプが多い気がします。極論、成功は部下の功績とし、失敗は上司(自分)の責任とするタイプですね。 まぁ体験的には大体ヒエラルキー型組織だと中間管理職層は人間が腐っていく例を良く見てきた気がしますが(笑) 私が開発マネージャーだった際にこういう優れたマネージャー像を目指して奮闘してましたが、理想像からは程遠い感じだったような気がします(汗)
いずれにしてもスピード感を持って変化に対して対応していく為には現場でコトに当たっている当人が誰かに判断を仰ぐことなく 自分の判断で臨機応変に行動することが出来てしかもその判断が正当であれば(結果がどうあれ)最も正しいと思います。 まぁ逆に振り返って判断が正当でないように第三者からは見えても、結果がマズい方向ではなく良い方向であればヨシとすることもあるかもしれません。
私は、クリエイティブな仕事に携わる人々が関わる組織が今のところ最も上手く行く方法論としてホラクラシーを捉えています。 逆に1ヶ月ほど前にバズってた、CIAのスパイマニュアルの記事がヒエラルキーの問題点を端的に表していると思いました。
これは必見。まぁ組織が成熟してくるとこうなりがちなんだろうけど/CIAのスパイマニュアルに学ぶ「会社をダメにする11の行動様式」 https://t.co/RcLV7aNegb
— Tsutomu Chikuba (@tchikuba) 2015, 11月 5
曰く、
会社内での組織的位置付けにこだわる。 これからしようとすることが、本当にその組織の権限内なのか、より上層部の決断を仰がなくてよいのか、といった疑問点を常に指摘する
これとかまさに先ほど書いた現場の臨機応変な判断を阻害する真逆の論理で一見正当性が見えるので厄介なんですよね(苦笑)
ちょっとここまで書いた所で息切れしてきましたが(笑)そろそろ結論めいたことを書きたいと思います。 結局のところ私の体験という文脈の中でしか実感を持って判断出来ないと思っていまして、その意味では至極主観的極まりない話だということが前提ですが。 現時点での私の文脈(コンテキスト)では、これら一見相反するように見えるものが実は一体不可分である、ということです。
まず、ビジネス上使われる一部に過ぎなかったエンジニアリングが、経営の中心となりつつあります。 次に、極端なゴール思考の行き詰まりや矛盾から、持続可能な発展を考慮したゴール思考によるビジョンに基づいたシステム思考の重要性に気付きました。 最後に、ヒエラルキー型組織の矛盾の中でキラリと光るマネージャーを垣間見たり、理想像目指して奮闘したりするも、 マネージャーとなってコードを書かなくなったらエンジニアとして終わりなんじゃないかと自問自答して、 私自身の手でエンジニアのホラクラシー型組織を実現したいと夢見て現実と奮闘していたりします。
私の体験としては実は予期せず元いたコンテキストがあったからこそ、気付きを得たと言えますし、 対立しているように書いたことも実は存在意義が多分にあり一体不可分なのだと思えるのです。 これを代弁する考え方に仏教の用語で「不二(ふに)」という言葉があります。
曰く、
対立していて二元的に見える事柄も、絶対的な立場から見ると対立がなく一つのものであるということ。
前述のような見方が絶対的な立場か否かは分かりません。
ただ、ヒエラルキー型組織でウォーターフォール型開発を一通り経験出来たからこそ、その長短を体得することができたのだと思います。 ビジネスと遠いところで開発をしていたからこそ、ビジネスに近接するところで開発する際の違いを痛感し開発プロセスを多少なりとも改善してきました。 そもそもホラクラシー型組織を上手く回す為にはセルフ・マネジメントが出来る優秀なメンバーのみで組織を構成する必要がありそうです。 職能的にジュニアクラスのメンバーは一向に力を発揮出来ないことになりそうですが、敢えてヒエラルキー型組織で力を付けるという選択肢もあるかもしれません。
これらを踏まえた上で、私自身の経験に即して、これからの時代以下のような流れになっていくのかなと考えています。
私自身はこれまでの経験を踏まえてやりたいことが比較的明確になりつつあるのですが、 キーワードはITと新規事業と教育ということで一応一貫しているつもりなのでこの方向性は常に持ちつつ、 これまでのエンジニアとしての技術的な方向性から、更にビジネス・経営的な方向性で社会貢献出来る人材になろうと決意しています!
この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。
#dotsgirls #eventdots ハロウィン仕様の女子エンジニアたち pic.twitter.com/d5IIPxpf2o
— Tsutomu Chikuba (@tchikuba) 2015, 10月 31
※リアルタイム更新してました!
お次は矢倉さんによるPromiseのお話! #eventdots #dotsgirls pic.twitter.com/kRmQIKpQiY
— dots. 女子部 – 公式アカウント (@dotsgirls) 2015, 10月 31
pixiv川田さんによる『ECMAscript6 arrows & classes』です!ガチャピンがすごいお似合いです! #eventdots #dotsgirls pic.twitter.com/1J9rSXJe5j
— dots. 女子部 – 公式アカウント (@dotsgirls) 2015, 10月 31
Javascriptの祖先図!初めて知りました! #eventdots #dotsgirls pic.twitter.com/VH1pY4EGYa
— dots. 女子部 – 公式アカウント (@dotsgirls) 2015, 10月 31
※リアルタイム更新してました!
ビッグデータの分析技術とヨミウリ・オンラインの記事を使った「Jubatusハッカソン with 読売新聞」。優勝したのは、どんなアイデアだったでしょう?
http://t.co/euayPP6mU0 pic.twitter.com/BbQxG2Vkc7
— 読売新聞YOL (@Yomiuri_Online) 2015, 8月 25
ちょっと遅くなってしまいましたが参加レポートをば。
Jubatusは「ユバタス」と読み、Preferred Networksと NTTソフトウェアイノベーションセンタが開発した オンライン機械学習向け分散処理フレームワークです。 ※公式HPの受け売りですが(笑)
今回のハッカソンはピンで参加したのでその場で即興でチームビルディングしました。 以前から知人で選挙ドットコムCTOの佐藤さん 率いるチームで「2030年の日本の首相を予測する」というチャレンジング?(笑)なテーマに挑戦しました。 大枠やったことを書くと、1985年時点での各政治家の当選回数、世襲か否か、得票数、選挙区の都市などを説明変数として 2000年の閣僚経験数が一番多い政治家=首相を推定する 回帰モデルを5年毎に作って2015年時点から2030年を推定する、という感じです。 説明変数のデータは主にwebクロールしてきたものを利用しました。
私の担当は前回参加したハッカソン同様、この辺のクロール周りだったんですが やはり時間がかかって思ったより大変でした。(前処理大事) 収穫としてはDBpediaの存在を知ったことです。 SPARQLというSQLライクな言語でデータの関係性を含めてデータ取得出来ます。 例えば安倍晋三だとprop-ja:内閣を参照すると閣僚経験数が分かります。 ※SPARQLって難解で使いづらいんですがw
で、肝心の結果なんですがこれが面白かった(笑) 以下、首相に最も近い順の予測結果です。
ホントはチームメンバーみんなで「小泉進次郎」とか期待してたんですが全くかすりもせず(笑) 1位の亀井静香は2030年には94歳だし(笑) ちょっと悔いが残ったのはJubatusのオンライン機械学習の良さを全く活かせてなかったりwebインタフェースがなかった辺りでした。 ただ今回のようにかなり具体的なデータで機械学習を応用すると話題としては面白いものが出来るなぁということが改めて実感出来たのは収穫でした。
以下は発表会の様子です。
jubatusハッカソンwith読売新聞の発表会なう #jubatus_hackathon pic.twitter.com/dP0cSD5In8
— Tsutomu Chikuba (@tchikuba) 2015, 8月 23
発表会はどなたもかなりガチの内容で非常に刺激を受けました。 その中でも特に印象に残っていたのがドワンゴの小田桐さんの発表でした。 ニコニコ動画のコメントをChainerによるディープラーニングでカテゴライズや次のコメントを予測する、 みたいなことをやってそのモデルをtwitterに応用しても結構使えるよね、という内容でした。 スライドが公開されていないかググってみたんですがちょっと見当たらず残念ですが・・・
ちなみにこのChainerもJubatusを開発したPreferred Networksが開発したディープラーニングフレームワークです。
同じチームメンバーの方がまとめたQiita記事が分かりやすいです。 自然言語処理を行う際に避けて通れない前処理が機能としてJubatusに備わっているので便利ですね。
オンライン機械学習はJubatusの最大の特徴とされています。「機械」を省略して「オンライン学習」とも呼ばれます。 オンライン学習について分かりやすい解説は以下のNTTデータの記事です。
以下の記述がオンライン学習について端的に言い表しています。
オンライン学習は機械学習モデルにおける学習アルゴリズムの1つであり、データを1つずつ読み込んでモデル更新を繰り返すことで学習を行う手法です。反対に、データを全て読み込んでから学習する手法をバッチ学習と呼びます。
バッチ学習のデメリットとオンライン学習のメリットについては以下の記述が分かりやすいです。
通常、機械学習で作成したモデルは運用していくうちに徐々に精度が低下するため、モデルの精度維持のためには定期的に新たなデータを加えたモデル更新が必要となります。この時、バッチ学習では過去のデータと新しいデータを合わせてモデルを1から作り直す必要があり、多くの計算時間が必要になります。オンライン学習を用いれば、新たなデータのみを既存のモデルに取り込む逐次更新が可能になるため、モデルの精度維持がわずかな時間で可能になります。これを推し進めて、発生したデータをその場でモデルに反映すれば、モデルの精度低下を意識する必要すらなくなります。
このオンライン学習が迷惑メール判定ロジックに利用されていることを考えるとオンラインであることのメリットが分かりやすいですね。 常に迷惑メールの対象は増えていくのでバッチ学習で学習したモデルを運用してもすぐにそのモデルは古いものになってしまって 新しい迷惑メールを判定出来ないことになってしまいますよね。 そういう意味で特に変化の早いビジネス上では、IoTの絡みも相まってオンライン学習は今後拡大していくだろうと思います。
私自身、機械学習周りのインプットをし始めたのはここ半年くらいです。 インプットを初めて痛感するのは、統計学、機械学習、人工知能などの情報をググっても断片的な知識ばかりであまり体系的にまとまっていないので 初学者が体系的に知識をカテゴライズすることの難易度が高いという点でした。 体系的に知識を学ぶにはネットで楽しないでちゃんと本読めよ、というのが王道ではあるのですが、、 そう言っては身も蓋もないので何か良い方法はないかなと。
そこで個人的に最近良くお世話になっている銀座で働くデータサイエンティストのブログを書かれている Takashi J. OZAKIさんの以下の記事がオススメです。
ここで出てくる「落下傘方式」とは
「必要になった時に必要な項目だけ学び、覚えたらとにかく実践してみる」
という定義だそうですが、この勉強法はwebエンジニアとの親和性が高いんじゃないかと思います。 ググッたらちょっと古い「Rubyのパパ」ことmatzの記事がヒットしました。OSSのコードを読む場合の戦略の一つとして紹介されてました。
特に私の場合は機械学習アルゴリズムそのものを研究する訳ではなく、既に確立された機械学習アルゴリズムを利用するユーザーの立場なので、 実際にJubatusを触ってみたりpythonの機械学習ライブラリのpandasやscikit-learnを 実データで利用してみた方が理解が進んでいる気がします。
(当選時の喜びの声)
ハッカソン当選通知キタ━(゚∀゚)━!/【人工知能】ハッカソン <UBIC×Samurai>〜益々盛り上がる人工知能技術を活用したサー… (開催日時:2015/05/23 11:00 ~ 2015/05/24 19:00) http://t.co/DYe6f2CGpe
— Tsutomu Chikuba (@tchikuba) 2015, 5月 15
若手エンジニアが人工知能のビジネス活用を競うハッカソン - 最優秀賞は? - マイナビニュース: マイナビニュース 若手エンジニアが人工知能のビジネス活用を競うハッカソン -… http://t.co/Qv53xo0f9o pic.twitter.com/DhmPIm5QiC
— ビジネスソース JP (@BizSourceJP) 2015, 5月 26
1日目前半にアイディアソンやって1日目後半、2日目に開発をやるというガチなハッカソン自体、 初参加でしたので良い経験になりました。今回のハッカソンでは基本ハスラー、ハッカー、デザイナの3つの役割の人が各チームに均等に割り振られるルールのようでした。 私がいたチームはハスラー2名、ハッカー3名(サーバサイドエンジニア2名、インフラエンジニア1名)な構成でした。 やはりデザイナかフロントエンドエンジニアがいないとプロダクトの見栄えが・・・な感じでした。。
ネタとしてはうちのチームでは「みんなのカイシャ(仮)」というタイトルで開発を行いました。 過去の判例の情報解析を手掛けるUBICさんが用意した自然言語処理系の人工知能APIを使って 選択肢に企業理念を候補として出力して選択していくと企業理念が似通った企業を推薦してくれるというものです。 クローラによるデータの収集や前処理に時間をかけすぎて肝心の人工知能APIバックエンドの実装が中途半端だったのが悔やまれました。
(2日目の成果発表の様子)
人工知能ハッカソン、成果発表中。1チーム目から面白い! #AIhack pic.twitter.com/jvUVYxOpBU
— サムライインキュベート両角 (@ryokado) 2015, 5月 24
以下の通り、優勝したのはダイエット家庭教師等を手掛けるFiNCのインターンの方がいたチームでした。
《人工知能ハッカソンにてFiNCのインター生が優勝しました!》
5月23日と24日の両日にわたり、株式会社サムライインキュベートとUBICが開催した人工知能ハッカソンに、FiNCのインターン生や社員が参加してきました!… http://t.co/upOrpdQUNF
— 玉野井桐子 (@tamanoifinc) 2015, 5月 27
参加して思ったのはハッカソンは(アイディア出しよりは)開発メインでテック寄りな方が良いかなという点です。 アイディア出しに注力するならハッカソンじゃなくてアイディアソンとして別枠でやった方が時間的な制約で中途半端にならずに良いかなと思います。 開催する側のメリットとしても2点あると思っていて、1点目はAPI提供側が開発時にストレスなく組み込めるか温度感を見る点、 2点目は提供したAPIが具体的な課題解決にどのように応用されるかアイディアの幅を見る点。 この2点の検証が盛り込まれた今回のハッカソンだったと思うのですが、提供されたAPIがシンプル過ぎてちょっと拍子抜けした参加者もいたようで 両方の検証がUBICさん的に十分に出来たのかはちょっと疑問が残る内容だったかもしれません。
ところで今回のハッカソンのメンターがトレタ増井雄一郎さんと 東京大学准教授の松尾豊さんだったのも参加理由の一つでした。 増井さんのお話を1年前のデブサミ2014で聞いたことがあり、 スタートアップ的な考え方からのツッコミが聞けそうだなと思っていたところ まさに想像通りのフィードバックがあってその視点が非常に参考になりました。
また、松尾豊さんは人工知能の専門家で 人工知能は人間を超えるか (角川EPUB選書) という有名な本の著者だということを知っており一度お会いしてみたかった方でした。 (この書籍は後日読んで興味深かったので次回のブログ記事のネタで書こうかと思います) ハッカソンの中間と発表時にチームへのフィードバックをいただいたのと、ハッカソン終了後にご挨拶して 日頃の興味関心事等について色々意見交換が出来たのは収穫でした。
ハッカソンで実際に何を作るのかという以上に、ハッカソンのテーマ(今回なら人工知能)に興味関心が近い人と繋がれる、 という意味でハッカソンに参加することは有意義だなと思いました。 初日にハスラー2名と私の3人で飲みに行って意見交換したんですが、参加者やメンターの方と直接会って意見交換するのは貴重な時間だと思います。 私は常日頃人が会うことで生じる「場のエネルギー」を信じているところがあり(別にオカルトという訳ではなく) 共通の指向性を持った人同士が出会う場としては相当良い場ですね。
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
上記の通りqueryメソッドの第5引数にoptsというハッシュで指定するオプションがあり、
type: :presto
な指定をするとHiveではなくPrestoでクエリが発行されます。
以下、rakeタスクでのサンプルコードです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
1
|
|
1
|
|
上記のように単純なクエリの場合、Hiveだとパフォーマンス的にwebアプリ等から動的に取得するのが 現実的に時間がかかりすぎたクエリでもPrestoであれば動的にデータ取得可能なので利用の幅が広がりますね。
私はちょっと前にこのブログ記事を読んで凄い共感しました。 記事のコメント欄を読むと比較的肯定的な意見が多いようです。 一方、はてブのコメントだとかなり批判的な意見が多いように思います。 コメントも合わせて読んで色々思うところがあったのでちょっと自分としての考えをブログにまとめておこうと思いました。
個人的には自分が正しいと思う価値観や信念に素直になって自分の仕事を選んで行こう。 何も規模や効率化だけを選ばなくても食べていける選択肢はある、って解釈しました。
これは秀逸なエントリ!めちゃくちゃ共感。スモールビジネスに注目しているが端的にこれはスモールビジネスの話だと思う/僕がアクセンチュアを辞めた理由 - 元外資系コンサルタントがなぜ鎌倉で自給的生活をはじめたか? http://t.co/wqOQQwWblQ
— Tsutomu Chikuba (@tchikuba) 2015, 3月 29
この記事の方に対する嫉妬が邪魔するのか、単に価値観が違うのか、理解できない向きもあるようで、 それが個人的には不思議だったんですよね。一般的には好きなことを仕事に出来ていない人が想像より多いのかな?と。 そこでちょっと好きなことを仕事にするという切り口で色々な考え方を調べてみることにしました。
好きなことを仕事にしたい
でもそんなのひと握りどころかひとつまみくらいの人しかできないんだろな
— きょろすけ (@Kyonnnncy) 2015, 4月 21
自分の好きなことを仕事にしたい!とか言う人いる。それは素敵だと思う。でも、その考え方を人に押し付けたり、見せつけないで!
— 百姓の奇妙な冒険 (@hyakusho_T) 2015, 4月 21
好きなことを仕事にしていっぱいいっぱいになるよや勤務時間最適な地味な仕事か…まだまだいくつか面接予定詰め込もう。
— S.SHIZUKA (@Jeshikasan) 2015, 4月 21
やっぱり好きなことを仕事にできたら最高だよね!
そのために辛いことも楽しいこともあるけど、頑張って学校通わなきゃ!
— エリー@AAA真駒内 (@AAA_Eri101) 2015, 4月 21
「好きなことを仕事にすれば、 二度と仕事をしているとは感じないだろう。 byエルビス・プレスリー」 その通りだね!!仕事をしたくてしたくてたまらなくなるんだ!!そして本当に良い仕事ができる☆
— 伊藤元二@人生を幸せに生きる秘訣 (@motoito) 2015, 4月 21
将来好きなことを仕事に出来たら一番幸せな訳だと個人的に思う訳で、という訳で叶う叶わないはひとまず置いといて自分の好きなことで職に就くことを夢にしてる人には何処に就職目標立てればいいのかその為にどうすればいいのか悩む会を作りたいねって寝言言って寝る(ृ ु *`ω、)ु ⋆゜
— 菜織@眠い (@naori_knvl) 2015, 4月 20
上記の通り色々意見がありますが、職業を選択するときははなんだかんだ言って好きか、 好きになれそうかを基準にした方がこれからの時代にはマッチしていると改めて思いました。 で一度選択したら多少何があっても好きになれるまで修行だと思って踏ん張ってみて、 その仕事を好きになって自他共に認められるようになったら次のステージを検討しても良いのかなと。
あと学生を卒業したばかりの新社会人や第二新卒などのジュニアクラスの人は修行だと思って、 選択した仕事を好きになる為に一定の努力をするのは必要ってことでしょう。 といっても所謂ブラック企業でただひたむきに働き続けるのはブラック企業に加担することになってしまうので良くないので、 そういうケースに該当するかも?って思ったら経験豊富な人に相談した方が良いですけどね。
一番重要なのは、好きな仕事でどうやったら継続的に稼げる(少なくとも食っていける)ようになるかを 真剣に考えて行動していくということ。 そして個人的にはよりクリエイティブな仕事を選択すると好きな仕事で継続的に稼げる可能性が高いと思っています。 好きな仕事って1つじゃない可能性もあるので、もし色々好きになれそうで1つに絞れないって人は よりクリエイティブな仕事を選択すると幸せになれると思います。
]]>FIBC2015 金融イノベーション ビジネス カンファレンス。金融サービス関連のピッチが熱く面白い。テーマゆえか、スーツ姿だらけのイベントでびっくり。 http://t.co/XToGJN8Hy5
— 中嶋文彦 (@monfumi) 2015, 2月 26
あと、いつも参加するイベントに比べて50-60代くらいのおじさまがいるのも新鮮でした。
FIBC2015のスケジュール #FIBC pic.twitter.com/vv0piHwg6K
— Tsutomu Chikuba (@tchikuba) 2015, 2月 26
ただいま開催中のFIBC、Moneytreeよりポールのプレゼンテーションがはじまりました!#FIBC2015 pic.twitter.com/H6NJaWtR5j
— Moneytree (@moneytreejp) 2015, 2月 26
FIBC2015でピッチに立つCoinCheckの和田さん。#ビットコイン の特徴からサービス展開まで7分という短い時間に良くまとめられてました! #bitcoin pic.twitter.com/RdygzTpO04
— caicaikiki (@caicaikiki) 2015, 2月 26
ここまでで1部完了
あすかぶの林氏はプレゼンが上手すぎる。その点だけは間違いなく神がかりだな。 #FIBC2015
— JAXA生まれ慶應育ち (@geojackass) 2015, 2月 26
これで2部完了
これからキーノートスピーチ pic.twitter.com/wbSO2E59Za
— Tsutomu Chikuba (@tchikuba) 2015, 2月 26
FIBC2015のキーノートスピーチに登壇しているシンクタンク・ソフィアバンクの藤沢氏の講演が深い。金融とは何か。考えさせられる。 #FIBC
— Tsutomu Chikuba (@tchikuba) 2015, 2月 26
この後、ネットワーキングの時間がありました。 ピッチ登壇者がブースを出し、軽食をつまみまながら登壇者と参加者が交流するという形式でした。 個人的にも非常に刺激的な時間を過ごすことが出来て楽しかった!
先日参加したFIBCの記事/金融イノベーションビジネスカンファレンス(FIBC)開催、大賞に選ばれたのは…(ZUU online) - Yahoo!ニュース http://t.co/Dusk1md15C
— Tsutomu Chikuba (@tchikuba) 2015, 3月 2
]]>まず本題に入る前にこの記事を読んだ人の感想をピックアップしてみます。
このサービスでこんなにお金もらえるのか。アメリカいいな。
ちなみにこの投稿もBufferのスケジュール投稿
http://t.co/WMMd5CHmpq
— 児玉秋二 (@robox0917) 2015, 1月 22
こういう捉え方はちょっと寂しいような気もしますが、私はむしろこの規模の企業の社長としては貰ってない方だなと率直に思いました。 と同時に従業員の平均給与はそこそこ良いのかなとも思います。 ビジネスは仕組み作りなので、Bufferはそれが着実に出来ているということなんじゃないでしょうか。
最後の方にある、利用していないサービス料金は返すというところに、この会社の考え方が表れててとてもよいね。 / CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ
http://t.co/joq14GpO6O #NewsPicks
— ジョン (@yori102) 2015, 1月 22
この意見は私もその通りだなと思いました。これからは資本主義で競争するのではなく人道主義で競争する時代になっているのだと確信します。 インターネットが普及したことで物事がオープンになり、資本主義の為に多少なりとも人道主義を犠牲にすることが出来ない程、衆人監視の目が光っているのだと思います。
この記事、面白いな。特に組織体系。CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ | HRナビ http://t.co/bjdje6TB69
— NPO法人D×P 今井紀明(共同代表) (@NoriakiImai) 2015, 1月 22
Bufferの透明感あるマネジメントスタイル個人的に好き。途中に出てくる組織論の変遷についても勉強になった>CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ http://t.co/483OHswpbC
— Akihisa Ishikawa (@a_ishikawa) 2015, 1月 22
組織をデザインするってほんとにおもろい。うちは今二人だけど、いつかもう少し大きなチームにしたいなと思ってる。 / “CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ | HRナビ” http://t.co/QHK1KNPlwq
— Hikari Mimura (@picacch) 2015, 1月 22
ホントそうですよね!記事では自律分散型の組織運営としてフレデリック・ラルーの講演内容から引用して紹介していますね。 このフレデリック・ラルー(Frederic Laloux)という人、カタカナでググっても全然情報出てこないんですが、 Reinventing Organizationsという本の著者のようです。
直訳すると再発明組織ですね。まさにこのブログ記事のテーマ。
居住地によって給与が変わるのは良いと思う。肩書きもいらない、けど日本はなくしたところで見えない肩書きみたいなのが残りそう。 CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ | HRナビ http://t.co/CbKdGJg8iq
— Toru Maseguchi (@toru) 2015, 1月 22
「肩書きがアイデンティティになってしまう」これなぁ。特に日本人は規律を重んじて、期待に応えようとするからその傾向が強い。 / CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く…
http://t.co/p5wWR9ppQm #NewsPicks
— (ぼn^ω^nん) (@vonvovon) 2015, 1月 22
確かにBufferはグローバル企業で日本に閉じた場合に上手く行くかは必ず議論として出るところかと思うのですが、 ここはむしろ日本でも組織のイノベーションの波からは逃れられないと思います。実感値として。
これは興味深い同時に面白い
CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ
HRナビ http://t.co/2Iw9H7UICT
— コーヒー屋 (@coffea_canephor) 2015, 1月 22
世界で大切にしたい会社ベスト23 Buffer、尊敬する現役経営者の一人ジョエル。すべての経営者に読んでほしい。見ている世界が違う。
— Ken@世界23周の旅 (@u23ken) 2015, 1月 22
Kaizen PlatformのUSオフィスとBufferが同じビルってのはへぇ×2でしたw
このようにざっとSNSから声を市況かぶ全力2階建てばりに並べてみましたけど概ね好意的な意見が多かったように思います。 中には少数ながら給料公開とかダメでしょって見解の方もいましたが。 そしてやはり給料のことよりも組織論の部分に感じ入る方が多かったんじゃないかなと。
んで、このHRナビの記事読んで思い出したのが、私が常日頃書き溜めていた「もし自分が起業するなら」というタイトルのgoogleスプレッドシート。 かなりこっ恥ずかしいようなタイトルではあるんですが、今回の記事で紹介されていた事例のいくつかと共通する点が少なからずありました。 情報をオープンにした方がより良い方向に進むという実感があるので思い切って晒してみようと思います。
全社員が貰っている報酬を内外問わず公開する。
小声でヒソヒソ隠れて話をする必要のない会社にしたい。ヒソヒソ話が多い職場は気持ちが悪い。
会社の組織を10人前後で構成する小集団に分け、独立採算制を徹底させる「部門別採算制度」の仕組み。
10人前後のスペシャリスト同士が集まって高効率な組織を作る。報酬も会社の利益の山分け方式など。 この組織はスペシャリストだけがおり自身でマネージメントを兼務する為、マネージャーは必要ない。
四半期毎など従来型のスパンでの目標管理シートではビジネス環境の変化による目標変更に柔軟に対応出来ない。 そこでよりアジャイルな評価制度を取り込む。
技術を外部に委託せず自社で賄いこれを財産とする。
会社が社会に提供している価値に内外問わず誰もが共感してくれる。むしろ共感しない人がいない。
従業員の残業を原則禁止とする。家族や勉強会など社外のコミュニティを大事にすることを奨励する。
ここ1年くらいで書き溜めてきたものなんですが、読み返すとまだ抽象的過ぎるものもありますがベースラインは的を得ている気がしています。 Bufferのジョエル・ガスコインCEOもインタビューで言ってましたが、これまで既存の組織にいくつか所属していて感じた違和感をベースに、本来あるべき組織について、理想論じゃん無理無理的なことは全く考えずに書き溜めてきたものです。 個人的にはまだまだ網羅的にちゃんと考えきれていない点もあるかなと思っているので今後この記事をちょっとずつ更新していこうと思います。
]]>