個人的な老害エンジニア行動指針を策定した - tehepero note(・ω<)
2016 - 07 - 01 個人的な老害エンジニア行動指針を策定した エンジニア 自分は今33歳なので、Webの世界においては完全に 老害 と言われてもおかしくない世代にさしかかっています。自分は 老害 には決してならないと強い意思を持っていたとしても、どうやら 脳科学 的には避けられないものだと聞いたことがあります。 というわけで、意思よりも明文化すべきだろうということで個人的にではありますが、 老害 エンジニアとしての行動指針 を策定致しました。 若くないことを肯定し、世代の違いを認識する 親の世代に比べると例えば今の30代は過去の30代よりも若いし、40代は過去の40代よりも若い人が多くなったというイメージがあります。自分が子供の頃の30overって完全にオッサンオバハンのイメージでしたが、少なくとも見た目の面では変わってきている潮流にあるのでしょう。老化のスピードは緩まっているの
⼤企業で実現するイマドキの内製開発
1. Copyright © NTT Communications Corporation. All rights reserved. 1 ⼤大企業で実現するイマドキの内製開発 NTTコミュニケーションズ株式会社 技術開発部 岩瀬 義昌 2015年年7⽉月29⽇日 【A-‐‑‒5】【ユーザ企業登壇！】先進企業が語る、 ソフトウェア開発環境のビフォーアフター 2. Copyright © NTT Communications Corporation. All rights reserved. 2 ■名前 岩瀬 義昌 / @iwashi86 ■仕事 NTTコミュニケーションズ株式会社 技術開発部 Webコア Technology Unit Web/インフラ エンジニア ⾃自⼰己紹介 ■コミュニティ活動 ・WebRTC Meetup Tokyo
TechCrunch
In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today emailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
BPStudy#92で「エンジニアの経営学」の話をします - GoTheDistance
おはDで有名なビープラウド佐藤治夫 (@haru860) | Twitter様よりご依頼を頂きまして、お話をさせて頂きます。BPStudy91,BPStudy92と連投でございます。 bpstudy.connpass.com 注意事項 イケてるWebサービスのビジネスモデルみたいな話は一切しません。 自社サービスを成長させる為にみたいな話は一切しません。 エンジニアは経営者になれ(ﾄﾞﾔｧ みたいな話は一切しません。 会計(簿記の基礎や決算書の読み方的な)話も一切しません。 社内政治や人間関係がどうこうみたいな話も一切しません。 僕のマイブームはWelcome | Flask (A Python Microframework)ですが、flaskの話も一切しません。 テンション上がると野球の話に切り替わる恐れがあります。 お話したいこと 皆さんに「会社を見る目」を養って欲しいと思っていますの
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
デキる企業ではもう当たり前、会議を「任意参加」にするメリット | ライフハッカー・ジャパン
あなたの勤めている会社で、すべての会議が任意参加になったとしたらどうでしょう？ 想像してみてください。どんな会議にも、出席を強要されなくなるのです。このルールが適用されたら、どれだけの無駄な会議がなくなると思いますか？ 実は現在、こうした動きを見せる賢い企業が増えています。 ソフトウェア企業であるAtlassianのインフォグラフィックによると、標準的な企業の従業員は、1カ月間で31時間を会議に費やしていますが、そのうち少なくとも50％の会議は、完全な時間の無駄だと思われているそうです。91％の人は、少なくともいくつかの会議でボーッとしたことがあり、75％は隠れてほかの仕事をしたことがあり、39％は居眠りをしたことがあるそうです。さらに、こうした不必要な会議による損失額は、年間で実に370億ドルにも達します。 管理職クラスの場合も、大差はありません。コンサルティング会社Bain & Com
そろそろ「プログラマー35歳定年説」を徹底論破しとくか - 書架とラフレンツェ
世の中に流布している「プログラマー35年定年説」は、大きく以下の3つに分類できる。 プログラマーは激務なので、35歳を過ぎると体力低下のために続けられなくなる(体力低下説) プログラマーは常に新しい情報を吸収しなければならないが、35歳を超えると脳の働きが低下して新しいことを覚えられなくなるために続けられなくなる(学習能力低下説) プログラマーは35歳を超えると開発ではない業務を求められるようになるので、技術職としてのプログラマーのキャリアが途絶える(マネージメント原因説) 以下、ひとつずつ検証していく。 体力低下説 まず1つ目の「体力低下説」だが、これについてはそれほど深く考る必要がなさそうに思える。周知の通り気力や体力には個体差があり、若くても元気がないひともいれば歳をとっても元気なひともいる。また、35歳あたりの体力低下の原因としては、単純な加齢というよりも生活習慣の要因の方が大きそ
WIPであろうと、情報共有すると何がいいのか？ - ppworks.jp
口頭で話したことを文字に起こすことについての続編のような記事です。 消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。 口頭で相談したことをesaやqiita:teamにまとめる 口頭でコードレビューしたことをgithubやgitlabのコードレビューのコメントにも書き残す 口頭で話したことをチャットにも書き残す チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す 情報共有すると何がいいのか？ 何がいいか。 暗黙知を減らすことが出来る 当事者に なろうと思えばなれる なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるという
マネージャのいない組織に進化する現実と幻想 - ワザノバ | wazanova
マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。 1) 非同期 & 可視化が進む GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。 2) マネージャの役割が変わる 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。 プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向
難題にぶつかったときは、必ず2つ同時に取り組むべし。その理由 | ライフハッカー・ジャパン
仕事や私生活において、ときに単純なステップ・バイ・ステップの、規則的なやり方では解決できない難しい問題にぶつかることがあります。いらつきや燃え尽きを防ぐために、こういった問題には2つ同時に取り組むべきだということを推奨します。でも、2つより多くてもいけません。 作家で、大学の助教授でもあるCal Newportは自身のブログで、「『決定できる』課題と『決定できない』課題の違い」について論じています。 決定できる課題というのは、規則的な手順に当てはめれば解決策が明らかになるものです。こういった問題には、細々した仕事や散らかった家の掃除などが挙げられます。 一方、決定できない仕事とは、もっと大きく、解決方法がはっきりしない問題です。 例えば、作家が本の新しいアイデアを考えるとか、事業家が損失を取り戻そうと考える...といったことです。こういった問題の解決策ははっきりしておらず、規則的なやり方で
会社は儲けるためにあるのか - $shibayu36->blog;
以前、「会社は儲かればいいのかもしれないけど」というワードを聞いたことがあって、今から考えるとそうではないんじゃないかな―と思ってきたので、適当にメモとして残しておく。 今のところの個人的な意見としては、会社は儲けるために存在するのではなくて、社会的に価値を提供するために存在し、そして社会的に価値を提供した結果、自然と儲かるだけであると考えている。ただし、以下の様なことから少し問題を複雑にしているとは思う。 社会的に価値を提供し続けるためには、儲かっていなければならない 価値というのは、それが人に理解されなければ発生しない このへんの話いろいろ難しいのだけど、会社は儲けるためじゃなくて社会に対して明確な価値を提供するために存在していると僕は考えていたいし、その価値を提供し続けるために儲かっている状態を作り出さないといけないとも思う。ただし、これを逆転させてはならなくて、儲けるために会社の提
Qiita:Team を3ヶ月運用してわかった中長期的な運用 Tips 3点 - kakakakakku blog
どうも！CQO の @kakakakakku ですw （参考：CQO : Chief Qiita:Team Officer - kakakakakku blog） 今日は Qiita/Qiita:Team Meetup #9 Fukuoka があるので，参加したかったんですが，LT するためだけに東京から出張する許可をもらえず，残念ながら不参加となってしまいました． Meetup に参加できないことには変わりないのですが，Meetup を盛り上げたい！ということで，LT の代わりに1本エントリーを書きます． 中長期的な運用 Tips 3点 Qiita:Team を導入したのが去年の11月だったので，もう3ヶ月もたったことになります． チーム内のアカウントは23人にまで増えましたし，今まで Redmine や ChatWork にドキュメントを書いていたのが嘘のようで，もう全て Qiita:
チームを破壊しているのは議論好きなあなた | サイボウズ式
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は、日野瑛太郎さんによる「チームを活性化する議論のやり方」について。 チームで働いていれば、時には議論をすることもあるはずです。以前、「民主的なチーム」が崩壊した話という記事の中で話し合いばかりしているチームの問題点について書いたことがありますが、これの逆で一切議論をしないチームというのも不健全です。議論したことで一人では到達しえなかったよりよい解決策が見つかることは少なくなく、こうやって「他人の頭」を借りることができるのもチームで仕事をすることの醍醐味の１つです。 2014年5月19日「民主的なチーム」が崩壊した話 もっとも、ただ議論をすればそれでいいというわけではありません。議論はやり方に注意しないと、時にはチームワークを大きく乱す原因
気づかぬうちに増える仕事を減らす取組み - ワザノバ | wazanova
https://codeascraft.com/2014/12/22/engineering-rotation/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 「このタスク、思ったより時間がかかったな。」となるのはよくあることですが、仲間と仕事をするということは皆で大きなことを成し遂げているということなのだというそもそものメリットは空気のように忘れがちで、ある程度の非効率は避け難く生じるし、それが目につくのでストレスの元。どう解消するか？ 元Quoraのリードエンジニアで、現在Quipに勤務するEdmond Lauは、"Hidden costs that engineers ignore”"と題したブログのエントリーにおいて、 コードの修正だけでなく、別のメンバへの説明の時間はかかる。 単純に分量で
要求の複雑性とアーキテクチャの複雑性 - assertInstanceOf('Engineer', $a_suenami)
なんか朝ふと考えたこと特にまとまってない状態で書いてみる。もしかしたら今年最後のエントリになるかもしれないエントリがそれでいいのかっていう気がしなくもないけど。 僕たちのようにソフトウェアをつくている人たちは本質的に複雑性に立ち向かうことが主な営みである。世の中というのは複雑であり、その複雑な世の中で問題とされていることを解決しようとするとその中でもとりわけ複雑な領域を取り扱わなければならない。そうでなければそもそもソフトウェアなど必要ないことになる。人間がそれをやるにはワーキングメモリが少なすぎるとか、時間がかかりすぎるとか、原因は何かわからないけど何らかの理由によりちゃんと遂行できないものこそソフトウェアをつくって解決するべきなのだということになる。 逆に言えば僕たちソフトウェア産業従事者が今も仕事を手に出来ていてちゃんとご飯が食べられているのは世の中が複雑であることの恩恵かもしれない
【最新版】これくらいは知っときたい、源泉徴収票の見方！ - みんなの給与計算教室
こんにちは、給与計算教室です。 2014年も残すところあと2週間ほどになってしまいました。今年はソチオリンピックや消費税UP、モーニング娘。'14 道重さゆみさんの卒業と12期メンバー加入、Berryz工房の無期限活動停止発表、スマイレージ*1 3期メンバー加入などなど、本当にたくさんの出来事がありましたね。 そんな2014年を気持ちよく締めくくるためにも、今日は源泉徴収票の読み方について解説します。ちょうど今ごろから来月にかけて、会社からみなさんのもとへ配布されていることでしょう。一昨年にも同じような記事を書いたのですが、法改正もありましたし、もう少し分かりやすく書き直してみることにします。 スポンサーリンク 源泉徴収票とはなんなのか すぐなくしてしまいそうな紙切れ1枚ですが、そこにはとっても大事な情報が載っています。まずは 今年一年間、あなたがいくら稼いだのか それに応じていくら所得税
エンジニアリングのマネージメント | GREE Engineers' Blog
こんにちは、岡崎です。最近はグリーのインフラチームにおける開発のマネージメントを担当しています。 このエントリーは「GREE Advent Calendar 2014」2日目の記事です。昨日は岸田さんによる「イノベーションが失われた組織から脱却する10のルール」でした。 さて、気がつけばここに書くのも昨年のAdvent Calendar 2013「開発ワークフローを、いつどう変えるか」以来です。去年は開発プロセスについてやってきた事の振り返り記事でしたが、今年も同じようにこれまでのプロジェクトを振り返りながら今回はエンジニアリングのマネージメントについて考えてみます。 エンジニアリングマネージャーとはどのような責任を持っているか エンジニアリングマネージャーとはどのような責任を持った役割でしょうか。本題に入る前にまずは「責任」という言葉の定義について確認しておきます。 「責任」と一言で言う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pocket - My list
職場ストレスからの未来型・避難場所「Orrb」
Loading...