詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
Twitterの書き込みをきっかけに仕事についてあれやこれや考えてみた - 未来のいつか/hyoshiokの日記
先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件／環境／待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の（１）良いところ（あれやこれや）、（２）悪いところ（あれやこれや）と、仮に転職するとして、その候補となる会社の（３）期待値（あれやこれや）、（４）転職するにあたっての手間暇（あれやこれや）をざっくり天秤にかけて、いまのところにとどまるインセンティブA＝1-2、転職のイン
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
ソフトウェアの国際化をやっていたころの話をしよう - 未来のいつか/hyoshiokの日記
2008年の10月ごろ受けたインタビューが最近再掲された。スーパーハッカー列伝というタイトルなんで、ちょっと気恥ずかしいが、まあ、それはそれとして、昔話をはてなの方でも引用してみる。 http://web-engineer.buyuden.net/hacker/2009/10/1-1.html DECでの仕事。 川井その先は、どんな仕事をされてたんですか？ 吉岡DEC の中で日本語COBOLを作って、その後にいくつかプロジェクトはあったんですけど、 RDBMSでVAX Rdbっていうのがあって、それの日本語化をやったんです。 そのソースコードを持って、香港のエンジニアリングチームが中国語版とか韓国語版かなんかを作ったんですね。ソースコードを1つにしてアジア共通のRDBを作ったわけです。 Cで言う所の#ifdefでソースをかき分けるみたいなことをやっていたわけだ。だけど、複数のバイナリが出来
そろそろオラクルについて一言いっておくか - 未来のいつか/hyoshiokの日記
自分が受けたインタビューを自分が解説するという変な企画の第3弾（笑）。スーパーハッカー列伝。吉岡弘隆氏 その１ ソフトウェアの国際化をやっていたころの話をしよう http://d.hatena.ne.jp/hyoshiok/20100113#p1 その２ そろそろUnicodeについて一言いっておくか http://d.hatena.ne.jp/hyoshiok/20090419#p2 イノベーションのジレンマによって駆逐されたDECという会社 川井 そんな歴史があったんですね。「オラクル」さんに移られたのは「DEC」さんの終焉に伴ってていうのがあるんですか？ 吉岡 ありますね。1993年ぐらいから「DEC」が大赤字を出してる年なんですよね。 それで日本の「DEC」もどんどんシュリンクするという方向もあって、希望退職制度かなんかで200人ぐらい募集したんですよ。 そうするとやっぱり同僚がど
2009-02-07
社内で勉強会やりたいと会社に言ったら、「言うまでもない」と断られた。http://d.hatena.ne.jp/hkhumanoid/20090205/1233844080 せめて、自社の人間と活動をスタートして、そのうちグローバルになればいいかなぁという気持ちで、会社に相談してみた。 結果・・・ 「言うまでも無く、駄目。」 えーーーーっ！！ 正直ショックだ。社内勉強会を開催しようなどと煽っている*1責任の一旦はわたしにもあるので、なんで、会社が認めてくれないか考えてみた。考えてみたところで状況が変るわけではないし、そんな会社が存在するということを想像もしていなかった事自体、わたしが世間を知らないことなのかもしれないけど。世の中は広いので、ブラックな会社は存在はするだろう。だけど、従業員のモチベーションを挫いて何かいいことがあるんだろうか。本当に良くわからない。 当該ブログを読んでみると客
hatenalabo - 未来のいつか/hyoshiokの日記
はてなラボのサービスhttp://hatena.g.hatena.ne.jp/hatelabo/20060221/1140521491と言うのは何がなんだかよくわからないのだが、なんとなく面白そうという感じのものだ。だけど、ヘルプも何もついていないので使い方が正直よくわからない。 さっそくLife is beautiful (http://satoshi.blogs.com/life/)さんが噛み付いた。いわく「50%の完成度でサービスを出す」という言葉を誤解してはいけないである。（50%の完成度でサービスを出すも参照のこと。http://d.hatena.ne.jp/jkondo/20060222/1140588819もね） おっしゃる通りである。おっしゃる通りであるが、ちと週末考えてみた。 昔、シリコンバレーにいたころわたしのソフトウェア開発に関する思いを根本的に変えたことの一つが、「
未来のいつか/hyoshiokの日記 - OSSの昨日今日明日
1998年3月31日、米国Netscape社は同社の主力製品であるコミュニケーターV5.0のソースコードを公開した。商用ソフトウェアのソースコードを公開するという前代未聞の行動は後にオープンソースとして広く知られることになるが、その当時はごく一部のプログラマの注目を集めるに過ぎなかった。もちろん、日本の日刊紙（日経をはじめとするマスコミ）は、その重要性についてまったく理解も注目もしていなかった。 webのあちら側には当時の記録、日本語でのレポートが残っている。最近、その記録を発見したので、引用しながら8年後の今について考えてみよう。8年前のオープンソースを理解することが8年後のオープンソースを理解することにつながるかどうかは正直わからない。しかし当時の理解を検証することによって、我々が当時理解していなかった事を知ることができ、それが今後の8年を俯瞰することに役立つかもしれない。 http:
未来のいつか/hyoshiokの日記 Desktop Linux
なかなかブレイクしない。デスクトップリナックス。実証実験とかもさかんだが、その成果がデスクトップでもリナックスが問題なく使えるという程度ではなさけない。ユーザーにとって強烈な目に見えるメリットがない限りわざわざデスクトップをリナックスに変える人はそうはいない。当たり前の話である。 まあ、こーゆーことをいうとT社の社長に怒られてしまうのだが、事実だからしょうがない。T社の社長は経済産業省あたりがデスクトップリナックスのシェアの数値目標を持つべきだなんてことを言うわけだが戦後の経済復興の時代じゃあるまいし日の丸ソフトウェアがどうだとかいう話ではないだろうと思う。 デスクトップリナックスが普及するかしないかは最終的にはエンドユーザが決定すべきことで政府が強力に推進すべきことだ、とは言えないと思う。日本のソフトウェア産業を振興するために施策としていろいろな政策を打ち出すことはあってもだ。 マイクロ
XMLユーザーシンポジウム - 未来のいつか/hyoshiokの日記
Alternative 笑門来福さんのBLOG http://blogs.itmedia.co.jp/pina/2005/12/_3_2b5b.html につられてXMLユーザーシンポジウムに行ってきた。http://www.xmlconsortium.org/seminar/051214-U04/051214-info-v1.html お目当てはもちろん大成建設の木内さんの講演である。資料は配布されなかったのでせっせと手書きでメモをしたので木内さんの表現と微妙に違っているので注意してほしい。 情報サービス企業の七不思議。 事業登録制でない（許可が要らない） 格付けランキングがない 標準労務単価がない 標準積算基準がない 下請け構造の提示義務がない 成績評価がない 品質確保法がない まあ、内部統制もできていなければ外から見て分かる標準的な品質管理尺度もない。まったくもって工学的なアプローチ
FOFA - Find Once Fix All
バグを見付けたら同じようなバグがそこかしこにあると思え。そしてそれと同じようなまだ発見されていないバグを見付けて全部直せ、という原理原則がFOFAだ。言うのは易く行うのは難し。 某社のサポートの責任者と会食する機会があって、やっぱ、メインフレームの経験ですよね、修羅場をくぐった経験があるかないかで全然違いますよねという話になった。最近のゆるいシステムの話じゃなくて、ぎちぎちの基幹システムで胃がキリキリ痛むようなインテグレーションをして最後に腹を括らなきゃいけないような時、FOFAでやらなきゃ痛い目にあうのは自分だ。 手を抜かない。全力投球をする。それがFOFAだ。 オープンソースの若いエンジニアに伝授しなければいけない原理原則がいくつかあるとすると間違いなくFOFAはその一つだ。日本の競争力のある製造業の現場では問題を発見したら、その原因をとことん追求して同じ間違いを絶対しないような仕組み
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
