タグ

考え方に関するTAKAyuki_atkwskのブックマーク (60)

  • Google の新しい専門職 : CRE が必要な理由

    Google Cloud Platform (Google App Engine, Compute Engine, BigQuery や Container Engine など)の情報の日公式ブログ

    Google の新しい専門職 : CRE が必要な理由
  • Qiitaにおけるリモートワーク主体の開発プロセス - Qiita

    2016/9/27 スタートアップRails勉強会発表資料 About @takashi Increments アプリケーションエンジニア 主にQiita:Team担当 最近入社した 最近 Incrementsの開発チームが大事にしていること HRTを大切にしたコミュニケーション 作業は意識的に自動化する 属人性を極限まで排除する 重要な価値に集中する Qiitaにおけるリモートワーク開発プロセス HRTを大切にしたコミュニケーション Humility(謙遜), Respect(尊敬), Trust(信頼) リモートワークにおいてHRTとは? オンラインコミュニケーションは誤解を招きやすい (当に)意図せず冷たく接しているように伝わる そこで なにげないレビューに を添えるだけで雰囲気が良くなる (けど普段喋れないこともあるので)月1回はオフラインで集まるようにしている 作業は意識的に自

    Qiitaにおけるリモートワーク主体の開発プロセス - Qiita
  • 社員が増えたので物理的なオフィスをやめました 〜 これからは「分散型ワークプレイス」へ | Social Change!

    私たちソニックガーデンでは、かねてより全社でリモートワークに取り組んできました。今では24名いる常勤メンバーの半数以上は地方に住む在宅勤務者です。採用応募の殆ども地方からであるため、今後もリモートワーカーは増えていくでしょう。 それでも、これまでは東京の渋谷にオフィスを構えていました。しかし、2016年6月末の契約更新の際に解約を行い、次の移転先は用意せず物理的な「オフィス」という概念を一旦やめて、複数のワークプレイスに分散させることにしました。 今回の物理オフィスをなくした取り組みは、TechWaveでも記事にして頂きました。ありがとうございます。それがこちらの記事。「日でオフィスなくします」自律的リモートワーク先進企業の門出 【@maskin】 記事では、その補足として、私たちがオフィスをなくした理由と狙い、そして、新しい分散型ワークプレイスのコンセプトと実践について書きました。

    社員が増えたので物理的なオフィスをやめました 〜 これからは「分散型ワークプレイス」へ | Social Change!
  • プロダクトオーナーとエンジニアの役割分担が失敗した話

    By: Magic Madzik 友達から「優秀なエンジニアが会社をやめた」という話を聞いた。まぁ、とても残念な話ではあるだろうが、友人の話がなぜか心の奥にひっかかっていたので、考えをまとめながらここに書いてみる。 衝突と絶望 あるエンジニアがいた。彼はあるプロダクトに長く貢献していた人物だ。最近、組織や体制が変わったことにより、プロダクトの作り方や方針に変化がでてきた。 やがて、プロダクト面とエンジニアリング面で衝突がよく起きるようになった。 プロダクト面からは、決まった方針とともに作業が降りてくる。プロダクトに責任を持つ立場だとすればその気持ちもわかる。一方で、プロダクトを愛し、これまでに貢献してきたというプライドを持ったエンジニアの気持ちもわかる。エンジニア視点の意見も当然あるだろう。 ひとつのプロダクトに関わっているはずなのに、両者には溝が生まれた。 そして、当初、そのエンジニア

    プロダクトオーナーとエンジニアの役割分担が失敗した話
  • 「みんなで狂ったことをしよう」STORES.jpをつくる模索を止めないチーム | ブラケット - Poole(プール)

    『STORES.jp』と言えば、「最短2分で、驚くほど簡単にオンラインストアがつくれる」ことで大人気のサービス。約2年ほどで登録店舗が20万件を突破したことでも話題になりました。このSTORES.jpを展開しているのが、株式会社ブラケットです。 そこで今回は、驚異的な速度でユーザを巻き込み、サービスを成長させる株式会社ブラケットの組織、社員それぞれのマインドやこだわりについて、リード・デザイナーの河原氏とエンジニアの牧野氏に語っていただきました。 河原 香奈子氏 Webデザイン制作会社2社を経て、2013年5月に株式会社ブラケットにデザイナーとして入社。 前職では、企業からの受託案件のデザイン業務〜自社サービスのデザイン業務まで幅広く経験している。Webデザインの他、紙媒体のPOPなどの制作経験もあり。株式会社ブラケットに入社後は『STORES.jp』『Shoes of Prey』を中

    「みんなで狂ったことをしよう」STORES.jpをつくる模索を止めないチーム | ブラケット - Poole(プール)
    TAKAyuki_atkwsk
    TAKAyuki_atkwsk 2015/02/03
    狂ったことをするけどシステムは狂わないようにしていきます(^^;
  • 優れたプログラマに対しての、管理職への昇進以外のキャリアパス | POSTD

    あなたは、これからキャリアを切り拓こうとしている素晴らしいエンジニアたちを抱えています。チームは優れた成果を出して成長し続けているので、何らかの具体的な方法で賞賛したいと考えています。すぐに思いつくことは、特にエンジニアたちがそのチーム内ですでに事実上リーダーの役割を果たしている場合には、彼らにチーム内での役職を与えて昇進させることでしょう。でもその報酬は、当にエンジニアたちが望んでいるものでしょうか? もしかしたら彼ら自身も、昇進は望むべきもの、と思い込んでいるだけではないでしょうか? 人材マネジメント力は別のスキル エンジニアの世界では、エンジニアたちが技術面ではピークに達した後に、これまで習得したものとは全く別の、社交面だとかソフト面におけるスキルを学ぶよう求められることがよくあります。これらは、エンジニアたちが過去のキャリアではほとんど気にしていなかったものです。このようなスキル

    優れたプログラマに対しての、管理職への昇進以外のキャリアパス | POSTD
    TAKAyuki_atkwsk
    TAKAyuki_atkwsk 2015/02/01
    なるほど
  • 技術力がつかない負の流れに陥ってしまった。 - 東京アンダーグラウンド

    最近自分がとらわれている負のスパイラルについて、思うところがあって書いてみた。 吐き出せば楽になれるかもしれない。 例外的な人はもちろんたくさんいると思うけど、一般的にSIer社員は技術力が低いと言われている。 たしかに自分の周りのSI社員にまともにコードを書ける人なんていないし、話に出るのは1990年代から2000年代のテクノロジーだ。 業務中にプログラミングをするときは、それが業務を改善するためのものであっても、周りの目を気にしてIDEを開く。 隙間の時間に、ほんの少しだけ。 手を動かさないと技術が身に付かないのは事実で、そういう意味だと、SI社員が技術を身に付ける時間は非常に限られている。 少なくとも、業務中に技術的なことをやる時間はほとんどないので、何かを身に付けたいときは、業務外に頑張って時間をとって勉強しなければならない。 家に帰ってからが勝負になる。 例外的な人になるためには

  • Yehuda Katzという生き方とインディーWeb - ワザノバ | wazanova

    https://frontsidethepodcast.simplecast.fm/16 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 41分前 昨日のエントリーでも名前のでてきたYehuda Katzですが、Rails / Ember.js / jQuery / W3C Technical Architecture Group (TAG) / TC39-ECMAScriptなどで活躍し、今回はRustのコアチームに参加することが発表されてます。Tom Dale曰く「インターネットの半分くらい書いてる感じだから。[1] 」という勢いがあります。Yehudaの仕事振りやプロジェクト運営における考えは、オープンソースという視点での発言ですが、企業におけるプロジェクトの進め方や今後の働き方のスタイルがどう変わるか、変

  • ポール・グレアムによる「スケールしないことをしよう」後編 | POSTD

    エントリは 翻訳リクエスト より投稿いただきました。 ありがとうございます!リクエストまだまだお待ちしております! 前編は こちら です 火を燃やし続ける 時に、わざと狭い市場に焦点を合わせるのがまさにスケールしないコツなのです。丸太を加える直前に火が最高に熱くなるよう、最初は穏やかに燃やし続けるようなものです。 Facebookはこれを実行しました。Facebookは当初はハーバードの学生向けのものでした。その形態では、たった数千人の潜在市場があっただけでしたが、学生たちは、Facebookは当にためになると感じたので、極めて大勢の学生が登録をしました。Facebookがハーバードの学生に向けたものでなくなった後も、特定の大学の学生のために長い間残っていました。私がStartup Schoolでマーク・ザッカーバーグにインタビューした際に「各学校のために履修コースの一覧表を作成するの

    ポール・グレアムによる「スケールしないことをしよう」後編 | POSTD
  • スタートアップで540日間働いてわかった6つのこと | Tokyo Otaku Mode Blog

    こんにちは。Tokyo Otaku Mode(以下、TOM)の薮崎です。私はTOMで主力事業に育ったEコマースの運用チームとカスタマーサポートチームのリーダーを担当しております。 今回は、私が2013年2月にTOMに入ってから今日までの約1年半で体験してきたことを共有させていただきます。 ###はじめに -TOMと私- 私は大学卒業後、ベンチャー企業2社を経て、2013年2月にTOMにジョインしました。以前勤めていたスタートアップを辞めたあと、たまたま友人がTOMに社会人ボランティアとして参加していることを知り、EC事業を統括するCOOの安宅を紹介してもらったことがきっかけです。TOMのことについては、正確な時期は忘れましたが、いいね!数が30万くらいのころに存在を知り、それ以来ずっと気になっていた謎の組織でした(笑)。そのTOMの存在の謎が解けた、2012年8月に出た日経新聞電子版の記事

    スタートアップで540日間働いてわかった6つのこと | Tokyo Otaku Mode Blog
  • 考えすぎてコミュニケーション能力が低い人へ - teruyastarはかく語りき

    コミュニケーション能力の鍛え方を教えて欲しい http://anond.hatelabo.jp/20140807005003 でも、少し話をしてる中で、少なくとも「嫌なやつ」ではないことがわかった。 真面目だし、素直だし、やる気はある。 でも、会話が成立しない、ただただ成立しない。 「AとBのどっちが好き?」と聞くと 「〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 〜〜〜〜〜という理由で、Cのこと嫌いじゃないです」 と返してくる。 辛抱強く最後まで聞いてから、 「で、AとBのどっちが好きなの?」と聞くと 「あ!Aです、すいません」と答える。 ずっとこの調子。人に悪意はない、 単純にコミュニケーション能力が低いだけ、異様に、低いだけ。 (犬の糞は増田の訳だと思われるので引用しない) もし、会話の質を探るために 質問の前提をさかのぼり、抽象化して 会話するまでもない常識には触れず、 いかに

    考えすぎてコミュニケーション能力が低い人へ - teruyastarはかく語りき
  • 伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる|CodeIQ MAGAZINE

    伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 (CodeIQ中の人) 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです

    伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる|CodeIQ MAGAZINE
  • 翻訳:僕が Node に残る理由 - ほんやくとコード

    原文:Why I’m staying in with Node なによりもまず、T.J. に敬意を表したい。これからは Go推していくという大ニュースと、Node.js への別れの挨拶 とに感謝したい。ある問題に長く取り組んできた人は、時期が来たら別の場所へ進んでいく。そして彼の場合は、それが「仕事にふさわしいツールを使う」ことだった。 いいね。尊敬せずにはいられない。あいつはできる奴で、ヤバい。 僕はというと、まだ Node.js との付き合いを続けている。まだざっくりとした未来しか思い描けていないけれど、僕はずっと昔から JavaScript に賭けてきたし、ああ、なんというか、英語みたいなものかな。JavaScript はあらゆる所にある。 もちろんこれは喩えにすぎないのだけれど、T.J. が指摘した Node.js の問題点は、僕たちが英語に対して抱く問題に良く似ていると思う。

    翻訳:僕が Node に残る理由 - ほんやくとコード
  • Farewell Node.js (翻訳) - from scratch

    「visionmedia、Node.js辞めるってよ」って事で、今回はこの話の翻訳ですね。 Farewell Node.js — Code adventures — Medium 最近のnode.jsはホントTJ Fontaine のリーダー就任から始まってNode.jsでできたエディタであるAtomがreleaseされたり、gemのモジュール数をnpmのモジュール数が抜いたり、socket.io v1.0が出たりと色々あるんですが、今回の話は飛び抜けて衝撃的だったなぁと思ってます。 一応知らない方のためにvisionmediaについて説明しておくと、以下のモジュールは全てvisionmedia製です。 express (Web Applicaiton Framework) mocha (Testing Framework) jade (hamlライクなtemplate engine) s

    Farewell Node.js (翻訳) - from scratch
  • プラレール・レイアウト・パターン。折り返し編 - プログラマでありたい

    プラレール用の電池の考察の記事を書いたように、最近はもっぱら子供とプラレールで遊んでいます。作っているとついつい、プラレールのレイアウトに凝りだしてしまいます。レイアウトを作る上で、無意識のうちに満たしたいと思っている要件があるようで、考えてみたら次の3点がありました。 自動で、ずっと走りつづける 切り替えポイントを使う 構築した全てのレールを利用する 自動で、ずっと走りつづける 1つ目の「自動で、ずっと走りつづける」という要件は、出発点と終点で終わらないということです。つまりループしているということです。この要件を満たす最低限の構成は、次のレイアウトです。 構成 1/2直線レール 4 曲線レール 8 切り替えポイントを使う 上記の例は、簡単ですね。ただ、この構成だと飽きるのが早いです。そこで2つ目の要件である「切り替えポイントを使う」が出てきます。具体的には、ターンアウトレールや8の

    プラレール・レイアウト・パターン。折り返し編 - プログラマでありたい
  • スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog

    2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している

  • プログラマの心の健康

    目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードをべながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。

  • 「なんでRubyなんか作った!? 迷惑だ!」に対するMatzの答え:Rails Hub情報局:エンジニアライフ

    2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の質について語っていました(44分の動画)。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。 以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半

    「なんでRubyなんか作った!? 迷惑だ!」に対するMatzの答え:Rails Hub情報局:エンジニアライフ
  • 都市部と地方の仕事の違いについて

    色白で腹黒だけどテーマカラーは緑、WP-D グリーンです。 僕は東京と地方都市をいったり来たりしながら仕事をしています。 (東京にも地方都市にも事務所を構えています。) 月の半分を東京、もう半分を地方で過ごすというスタイルです(4年目)。 ※最近はこのような方もチラホラいらっしゃいますね。 なんでこのようなスタイルになったのかと言うと、「いつかは地元に帰って東京で培ったノウハウやスキルを地元に還元したい」という思いがあったからです。 現在は仕事の9割以上が東京からの仕事です。 そんな立場の僕が感じる都市部と地方の違いを書いてみます。 ※主観的なところが中心なので必ずしも当てはまるという訳ではありません。その辺りはご了承ください。 1.都市部と地方の大きな違い 東京での仕事に慣れていた僕にとっては地方の仕事は驚きの連続でした。 ■単価の違い 半分などではなく何分の一かだったりします。 10年

    都市部と地方の仕事の違いについて
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type