むかしからなんでも斜にかまえるクセがある。 行列を見ては「よく並ぶねえ」と思い、流行りの曲を聞いては「これが流行ってんのね」と少しうがった目で見てしまうのだ。 そこでふと「斜にかまえる」「かまえない」を意識的に切り替えるとどういう感情になるのか気になった。実験してみます。 やり方 簡単にやり方を説明すると ①何かモノなどを目の前に置く ②それに対し、1分間は斜にかまえ、もう1分間は斜にかまえずに感想を言う。これだけだ。 ちなみに「斜にかまえる」を辞書で調べると、「物事に正対しないで、皮肉やからかいなどの目で見ること」とある。 わかりやすく言えば、1分間は皮肉めいた目で見て、1分間は素直に感想を言ったり肯定してみたりする実験である。 ひとりじゃ心もとないので、今回は後輩と一緒にやることにした。 後輩の郡司さん（左）と山宮さん（右）。二人とも斜にかまえがちな性格を自覚しているそうだ。 とりあえ

書く技術・伝える技術を読んでもらって提案文章をリアルな課題でやってもらう、というワークを部下(合計10名弱)に実施しました。フィードバックをした時に「共通して指摘してるなぁ」と思った部分があったのでまとめです。 以下の内容は本を読んでいないとわからない場合があります。 改訂新版 書く技術・伝える技術 (スーパーラーニング) 作者: 倉島保美 出版社/メーカー: あさ出版 発売日: 2019/06/24 メディア: 単行本（ソフトカバー） この商品を含むブログを見る 目次 【TIPS1】文章の目的を理解する 【TIPS2】課題をより明確にする 【TIPS3】文章内の重要度合い 【TIPS4】網羅して書く 【注意】打ち手先行型提案は通らない 【TIPS1】文章の目的を理解する ◎文章の目的 今回の文章の目的は改善提案を行うことです。ひいては上司の「それいいね！やろう！」を引き出すことです。 ◎

今日から平日で毎日日替わりでコパイロツトのナレッジラボチーム（Knowledge Laboなので今後KLと書きます）がブログを書くことになりました。 金曜日担当の定金 基です！岡山県出身1975年生まれのB型さそり座です。よろしくお願いします。 私は案件初期のプロジェクトの定義が緩いタイミングでヒアリングをさせていただくことがよくあります。 その時にしばしば気になることがあります。 それは【問題 Issue】【課題 Task】【対策 Solution】【作業 ToDo】の意味が人によってちがう！ということです。 例えば「コパイロツトさんに相談したいのはこの問題なんですよ！」と言われたときに、それが明らかに私たちの定義する【対策】のことを指している場合があったりします。 私たちはチームとして「プロジェクトを本質的な成功に導く」をテーマに掲げているので根幹である【問題】をクライアント様を含めた

うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その

先を歩むエンジニアへのインタビューを通してエンジニアのキャリアについて考える本連載、今回はゼロからOSやScheme処理系を作り、現在はTwitter本社で働く凄腕エンジニアのhigeponこと蓑輪太郎さんにお話をお伺いしました。 ［撮影：平野正樹］ 危機感を感じた1社目 ─⁠─higeponさんはいつもさまざまなことを勉強なさっていますが、いつごろから自ら技術を学び始めたのでしょうか？ higepon（以下ひ⁠）⁠：2001年に入った初めての会社が大きいSI系で、技術に長けたチームに入れてもらえました。そこではモデルケースになるような優秀な先輩がいて、たとえばトラブルが起きたときに、自分で率先して原因を解明して、周りにも的確に指示を伝えていて問題を解決していたんですよ。その先輩から「しっかりプログラミングを勉強しないとまずいよ」と言われたんですよね。それで自分で実際に勉強をし始めたら、今

CTO の舘野 (id:secondlife) です。丁度1年半ほど前に、クックパッドの CTO になり、自分が20代の時に憧れていたいわゆるハッカーとは違う道を歩んだという事もあり、ソフトウェアエンジニア*1のキャリアってどんな物があるんだろうと改めて考えた時期がありました。 しかしながら一人悶々と考えても、答えが見つかる物でも無かったので、私の先を行く方々の話を聞きたいんですよね、みたいな事を md2inao で有名な WEB+DB PRESS 編集長の稲尾さんとしていたところ、じゃあそれ連載記事でどうですか、とお話を貰ったので記事として連載させて頂きました*2。 その時、連絡させていただいたメールにはこんなことを書いていました。 背景としては、今やエンジニアは、サーバサイドは AWS/heroku 等 IaaS/PaaS の台頭、github を中心とした OSS フレームワーク・ラ

発信しないのは「仕事をしても請求書を出さない」のと同じ。堤修一が開発～発信の循環を作る理由 ブログ、書籍、そしてOSS。iOSエンジニアの堤修一さんは、常に「発信」のこだわり続けてきました。数多くのスターを獲得した『iOS-Sampler』シリーズも、発信活動の一環だと説明します。なぜここまで発信にこだわるのか、堤さんに聞きました。 「昔は、他のエンジニアと会話するのも怖かった。やりとりされる言葉の意味すら分からなかったので」 iOSエンジニアの堤 修一（つつみ・しゅういち／ @shu223 ）さんは、駆け出しだった過去を振り返ってこう言います。30歳を超えてから本格的にプログラミングに取り組み、あるときは「できないやつ」と見なされ、窓際も経験した堤さんを磨いたのは、強い学習意欲と学習したものを様々な形でアウトプットする、発信力。そして発信から次のミッションを獲得するという、サイクル作りに

Githubで海外のエンジニアさんをフォローしているのですが、あるエンジニアさんがtilというリポジトリをstarしていました。 github.com 「なんか新しいツールか何かかな？」と思ったのですが、覗いてみたらdescriptionに"Today I learned"の文字が。 どうもtilというリポジトリを作成してそこに"今日覚えたこと"を書いていくのがプチ流行している様子。 ・ 色んなTILが 今までだと同じような感じでベストプラクティス等をまとめた"◯◯-awesome"が流行ってましたが、 自分が何を学んでいっているのか自分も他人にも知ってもらうためにこういうリポジトリを作って書いていくのも面白そうですね。 関連したWebサービスとかが作成されたらそれはそれでまた面白いのかも。