好きなことを仕事にするのは、才能が必要。
でも、仕事を好きになることは誰でもできる。多分。
僕は幸いにも仕事が好きだし、好きなことを仕事にしている。
では、本当に誰でも仕事を好きになることができるのだろうか？
仕事が好きにも、 何の仕事をやるかが大事な人 、 仕事のやり方が大事な人 、 好きな人と仕事をしたい人 の3パターンがある。
僕なんかは結構、やり方によってはどんな仕事も好きになれるので、そういう人は結構簡単に仕事が好きになれる。
何をするかが大事な人は、かなり努力が必要だけど、好きなことを見つければ、簡単に進んでいくだろう。
誰とするかが大事な人は、誰を好きになれるかを考えて、仕事選びよりは職場選びを頑張ればいいと思う。
誰もが仕事が好きになれますように。
新卒採用で見抜くべきはここで、可能な限り自社の仕事か人かやり方が好きになれそうな人材を採用すべきかと。
今日はそんなエントリー。
僕が常に考え続けてること、それは 本当の強さとは何か？ ということ。
この問いは自分の中に、小学校1年生の頃から常に持っている。
小学校の頃の自分の答えは、二つの力が揃っていること。
体の強さと心の強さ。言い換えれば肉体的な強さ、精神的な強さと言えるだろう。
体の強さの方が、心の強さより、大事。
心がいくら強くても、喧嘩に負ければ意味はない。
次に大学生の頃の答えは、3つ。
肉体的強さ、精神的強さ、社会的強さ。
肉体的に強く、精神力があっても、周りが認め、信頼されなければ意味がない。
そして、今思う、本当の強さとは何か。
肉体的な強さ、精神的な強さ、社会的な強さ、そしてそれらを高め続けられる強さを持っていること
同じようなことを神様もおっしゃっている。
勝つことは難しい、勝ち続けることはさらに難しい、一度手放したものを取り返すのはもっと難しい
ー川上哲治
同じ志を持った人がたくさんいれば、世の中は楽しくなるだろう。
そういう仲間を作っていきたい。
皆様、レガシーコードとの戦いは順調ですか？(笑)
世にはびこるレガシーコードがある限り、我々の仕事は終わりません。
レガシーコード改善はTDDと少し違うのかなぁ？という自分の中の思いが生まれてきたので、ここに記しておきます。
イメージした仕様のテストを書く。
テストが通るようにテストを書く
コードが綺麗になるように変えていく
単体テストのTDDの場合、小さな部分の動きをテストで固定していきます。所謂単体レベル。
しかし、レガシーコードは単体レベルで書き換えられるようになっていないことが多いです。
まずそのコードが依存している部分で、全体の仕様を洗い出すことが必要です。
特に抑えるべきは、インプットとアウトプットを洗い出しです。
おそらくこれが一番時間がかかる大変な作業です。
洗いだしたfixtureを作成していきます。fixtureというのは、データベースの値に限りません。ファイルを作成するのであれば、ファイルも、ブラウザに出力するのであれば、ブラウザへの出力の値もです。
本来であれば、1つの関数やクラスに閉じているはずの条件分岐を全体で洗い出す必要があります。
エンドツーエンドのテストの作成。
input fixtureを使って、output状態が保証されることを示すテストを書きます。 ...
php嫌いだから、ここはrubyで書きます
rubyの方が早いから、ここはrubyで書きます
rubyだとやり方わかるから、rubyで書きます
え、rubyわかりません。
え、phpって聞いてたんですけど
ちょ、rubyとphpで同じ処理あるしカオスwww
あれ、この間のバッチ止めたのに、バッチ実行されてるし、、ちょおまrubyやんwww
もう無理やし、ruby駆逐プロジェクトやろうぜー
という流れを何度かみたことあるけど、
結局のところ適切な場所で適切な言語を決定した根拠を持っておかないとですね。
ワーキングメモリってのが流行ってる臭い。
ワーキングメモリを鍛えて脳の働きを強化するための4つの方法 http://namaraii.com/archives/4845
要は、人間の処理能力を高めることで、ミスを減らして確実に作業をするということ。
そして、これらは人によって個人差はあるものの、訓練によって鍛えることができるというのがわかってきたそうです。
まぁ、この本を読んだら、ワーキングメモリってのが、どういうことかとかが書いてあって、どのようにして鍛えるかということも書いてありました。
...
今日は突然の雨でしたね。
僕も帰りがけに雨に振られました。
僕は家を出るときに雨が降っていない限り、傘を持っていかないので、いつも雨に振られます。
後先のことを考えられないバカな人間なのかもしらませんが、とある10人くらいのスタートアップ企業で働いていたとき、メンバー全員が僕と同じ行動をとっていたことに驚きました。
(しかも、雨が降るかもしれないと思ってても、傘を持ってこない人たちばかりでした)
空を見て、雨が降りそうだから、傘を持って出る
マッキンゼーではそうかも知れませんがスタートアップでは、そんな行動力では通用しません。
できるだけ早く出社することの方が大事なのです。笑
大久保じゃなかったら細貝だったのかなぁ？
いや、わからないけど。
俺はこういうサプライズができる日本代表になったことが嬉しい。
ジーコ時代の巻とかさ、全然サプライズじゃなかったやん。
いや、フォワードもう一枚誰か欲しいよな。
ここで、中山！とか佐藤寿人！とかなってたら、サプライズやったけどさ。
でしかも、大久保ってただ調子いいだけじゃなくて、代表経験も豊富やん。
本当に前回大会の中村俊輔以上の精神的支柱になる確率あるじゃないですか。
しかもフォワードやし、スーパーサブとして、最適。
チーム力でどうこう行かなくなったときに、ロングボール追いかける仕事。
前線で声出すフォワード。いやー、ありですよ。ほんといいと思います。
ただ、大久保なしで全然戦えるのよね。
システムが使えるうちは大迫か柿谷か斎藤か前線で、やれるやん。
あー、これだけ戦力そろってるやん！
でも、コロンビア強そうやわー。
あー、勝ちたい！勝ちたい！
勝ちたいわ！！
それだけ強力ってことですが、なんか使い勝手悪いなぁっていつも思います。
あと、rsyncのvオプションはデフォルトでオンでよくないかな？って思います。
あと、rsyncのaオプションは一体どんな操作をしてくれてるの？っていつも思います。
あと、nオプションで--dry-runのエイリアスってセンス悪くない？っていつも思います。
実行はrsync av path/to host:path/toで、
素振りはrsync avn path/to host:path/toか。。
いや、まぁそれでもscpやsshに比べれば、いろいろと使い道もあるんだけど、小さくあるべきなんじゃなかったかな？とかよく思ってしまうんですが。
何が一番の解なのかは正直わからんのです。
<?php
$array = ['a','b','c'];
foreach($array as $key =>$value); {
$newArray[$value] = $key;
}
var_dump($newValue);
foreachの後ろに;があるために、そこでforeachが回って、その下の{}の中は一回しか実行されず、newArrayの中には一番最後の値が代入される。
これで、array(c => 3)が出力されます。
タイポなんですけど、IDEとか使えない環境だったりあると思います。
NetBeansで開いたら、｛空のforeachです}みたいに警告が出てました。
vimな人でこういうのIDEみたいに警告だしてる人いたりしますかね？
僕の使ってるプラグインはパースエラーしか教えてくれないんですよねー。
なんか重そうですけどね。
圧倒的な人不足の中で、いかに自分の力を磨きながら価値を発揮するかっての最近のテーマです。あと数年はこの状況が続きそうなので、人が居ないから仕事がある状態をいかに抜けだして、koheisgだから仕事がある状態にしたいってのを常々考えています。
んで、この間髪を切りに行ったんですけど、
プログラマもですけど、ガードマンも飲食店も人不足らしいですよー
みたいな話をしていて、美容師さんはどうなんですか？
みたいなこと聞いたら、人不足って感じはしないらしい。
まぁ、昔から糞忙しい業界ですし、顧客に対して美容師が足りない自体にはなっていないみたい。
昔からずっと人不足なのかもしれないけど。。
「あー、でも若い人は少ないかもしれないですねー」
そんな言葉が返って来た。
どうやら、30代前後の美容師は多いけれども、20代前半の美容師は数が少ないらしい。
それが人不足にあてはまるかは別として、なるほどなと思った。
カリスマ美容師なんて言葉が流行ったのも今30代の半ばくらいの人たちが、高校生くらいの頃なんじゃないかなぁ。
その世代はぎりぎりロストジェネレーションで、どこもかしこも不景気で、美容師の下積み時代がきついといえども、なんとか根性で乗り越えてきた世代。
それにブームの影響やそもそもの人口的にも、美容師が多いんだろう。
だけれども、80年生まれ後半世代は人数も少ない上に、カリスマブームも過ぎ去ったあとに進路選択をした。
そして、割りとアルバイトでも高単価の仕事が周りに多い中、美容業界でやってられっか！ってなった組が多いのかも知れない。（そして、それを人はゆとり世代と呼ぶ）
インフラ費用はherokuやAWSでめちゃめちゃ下がってる。
プログラマの学習機会も一気に増えている。
railsのようなフルスタックフレームワークを採用すればモックまでの開発スピードも短縮できる。
今、Web業界で求められているのは、何発の弾を撃てるか？だと言われているし、
それこそがもっとも事業の作り方として正しい。
何があたるかわからないから、顧客のニーズをひたすら探りながら、暗中模索してサービスを作っていくのが、今の時代の成功法だと思う。
でも、死ぬ気でメンテしていく心を忘れちゃいけない。
じゃないとサービスも、ユーザーも、チームもグロースしない。
グロースハッカーに最も求められているのは、愛して愛される力だと思う。
all you need is LOVE!!!!!!
アイデアに意味はない、動くものに意味がある。
最近のIT界隈ではそういう言説が多い。
確かにアイデアだけでは、お金を生まないし、アイデアを形にしてはじめて、それに価値があるか判定できる。
だがしかし、優れたアイデアを持った起業家はアイデアに溢れている。
つまらないものから、面白いものまでたくさん。
アイデアは突然生まれることもあるかもしれないが、努力をしないと優れたアイデアを生み出すことはできない。
数多くのアイデアを出すことで、シナプスが繋がり優れたアイデアが生まれるのだ。
彼らはそういったトレーニングの上に、優れたアイデアを持って形にしているのだ。
アイデア自体は価値を生まないかもしれないが、アイデアを出すこと自体は最高の頭の体操なのだ。
どこの会社もエンジニアを必要としてます。どこの会社の人と話してても、_誰かいい人いない？_って言われます。
あと、ある程度のスキルの人を探そうとすると本当に大変みたいです。
要件定義からテストまで全てこなせる人、インフラからアプリまで全てこなせる人、社内外調整からプログラミングまでできる人、、
そして、エンジニアだけの話でもないようで。。
飲食店もガードマンもギャルも暴走族もみんな人不足みたいですよ！！
だからこそ、人がしなくてもいい仕事をプログラムにやらせるプログラマは、特に必要なわけですね。
最早、人はいないので、プログラマがサービス考えて、自分で開発しちゃう のが最も早いですね。
金払いのいい会社に転職しよう、、なんて思って履歴書書く時間を、人不足を解消するサービスを開発するのが最も金払いいいはず。
昨年、 フルスタックエンジニアがちょっとしたバズワードになりました。
大体のフルスタックエンジニアは以下が要件になってきています。
・railsやdjangoなどのWAFの経験
・高トラフィックに対する対応経験
・backbone.jsやAngular.jsなどのJavascriptフレームワーク経験
・HTML5/CSS3の経験
今までは、HTML/CSS+Javascriptはwebデザイン的な領域だと考えられていました。
しかし、シングルページアプリケーションの普及でクライアント側もプログラマブルな対応が必須になってきているため、このような求人要項が増えてきているのです。(特にスタートアップで)
しかし、このようなフルスタックエンジニアだけで、僕はいいサービスが作れるとは思いません。僕がスタートアップのCTOならば、もっと別の能力を重視します。
以前 受託開発を行うエンジニアにとってのfeatureとサービス開発を行うエンジニアでのfeatureは少し違うという話をしたように、自社サービスの開発を行うエンジニアは、
テクニカルなプロジェクトマネジメントや実装能力ももちろんですが、組織に文化を浸透させることが重要になります。
...
社会人生活5年目に突入しました。
まさか僕がエンジニアをやっているとは、5年前からすると考えられない事態です。
昨日、目標は立てました。
非常にシンプルな目標になりました。
これは良い兆候のように思えます。
社会人生活5年目は、エンジニアとして エモーショナル になることがテーマです。
KPIを意識して喜んだり、悔しがったり。
スケジュール通りに進めてよろこんだり、遅延して悔しがったり。
リリースして喜んで、バグ出して悔しかったり。
もちろん、KPI未達もスケジュール遅延もバグも、褒められたことではありません。
しかしながら、論理的思考によるKPTを確認しても、仕事は楽しくならないんです。
目の前のことに夢中で取り組んで、一喜一憂してききます。
去年塞いでたのは夢中さの欠如。
感情を目の前のことに、本気で投入する。
僕は作るだけや書くだけで満足できるタイプではないので、そういう勝ち負けをサービスレベルから実装レベルで意識していきたいなと思います。
アジャイル開発の文脈で語られるfeature。
機能と直訳するのは、多少厄介です。それはどんな機能ですか？と聞いてしまっては「投稿機能」というような答えになってしまうからです。
featureは主語と述語がはっきりとして、具体的な一文で書くべきです。
投稿機能ではなく、「ユーザがブログに対してコメントを投稿できること」のように。
作りたいものの、特徴を端的に書くため、featureを特徴と訳している人もいるようです。
受託開発の場合は顧客の要求をそのまま、一文に落とし込めば良いと思います。
そのときに顧客の言葉を使うと価値の共有が測りやすいです。
featureは誰にとってどんな価値があるのかを意識しなければいけません。
顧客にとってコメントを投稿するということが価値があることが、明確であれば問題ありません。
顧客の言葉に対するfeatureが完成されれば、その実装は受け入れられます。
ただ、サービス開発の場合は違います。
そもそもユーザがコメントできることに価値があるかがわかりません。
コメント機能を実装して、それが使われるかどうかまでを意識したfeature設定が必要になります。
サービス開発では、無駄なfeatureをなるべく削ぎ落として、純粋に価値があるものをユーザに届けるべきなのです。
この場合、コメント機能を実装して、ユーザの滞在時間を上げたかったり、コメント機能で通知を行いコメントのあったユーザに承認欲求を与えるということに価値があるはずです。
そうすると、featureはもう少し抽象度が上がる可能性があります。
「ユーザが他のユーザとコメント欄で交流できるようにする」といったところでしょうか。
...
アジャイル開発とは何でしょうか？
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
_計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
かの有名なアジャイル宣言です。
http://agilemanifesto.org/iso/ja/
しかし、アジャイルで開発をやろう！という話になると、いろいろなことをみんなが想像しはじめます。
人によってはカンバンや見積もりゲーム、振り返りなどのイベントやツールを思い浮かべます。
中には「アジャイルだからドキュメントは作らなくていい」とか「計画を立ててはいけない」など間違った発想を持ってしまう人がいます。
アジャイル開発の一つの手法であるスクラムでは、確かに見積もりゲームや振り返りなどのイベントがありますが、
それを実践したからといって、アジャイル開発になるとは限りません。
ドキュメントよりも動くソフトウェアを重視しているからといって、動くソフトウェアをドキュメントなしで作れとは誰も言っていません。
僕は今までアジャイル開発の現場に何度も入ってきましたが、アジリティ高く開発できているチームに共通する点があります。
それは、継続的にプロジェクトを改善して、アジリティを高めて行こうとする意思がチームにあることです。
...
長期的な目線は大切です。
ただ、長期的な課題はすぐには解決できないことが多いです。
途方に暮れる様な大きな問題は、小さな問題の積み重ねです。
小さな問題を一つ一つ解決するしか方法はありません。
小さな問題から逃げてはならないのです。
そして小さな問題は解決できることがほとんどです。
小さな問題を解決して、小さな成功体験を積んでいく。
かのイチローも言ってます。
とんでもなく大きなことを成し遂げるためには、小さなことを毎日積み重ねるしかない
newsアプリ大好きの私ですが、やはりRSSリーダーは欠かせない存在なのです。
Google Reader+Reederという運用をしていたのですが、Googleさんがサービスをやめてしまったので、Reederも辞めました。
Google Readerの乗り換え先をいろいろと迷ったのですが、Feedlyにしました。
理由は一番Feedlyの対応が早かったからです。
そしてReederはFeedly対応しなかったのでやめました。
iphoneでFeedlyアプリがイマイチな動きをするので、newsifyにしました。
ReederはMacもiPadもiPhoneもお金払ってたので非常に残念でしたが、と思ったらReederもfeedly対応してるんかい。。。
まぁ、７月１日には間に合わなかったみたいだから、いいか。
つーわけで、feedly+Reederをしばらくまた使うと思います。
composerは素晴らしいツールですね。
rubyのbundlerなんて超当たり前だったものですが、phpでもこういうツールがメジャーになってきました。
phpのあるある話として、開発環境で動いていたアプリを本番にリリースしました。
あれ、pearのライブラリが入ってないから、エラー出てるよ。
あとから、お客さんからの問い合わせで気づくという最悪のパターンから、ログ監視中に気づくパターン、デプロイ後にすぐ気づいて冷や汗かきながら切り戻すパターン。。
上記のうち一つくらいはプロのphperなら経験があるかもしれません。
ここで古典的なやり方としては、必ずリリースの際は依存系ライブラリがないか徹底して確認するっていうよくわからない再発防止策を障害報告で書く。。。
後から、ライブラリ使ったことをリリース責任者が知らなかったとか作業担当者が報告しなかったとか、しょうもないことを上司から言われる光景すらも目に浮かびます。
あれ悲観的に書きすぎ？？
こういった再発防止策はcomposerを使うという1点で解決できます。
composerはcomposer.jsonというファイルに依存するライブラリを記述し、コマンド一発でインストールできるというスグレモノです。
このcomposer.jsonを利用して、ライブラリのインストールを行うというルールさえ決めておけば、デプロイ用のスクリプトにcomposerを実行することを書いておくだけで、上記のようなくだらないミスを減らすことができます。
上記のようなことがなくなるために、composerの優位性を説くだけのエントリでした。
...
スピードが欲しい。
早く手を動かせるようになりたい。
遅い。腹が立つ。苛立つ。
関数一つにしても、すぐにさっと書けないし、
いちいちgoogleに聞きにいかなければならない。
いや、調べるのは問題ないとしよう。
なぜ、それが遅いんだろう。
調べて理解するまでが遅い？
書いても、シンタックスが間違っていたり、データの流れをしっかり追えていなかったりするから、遅い？
どうすればスピードを上げられるのだろう？？
関数の動きを正確に覚えることを日々やればいい？？
例えば、絶対にググるのがjQueryいつまでたっても覚えられないし、
javascriptよりphpを書いている時間が圧倒的に長いからか？？
意識して書くことがサーバサイドよりも複雑だからか？？
でも、スクリプトが呼ばれるタイミングと、呼ばれる時の挙動がしっかり把握できていれば、そんなことにはならないんじゃないか？
集中力がないからか？集中力は書いて動いてこそ生まれるきがする。
ハマっているコードを書いているときはどうしても、集中力が削がれる。
できないことを一つ一つできるようにしていく、もっと一日に書ける行数を増やさなければ。
...
大学4年生の時に、元マッキンゼーのコンサルタントだった教授の授業を取っていた。
その人はもともと医者で、経営を学ぶためにコンサルになり、その後経営学者になるという道を辿ったらしい。
授業の名前は「医療現場のマネジメント」という名前だったはず。
名前は医療関係の授業だけれども、中身はロジカルシンキングの授業だった。
私がこのロジカルシンキングの授業の中で身に付けたフレームワークがSCQAだ。
もしかしたら、1,2年生向けの授業だったからかもしれない。
これからたくさんのレポートを書く必要がある学生に向けて、どのように文章を組み立てれば良いのかをレクチャーしていた。
(私は4年生で単位が足りなかったから出ていたわけではなく就職活動の中でマッキンゼーの存在を知り、そんなエリートの先生の考え方を学びたかったのだ。)
文章を書く時に「簡潔に」とか「結論から」などとよく指摘を受けることが多いだろう。
しかし、私自身、簡潔に結論から伝えようとして、うまく文章が書けないという罠に何度もはまったことがある。
文章に大事なのは、そもそも簡潔に伝えることでも、結論から伝えることでもない、伝わる順番で伝えてあげることなのだ。
そして伝わる順番こそ、ストーリーとして仕立て上げることである。
ストーリーにはめるフレームワークは実は数多ある。
起承転結や三段論法といったものがそれである。
私が例の授業で学び、今もよく使っているのが、SCQAのフレームワークである。...
Blurのドキュメンタリー映画「 NO DISTANCE LEFT TO RUN 
僕は世代的には活動休止直前をわずかに知っている世代なんだけど、一番好きなアルバムは「blur」かな。
中学生の時中古で手に入れたのか、ずっと聞いてた気がする。
...
自分を見つめなおすためにも、少しブログを書いておく。
転職してから、新しいことをはじめている。
AWSを仕事で使い始めた。
Gitを仕事で使い始めた。
Macを仕事で使い始めた。
Gmailを仕事で使い始めた
Skypeを仕事で使い始めた。
今まではこれらの便利ツールを使うために、どれだけ環境を変化させる必要があったか。
どれだけ労力が必要だったか。
よく考えると、すべてプライベートでしか使ったことがなかった道具を、仕事道具として使っているわけだ。
これってすごい。
なぜ、これらがそこにあるすべてのベースにはスピードが隠されている。
全ては会社の意思決定と行動のスピードが基礎になっている。
自分がコードを書くペースが遅いことは知ってはいたけれど、ここまで鮮明になることはなかったし、
慎重に設計しすぎることが多いとか、理解できないコードを追いながらタバコが吸いたくなるとか、自分の「遅さ」がここまで際立ったことはなかった。
即断即決は得意だけど、行動から成果まで最速で出すってのは得意じゃないようだ。
即断、即決、即行動、即成果ってのを意識していこうと思う。
今まで、成果を出せないのは、自分の行動のスピードの問題ではなく、仕組みそのもの問題だと思っていた。
環境を変えてわかったことは、仕組みの問題ではなく、自分自身が止まっている時間が長いということだ。
いつも、どこかで自分に言い訳してしまう。
自分を赦すのは大いに結構。自分を慰めるのも大いに結構。
精神衛生を保つために、それは絶対必要。
...
