発注者「簡単なアプリです」エンジニア「簡単か否かを決めるのはお前じゃない」
発注者「誰かiPhoneアプリ作ってくれませんか？簡単なアプリです！！」 エンジニア「簡単かどうかを決めるのはお前じゃない。」 — のり@食べるの大好きエンジニア (@sugi511) 2014, 11月 10 発注側と受注エンジニア側だけでなく、同一社内の営業と開発という部門間でも生じやすいギャップのお話。はた目にはシンプルそうに見える、ちまたに沢山出回っているから簡便そうに見える、だから作るのも簡単だろう。作ってくれませんかと発注側は語るけれど、実のところ開発が簡単か否かを決めるのは発注側では無くて開発側。 数枚、あるいは数行の仕様での発注案件でも、いざ開発してみると山ほどのリソースを投入して数か月かけても終わらないという事案も山ほどある。プログラム、アプリ開発周りで分かりにくければ、料理などが分かりやすいかな。シンプルに見えるけど目新しくて美味しい料理。そこにたどり着くまでにどれほど
各国プログラマーのステレオタイプ的分類 - himaginary’s diary
タイラー・コーエンが、なぜソフトウエアでは一物一価の法則が成り立たず、米国や日本企業は自国の高いソフトウエア技術者を使い続けるのか――香港やシンガポールや中国ではもっと安価で雇えるにも関わらず――という一読者の疑問をブログエントリ化した。それに対し250を超えるコメントが付いたが、予想される通り、ソフトウエア開発においては単なるコーディングだけではなく、発注元と発注先とのコミュニケーションが重要なウェイトを占めるのだ、という指摘が相次いだ。その中で、各国のプログラマをステレオタイプ的に寸評したコメントが少し面白かったので、以下に訳してみる： Well, while we are being rude let me speak… It’s not the individuals of course, but the culture. And culture is why Americans
「美しいソースコード」に価値はない - カタチづくり
「美しいソースコード」を書くために頭を捻っている時間は「コスト」だ。「価値」じゃない。 同様に、「醜いソースコード」の解読やデバッグに費やす時間も「コスト」。 要件定義も設計もテストもリファクタリングもみーんなコスト。どれもそれ自体に価値なんてない。 それがお客さんの手に渡って、きちんとお客さんに利便性を提供したときに初めて「価値」が生まれるんだと思う。 つまり「価値」を自分だけで生み出すことは不可能ってこと。「価値」とは「評価」だから。他者に評価してもらって初めて「価値」になる。僕たちが自分だけで出来るのは、ただ「コスト」を積み上げるだけ。それに「価値」を認めてもらうにはお客さんの存在が絶対に必要。 できるだけ大きな「価値」を最小の「コスト」でお客さんに届けたい。そう考えたときに「美しいソースコード」にこだわるべきか否か。コードの洗練にかかるコストと、醜いコードのまま放置した場合にメンテ
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
