学習、成長、生産性といったテーマについて最近ずっと考えているうちに、こんな話題が気になってきました。
さらに言えば、良い開発者と卓越した開発者は、どんな点で違うと思いますか?
開発者を、皆さんが属している、あるいはよく知っている別の役割・職種に置き換えて答えていただいてもありがたいです。 (e.g., テックリード, CTO, CEO, 創業者, デザイナー, PM, ...)
私は、卓越した開発者の共通点は大きく次の3つだと考えています。
-
問題認識: 他の人たちが問題だと認識すらしていないことを見つけ、改善の可能性を探します。
-
問題定義: 問題の状況や原因を非常に多様なレイヤーと観点から捉え、これまでの経験をパターン化することで、その問題をはるかに簡単な(あるいはより効果的な、より本質的な)問題へと還元します。
-
問題解決: 選択可能な複数のソリューションを思い描くことができ、それぞれのソリューションのトレードオフを理解したうえで、現在の組織の状況に合ったソリューションを選びます。その意思決定を、どの時点でどんなシグナルを見て変えるべきかも分かっています。そして、小さな単位で、素早くフィードバックを得られる方法で解決策を適用します。
6件のコメント
ファッションセンス0点。
共通点と言うなら、これしか思い浮かびませんね。
半分冗談で半分本気です.....haha
基本的に、私も開発者とは問題を解決する人だと考えています。
必ずしも開発者に限定して話す必要はないと思いますが、私は卓越した人たちの特徴として「つなぐ力」を挙げます。
知識や経験、アイデアなど、頭の中に多くのものを持っていて、それらをうまく結びつけられる人かどうかが重要だと思います。
問題を見つけたときに解決策を思い浮かべるのは一次的なつながりですが、
問題と問題を結びつけて複合的な状況を思い描き、別の解決策を探すのもつながりですし、
解決策やさまざまなアイデアを結びつけて、より簡便で柔軟性があり、優れた解決策を生み出すのもまたつながりだと思います。
開発に限らず、開発とビジネス的な要素を結びつけて考えたり、まったく関係のないもの同士を結びつけたりすることが、今の時代にはとても重要な能力なのではないかと思います。
spilist2 さん、こんにちは! Facebookでもご質問を投稿されていたのを見た気がします :) 私もいつも抱えている悩みなのですが、もしよければ、その論文の内容はおすすめできるものでしょうか?
論文はおそらく博士論文(dissertation)だと思うのですが、PDFベースで300ページもあるんですよね。 https://digital.lib.washington.edu/researchworks/bitstream/…
なので、まだ2章までしか(introduction, related works)読めていませんが、ここまででも内容はとても気に入っています。文章も難しくなく書かれていますし。おすすめです。
共有してくださった論文の中では、第6章がいちばん核心のように思えて読んでみたのですが、内容がいいですね! もう一度自分自身を振り返るきっかけにもなりました!! ありがとうございます。
質問を投げてから Google 検索をしてみると、いくつか記事が見つかりますね。
10x engineersというキーワードもありました。https://linkedin.com/pulse/great-engineer-vs-good-marissa-fayer-mba/
優れた開発者は、問題を解決するための特別な道具を備えている。優れた開発者は体系的で合理的であり、あらゆる角度から見て、考えうるすべての入出力を分析する。
卓越した開発者は、上で述べたすべての能力を土台として、それをすぐに使える解決策へ適用する。すでに知られているパターン(科学や数学の原理、リーン開発の原則など)を、創造的な方法で新しい現実の問題に適用する。
最も卓越した開発者たちは、耳を傾けることができる。問題に耳を傾け、ステークホルダーと彼らが価値を置くものに耳を傾け、市場に耳を傾け、フィードバックに耳を傾ける。そして、創造的な方法を思いつく内なる声にも耳を傾ける。
==
https://www.quora.com/How-do-you-identify-a-good-vs-great-engineer
回答がものすごく多いのですが、vote の高いものをいくつか見ると
(コンベヤーベルトに扇風機を持ち込んだ人の例を挙げながら)怠け者はいつも働かずに済む方法を探す。怠け者のエンジニアが最高のエンジニアだ。
優れたエンジニアは、依頼された問題を解く。ときどき自分の技術力を高めるための授業を受ける。卓越したエンジニアは、依頼されたことからさらに一歩先へ進む。
人々が質問をするとき、彼のところへ行く。
絶えず学習する。
知っていることを継続的に共有する。
正しいと思うことは貫くが、いつ手を引くべきかも分かっている。
泥臭い作業をすることを恐れない。
他のすべてのシステムにも似たバグがないか(あるいはすでに修正されているか)チェックする。
類似のバグが再び起こるのを防げる長期的な解決策や設計を提案する。(各解決策ごとの cost/benefit analysis を添付)
自分の専門領域の外にも目を向け、他のグループで似た問題が起きていないか探す。(あるいはすでに連絡を取ってみている)