タグ

2013年7月1日のブックマーク (11件)

  • 奥村隆「息子と僕のアスペルガー物語」【第33回】「飲食しながら会話すること」が絶対にできない悲劇(奥村 隆) @gendai_biz

    【第32回】はこちらをご覧ください。 職場の飲み会に出たがらない理由 「編集長は僕が嫌いなんですね」と言い捨てて泣きながら会議室を飛び出し、3日間も欠勤した後、S君はようやく出社してきた(前回参照)。 彼の教育係を命じられた僕は、「俺と同じASD(自閉症スペクトラム障害)を持っているらしいこの厄介な後輩ディレクターを、どう扱っていけばいいのだろう」とあれこれ考えてみたが、有効な対策を思いつく前に、彼はまた一つ"やらかして"しまった。 S君が入社して2ヵ月も経とうというのに、実は、僕たちの職場では彼の歓迎会をまだ行っていなかった。それはこの春、会社の制作現場が、諸々の事情で異常に忙しくなって、スタッフたちに時間的余裕がほとんどなくなってしまい、とても会合を持つなどという雰囲気にならなかったためである。しかも、S君が前述の企画会議でのトラブルを起こしたため、改めて歓迎会を開こうという雰囲気には

    奥村隆「息子と僕のアスペルガー物語」【第33回】「飲食しながら会話すること」が絶対にできない悲劇(奥村 隆) @gendai_biz
    solailo
    solailo 2013/07/01
  • イノベーションが欲しいなら奇人変人を重用するしかないよね。 島国大和のド畜生

    重用(ちょうよう:その人を重んじて重要な役に付ける事) ジョブスは明らかに一緒に仕事をしたく無い種類の人だろう。 富野由悠季が語る言葉は、一般人とは違うものを指している。 松下にしろホンダにしろ創業者のエピソードは無茶な物が多い。 何かイノベーションを起こす人というのは、常識と違う所に価値感がある。 奇人変人の類ではないか。 今もしそういった新入社員が居たら、縄張り争いの末に潰される。 今もしそういった中堅社員がいたら、キチガイな部分を極力抑えて個性を殺している。 しかし奇人変人は成功を収める可能性がある。 空気を読まない、慣習に沿わない、善なるタガが外れてる。 そういった武器があるから。 日の社会は成熟し過ぎていて「異物を排除」する傾向が強い。 なんらかのポストが空いた時、そこに誰を付けるかは「もっとも波風を立てない人」が選ばれたりする。 波風立てずにイノベーションが起ると思ってるなら

  • - UML超入門_第2章

    2章では,簡単な業務システムを例にしてUMLの記法をひと通り詳しく解説して行きます. なるべく分かりやすく具体的な例として,社員の出退勤の管理を行う,勤怠管理システムを選びました. この章は入門ということで、通常のモデリング作業でよく用いられる基的な要素に重点を置いて説明していきます。 UMLの図と、その図に使用される要素を説明するだけでなく、イメージしやすいように、 勤怠管理システムを例にして説明していくことにしましょう。 勤怠システムの仕様 今回の例に用いるのは、社員の出退社時間を管理するシステムです。 社員は出退社処理しか行えませんが、総務の人は勤怠変更入力することが可能です。 また、次期開発では、遅刻/早退の場合には、理由を入力する機能を持たせます。 画面のイメージは図1のようになっています。勤怠変更画面のイメージは省略します。

  • ユースケース図(Use Case Diagram) - UML入門 - IT専科

    ユースケース図(Use Case Diagram) ユースケース図とは、ユーザ(外部システムも含む)の要求に対するシステムの振る舞いを表現する図です。ユースケース図はシステムの要件定義についての俯瞰的情報を提供します。したがってユースケース図を描くことは、同時に要件定義の分析の機会になります。 記述例 例えば、次のような仕様の「受験管理システム」があるとします。 【要件定義】 ユーザ(受験者)は「受験申し込み」、「受験料振込み」、「テストを受ける」という処理を行っています。 このとき、ユースケース図では次のように表現できます。 ユーザ(受験者)が何を行うのかを書き出すことによって、より具体的な要件定義の視覚的な理解深まると同時に、不足している要件や修正するべき要件を洗い出す事が出来ます。 ▲PageTop 構成要素 ユースケース図は次の要素で構成されます。 構成要素一覧

  • 要求開発×アジャイル開発×ドメイン駆動開発

    オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年6月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/6 regular meeting of the presentation materials.Read less

    要求開発×アジャイル開発×ドメイン駆動開発
  • ゲームプログラマが語る 楽しさの仕組みとゲームメカニクス|ガジェット通信 GetNews

    太古、人類に宿った英知は職業分化や健康をもたらし、狩猟と休息を繰り返しその日暮らしに追われる獣にはない、文化的な余裕を生み出した。獲物を備蓄し富が生まれ、そうして得た死の危険からの距離は、嗜好という概念をまた生み出し、やがてそれは娯楽へと進化した。人々は、それまでのただ生き残るためにだけ費やされた時間を取り戻し、それぞれの人生を楽しむ術を身につけたのだ。 “ゲーム”は、昨今における娯楽の代表として挙げられるであろう。紀元前の歴史に現れた神々をかたどる古代のカード遊技から、現代の美麗な3D映像大迫力音響アクションに至るまで、ゲームという娯楽が我々の生活に深く根を下ろして久しい。 人が、生理学的な意味において“生きる”ためには、来必要のない概念であるはずの“娯楽”と、そしてその代表例“ゲーム”。 ゲームをプレイしている人々に、それを楽しいと感じさせる仕組みとは一体どのようなものであろう。今回

    ゲームプログラマが語る 楽しさの仕組みとゲームメカニクス|ガジェット通信 GetNews
    solailo
    solailo 2013/07/01
  • 要件におけるユーザーストーリーの利点 - winplusの日記

    これの続きというか、Mike CohnのProject Advantages of User Stories as Requirementsを適当訳しておく。たんにまだ『User Stories Applied: For Agile Software Development』に手を出しかねているのだけなのだが。 ■要件におけるユーザーストーリーの利点 エクストリームプログラミング(XP)は、ユーザーストーリーの形式で要求を表現するというプラクティスを導入します。ユーザーストーリーは利用者の視点から語られた機能要件の短い説明です。機能要件とはソフトウェアの利用者あるいはソフトウェアの顧客のどちらかにとって価値があるものです。人材募集・検索サイトのための典型的なユーザーストーリーをあげましょう。 利用者は自身の履歴書をウェブサイトに掲示できます。 利用者は仕事を検索できます。 企業は新しい求人

    要件におけるユーザーストーリーの利点 - winplusの日記
  • @IT:連載:【改訂版】初歩のUML

    ユースケースとは何か? なぜ必要か? 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML

    @IT:連載:【改訂版】初歩のUML
  • ユーザーストーリーとは?

    ユーザーストーリーとは? 1. ユーザーストーリーとはhttp://www.flickr.com/photos/cannedtuna/4674434821/ 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外

    ユーザーストーリーとは?
  • 開発にドキュメントなんていらない(2/2)

    株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニアコンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。

    開発にドキュメントなんていらない(2/2)
  • 開発にドキュメントなんていらない(1/2)

    株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニアコンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。

    開発にドキュメントなんていらない(1/2)
    solailo
    solailo 2013/07/01
    うーん