タグ

managementとdevelopmentに関するhush_puppyのブックマーク (112)

  • 大規模SIは少数精鋭で乗り切れるのか? - 急がば回れ、選ぶなら近道

    まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術

    大規模SIは少数精鋭で乗り切れるのか? - 急がば回れ、選ぶなら近道
  • 『国境なきプログラマ』を目指す~ノマドワークの究極のかたち | Social Change!

    先週末から、SonicGardenのプログラマである @maedana が、住居をアイルランドのダブリンに引っ越しました。一方で、SonicGardenの仕事は続けてもらうことになっています。少し面白いワークスタイルなので紹介します。 View Larger Map 彼は特にアイルランドに縁もゆかりもあるわけではないですが、英語を身につけたいというモチベーションがあり、英語圏で彼の年齢で長期滞在が出来るところは限られており、結果としてアイルランドに決めたようです。(ただダブリンはRubyにゆかりのある松江市と姉妹都市らしいというのを後から知りました。縁ですね。) 当社(SonicGarden)では、以前からどこでも仕事が出来るためのノマドなワークスタイルを目指していました。その為に、仕事は当然ノートPCですし、システムはすべてクラウドに置き、厳密な勤怠管理をするのではなく自主性を重んじるな

    『国境なきプログラマ』を目指す~ノマドワークの究極のかたち | Social Change!
  • マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発(前編)。Agile Conference tokyo 2011 - Publickey

    アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化(Semantic Diffusion)が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画(Predictive Plannning)」と「適応的な計画(Adaptive Plannning)」について。 土木や建築に由来するのが「計画駆動開

    マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発(前編)。Agile Conference tokyo 2011 - Publickey
  • エンジニアの役割

    技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら,自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし,当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても,難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは,「こんなものを作っても誰も使わないんじゃないか,会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が,「自分たちがど

  • 開発中に求めること - ✘╹◡╹✘

    7月1日にCookpadにインターンとして参加してから1週間が経過した。「インターンに参加する」では齟齬があり、「インターンとして参加する」が最もしっくりくる雰囲気。ここでは時間が過ぎていくのが速すぎて恐ろしい。月と太陽まで高速なサイクルを回さなくてもいいのに。 今まではてなで働いた経験しかなかったけど、今回クックパッドで働いた経験が1週間貯まった。これまでは「はてなだからこうしているのかもしれない」という捉え方しか出来なかったけど、この時点で「ああどこも共通してこうなっているのかも」という視点に立って考えることが出来る状態になった。その視点から考えてみて、幾つかの共通する意見が明確になってきた。 学習コスト Cookpadの開発は、途中からJoinしやすい環境が整っていた。Railsを採用しているところは特に、内製フレームワークに対する理解の為の学習コストが発生することなく、開発に取り掛

    開発中に求めること - ✘╹◡╹✘
  • http://japan.internet.com/busnews/20110627/2.html

    hush_puppy
    hush_puppy 2011/06/27
    サブのモニタがあると重要ではないものをそちらに放り込めてメインのモニタでの作業で集中できる。あと紙全般やホワイトボードなどのアナログな手段もモニタの使用面積の節約になる。
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type
  • 本当はすごい codefirst の開発環境 - suer のブログ

    (記事は @suer, @mallowlabs, @mzp がノリノリで共同執筆しました!) 近代的なソフトウェア開発に必要なツールは3つある。 分散バージョン管理ツール ITS CI ツール 私はこれに AsakusaSatellite (以下AS)を加えたいと思う。 以上の4ツールを使用することによって、迅速なコミュニケーション、洗練された自動化をベースとした開発リズムを体験することができる。 このあとの節では具体的なユースケースをベースに、上記ツールの連携方法及びそのメリットをみていく。 ユースケース:開発中にソースコードの特定行で例外が発生した原因を探る ここは codefirst の開発室。 @suer と @mallowlabs と @mzp はリズム良くコードを書いています。 そんなとき、ビルドの異常を知らせるポップアップが表示されます。 さっそくAS 上でミーティングがは

    本当はすごい codefirst の開発環境 - suer のブログ
  • あなたのソフトウェアプロジェクトが破滅する10のサイン

    週末はやはりリストものという事で、古典的なリストを紹介します。このリストはマイクロソフトでもいくつものプロジェクトを手がけていたDare Obasanjo氏による物です。マイクロソフト繋がりなのかジョエルスポルスキー氏の著作でも見られるような考え方に近いですが、かなり普遍的に当てはまるリストになっています。 最初から機能を詰め込みすぎ 不確かな技術に依存している 稼ぎ頭だったり政治的に強い別な社内プロジェクトと競合している 人手が足りない 複雑な問題を複雑な方法で解いている スケジュールの遅れを報告できない スコープが拡大している セカンドシステムシンドローム プロダクトがエンドユーザーに使われる見込みが無い 解決できるかわからない問題がある このサインを感じ取った所で、実際にエンジニアが打てる対策はあまり無いのが難しいところです。いくつかのサインがあるくらいならまだなんとかなるのでしょう

    あなたのソフトウェアプロジェクトが破滅する10のサイン
  • これが本当のWeb男子。朝起きたら早く会社行かなきゃと思いつつRSSリーダーを消化

    これが当のWeb男子。 先週「ゲットするなら断然Web男子!」という記事が話題になっていたがあれは後半が浅い!という声を聞いた。違うよ。全然違うよ! 「今とても旬、そしてまさに買いどきな男子をチェックしましょう。」ってなんだよ(笑。 hara19.jpでは早速その中の一人にインタビューしてきたのでリアルなWeb男子像に迫りたい。 彼が誕生日だったので夜景が見える美味しい和をご一緒してきたよ。 Web男子のプロフィール今回登場してくれたのは港区にお勤めの28歳男性。仮にTクンとしよう。 ・誕生日を迎えたばかり。おめでとう! ・Webエンジニア ・港区の会社に勤務 ・今フリーだけど顔出しはNG(><) ファッションはカジュアルなYシャツにカーディガンと綺麗目で清潔感あり。 Web男子の一日ファッションチェックやかばんの中身チェックをしてみようかと思ったがかばんは財布と鍵しか入ってないとのこ

    これが本当のWeb男子。朝起きたら早く会社行かなきゃと思いつつRSSリーダーを消化
    hush_puppy
    hush_puppy 2011/06/06
    昼食の時間が自由なのって地味に重要な気がする。時間が決まっていると昼食前の数時間は気合いが必要な作業を避けがちになる。ポール・グレアムの"クリエイターのスケジュール"に近いかも。
  • 良いデベロッパになる為の13のTIPS

    読みやすいTIPSのリストが話題になるのは洋の東西を問わず見られる現象です。ハンガリーのブタペストのデベロッパ、Csaba Okronaさんが書いた記事が話題になっていました。さっそくその項目を見てみましょう。 レッスン1 全体像を理解せよ コーディング作業だけに囚われず、ビジネスやプロジェクト等の面からも理解する。 レッスン2 自分の時間を確保せよ 残業や早出は結局バグを招く。スピードは良いデザインと正しいアーキテクチャから生まれる。 レッスン3 間違った時は考え方を変えるチャンス 既存の技術で問題が遅くなってきたような場合は新しい技術へ移行する。ただし既存の技術がうまく行っている場合にただトレンドを追ったりはしない レッスン4 脳を鍛え続けろ 日々のタスク以外の鍛錬を行え。コードゴルフなどはよい例 レッスン5 人生を大事にする 特に重要。残業が続けば燃え尽きるのも早い。 レッスン6 集

    良いデベロッパになる為の13のTIPS
  • 蒼と碧の幻想 プロジェクトマネジメントのノウハウ(2011/4)

    受託系ソフトウェア開発チームのリーダーをやり続け、現在までにおおよそ20プロジェクト全勝・・は言い過ぎだけど、とりあえず無敗とは言えそう♪ 最初の会社では「なんでそんなにうまくいくのかさっぱりわからない」と言われ続け、今の会社ではチームと個人の賞を独占したノウハウをタダで公開♪ -- ●リード 1)プロジェクトの成功には、短期的な成功と中長期的な成功をがある。両方を意識すること。 2)プロジェクトの短期的な成功は、お客さんを満足させて利益をあげること。 3)プロジェクトの中長期的な成功は、メンバーが成長することとメンバー同士がまた一緒に仕事したいなと思い合うこと。 4)リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 5)ほとんどの人にとって仕事はあくまで生活の手段。生活のイベントより大切な仕事のタスクなんてない。 ●フラット 1)リーダー、

  • 個人で作ったWebサービスの仕様書(Evernoteのメモ)を2つ公開してみる - アインシュタインの電話番号

    個人でWebサービスを作る際の考察に関する以下の記事が、とても興味深く面白かった。ここに書いてあることはだいたい同意で、自分も実践したいと思うことばかり。 個人でWebサービスを超高速でつくる人たちの作り方を考察。 │ モノづくりブログ 株式会社8bitのスタッフブログです で、記事の最後に執筆者が聞いてみたいこととして「個人Webサービスの場合、仕様書はどうしてるの?」と呼びかけていたので、僭越ながら自分が過去に作ったWebサービスの仕様書(Evernoteに書いたメモ)を公開してみる。公開するのはNekostagramとはてなスターカウンターのもの。 仕様書(TODOリスト)の書き方 自分の場合、Webサービスを作るときに書くものは「仕様書」などと呼べるようなちゃんとしたシロモノではなく、Evernoteに思いついたことをどんどんリストアップしていくだけ。いわゆるTODOリストですね。

    個人で作ったWebサービスの仕様書(Evernoteのメモ)を2つ公開してみる - アインシュタインの電話番号
  • 理想の開発環境 - mixi engineer blog

    たんぽぽグループの森です。 一日の半分近くを机に座ってすごすエンジニアにとって、快適な開発環境は切実な問題です。 外界からうけるストレスを極力排除し、効率よくフロー状態にはいることと、フロー状態を長く維持することはとても重要です。 お前は今までに購入したキーボードの数をおぼえているのか?と突っ込まれてもしかたが無いキーボード遍歴を重ねましたが、KINESISに出会い キーボードに関してはまぁまぁ満足することができました。 机・椅子・マウス・ディスプレイとまだまだ欲望は果てしないのですが、今回のミクシィ社の引越しに伴い、エンジニアの机と椅子にオカムラ社のクルーズ&アトラスが選定され、机と椅子に関してもかなりの満足度を得ることができたので自慢報告します。 クルーズ&アトラスの御紹介 クルーズ&アトラスはオカムラ社が販売している低座・後傾姿勢を特徴としたパーソナルワークステーションです。 2

    理想の開発環境 - mixi engineer blog
    hush_puppy
    hush_puppy 2011/05/18
    「クルーズ&アトラス」も羨ましいが、個人の裁量でさらなるカスタマイズが許されているのが羨ましい。
  • IT業界の仕事を辞めたくなるとき--10の理由を紹介

    これまでに少なくとも何回か、もう少しで仕事を辞めそうになったことがある人は手を挙げて欲しい。遠慮しなくていい。IT業界が、世の中でもっともストレスが高い業界の1つであることは、誰もが知っている。そして残念ながら、大学では日々を切り抜ける術を教えてはくれない。この記事では、愛するIT業界のキャリアを離れる決断をする理由になり得る要因について考えてみよう。 1.ストレス IT業界仕事など楽なものだなどと言う者がいたら、決して許してはならない。IT分野では、ストレスのない職は珍しい。なにしろ、ITとは災害管理なのだ。顧客やユーザーがわれわれに電話をかけてくるときには、ほぼ間違いなく直ちに対処する必要のある緊急事態だ。そして、その作業に取り組むときには、間違いは許されない。さもなければ、契約や自分のクビを失うことになりかねない。さらに悪いことに、ストレスはほとんど途切れることがない。われわれは常

    IT業界の仕事を辞めたくなるとき--10の理由を紹介
  • 株式会社ミクシィ が引っ越したらしいので行ってきた! - 941::blog

    ヤマピカリャー!! どうも、くしいです。 株式会社ミクシィ に行ってきた!ってのを丁度1年前(2010年4月)に書いたのだけど 最近出来たばっかりのビルに引っ越したらしいのでお邪魔しに行ってみた! なんと今回は執務エリアまで撮影させてくれちゃいました。うひょー。すげー。 ミクシィさんはもう説明の必要がない有名SNSと思われるので説明は省略。 わからん!て人は前回のエントリを参照してくだちい。 ほいきた受付。 ==== どどん、mixiロゴ。 なんだかシックな雰囲気。大人になったっていうか。 ※公開から3ヶ月以上経過した特定の記事は有料となっている場合があります この続きはcodocで購入

    株式会社ミクシィ が引っ越したらしいので行ってきた! - 941::blog
    hush_puppy
    hush_puppy 2011/05/10
    クルーズ&アトラスなる机と椅子がうらやましい。欲しい。でもマウスが滑り落ちそう。
  • スタートアップで働くのが素晴らしい7つの理由

    僕はいくつものスタートアップで働いてきたし、ほら、ここに証拠の古傷もある。確かに大変なこともあるんだけど、何事にも代え難い、得るところの多い経験なんだ。 クールなプロジェクトの一端を担える スタートアップで働く一番の理由はクールなことができるってこと。新しいアイデア、あるいは主流とは違った見方で、スタートアップはいつでも限界を押し広げてる。スタートアップは目新しさや革新性で生きている。みんなアイデアに取り付かれてる。いかに次のレベルへ持って行くか、あるいはそのアイデアを実現するかが全て。たまに怖じ気づくこともあるけれど、クールなことに取り組むってことは何事にも代え難い。 皿洗いから料理長まであらゆることが出来る 同じことをしなくてすむ。大きな会社では同じことを5年間続けるとかありがち。仕事でもプライベートでも、僕は変化が好きで、それがスタートアップのいいところ。新しいことをに飢えることがな

    スタートアップで働くのが素晴らしい7つの理由
  • TechCrunch

    Multiple studies show that younger generations aren’t buying homes as quickly as their generational predecessors. Yet a relatively new startup, Summer, thinks it can convince this cohort to snat

    TechCrunch
    hush_puppy
    hush_puppy 2011/05/10
    ちょっとポートフォリオの作り方調べてくる。
  • 35歳を超えたエンジニアの5つの働き方

    おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 ぼくは36歳です。けっこう大きなサイトで、RailsJavascriptを書いたり、パフォーマンス改善したり、iPhoneアプリの開発でObjective-Cを書いたりしています。マネージメントはしていなくて、今でも普通にエンジニアとして働いています。 35歳定年説の35歳を超えてから1年以上が過ぎたところですが、昔のようにはいかなくなってきたところ、昔と変わらないところ、昔よりよくなってきたところなどがいろいろあります。年を取ってもエンジニアを続けたい人の参考になるかどうかわかりませんが、そういう人たちのためにぼく個人の体験をここに書いておこうと思います。 1.理解できるまで聞き返す 特に若い人たちとの会話で痛感するのですが、相手の言いたいことを一度で理解することが難しくなってきまし

  • http://devsummary.miukoba.net/