ラバーダッキング法とは？悩みや問題解決に効果的な実践方法をご紹介！
ラバーダッキングとは問題解決手法の1つに、「ラバーダッキング」というものがあります。IT用語的にいうと「ラバーダック・デバッグ」とも呼びます。ラバーダックはゴム製のアヒルの玩具で、幼児がお風呂に浮かべて遊ぶ姿を見たことがあると思いますが、あのアヒルの玩具です。そんなものが問題解決にどう役立つのか信じられない方もいますよね。 ここでは、ラバーダッキング法を活用した問題解決方法について紹介していきます。 やり方は非常にシンプルです。 ・机の上など、目につくところにラバーダックを置きます。（ラバーダックが入手できなければ、小さなマスコットキャラクターでも可） ・現在、頭を悩ませていることをラバーダックに向かって、声を出しながら話します。 ただこれだけのことですが、声に出して悩みを説明する過程で、「何について悩んでいるのか」「その解決策は何か」ということが次第に見えてきます。 IT系のエンジニアな
退屈な技術を選ぶことについて
この記事は、著者の許可を得て配信しています。 https://panelbear.com/blog/boring-tech/ 注：この記事で書かれている考え方は、過去に何度も取り上げられています。長年にわたって私の視点に大きな影響を与えてきた記事の一つに、McKinley氏の「Choose Boring Technology（退屈な技術を選ぶ）」というものがあります。以下では、私自身の経験からこのトピックを探り、最近のプロジェクトでKubernetesを使うことになった経緯を紹介します。 長年にわたり、私は多くのエンジニアが会社の成功や失敗の多くを技術的な選択が原因であると主張する傾向があるところを見てきました。私にももちろんそういう時もあります。それはしばしば正当化されますが、大多数のスタートアップ企業にとって、プログラミング言語、フレームワーク、あるいはデータベースの選択はそれほど重要
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。 こんにちは。白山（@fushiroyama）と申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。 自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。 そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか？ 考えてみると、次の4つの戦略で生き延びてきたようです。 自分だけの居場所を見つける 必要な知識を効率的に取捨選択する 他のエンジニアに差を
「真面目さ」なんて社会で1ミリも役に立たないと早く気付くべきだった - ノンストレス渡辺の研究日誌
小・中・高・大学と真面目に生きてきました。 大人たちが言う「真面目に生きていれば報われる」という言葉を信じて。 しかし、社会ではそんなものは1ミリも役に立ちません。 役に立つどころか、ただ生きるのを辛くするだけです。 世の中にはまだ真面目さが美徳だと思っている人がいるのだろうか？ もしいるんだとしたら、早くその考えを改めないと大変なことになってしまいますよ。 真面目に生きてきた学生時代 本来の意味はさておき、現在「真面目」という言葉は、 先生の言うことや決まりをきちんと守れる子供 などに向けて使われています。 学生時代のぼくはまさにそんな子供でした。 真面目なことは良いことだという風潮を疑うことなく、そんな人間になろうと努力していました。 先生の言うことは素直に聞きました。 あれをやれと言われればそれをやり、あれをやるなと言われればそれをやめました。 それができない生徒は、自制心も礼儀もな
死ぬまでエンジニアでいたい - seri::diary
理想の死に方は、前夜にOSSのリポジトリにPRを出して、翌朝には机で突っ伏して死んでて、最期に出したPRのコメント欄がr.i.p.で溢れている。そんな状態。 なんて話を冗談めかして飲み会ですることがある。*1が、本人は割と本気で死ぬまでコードを書いていたいと思っている。 年金がもらえそうにないので生涯働かないといけないみたいな主張を最近各種メディア界隈でよく見る。しかし、それとは別に、体が元気なら死ぬまで働き続けていたいものである。定年で悠々自適におとなしくできる気がしないし、それに、エンジニアとしてならリモートでも働きやすいし、数十年後にはさらにそれに適した社会になっているとも思われるし。 死ぬまでエンジニアでいる。それはおそらく難しい。 40歳を超えた辺りで、現場を離れてマネージャーとかIT芸人とかCTOとか技術顧問とか、そにかく違う肩書で働くようになる人がたくさんいるを見てもわかるよ
エンジニアの幸せ - 読むために生まれ。
エンジニアにとっての幸せとは何だろうか。一般的には、エンジニアとは何かを作る人だ。橋を作る人、ビルを作る人、電子機械を作る人、ソフトウェアを作る人、これらは皆エンジニアだ。よって、創造の喜びというのがひとつの答えとなるのではないだろうか。 一方で、世の中には、何も作りはしないけれども、エンジニアと同じように高度な専門技術を持っている人たちもいる。医者や弁護士やコンサルタントだ。このような人たちにとっての仕事をとおしての幸せは何だろうか。私は、技術の行使がその答えだと思う。 後者の人たちの仕事は、顧客あるいは患者から持ち込まれた問題を解決することだ。なぜ彼らのところに問題が持ち込まれるかというと、そのような問題の解決には高度な専門技術を要するからだ。問題解決者としての彼らの興味は、自らの専門技術を行使していかに困難な問題を解決するかという点に注がれるのではないかと思う。難しい問題ほど挑戦し甲
Ruby書いたことないけどRuby書いた人の講演に行った - みたぬメモ
【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略 - connpassに参加してきました。若手エンジニアないしはエンジニアを目指す学生向けに、生存戦略を説く主旨の講演でした。まつもとゆきひろ氏とは、プログラミング言語・Rubyを作った人です。 全体的な内容はこちらのブログで非常にコンパクトに紹介されているのでご参照ください。 zuckey17.hatenablog.com 私のブログではまつもとゆきひろ氏もといMatz氏が語ったことを前半に紹介しつつ、後半に主観感想もまとめたいと思います。 ■生き残るには？ -死ななければいい。 「エンジニアの生存戦略、つまり生き残るには？」 その問いに「単純ながら、死ななければいい。」という皮切りでスタートした。 じゃあこの"死なない"ためにはどうするか。 そもそも生き残るとはどのような戦略を取ればいいのか？ Matz氏は「背景や環境など当然違う
ベンチャー系行ったらレベルが高すぎて辛い。 - 負け犬プログラマーの歩み
今の職場で働きだして少し経つが、既にエンジニアとしての自信を割と失っている。 俺は自分のことを少なくとも「そこそこのエンジニア」と思っていた。でも今の職場では、俺は下から数えた方が早い。「技術は有るが人間的にはクソ」と自負していた俺は今「技術者としても人間としてもクソ」となりかねない事態に陥っている。 言い訳の材料はある。周囲のレベルが高いのだ。 自分で言うのもなんだか経歴は豪華な人が集まっている。コアメンバーは最高学府(あえて誤用)卒はザラだし、某世界時価総額トップとか某金融会社とか某大手ゲーム会社に居たとか、某ソシャゲーの幹部とか、あのフリマサービスを作ったとか、別会社の元CTOでしたとかはたまた現役CTOやってますとか集えば、下流エンジニアも皇帝、四天王、１０傑（俺含まない）などの超一流だ。 文系で有名企業どころか正社員歴すらなく、名のしれた商品やサービスに協力会社の人間としても一度
日本人の低すぎる生産性と、IT打ち壊し百姓一揆
生産性の低すぎる日本社会デービッド・アトキンソン著『新・所得倍増論』を読んだ。日本社会は世界トップクラスの質の労働者を抱えながら、「一人当たりGDP」や「時間当たり生産性」 において極めて低い水準にあるという。その結果、先進国で最も貧しい国になっている。（いずれもデータに基づく議論なので、関心のある人は本を読んで確認してほしい。） そのような現状分析からの政策提言として、「政府がGPIF（公的年金ファンド）を通じて上場企業に『時価総額を上げろ』というプレッシャーをかけるべきだ」と書かれている。 曰く、日本の上場企業経営者は、国際水準ではまったくの無能であり、利益を出せていない（「3時に閉まる銀行」という例が何度も登場する）、無能な経営者を交代させることでしか生産性の向上はない、女性の活躍もないという論旨だ。 同様の提言は他の識者からもなされている。藤野英人著『ヤンキーの虎』では「5年平均で
エンジニアから見たSIerがクソな理由 - 負け犬プログラマーの歩み
少なくとも90%以上のSIerはクソだと思っている。 もちろん、これはポジショントークだ。SIerの中の人なら「SIerは最高だ」と言うだろうし、エンジニアをWeb系に売り込んで紹介料を稼ぐ転職エージェントなら「SIerはクソだ！Web系こそ至高！」と言うだろう。そして中立的な第三者であれば、一歩引いて日本にとってSIerは必要悪なのかどうかという視点で語るかもしれない。 しかし俺はエンジニアであり個人事業主だ。その上「技術的にはそこそこかもしれないが、人間としてはクソ」という特徴を持つ。だからこんな世渡りが下手な人間にとって便益があるかどうかという狭い視点でしか語れない。これが一般的な観点と言われれば否かもしれない。 それを前提で書かせてもらうと、よほど未熟でもない限り、エンジニアがSIerで働くのは時間の無駄だ。 なぜなら、SIerとはエンジニアの為の組織ではないからだ。 SIerの主
お題「エンジニア立ち居振舞い」 - はてなブログ
マイお題はユーザーが作ったオリジナルのお題です。このお題をネタに他のユーザーも記事を書くことができます。ブログのネタ探しや、ブログを書くきっかけにご利用ください。マイお題の使い方はこちら
iPhone７はいらない。 - Everything you've ever Dreamed
検討の結果、アイフォン７の導入は見送ることにした。このたびの見送りはごく私的で、かつ希少な理由によるものなので、アップル社には訴訟を起こすようなことのないようお願いしたい。もともと僕はスマートフォンで人生を革命された人間ではない。なので条件反射的に新型アイフォンに熱くなれない。愛用しているアイフォン６がまだまだ元気というのもある。だがそれらは決定的な理由ではない。私事で申し訳ないが、僕はケータイ時代から新機種を手に入れるたびに自分の尻を記念撮影している。なお、ここでの尻は臀部ではなく穴を意味している。15、6年前にジェイフォンから写メ機能が搭載されたケータイが出たときの衝撃を僕は忘れることができない。当時、駆け出しの営業マンとして走り回っていた僕は、忙しい毎日を送る一方で、永遠に続くような退屈な日常に怯えていた。その退屈さに光を当てたのが写メだった。写メ付携帯を買った日の夕べ、僕はなにか大
エンジニアが持続的に成長するスキルサーズデー型勉強会 〜なかだるみしない社内勉強会の運営方法〜
2016/08/25 CEDEC 2016
職人的であること、エンジニアであること | タイム・コンサルタントの日誌から
ちょっと贅沢をして家族3人でお寿司を食べに行った。ネタの新鮮さでは界隈で一番という店である。期待通りの、いや期待を超えた美味だったし、いつもは寡黙なメインの寿司職人さんが、珍しくいろいろ話をしてくれた。包丁の入れ方だけでイカはどれほど旨みが変わるか、雲丹は塩水保存とミョウバンを使ったものでは口どけが全く異なること、などなど。サンプルと実演を混ぜて教えてくれた。寿司職人の勤務時間や修業時代についても、語ってくれた。お盆の連休前で、リラックスしていたのかもしれない。 帰り道に、息子が感心したようにつぶやいた。「寿司職人て、なるのはやっぱり大変なんだね。時間も仕事もきつそうだし。でも、それだけ修行したら、あの人みたいな腕になるんだ。」就活が一段落したばかりの息子は、たぶん来年からの自分自身も重ね合わせて、感じ入ったらしい。「それに、あのイカの味の差！ すごい技術だよね。」 ——技術じゃなくて、技
long_time_work_cannot_finish_tasks
先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい？ 困ったことはない？」と尋ねられ、 僕は即座に「すごく楽しいですよ。日本で働いていた会社とは大違いです」と答えた。 「日本では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日本の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか？」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる
仕事が出来る人の勉強法 優秀なプログラマに学ぶ、効率のいい勉強の仕方 - ケーススタディの人生
「あの人はいつも仕事が速いし正確だ」 「なんであんなにもアイデアが出てくるんだ」 優秀な人、デキる人に対しては、これらのようなことを思うでしょう。 彼らのようになるにはコツがあり、それはアウトプットの試行錯誤だけではありません。 結論からいうと、デキる人たちは集中したインプットをしています。 みんながみんなというわけではありませんが、頭の回転がすごい人というのは事前に膨大な量のインプットをまとめて行っている可能性が高いです。 取り組む前にまとめてインプットしておくことで全体像を把握でき、また勉強にかかる時間も減らせる。 彼らはあまり語りませんが、実は裏でやっているというパターンがほとんどです。 目次 はじめる前に10冊読む 基本的な勉強は最初で済ませる 緻密な情報収集が成否を分ける まとめ こちらの記事もどうぞ！ はじめる前に10冊読む 優秀な人の特徴のひとつとして、発想や情報処理のスピー
マネジメントを経験してようやくわかってきた、半年で部下を１人前にするコツ - トイアンナのぐだぐだ
試行錯誤しながら手に入れた部下や後輩を半年で１人前にするコツをまとめました。 嫌な先輩から、まあまあの上司になるまで まずは私の経歴を少し。昨年独立するまで外資で働いていました。新卒で入ったのは少数精鋭にしたって、いくらなんでも少なすぎない？ と人事の肩を揺さぶりたくなる部署でした。 入社2年目には「もう１年いるんだからシニアだね！後輩指導よろしく」と宣告され、必死で３人指導してのち転職。その後はプロジェクトごとに部下を持っていました。独立した現在は外注マーケターとしてトレーニング業務も担当することもあります。合計で指導した部下・後輩は約10名前後。 最初は最悪の上司だったと思います。詳しくは「いつの間に自分が「細かいことにウルサイ嫌な先輩」になっていた 」に書きましたが、もうタイトルだけでお察しください案件。自分でもこれはいけないと思い四苦八苦した今、半年くらいで「いいね、それで行こうか
「アクションを起こさない理由」を説明するメンバーは暗闇プロジェクトに不向き
この連載では、先が見えない「暗闇プロジェクト」を担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。 前々回（現場に行かずにマネジャーが危機の予兆をつかむ方法は存在する）と前回（「役割分担をはっきりさせよう」、メンバーがこう言い出したら危機のサイン）では、危機の兆候を察知するためのセオリーを紹介した。今回も、関連した二つのセオリーを説明する。 セオリー1 「できる、できない」と「やりたい、やりたくない」の議論を混同しない マネジャーが「扱いにくいな」と感じる部下や後輩はどこにでもいる。IT企業に勤めるG氏はその一人だ。 G氏はこれまで複数のプロジェクトに携わってきた。ブロジェクトの規模や内容はそれぞれ異なるが、共通しているのはどのプロジェクトでもマネジャーがG氏に手を焼いたことだ。依頼された仕事にとにかく難癖をつけたがるのである。 「このタスクにこれだけの時間がかかり
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
優秀なプログラマーになるためのコツ
