dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
はてブのシステム考をするなら - プログラマーの脳みそ
はてなブックマークというか、システム全般というか「こうしろ」「ああしろ」という意見は多く聞くけども、人によって意見はバラバラ。全ての意見をホイホイ聞いていたらシステムは迷走を極めることだろう。それでもガツンといいたい人は絶えないのだろうけども。 システムを論じるときにありがちなミスのひとつは、自分のユースケースのみを前提にシステム改修案を考えると言うことだ。システムというのは設計者が意図した使ってほしい形で使われるんじゃない。ユーザが使いたいように使うんだ。その設計意図をあざ笑うように、ユーザは珍妙な使い方をするものだ。そして、携帯電話をカナヅチ代わりにして「使いにくい。どうにかしろ」みたいなことを言い出すものなんだ。 携帯電話をカナヅチにするなんて原始人ですか、と言ったところで話は始まらない。 なんせ、はてなブックマークをブックマークとしてではなく、ミニブログとして使いたいんだけどミニブ
デザイナー：佐藤可士和さんの言葉からSIを考えてみた - Float on the flow
SIerってのも、デザイナーであるべきなんですよね。つい、お客さんのいいなりになって開発しがちですが。 ほんとうは、グランドデザインがないといけない。そうしないと軸がブレる。発言力のある現場ユーザの声に引きずられ、既存システムの焼き直しに終始したりとか。 ただ、「グランドデザインからやりましょうよ」と説得できる人がいない。なんでだろう。 グランドデザインの必要性を認識していないから？ わかってるけど自分にはできないと思っているから？ クライアントのトップに説得しないといけないけど腰が引けている？ お客さんがグランドデザインできると思っている？*1 SIerのコスト構造や会計制度、人事制度が「企画・戦略立案」みたいなフェーズに対応していない？ デザインってボトムアップで要求を拾っていって、トップダウンで意思決定していく必要がある。要求だけを単純に足していくとキマイラになってしまう。 でもSI
痛い目に合わないとわからない - masayang's diary
酔狂人の異説: ウォーターフォール型開発は最初から破綻している? そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。 そのとおり！ でもね... 洗い出せていないリスクや問題点を吸収できるだけの「ゲタ」を履かす事で、破綻する確率を下げる事ができる。 その「ゲタ」は例えば下記の通り： おびただしい量の成果物を記述するための労力分を余裕をみて請求する。 プロジェクト後半で発覚する問題点を押さえ込むための労力分を余裕をみて請求する。 それらのゲタを見越した顧客の値引き要求に対するさらなるゲタ。 その値引き要求に対す
ウォーターフォール型開発は最初から破綻している? - 酔狂人の異説(新館)
ウォーターフォール大好き人間達にいつも言われたことは 「リスクと問題点は全て洗い出して解決しなきゃいかんのです。 随時解決するなんてリスクはとれませんよ」 よくよく思えばやり始めていきなりわかるほうが対策が打てる分有利だよなとしみじみ思った。 そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。
ドメインモデリングよりもユーザーインターフェースを (arclamp.jp アークランプ)
S/N Ratioで紹介されていた「ソフトウェアアーキテクトが知っておくべき10のこと」が、いい感じです。佐藤さんの紹介をそのままに。 人がプラットフォーム (People are the platform) すべてのソリューションは時代遅れ (All solutions are obsolete) データは永遠だ (Data is forever) 柔軟性が複雑性を生む (Flexibility breeds complexity) 期待通り動くものはない (Nothing works as expected) ドキュメントは普遍的なソースコード (Documentation is the universal source code) ビジネスを知るべし (Know the business) ビジョンを維持せよ (Maintain the vision) ソフトウェアアーキテクトもコー
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
ITをサービスにする方法（ホテルオークラの場合） (arclamp.jp アークランプ)
ITを本当の意味でサービスにするとは、どういうことでしょうか。それはヒトの作業を代替することではなくて、ヒトを支援すること。そして、IT自身は透明になっていくのです。 デブサミ2009の講演「【12-C-1】不確実時代のアーキテクチャを予言する」向けにプレミーティングをしていて、非常に面白い話を聞きました。 ホテルオークラで情報システム担当をしていた石原 直さんは成田の発着情報のオンライン化に尽力された人（その後は芝パークホテルの社長、会長。現在はＮＰＯ法人旅行電子取引推進機構理事長）。 じゃ、オンライン化されて入手した発着状況をどう使うのか？ 普通のホテルならロビーのインフォメーションパネルに情報を流しますと。そして、自由に宿泊客がみれるようにする。 でも、オークラは宿泊客から情報を隠してしまう。そして、しかるべき時に取り出せるようにする。つまり、宿泊客にサービスする瞬間に、従業員が入手
株式会社マジカジャパンの羽生章洋が書いてるブログ:大雑把でもいい - livedoor Blog（ブログ）
システム化・IT化で失敗しがちなのは、これまで全くといっていいほど何も管理してこなかったのに、せっかく多額の予算を割くのだからといきなりものすごく詳細に精密に物事を管理しようとして運用が回らなくなるというケースです。 そういうとこれまた極端な話が出てきて、言わば0/1のような感じで「だったらやるだけ無駄だ」という風になってしまい現状追認で終わってしまうということも見受けられます。ですが現状のままであるということは問題はそのままなのが当然なので、それが自然に勝手に解決して欲しいと思っても、そこにはちょっと無理があるように思うのです。 いきなり精緻にやらなくてもいい。まずは大雑把でいい。出来る範囲だけでいい。始めることに意義があると考えて、実際にやることが重要だと思うのです。そして成果が出てくると、段々とやる気も高まってきます。 何も最初から無用に目標を高く設定する必要などないのです。本当に目
非機能要件の開発体系 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前のブログで、 非機能要件が体系的になっていない、行き当たりばったりでは、本当にその期間や予算で実装できるかどうかわかりません。 現在の機能要件重視の考え方は、プロジェクト失敗の要因を内在しているといえそうです。 と書いた以上は、非機能要件の体系化をしないといけません。 というわけで、考えてみました。 ■非機能要件における開発手順 （１）まず、非機能要件を、形容詞、副詞、数詞などを使って出す。 この段階では、「早く」とか、「美しく」とかであって、「Linuxで」とか「ブラウザで」とかは、とりあえず置いておく。その次の段階で出てくる （１）’ユーザーのシナリオとかでもいい ペルソナとか。っていうか、そういうののほうがいいのかな・・・ （２）その要件を実現する技術を検討する 「使いや
現在の機能要件重視の考え方は、プロジェクト失敗の要因を内在している - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前のブログで、「機能要件中心の現在の開発手法は、もう一度レビューしたほうがいいことになる。今度、そのレビューについて書いてみたいと思います」と書いたので、従来の機能仕様中心の開発方法を書いてみたいと思います。 ざっとこんなかんじ？ つまり、要求段階では、業務内容を機能要件としてまとめ、非機能要件は、その際の条件としてまとめると思います。 このとき、「どのくらいの量」とか「どのくらいの正確さ」といった、形容詞、副詞的な要素のほか、「Linuxで」とか「Javaで」といった、環境などに関することも一緒にまとめてしまうと思います。 そして外部設計の段階で、画面設計など、ユーザーインターフェース関連をきめ、さらに、要求仕様が終わった段階で詳細化とかフレームワークの決定などをすると思います
バザール型ＥＡ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 従来のＥＡっていうのは、会社全体のシステムを調査し(to-be)、そしてあるべき姿を分析する(as-if)という形式だった。つまり、全体像を描き挙げ、それを、ブレークダウンし、実装していくという、 伽藍とバザール http://cruel.org/freeware/cathedral.html で言えば、伽藍型の開発方法といえる。 では、バザール型の開発方法はないのか？ つまり、会社の機能を部分部分につくっていき、それをつなぎ合わせる手法 ・・・って、まさにＳＯＡである（＾＾；） でも、その場合、各部分で利用するデータの関連をとるには、どーしたらいいだろう？ 従来（伽藍型）は、会社全体を考え、そこからデータの全体構造、関連を正規化手法にしてＥＲ図などで表現し、１事実１箇所、データ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インハウス開発とか | 眠る開発屋blog