タグ

仕事に関するbrendonのブックマーク (11)

  • 目標設定の基本

    NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2

    目標設定の基本
  • 「Be Lazy」を極めるためには残業をしてはいけない - メソッド屋のブログ

    「Be Lazy」というのは、日側の上司にあたる Drew がいつも口にしている言葉だ。その意味合いは、「最小の工数で、最大のインパクトを出す」 という考え方だ。私もアジャイルやリーンを学んできたので、「大量のものを高速に作れること」はむしろ悪であり、いかに「作らなくていいか」を考えてインパクトの出るものにエネルギーをフォーカスするのが重要と思っている。 しかし、正直に言うと、それは、日人の感覚からいうと最も縁遠い感覚だ。私がなぜ「Be Lazy」を極めたいと思っているか?というと、インターナショナル チームの同僚は仕事で成果をガッツリ出すのも尊敬に値するが、仕事をしている様子も実に楽しそうだ。誰も苦しそうだったり、我慢したりしていない。 仕事は楽しむものと言っていて、「我慢するべきもの」という日側の空気とは相当違う。私は自分も人生仕事を楽しみたいし、多くの人がそうなったらいいのに

    「Be Lazy」を極めるためには残業をしてはいけない - メソッド屋のブログ
  • RE: どんなことを勉強すればいいですか? - satococoa's blog

    仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか?」です。 それについてちょっとポエムを書いてみようかと思います。 主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。 専門家であるという視点から エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。 僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基がないと、曖昧な知識の上にさらに曖昧な

    RE: どんなことを勉強すればいいですか? - satococoa's blog
  • 鬱病で会社を辞めていった君へ - 私のちオレときどき僕

    社会人生活1年目を過ぎた頃。 僕に初めての部下が出来た。 名を綾野という。 綾野は専門学校卒で20歳。右も左も分からないような青年だったが初めての部下ということで、彼の面倒を見てやろうと僕は張り切っていた。 研修期間から担当してメールや報告書の書き方からみっちり指導。休憩で一緒にメシに行くようなことがあれば必ず奢っていた(自分も大してお金を持っていないくせに)。 要するに、先輩風をビュウビュウと吹かせていたわけである。 綾野はお世辞にも要領が良いとは言えなかった。むしろすこぶる悪いタイプだった。3ヶ月の研修期間が終わる頃になっても、誤字脱字等のいわゆるケアレスミスが多かった。その部分に関しては細かく注意したり敢えて注意せずに自分で気がつくように仕向けたり色々と試していたがなかなか改善傾向は見られなかった。 ただ、綾野のパフォーマンスが良くないことについて僕は楽観的だった。 自分が20歳そこ

    鬱病で会社を辞めていった君へ - 私のちオレときどき僕
  • 凡人のあなたが爆速で仕事をこなすための6つのポイント。 - プロジェクトマネジメントの話とか

    「何をしてきたかと同じくらい、何をしてこなかったかを誇りたい」 ――スティーブ・ジョブズ 君の周りに異常に仕事の速い同僚はいないだろうか?僕らが四苦八苦してやり遂げるレベルのタスクを、3倍~5倍のスピードで次々消化していくモンスターたち。 「彼らとはアタマのできが違うから…」 当にIQの差だけなのだろうか? 今回は、凡人が爆速で仕事を進めるにはどうしたらよいか、考えていこう。 スポンサーリンク 1.何をやらないかを決めよう 「何をしてきたかと同じくらい、何をしてこなかったかを誇りたい」 ――スティーブ・ジョブズ 大切なことなので2回言ってやったぜ、げへへ。自分の言葉じゃないけど。 ジョブズクラスの天才ですら、自分のリソースが有限であることを認識し、何を捨ててどのような仕事に集中すべきかにアタマを使っていたわけです。あれもこれも…そりゃ、全て完璧にこなせればベストだけど、人間(天才含む)に

    凡人のあなたが爆速で仕事をこなすための6つのポイント。 - プロジェクトマネジメントの話とか
  • 毎日コードを書くこと - snowlongの日記

    ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。(そして、うまく行かなかったら失敗したような気分だった。) 週末にいつも予定が空いている

    毎日コードを書くこと - snowlongの日記
  • 先に相手の予算聞けよ

    見積もり初心者の増田君にマジレスな。 先に相手に予算聞いて「う~ん、200万ぐらいかな~」って言ってきたら、それに合わせて見積もり作れ。 簡単な要求でも200万円分の機能をつけてやればいいし、難しい要求なら200万円以内でできる仕様にすればいい。 これができれば見当違いだったり桁違いの見積もり出して大失敗することはないし、確度はかなり高い。 ある程度精度のある見積もりを作った方がいい。 要求仕様だけ見せてきて予算を言ってこない場合は「降り」 これは発注先が決まっていて、社内でちゃんと相みつ取った証拠に使われるだけで完全に無駄な労力になる。 出すならバカ高い金額で適当に作った見積書出しておけ。 マジなコンペも「降り」 零細企業は5分の1とかのコンペに付き合ってる暇はない。 金額は限界まで下げないと取れないし、仮に取れても要求仕様も期間も厳しくなってデスマーチ確定。 無理しすぎたせいで納期内に

    先に相手の予算聞けよ
  • Eメールで作業内容を管理するのはやめましょう - GoTheDistance

    BacklogとかサイボウズLiveとかをご存じないクライアント様が結構多くて、そのような方々にとってのコラボレーション・ツールはほぼ間違いなくEメールになります。まずその啓蒙から入って仕事をさせて戴くことが多くなりました。 お打ち合わせの場でAction決めて、その後はちょいちょいメールフォローでだましだましやってこれた時もあったのですが、やっぱこれダメだってことになったので、その話をしたいと思います。 Why Email Collaboration SUCKS そもそも、Eメールは双方向性があるようで無いツールです。Eメールでの各種進捗管理は、以下の点で非常に効率がよろしくありません。 1つのメールに複数の事項が含まれることがある 例えば、Xさんに対してAという事項の修正事項が記載されたメールに対して、Xさんが返信を行ったとします。その返信に対して別のBという事項のご相談があると、追い

    Eメールで作業内容を管理するのはやめましょう - GoTheDistance
    brendon
    brendon 2014/02/11
    御意
  • とある人から、「インタビュアーの姿勢」に関して色々と教えてもらったことについて: 不倒城

    昔話をします。 多分十年くらい前、私がまだとある出版社に時々お世話になっていた頃のことです。 一般的なのかどうかはよく分かりませんが、その出版社には明確な職位としての「編集者」という仕事はなく、大体の人が、編集者もするしライティングもするし取材して記事起こしもするし、というマルチタスクな人達でした。 その配分も人によって色々で、複数の作者さんをマネジメントしつつ原稿を書いてもらう仕事の分量が多い人もいれば、取材に行って、その内容を自分でテキストに起こす仕事が一番多い人もいて、当時また出版社のことを「編集者さんがたくさん仕事していて、作家さんや漫画家さんに原稿をもらってる」という程度にしかイメージしていなかった私には、結構カルチャーショックな世界でした。 別にこれが一般的な出版社の業態だなどとは全く思っていません。なにせ小さい会社だったので、明確な分業がなされないまま属人的に色んな仕事が回っ

  • 10年計画 2008-01-05 - 2008年のはぶにっき

    not found

  • ITmedia エンタープライズ:あるWebプログラマーの作業環境――豪傑の三種の神器【後編】 (1/3)

    Zshを使おう! 前回紹介したWebアプリケーション開発における三種の神器。GNU Emacs、GNU screenと紹介してきましたが、締めくくりはZshです。ZshはBashやtcshなどと同じUNIXのシェルですが、プログラマー向けにさまざまな機能を搭載した高機能シェルといえます。Bashやtcshと比較して、機能的に大きく違うわけではありませんが、細かな使い勝手でほかのシェルにはない便利さが感じられると思います。 またわたしがほかのどのシェルよりもZshを推薦するのには理由があります。 Bashにしてもtcshにしても、シェル上で実行したコマンドをさかのぼる際にはCtrl+Rキーを押して、履歴のインクリメンタルサーチを行うのが便利です。例えばBashでは、

    ITmedia エンタープライズ:あるWebプログラマーの作業環境――豪傑の三種の神器【後編】 (1/3)
  • 1