Living as engineer
ネット上では「@higepon」のIDで知られる日本人のソフトウェアエンジニア、蓑輪太郎(みのわ・たろう)さんは、2014年9月現在、米国サンフランシスコ市内にあるTwitter本社に勤務している。前職であるサイボウズ・ラボを退職し、Twitterの日本法人へ転職したのは2年半前。ビザ手配の関係から渡米が遅れたが、1年8カ月ほど前に妻子を連れて家族ごとサンフランシスコへ移住した。 もともとエンジニアとしてアメリカで働いてみたいという憧れがあったという蓑輪さん。単に「憧れ」というだけではなく、着々とプログラミングや英語といったスキルを磨き上げて渡米したという印象が強い。「いつも当初の計画の数年遅れ(笑)」と自嘲気味に笑う蓑輪さんだが、数年単位で「憧れ」を1つずつ実現してきたことから周囲のエンジニアからも一目置かれる存在だ。 蓑輪さんは、趣味でOSや言語処理系を実装したり、IPAの未踏ソフトウ
かつてないほど手軽にネットショップ運営を始められる「BASE」。今年の5月には3億円の資金調達に成功し、今、最も勢いのあるECのスタートアップだ。同社に約2年間にわたって技術顧問として関わってきた「えふしん」こと藤川真一氏が、このほどCTOとしてジョインした。 エンジニアとして名高い藤川氏だが、BASEでは「コードを書かない」と公言している。代表の鶴岡氏の掲げるビジョンを具現化し、サービスを成長させるために、マネジメント業務に徹することを決めたという。藤川氏が考える、エンジニアにとっての理想の組織、そしてキャリアパスについて、詳しく話を聞いた。 なぜ藤川氏は「コードを書かない」のか? ――BASEでは「コードを書かない」と宣言されていますが、それはなぜですか? 藤川:一言で言うと、コードを書いている余裕がないからということに尽きるのですが、BASEにはすでにある程度の規模のチームがあるので
Photo by Jonathan Kos-Read 今回のpaiza開発日誌は片山がお送りします。 SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか? その点について今回は少し整理してみようと思います。 ■「多重下請け構造」とは何か 説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請(たいていの場合が大手SIer)が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。 良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3
OR メールアドレスで登録上記ボタンのクリックにより、利用規約 及び 個人情報の取り扱い に関する要項に同意したものとします。 ※X(旧Twitter)での登録時に不具合が発生する場合があります。その際は他の登録方法をご利用ください。 アカウントをお持ちの方はこちらからログイン
※会員ページにて本日より天才火消しエンジニア霧島の水着壁紙(2560x1600、1024x768)がダウンロードいただけますので、会員登録がまだの方はご登録が必要です。 2014年7月30日より開始したpaizaオンラインハッカソン(略してPOH![ポー!])Lite「天才火消しエンジニア霧島 もしPMおじさんが『丸投げ』を覚えたら」ですが、2014年8月27日いっぱいをもって開催期間を終了いたしました。(コードの実行自体は引き続き可能です)。 今回のオンラインハッカソンは、誰でも参加しやすいように問題の難易度をこれまでよりも少し下げ、ヒント機能等もつけた形でした。今回も数多くご参加いただき無事オンラインハッカソンを終える事が出来ました! 今回はpaizaオンラインハッカソンLiteのレポート、最終結果と、提出された各プログラミング言語毎の最速コードについてお届けします。 ■言語別 最速・
本稿では、まず「ウェブサービス開発の現場で、ウェブデザイナーの仕事はエンジニアに奪われつつある」という脅威を語る。次に、生存戦略を考えるヒントとして「分かりやすい生存戦略」を2つ提示する。「アートディレクター」と「フルスタックウェブデザイナー」という2つの生存戦略だ。 なお、「仕事を奪われていくプロセス」と「生存戦略を遂行するプロセス」について、5〜10年程度のタイムスパンをイメージしている。 ウェブデザイナーの仕事がエンジニアによって奪われつつある ウェブサービス開発の現場では、ウェブデザイナーの仕事がエンジニア/プログラマーによって少しずつ奪われつつある。とくに小さな組織や新規事業の現場では。 象徴的なのは「Bootstrapがあればデザイナー不要だよね」論。「もはや社員としてデザイナーを雇う必要はなくて、必要な時にランサーズで発注すればいいよね」「スタイルシートいじったり画像パーツ作
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
「その便利そうなやつ、何使ってるんですか?」的ツール百選 (のうち10個くらい) DIST#4 LT発表資料Mactool DIST.4 「Life is Short」 のLT発表資料です。 紹介するツール一覧 (基本、Macです) デザイナー、ディレクター、エンジニア問わず、誰でも使えるやつ エンジニアむけ いちおう下記、分類してますが、紹介する順番はいい感じのやつ順です。 誰でも使えるやつ Alfred : ランチャー Kiritori : 画像付箋化 ClipMenu : クリップボード拡張 Skypeログ整形ツール Table→マークダウン MacでWindow切り替え(⌘+F1) Fluid (Mac) : Webサイトをアプリ化 Push Bullet : なんでもpush通知 エンジニアむけ CodeRunner (Mac) : なんでもコード走らせる Google Apps
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
2014年7月30日より開催中のpaizaオンラインハッカソン(略してPOH![ポー!])Lite「天才火消しエンジニア霧島 もしPMおじさんが『丸投げ』を覚えたら」ですが、たくさんのご参加ありがとうございます。引き続き開催中ですので、まだチャレンジしていない方は是非チャレンジください。 今回の物語では、主人公霧島京子の発注元にあたる1次請けSIerのPM火村氏に、いかにアホなコードを書かせるかという事で色々悩んだのですが、ネタとしては面白いが可読性が悪すぎてヒントにならないという事でお蔵入りしたコードを紹介ます。 ■しょうもなさ過ぎてお蔵入りに… 今回は、これまでのオンラインハッカソンVol.1、Vol.2よりも難易度を下げて、より参加しやすい形を目指して、タイトルもPOH Liteとしました。物語の中で提示される元受PMの火村氏が書いたコードを読めば「愚直な解き方はある程度分かる」とい
今いる会社でプロジェクトはいくつかあって、それぞれのチームにエンジニアが居るんだけど、僕のチームでは厳密にはエンジニア1人でやっている。 最近、ただ単にぼっちなのが寂しいのかこの半年で急激にエンジニアの数が増えてきてコミュニケーションの機会が減ったのか僕が昼すぎから出社するからなのか、理由はよくわからないけど、会社の日報に日々思ってることを長文にして投げたりとか、Wikiにポエム書いてたりしてたら、なんとなく他のチームにも伝搬していってて日報にポエムが溢れかえるようになった。お前ら女子か。 ポエムというのは言い過ぎかもだけど、日々思っていることをチームの中に共有するのはすごいいいものだなぁと感じる。日報、ありがちなのはその日にやったことを書いたりするけど、僕はあんまりそういうの気にして無くて、「君がいるチームのリポジトリでgit logすればわかることやん?」ってなる。いや、もちろんそうい
2014.08.05 スキル 業界で名の知れたプログラマーは、今年の上半期に何を学んでいたのか? 「同業者が役に立ったものは、自分にも役に立つはず」という仮説を基に、彼らの学びlogから、2014年上半期の流れを振り返り、今後の動向を予想してみよう! 株式会社nanapi 取締役 CTO 和田修一氏 (@wadap) 中央大学経済学部卒業後、2005年に楽天入社。楽天市場の運用担当のほか、台湾版楽天市場の設計・構築・運用などに携わるなど、インフラエンジニアとして活躍。現在は、CTOとして2009年9月オープンのライフレシピ投稿サイト『nanapi(ナナピ)』を技術・経営の両面から支えるかたわら、講演や執筆、メディア出演経験も多数。個人ブログ『Unix的なアレ』も人気
ペパボの新しいエンジニア評価については、ペパボのエンジニア評価制度をパワーアップしたで既にお知らせしたところです。さて、今回その評価が終わり、総評を書いたので、さしつかえない範囲で公開します。 ちなみに、技術上級職については既に「ペバボのエンジニア職位制度のアップデートについて」で紹介しています。そちらも御覧ください。 制度の概要 そのエントリにもある通り、新しい制度では、以下の特徴があります。 エンジニア全員を、エンジニア集団である技術基盤チームが評価する GitHubに評価用の提出資料をまとめpull requestを出してもらい、それに基いて、結果も含めて全員にオープンな状態で評価する あらためて上記のエントリを引用すると: 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く