マネーフォワードに在籍したのは 2年ちょいでしたね。 最近はこんな感じでした。歴代2位ぐらいの長さでした。 1月一杯はちょっと有給消化をしてブラブラとしつつ、次の準備をしようかと思っております。 なんとか顧問のお誘いだったりとか、一緒にご飯食べようとか、ナンカ分からないですけど、需要があればFacebookや koshikawa at ppworks.jp 宛へ、お声がけ頂けると嬉しいです。 誰 Wantedly ppworks.hatenablog.jp 例のリスト https://www.amazon.co.jp/registry/wishlist/2KN1MJGJL69Z0/

pplogがキッカケ？ 当時の私は、このまま何者にもなれずに終わるのかなって思ってた。 そんなときpplogを知って、つらつら思いつきをぽえんでたら、私のアイデアに「需要ある」と足跡を残してくれた方がいた。それが #マンガでわかるWebデザイン の始まり。 pic.twitter.com/rJby0gp3r7— 湊川あい🌱技術書典5 あ20 マンガでわかるDocker② (@llminatoll) 2016年6月19日 まじかよッて感じでずっと楽しみにしていた本がやっと届いた！ わかばちゃん来た！Special thanksにpplogという文字列を発見してニヤついてる( ˘ω˘) pic.twitter.com/MgJsGHwXyJ— 🌈KOSHIKAWA (@ppworks) 2016年6月19日 ので読みました。読みながらの感想はツイッターに書いてたのでその辺を適当に貼っておく。

そこには足跡があった。 そう、名前の下に「最後に読んだよしたあしあと」が出ていたのだ。正確には、「最後のあしあとの最後の20文字」が出ていた。ウッカリおしりが見えちゃっている感じだ。 何故作ったか ツイッターの名前欄にはロマンがあるんですよ。 名前欄とは、Koshikawa Naoto とか書いちゃうところである。しかし、なんでそれ名前欄に書いたのって言う文字列を名前欄に入れている人々がいるのだ。なんていうかMNS MessengerとかSkypeにあったアレ、ムードみたいなアレ。間違ってアレ目的で名前欄を書き換えている。それも頻繁に書き換えている。そんなNAMAE-RAN FREAKSがいるんですよ。 正直ツイッターにおける一番いい機能である名前欄で遊ぶという機能を、我々はそんな機能を、pplogに搭載したくなったのですよ。 （当時の会話です） そうですね、一時期「コントレックス」という

とは 人事評価制度において、「人が人を正確に評価するなんて不可能」といった立場に立った時大事なのは、当人にとって「モチベーション」を適切にコントロール出ている状態をいかに長く継続するかということではないか。 透明性が大事 360度評価が自然に行われる環境とは、どんな環境であるか。 透明性のある状態で、誰かが誰かに感謝を通じて評価の代わりとなるようなものがある環境があると良い。 感謝とは すみませんではなく、ありがとうである。 人事において、この人が会社にいた本当に良かった。マジでよかった。ほんとありがとう。と思える人物が評価されるべきだと思う。 つまり評価とはありがとうという感謝で表すことが出来るかもしれない。 モチベーションと感謝の関係性 承認欲求を得たいという欲求によりモチベーションは保たれそう（ひとによる）

先日会社のブログに、「ふりかえりのススメ！〜モチベーションのコントロール〜 | マネーフォワード エンジニアブログ」という記事を書きました。 KPTという振り返りのフレームワークがあります。 よかったこと(Keep)、うまくいかなかったこと(Problem)、改善するために試すこと(Try)に分けて考えるんですが、これを導入して仕事を改善しようと私のチームの若手を中心を中心毎週KPTすることを始めました。 元はというと、前職で「ソニックガーデンギルド」に参加していた際に、ソニックガーデンの倉貫さんやメンバーと行っていたふりかえりで、このKPTを使っていたというのがあります。このKPTで自身の成長を実感したのもあり、今の会社でも少しずつ取り入れています。 KPTのコツは、倉貫さんの記事にあります。 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハ

スタートアップ界隈でのRuby on Rails利用率は割と高く感じる。 みんなが使っているから使う？それだけではないはず。なぜ使うのだろう。 railsの特徴を考える。 規約縛りの哲学 周辺gemのエコシステム webの進化への追従の速さ 規約縛りの哲学 Convention over Configurationてやつ。規約を決めて、それに沿えば、フレームワークに乗って素早く開発できるようになる。規約で縛ることでRailsに流れる哲学に従うことを強制化している。 外れると痛い目を見る。Railsに乗るということは電車に乗って簡単に遠くまで行けるということ。Railsから降りるということは電車からも降りるようなものだ。中途半端な理解で突き進むと線路からすぐに降りて歩くことになる。 スタートアップでRailsが採用される一番の理由は、 簡単に遠くまで行ける だと思う。ただ、そんなにうまい話は

何かしら失敗経験を踏まえて今度は成功するぞって気持ちや今までとは違う理想を描いて転職ってすると思うんですよ。 なので、失敗経験はちゃんと振り返る。どうすれば改善出来るか、どんなアプローチが適切かを分析しないと同じ失敗を繰り返すと思うんです。そして同じ理由で転職を繰り返す。 アプローチは圧倒的に変えないと劇的な変化は訪れないんですよ 。真逆の自分になることも必要かもしれません。また過去の失敗や後悔に論理的な理由付けをしておかないと過去に引きづられ続けます。 理想にどうたどり着くかというアプローチは圧倒的に変えないと以前と同じ失敗をする。理想にはたどり着けない。 理想を語るのは簡単。理想に向かうためのプロセスを見せるべきだし、行動で示すべき。人は議論では動かない、議論の前に行動を。よりよい仕事をしたいなら、不満を口にする前によりよい改善的行動を。 そりゃ入ってみたら思ってたのと違う、よろしくな

Gemfile pplog のGemfileです。 rev: 38530c94aebae07372f184ee3b726b988ea53aa4 source 'https://rubygems.org' ruby '2.2.0' # Framework gem 'rails', '4.2.0' gem 'responders', '~>2.0' # Database gem 'pg' # Authentication gem 'authority' gem 'devise' gem 'omniauth' gem 'omniauth-twitter' # APIs gem 'twitter', '>= 5.11.0' gem 'airbrake' gem 'hipchat' gem 'idobata' gem 'grape' gem 'pusher' gem 'em-http-request

プログラマー、絵が描けないじゃないですか（偏見） こんなじゃないですか。 なので描けるようになりたいなとずっと思っていて、ベジェ曲線って滑らかでナンカヨサソウ、とチャレンジしました。 「ベジェ曲線」習熟ドリル 7,8年前に買ったのがこれ。そう、チャレンジは2回目なのです。前回は3ページぐらいで挫折してました。んで、最近急に暇になったのをキッカケに「よしやろう」という気になり始めたのです。 改訂二版〈Illustratorで学ぶ〉「ベジェ曲線」習熟ドリル 作者: 中村高之出版社/メーカー: ラピュータ発売日: 2005/04メディア: 単行本購入: 2人 クリック: 8回この商品を含むブログ (4件) を見る (2014.1.10追記) なんと、長らく手に入りにくかったこちらの書籍が新装改訂版で再登場とのこと。 表紙が若干、損していた分、今回はスタイリッシュで内容と合っていてヨサソウです。