[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)
[原点回帰] 業務系システムは、四半世紀前に戻れば良い3つの理由 [序章] | oshiire*BLOG
本気ととるかネタととるかは貴方次第の話をします。 企業の業務系システムは、古くのホスト+ダム端末で、黒背景で 80×24文字を表示するだけのアーキテクチャに戻った方が、業務効率が良くなると、日々、考えています。 ホスト系の黒背景の文字だけ画面というのは、”ホストコンピューターへの戸惑い : The world is a playground” の方のblogに画面写真あるので、ご参考にどうぞ。 調べてはいないですけど、同じコトを考えている人はいる気がするので、とりあえず思いつくことだけを書き殴ってみます。 1.最近のコンピュータ・アーキテクチャは回帰傾向にある そんなことを思いついた理由ですけれども、最近のシステムアーキテクチャって、昔に戻ってる気がしてならないんです。ちがいがあるとしたら、Internet との関わりくらいでしょうか。 おおきくは次の二つです。大ざっぱなアーキテクチャとし
![[原点回帰] 業務系システムは、四半世紀前に戻れば良い3つの理由 [序章] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/8d71ff5111e05619a10d29bb40d7aebaa75c8fbc/height=288;version=1;width=512/https%3A%2F%2Fs0.wp.com%2Fi%2Fblank.jpg)
IT業界エヴァンジェリストのためのオススメ書籍(しょっさん編) | oshiire*BLOG
5月中旬までが〆切の、けっこう重要なお仕事がたくさん舞い込んでいて、3月から徐々に、そして 4月には本格的に仕事優先の生活になっていたしょっさんです、こんばんわ。 3月までは、ほぼ毎日 blogを書いていたにもかかわらず、4月は 17日分だけと、とても残念な結果に終わりました。とは言え、3月までも、そんなこと書いてどうするんだ Twitter でいいじゃねぇかみたいな内容のものも多く、よくこんなものを公開してたな、このやんちゃ丸などと自分を戒める日々が続いています。 まぁ、そんなことはどうでも良いわけで、なんとなく思いつきで始めた「オススメ書籍」も今回で終了です。 しょっぱなら「オススメする書籍はありません」とか、明後日の方向を見ながら続けてきたものの、気がつくとけっこう真面目な感じになっていて、ちょっと物足りなく感じている今日この頃です。 ただ、今になっても文書の構成は考えていない、いつ
IT業界ジュニアのためのオススメ書籍(しょっさん編) | oshiire*BLOG
しょっさんオススメの書籍とは はい、自信を持って次の4冊をご紹介します。ジュニアクラスまでくると、簡単なアセンブラ程度は読めるメンバーになっているので、この程度は読みこなせないと意味がありません。 全部絶版かつX68k絡みかよ( ﾟдﾟ )ｸﾜﾉｯ!!と思わないで、入手できたらぜひ読んでみてもらいたいです。某「はじめて読むxx86」シリーズは、良書なのですが、いかんせん Intel系CPUという重荷を背負った、理解のむずかしいアーキテクチャです。 一度、680×0系のエレガントなアセンブラを経験しておくことで、Intel の大罪を理解しつつ、アーキテクチャの様式美について自分の思想を持つことができるようになります。 しかも、X680x0 はありがたいことに、多くの”X68000 エミュレータ｜エミュポータル“が提供されていて、しかも SHARPから BIOS/IPL-ROM/OS が無償で
[プロマネ] 無料で使えるガントチャート Webアプリ "gantter" はもしかすると、良いかもしれない [WBS] | oshiire*BLOG
ちょっと管理するために、無料で使えるガントチャートか、WBSの Webアプリがないかなーなんて調べていたんですよ、奥さん。 そうしたら、これを見つけました。 “Gantter – web-based project scheduling made easy” Google apps みたいで、Google Drive への保管にも対応してたり、日本語も含めマルチ言語にも対応ですヽ(´ー｀)ノ ふぁーすといんぷれっしょん パッと使ってみて、次の機能があるのを確認できたので、ガントチャート作るだけには困らないなーというのが、第一印象です。 多段階層によるタスクの追加 start と finish date が定義できる duration(期間)でも指定できる work day や、労働時間の指定もできる 前提となるタスクを指定できる(依存関係の明確化) 担当者も勿論決められる 自動的にガントチ
ネタはあるのに、書くことができない理由 | oshiire*BLOG
今から思いつきで書き殴っていきますね。書いていったら、理由が分かるのかも知れないと思って、とりあえず書き始めました。多分、読みにくい割に長いと思います。心してかかってください。 よくも毎日blogが書けるよなーと思っていたこともありますが、日々、ずっと書いていると、実は書くことはたくさんあることに気がつきました。昔は「書くネタが無い」と感じていたのですが、なんてことはない「書くのがめんどくさい」だったんだと最近は感じています。最近はネタが思いつきすぎて、仕事したくないくらいネタがありますが、まぁ仕事はせねばならないので、あきらめて労働します。国民の義務ですし。 で。ネタがたくさんあるけれども書けないその理由はと自分自身に問うと。 他にすべきことがある 準備に時間がかかる 裏を取ってからじゃないと、不安で公開できない なんてことがあります。これら全てに共通する原因までは、現時点で分かっていま
会議をスムーズに進めるために、事前に決めておきたい 4項目 [ファシリテータ] | oshiire*BLOG
来る日も来る日も会議、カイギ、ｶｲｷﾞ、もういい加減、会議なんてしなくていいんじゃないかと思われつつも、やっぱりなんとなく、そこへいないと情報から遅れていってしまう感じもするし、会議に出てないと仕事してないとか、プロジェクトへの参画意識を問われるんじゃないかと思われる不安があります。 まぁ、そうは言っても、必要のない会議には出たくはないですし、必要ある会議だとしてもだらだらせずにすぱっと終わりたい。 そうは言っても、下っ端だったりすると、なかなか「行きません」とは言い出せないという気持ちはよく分かります。 でも、今日はその話じゃありません。もうしばらく、ダメな先輩と付き合って会議に出てください。 今日は、会議を進行する側、または進行する人に進言が可能な人が対象です。 ひとまず、次の 4項目を、会議の前に決める、または決めさせましょう。まず、会議はそこからだ。 目的 ゴール 役割分担/メンバ
[ #qpstudy ]対立企業同士の案件でDevOpsを適用するにはどうするか[ #DevOps ] | oshiire*BLOG
やっと、”qpstudy 2013.01” の内容がまとまりましたので、この場をかりてご報告します。なお、今回の内容は、qpstudy内での情報だけを元にまとめたものであって、課題の調査に、他のソースは使っていません。 これを元に次のフェーズに入るとした場合、調査も含めて言及するつもりです。 めずらしく、いきなり本題に入ります。 今回の”qpstudy 2013.01“で解決したかった課題は です。Dev と Ops とで異なる企業が案件を受託した場合、そこでは同一企業内の部門同士のバトルとは比較にならないほどの、バトルが繰り広げられています。「お客様に価値を届ける」「お客様至上主義」「お客様を一番に」たくさんのスローガンをもって、企業はお客様にサービスを届けていますが、DevOpsをうまく取り入れて実践されている SIerと言うものはあるでしょうか? あったとしてもごく少数であったり、真
[ #qpstudy ] DevOps について考えてる(1) [2013.01] | oshiire*BLOG
毎度 qpstudyを開催するたびに、体力を消耗して、翌週の労働力が下がるしょっさんです。こんばんわ。 DevOps課題の対策検討中DevOpsの必要性は何となく理解されているにも関わらず、その効果指標が定量化されていないコトが原因だと考えています。ただ、それ以前に、定性的な効果も含めて、「DevOpsは自分の首を絞めるだけだ」と考えている人たちもいます。 そこで、DevOpsできるようになるための最大の課題として、私が考えているのは「企業間でのDevとOpsが対立(コンペ)せざるを得ない状況にある」ということです。今回の qpstudyでは、この課題を解決するためのヒントが出てこないか、アンテナを張って、皆さんの意見を聞いていたのですが、なんとなくひらめきました。それが、今、ノートにまとめている内容になるのですが、思ったより壮大になると想定され、どっかの雑誌に寄稿するか、社内での発表に使
[Do not do] やらないことリストを実現するために、始めたこと [not TODO] | oshiire*BLOG
寒い日が続きますね。 寒いと、眠いんです。なんででしょうか。寒い時に寝たら死ぬんじゃないですか。死にたくないです。 さて、半分寝ているので、前置きはこれくらいにして本題に入ります。 今日のお話は「やらないことリスト」のお話です。最近よく聞きますよね。「TODOリストを作るな、やらないことリストを作れ」って。 あたしも、毎週ひとつずつ「やらないこと」を増やしていくというドMまっさかりなことをしているのですが、そのうち「人を殺してはいけない」とかしかネタがなくなるんじゃないかと危惧してます。 ところで、TODOもそうなんですが、こういったリストって作るだけ作ってちゃんと運営されているコトってありますか? 私、TODOですら 30弱も Overdueになっているものがあって、人生が破綻しているんじゃないかと追い詰められています。この所為で生きる気力を失いそうなので、毎週の週次レビューでリセットし
[歴史]あの勉強会はいつから始まったのか[IT] | oshiire*BLOG
1995年前後から unix系の勉強会が開始され、2005年前後から徐々に増えていき、2007年、2008年頃からは「勉強会ブーム」と呼ばれ、2011年にはその爆発的な増加が見てとれます。 ここからなにを感じるかはみなさまにお任せしますが、ここからなにを読み取って、次になにを実行していくかを考えているところです。公開できるものができたら、またお知らせします。
[sfstudy] 数字で見る #sfstudy #2 [ストレージ友の会] | oshiire*BLOG
昨日のストレージ友の会で、宣伝タイムが無かったんですが、なぜかこのクラウディアさんが配布されていました。 出元がよく分かりませんが、クラウディア(*´Д｀)な感じでよろしくお願いします。 主催側の気になるドタキャン率は 15% 程度、今回も想定通りの範囲です。また、当日予定外に参加されたメンバーが 1名いました。 今回はディスカッションメインだったために、参加者自体が比較的少なめだったのだと感じています。ただ、キャンセル数が少なかったことは意識のあらわれでは無いかと考えています。事前キャンセルの方は、仕事･体調不良がメインで仕方の無い方がほとんどです。 当日ドタキャンの報告なしの方については、理由が無いため想定が分からないことが残念です。あえてヒアリングするのも難しい問題です。この辺は匿名で良いので、理由が収集できるといいですね。「忘れてた」「予定に入れ忘れていた」などであれば、Remin
[勉強会] #qpstudy 06 でファシリテーションしてきました [今回がホントの6回目] | oshiire*BLOG
昨日のお勉強会では、これまでのセミナー形式から、参加者が討論、ディスカッションをして、その内容を発表をする形式をとりました。これまでで初めての形式です。 ディスカッションを実行するに至った経緯は、ストレージ友の会 #0 キックオフ の時に遡ります。 実はすでにこのキックオフの時に、テーブル毎にグループを組んでもらって、ディスカッションをしてもらっていました。内容としては、「どんなことを学んでいきたいか」というのをグループ毎に出してもらうというものです。このときの目的はテーブルの人たちの顔と名前を覚えてもらおう、と言う程度なので難しいことは求めていませんでした。会話のきっかけにディスカッションを選択しただけです。 そして、qpstudy06 実施時に、このときのディスカッションが面白かったね、という話があがりまして、「じゃ、やってみよっか」という流れで至りました。 ですが、私はココで一つの企
[sfstudy] #sfstudy グループディスカッションまとめ | oshiire*BLOG
遅くなりました(´・ω・`) 4月22日(金) の「ストレージ友の会 キックオフ」で実施いたしました、グループディスカッションの結果についてご報告します。 グループディスカッションの目的 メンバーとのコミュニケーション活性化 今後の勉強会の進め方の案だし グループディスカッションのテーマ ストレージ友の会で学んでいきたいこと ストレージ友の会へ期待すること 各グループのメモ グループ #1 (@hideticks @wasaist @kometchtech @segami @gandalf_maki) よくある構築事例 (今までの事例 [I]オンプレミス開発 ) 今のトレンド (単に流行っている技術) その中で、これから主流になりそうな技術と、構築想定 グループ#2 (@hiroshi19790209 @diceken @nagi2100 @yasudatadahiro ) 分散ファイルシ
[qpstudy] #qpstudy という勉強会について | oshiire*BLOG
前にも書きましたが、qpstudy はキックオフミーティング から、4/9の 1周年記念LT大会まで、ずっと欠かさずに出席している希有な存在ですw 一度だけ qpstudy #04 の反省会に出席していませんが、それ以外の反省会にも全て出席している、本当にやっぱりおかしい存在です。 個人的に初めて参加した勉強会だから、と言うのもありますが私が予想していた斜め上を行く勉強会だったので、思い入れもあるのかもしれません。 そんな qpstudy の魅力をお伝えします。気になったら、是非、次回以降ご参加されてみてはいかがでしょうか。次回は 5月29日 の予定です。 qpstudyの魅力 ゆるい ともかくゆるいです。 初心者向けとしてスタートして以来、初心者向けかどうかではなく、いかにインフラエンジニアに共感を得るか、というか話したい人が話したいものを話して、聞きたい人が聞きに行く感じです。 初心者
[勉強会] #qpstudy 06 で LTしてきました [1周年記念] | oshiire*BLOG
右の写真は、先日、深夜に好評だった脚です。 それはさておき、0回目のKickoff から欠かさずに出席している #qpstudy 06 へ参加してきました。今回は、久々に Ust顔出しで LT やってきました。 全体的な感想は 熱かった・暑かった 長かった 笑った 大変だった といったところでしょうか。 具体的に振り返ってみます。 熱かった・暑かった 今回は全てが LT ですので、発言者の数が半端ない上、宣伝とネタに偏っていました。会場Only の危険なネタまで噴出し、とても熱い内容に、最後の方は外出てましたw [I]会計なので、お金の勘定していたというのもありますけれども それから、とにかく暑いです。100人までのキャパのところに 80人程度でしたが、常に人が動いていますし、機材もプロジェクタも多いですし、ピザなんて食べてたら、そりゃ人も放熱しますよね。暑かったです。帰りしなにはタンクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
