ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
長期的には皆死ぬように、どんなサービスもいつか終わる。会社ごと終わるときもあれば、採算に合わず事業から撤退することもある。だから企業が経営判断でコミュニティ・サービスから撤退すること自体は仕方がない。だがDoblogは今からでも遅くないから、グループへの風評リスクを最小限に抑えた撤退戦略を考えた方がいい。 復旧作業の終了を受け、今後のDoblogについて検討した結果、Doblog開設時の目的である、ブログシステムを構築するための技術的知見、およびコミュニティサービスを運用・運営するためのノウハウの蓄積については十分に達成できたものと考え、サービスを終了するという判断をいたしました。 無償だから、実験だから、データが消えても構わない、リンクが死んでも構わない、登録していたRSSフィードが死んでも構わないと考えたのだろうか。これから企業情報システムでもSaaSやクラウドの隆盛で課金モデルが多様
明けましておめでとうございます。 去年は少し、アジャイル・アジャイル言い過ぎた気がしており、今年はもう少し大切なことの範囲をエンジニアリングに回帰して、再度言おうと思っています。 オブジェクト指向やテスト技法をはじめとするソフトウェア工学の知識とスキルは、ソフトウェア開発に携わる人には絶対必要なもので、その上で、プロジェクトマネジメント手法としてのアジャイルがある。 ということは、もういちどちゃんと言っておこう。そう思った動機は、James Shore の「Art of Agile Development」を訳したこと。そして、それはXPの本だったこと。ここ3年くらいXPという言葉はAgile界では下火になっていて、AgileといえばScrumという風潮だったのが、「エンジニアリングの無いScrumは所詮うまく行かない」、というJames Shoreの当然な一撃があった。InfoQの日本語
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
こんにちは、livedoor Blog担当の眞子裕介です。 今回は、ビジネス上のスキルとして注目を浴びている「フレームワーク思考」について説明いたします。 そもそも、みなさんは、「フレームワーク思考」という言葉をご存じでしょうか? 「フレームワーク思考」とは、情報分析、問題発見や、問題解決(*1)や戦略を立案する際に利用する「思考の枠」のことを指します。 (*1)All Aboutの「フレームワーク思考してますか?」から引用しました。 この「フレームワーク思考」を活用すると、自然と思考が論理的かつ客観的となり、思考の結果を人に説明しやすくなります。 私の経験をもとに言えば、「フレームワーク思考」を学ぶ以前に「機能の要望」を検討する時は、ユーザーの立場でユーザーが求めるであろう機能を考えていましたが、どうしても主観的な意見となりがちでした。しかしながら、「フレームワーク思考」を学んだ後は、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く