エンジニアの思考を停止させる不安係数∞の罠 | F's Garage
エンジニアの職能の一つに「重箱の隅のような問題に気がつくスキル」というのがあります。このスキルのおかげで、見積もり精度はあがり、将来に起きうるリスクを防ぐことができるというメリットがある反面、不確実性のあることへの恐怖、100%の確信がないことから自分の発言に自信が持てない、決断できないなどのデメリットをもたらすことがあります。 これを総称して「不安係数∞」という言葉を、はるか昔から使っていましたが、それに言及した自分の昔のブログの記事でいいものが見つからなくなってしまったので、もう一度書いておきたいと思います。 我々は日常、たくさんのリスク要素に気が付きます。Webサービスならセキュリティホール、ネットワーク設定の不備、技術的負債に基づくスケーラビリティ問題などなどが代表例ですし、受託ならお客様の対応が信じられない、納期がころころ変わる恐怖、仕様が難しすぎて実現できないのでは？などなど。
個人的コードを早く書くための覚書
なんとなく書いてみた。というか書いてみると作業方針ぽくなったし、チケットの捌き方みたいになった。 IDEを駆使して自分の作業をoptimizeする ショートカットキーとコード補完などは覚える。 操作を行う頻度の多いもの、処理に時間がかかっているものを最適化するのが目的。 IDE自体の処理スピードがネックになる場合はチューニングすること。 タイピングからのレスポンシビリティが下がる、 ビルド・デプロイにコードベースの量から想定される以上に時間がかかる。 などと行った場合はなんらかのゾンビプロセスなりが存在しているかもしれない。 なるべくチケット化する これはプロジェクト方針と合致するかということも大いにあるけど、 基本的にチケットは細かくあったほうが良いと考える。 明らかに作業に対してチケットのタイトルが合致していない場合、 チケットにない作業をしている場合などが該当する。 タスクを細かく切
学習コストを下げるために大切な3つのこと ～エンジニア編～
子育てエンジニア advent calendar 2012 に刺激を受けて書きます。 世の中のパパエンジニアの人、色々苦労されてる反面、楽しくイクメンされてるようですね。 特に苦労されているところは学習コスト（金銭的・時間的）を払えなくなったというのを見ます。 しかもこれだけ変化が早いIT業界なら尚更です。 しかしながらIT業界で研鑽を止めると言うのは大変リスキーなことです。 私ももうすぐ5歳になる長女と2歳の次女、そして今は妻のお腹の中にいる第三子（長男）がいる子育てエンジニアです。 しかも私はエンジニアを志したときは既に長女がおり、独身時代の知識が0でした。 （最初はコマンドプロンプトからpingも撃てませんでしたｗ） そんな私が日々行なっている学習の3つのコツを紹介したいと思います。 １ 業務を通して知識を研鑽する これは一番手っ取り早く、かつ確実に行えます。 自分の興味のある技術を
Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成 - スタディサプリ Product Team Blog
ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス
「良いフィードバック」をするために覚えておいてほしいこと。｜TSUYOSHI KANEKO / GOGEN株式会社CXO
「フィードバックって難しい」配慮のないフィードバックをもらって傷ついたり、混乱したり..,。 逆にフィードバックの伝え方を失敗したり、言いたいことが言えなかったり... そんな経験のある人は多いのではないでしょうか？（特にデザインレビューのような定性的なフィードバックであればなおさら） 「良いフィードバックとはなにか？」を今一度考えるために、絶対に一度見てほしい動画があります。(約3分) 下記の動画はinVisionのクリエイターによる「優れたフィードバックを与える」ためのハウツーです。 当時の私は尊敬する同僚デザイナーにこの動画を勧めてもらい感銘し、それ以降フィードバックについて話すときは必ずこの動画を紹介するようにしています。 非常に本質的な知見が詰まった動画になっていますので、全デザイナー。ひいてはフィードバックする立場にあるすべての人に見てほしいと思っています。 まだ3,687再生
チャットを業務で運用する際の心がけ
エンジニアの職場でチャット（IRC, HipChat, Slack etc.）はごく自然な連絡ツールになっているだろうと想像しますが、僕のように非エンジニア社会で業務にチャットを取り入れようとするとそれなりの抵抗を受けます。 抵抗を示す人がチャットに慣れていない、あまり経験がないという場合もあれば、「どうせこんな感じでしょ」という少ない経験がそのすべてであると思い込んでしまうという人類全般に見られるあるある現象による場合もあるでしょうが、たしかにチャットを使えばすべて上手くいくなどということもなく、その意味でそうした思い込みも一概に間違っているとは言えず、他のさまざまなツールと同様にチャットもまた副作用的な問題を少なからず抱えているとは言えるわけですが、そのような事々もいくつかの点に注意を払っておけば大した問題ではなくなる、というのが僕の考えです。 もしエンジニアの職場でチャットが上手く使
新人エンジニアにレポートを書かせて技術書の読み方を伝える。 - @ledsun blog
技術者が1~3年目で成長するかは自習するかに依存してる。業務とは別に勉強する方法を叩き込めば誰でもそれなりに出来るようになる。 そんなわけで僕の所属している会社では年に5冊指定した本を読ませてレポートを書かせている*1。 なぜレポートを書かせるか 僕の所属している会社が採るような大学生は自習しない。分からないことや知りたいことがあっても本を買わない。業務をやるうちに実地で学べることはあるのだけど、実際に自分がやっていることが世間でどれくらいの位置づけなのか知っておくとなお良い。理想的な手法が使えているのか、それとも現場に合わせて翻訳して使っているのか。本に書いてあることと一致していれば普遍的なことなので覚えておけばいいし、書いていないことをやっているなら、下手をうっているか、現場に合わせた調整をしたかどっちか。そういうことを知っておくと違うプロジェクトに移ったときに同じ名前でちょっと違うこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームで働くための礼節と心理的安全性 / Civility and psychological safety for working in a team
計画する技術 / Planning is Skill
プロジェクトの道しるべ WBSの作り方