GoogleがプロトタイピングツールPixateを買収。無料化される。オススメ。 | fladdict
Googleが、ローカルベースのプロトタイピングツールPixateを買収した模様。以後、Pixateアプリは無料となり引き続き開発が続けられるようです。 2013年頃、Pixateに$600払ってた俺は泣いた。おめでとうございます。 Invisionを主流に百花繚乱の分断化で割と困っていたプロトタイピング業界。Googleがこの分野に手を出したことで変動は起きるのだろうか。 これがプロトタイピングツールの決定版になるとよいですね。高性能だし無料だし。クラウド版も$5だし。 日本でプロトタイピングサービスばパッとしない究極の問題は、サービスがオンラインのことなんですよね。SI系の人たちは「セキュリティ的な事情でオンラインの共有サービスを使えない」という事情がありました。Pixateはローカルアプリなので、その辺の心配をする必要がないのがポイントですね。そのうち大手SIとかでもこういうツールが
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
要求とか要件についての四方山話[14] ～メタ質問を活用する～ - オブログ
こんにちは、平田です。 今回は、プロジェクトの初期段階で有用な質問について、「要求仕様の探検学」(*1)という本に書かれていることを紹介したいと思います。 この「要求仕様の探検学」という本は、「ライト、ついてますか」や「コンサルタントの秘密」などで有名なワインバーグさんの著作で、日本語版が出版されたのは20年近く前になるものです。装丁が古いし、翻訳もそれほど易しくはないですが、今でも要件定義に関わる人に刺激を与えてくれる本だと思います。 今日はこの本の中で触れられている「文脈自由な質問」という質問、その中でも特に「メタ質問」について紹介します。これまでの記事の中でも、「何かを仮定していないかを疑う」(*2)や「自分の質問にも理由を明示しよう」(*3)など、記事の中で有用と思われる質問の手法を紹介してきましたが、それらを考えるもとになった質問のやり方です。 「私の質問は的を得ていますか？」
高層ビルのエレベーターホールには、なぜ階数表示がないのか - 本当は怖いHPC
以前に高橋幸雄先生の授業で聞いて非常に面白いと思ったこと。 オフィスビルとかホテルとか、エレベーターが何基も設置されているビルの場合、エレベーターホールに階数表示が無いことが多い。エレベーターホールで画像検索してみればわかると思う。 これはなぜだろうか。 その理由は、「客がいても、その階を通過することができるようにするため」だ。 基本的に、多数のエレベーターを効率よく動かすのは難しい。工夫された高度なアルゴリズムが使われていることが多い。目標は「客の平均待ち時間を短くする」ことだ。ある階でボタンが押された場合、どのエレベーターがその客を迎えに行くか、という判断が平均待ち時間に大きな影響を与える。難しいアルゴリズムの中で、この点がもっとも重要なところだ。 高層ビルの場合、エレベーターはかなりの速度で走っている。既に客を乗せて走っているエレベーターが他の客を乗せるために停止すると、減速→停止→
他人の心に対して鈍感であっては、良いソフトウェアは作れない。 - GoTheDistance
はよプログラマとかエンジニアとかから脱却せんかい。 - 山本大＠クロノスの日記への私信。 山本さんの苛立ちを一言で言えば、｢お客様のお困りごとやお悩みごとに対してあまりにも無関心すぎること｣にあるんじゃないのかな。羽生さんのこちらのエントリを参照下さい。 一言で言えば、説明不足ということになるのでしょう。きちんとしたソフトウェアを作りさえすればよいという空気が間違いなく存在しています。(中略)自分たちが作っているソフトウェアがお客様に対してどういう価値があるのかということを説明できずにいると感じるのです。理解してくれ、と相手の努力に丸投げしてしまってるように感じます。 ではどうしてそうなるのかというと、端的に言えばお客様のお困りごとやお悩みごとに対してあまりにも無関心なのではないかと感じるのです。エンジニアとしての技術的な興味や自分自身の仕事と生活のバランスなど、つまりは内向きの関心しか持
第11回 中村好文（2006年4月13日放送）| これまでの放送 | ＮＨＫ プロフェッショナル 仕事の流儀
中村のオフィスは常に笑いがある。机の周りには古今東西で買い求めてきたおもちゃが並ぶ。そしてスタッフとの打ち合わせ中にも中村は、冗談を言うことを忘れない。しかめ面をしていてはいいものは作れない、「遊び心」が大切だというのが、中村の基本姿勢。 その遊び心が、自由な発想を生み、常識にとらわれないさまざまなくふうを生み出す。 中村は、依頼者との最初の打ち合わせで、希望する間取りや部屋の広さなど、家についての具体的な要望は、ほとんど尋ねない。なぜなら依頼者が本当に求めている家は、依頼者自身には分からないと考えているからである。心地よさは人によって千差万別、狭い部屋を心地よいと思う人もあれば、息苦しくて落ち着かない人もいる。 ゆえに中村は、打ち合わせの席で、生活についての雑談を重ねていく。その中から、依頼者にとってどんな家が心地よいのか、探っていく。 中村の口癖は、「これからできる家に仕える」。中村は
要求交換フォーマット(ReqIF)を調べてみた。(1) - たこはちの「へのかっぱ」日記
OMGが公開している要求交換フォーマット(ReqIF:Requirements Interchange Format)について調べてみた。以下のURLからダウンロードしたReqIFの仕様書を読んでいるところだ。2011-04-02にリリースされている。 http://www.omg.org/spec/ReqIF/1.0.1/ 以下の記事も参照のこと。 (1) ReqIFの3つのユースケース (※この記事) (2) ReqIFの8つの機能 (3) ReqIFの再利用性、RIFとの差異 (4) ReqIF/RIFの動向 (5) ReqIFフォーマットの構造 (6) ReqIFでの代替IDとアクセス制限 ReqIFは、要求を記述したファイルをXMLの統一規格で定義して、企業間やツール間で扱いやすくしようというものだ。これまで「要求仕様」は、WORDやEXCELで記述したり、リーズナブルなツールな
ラポール - オブログ
ラポールという言葉をご存知でしょうか？Wikipediaによると、 ラポール (rapport) とは臨床心理学の用語で、セラピストとクライエントとの間の心的状態を表す。 （中略） セラピストとクライエントの間に、相互を信頼し合い、安心して自由に振る舞ったり感情の交流を行える関係が成立している状態を表す語として用いられるようになった。カウンセリングや心理療法をどのような立場から行う場合であっても、ラポールは共通した基本的な前提条件として重視されている。 と書かれています。(*1) 今回はこの「ラポール」の構築について、僕自身の失敗談を紹介したいと思います。 とあるプロジェクトでの話です。そのプロジェクトで開発しようとしていたシステムは自分自身がユーザにもなりえるようなものだったので、お客様が提示してきた当初の要件をそのまま実装しても、これは良くないシステムになるだろうな、という予感がありま
失敗を少なくする為の要求定義の進め方について私なりの工夫。投稿論文｜投稿｜まいどフォーラム
失敗を少なくする為の要求定義の進め方について私なりの工夫。 １．はじめに 世の中のプロジェクトに関する本を読むと、上流工程に関して多くのことが書かれています。ＩＴコーディネータのプロセスガイドラインも上流工程に関する比重は高く、ＰＭＢＯＫもまた同じように感じます。これらの傾向を考えると、ＩＴ開発や一般的なプロジェクト管理においても、上流工程の失敗が多くそれを改善するがために、この様なガイドラインが出てきたのではないかと想像してしまいます。 ２．序論 システム開発を行う上で最も重要なフェーズのひとつに要求定義があげられるのではないでしょうか？少なくとも私はその様に感じます。私は製造業会社の、情報システム子会社に所属していました。ユーザは親会社の製品開発部門だったので、毎日の様に顔を合わせていたのでなあなあの関係になっていたところもあると思いますが、突然の仕様変更などは普通に発生し、プロジェク
i* Intentional STrategic Actor Relationships modelling - istar
November 15, 2010 From MIT Press: "This book offers a new approach to the requirements challenge, based on modeling and analyzing the relationships among stakeholders. The i* framework conceives of software-based information systems as being situated in environments in which social actors relate to each other in terms of goals to be achieved, tasks to be performed, and resources to be furnished. T
「AS-ISシステム分析は入出力から始めよ」講演メモ - mkoszk’s blog
テープ起こしをしていませんので、間違っているところもあると思いますし、補った言葉が間違っているかもしれません。また、編集の過程で順序が変わってしまったところもあると思います。 この講演は聴いて良かったと思っています。神崎さんのやり方と僕のやり方は非常に似ているのですが、徹底度合いが違うといいますか、僕が今まで気づかなかったことをたくさん教わりました。 ─────────────────────────────────────── 要求開発アライアンス2月定例会 テーマ：AS-ISシステム分析攻略法。トップダウンとボトムアップで挟み撃ち！ 日時：2011年02月22日(19:00~21:00) 場所：日本総合システム株式会社様 大会議室 ─────────────────────────────────────── ■19:00-20:00 AS-ISシステム分析は入出力から始めよ 講師：株
CSPO 認定スクラムプロダクトオーナーを受けてきた - メソッド屋のブログ
先日２日間で、CSPO Certified Scrum Product Ownerを受けてきた。 このコースはホンマ凄い。何が凄いっていろいろあるけど ・全てボランティアベース／コミュニティベースで運用されている ・スクラムの父、ジェフ・サザーランドさんとガブリエル・ベネフィールドさんがやってくる！ ・CSPOのコースが初めて日本で行われる！ ・最終日に、スクラムの父「ジェフ・サザーランド」日本のアジャイルの父「平鍋健児」 スクラムのアイデアの元「野中郁次郎」さんのスリーショットと歴史的ディスカッション なんて夢のようなラインナップが実現したんだけど、参加者がこれまた凄い。 @emersonmillsや、@essense_sや、@ryuzee @miholovesq @kawaguchi @nobiinu_and そして原田さんといった現在のスクラムを牽引する中心メンバー。そして同期メンバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storymapping presentation
IPA/SEC 統合モデリング技術WG 内田氏インタビュー
UMTPモデリング技術セミナー - 要の「もの」と「こと」で仕事のシステムを構想する-090119
Facebookにログイン
Facebookにログイン
「情報システム政府調達制度・ガイドライン見直しに向けた検討報告書」の公表について
プロダクトオーナーパターン
汝の隣人のブログを愛せよ | LOVELOG