タグ

Designとdevelopmentに関するblanc2005のブックマーク (6)

  • インハウスデザイナーが活躍できる組織づくり - Speaker Deck

    2018年5月30日 InHouseDesigners #2 登壇資料 インハウスデザイナーが輝けるチームづくりでリーダーがやるべきことをお話しました。

    インハウスデザイナーが活躍できる組織づくり - Speaker Deck
  • 決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note

    中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない(その逆は言語道断)。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ

    決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note
    blanc2005
    blanc2005 2017/11/05
    >「本質的でない目標を達成するため」に、長期のサービス持続性を犠牲に行われる施策...サービスは時間の経過とともに本質的でない機能や施策を抱え込んで行く...身動きが取れなくなったときサービスは寿命を迎え死ぬ
  • 【翻訳】Facebookのデザイン - MOL

    Original:Design at Facebook(2009-04-26)by Luke Wroblewski パロ・アルト社にて、Facebookデザインチームの理念や2.5億人にも及ぶユーザーに対してのデザインアプローチを確認し合った。彼らはコードを書くことの重要性、デザインを早い段階でこまめに共有すること、最初から最後までプロジェクトに関わること、そして自らの仕事に固執しないことを力説した。デザイナーがコードを書くのに十分にテクニカルであると確認した。 Facebookデザインチームはプロダクトデザイン、マーケティング、UIパターン、ブランディングやフロントエンドのコーディングに取り組んでいる。チームは、15人のプロダクトデザイナー、5人のUIエンジニア、5人のUXリサーチャー、4人のコミュニケーションデザイナーと、1人のコンテンツストラテジストからなる。1000人の従業員あた

    【翻訳】Facebookのデザイン - MOL
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • MacBookPro が来た - レジデント初期研修用資料

    医局の先輩がMacBookPro を買った。 同じ世代のパソコンなのに、自分が使っているThinkPad のT61 が、 いきなりみすぼらしく見えて、悲しくなった。 黒が輝いていた頃 銀色のノートパソコンに人気が集まってた頃、ThinkPad は「黒は銀より輝く」だったか、 黒いプラスチックの筐体にこだわりを持っていることを宣言したりして、かっこよかった。 昔のThinkPad は、風格あった。 今も昔も、ThinkPad の筐体はプラスチックだけれど、中身には金属のフレームが入っていて、 しっかりしていた。プラスチックだけれど、まっすぐであるべきところはまっすぐだったし、 たわむところなんてどこにもなかった。 今まで使っていたA30 からT61 に乗り換えて、パソコンの性能は4倍ぐらいに上がったけれど、 見た目は安っぽくなった。T61 の筐体は、フレームを包んでいるプラスチックの薄板が微

    blanc2005
    blanc2005 2009/02/15
    「現場の「カイゼン」に期待するような やりかたというのは、技術者としてはまだまだ未熟な証」
  • [姿勢編]理由無き要求は機能化してはいけない | 日経 xTECH(クロステック)

    要件がなかなか収束しないことがある。ステークホルダーが多いほど,その傾向が強くなる。しっかりとした要求仕様書が無い場合も同様である。システムに対する要求が打ち合わせを重ねるたびに増加したり変化したりすることはもはや当たり前であるかのようである。ところが,そのような要求を実装してはみたものの,システムが完成した後でほとんどど使われることのない機能だったということも少なくない。プロジェクト・マネージャ(PM)たるもの,実装すべき要求とそうでない要求とを見極めた上で,要件定義を行う必要がある。 Aさんは入社以来,プログラマからSEまで経験を積み,今回初めてPMとして抜擢された中堅技術者である。Aさんが担当することになったプロジェクトは,ある旅行会社の予約管理システムの構築であった。 顧客から提出された要求仕様書はA4サイズで3~4枚程度しかなかった。しかも,かなり抽象的な要求事項が多かった。そこ

    [姿勢編]理由無き要求は機能化してはいけない | 日経 xTECH(クロステック)
    blanc2005
    blanc2005 2008/10/06
    例のブランコの絵
  • 1