今朝の記事は予想外に色んな人に読んでもらえたみたいで、ありがたい限りです。一時間程度でラフにまとめたものなのでお恥ずかしい限りですが、みなさまの役に立ってたら幸甚です。いや、ほんとに。 んで、見たことないくらいたくさんついたブクマを眺めていると、「何のためにしたかイマイチわからない」「どうやって金を儲けるつもりなんだ？」という話がちらほら見受けられます。ねぇ、ぼくも色々もんもんと考えておりました。 んで、決して答えが出たわけではないんですけど（というか最後の最後がわからんのですよ、やっぱり）、でもこの方向性に向かう意図は僕の中で納得がいったので、ついでにメモ的に晒しておこうと思います。 分析の前に、ツールの確認 今回は、クラシックな戦略分析ということで、5フォース分析をしています。 ファイブフォース分析 - Wikipedia Microsoftという企業に対して、サプライヤとカスタマーを

Jason Zimdars / 青木靖 訳 2010年8月31日 「Webデザインを始めたい場合、どうすればいいんでしょう？」とか、「Webアプリを作り始めるには、どんなスキルが必要ですか？」といった質問をする人がたくさんいる。おすすめの本を山ほど挙げたり、「となりのやつより115%上をいく55の技」みたいな記事を何十本かリストアップするのは簡単だが、本当のところを言うと、始めるために何かを学ぶ必要はない。一番重要なことが何かというと、ただ始めることなのだ。 何かを作り始めること。Webデザインを学びたいならWebサイトを作ればいい。起業家になってWebベースの製品を売るビジネスを始めたいなら何かアプリを作ればいい。まだスキルがないかもしれないけど、どうしてそんなこと気にするの？ どんなスキルが必要になるかもわからないというのに。 すでに知っていることを使って始める Webで何か作りたいん

小飼弾(@dankogai) まずはMOONGIFTさん、10周年おめでとうございます。今調べたら、404 Blog Not Foundも今年の11月が開設で、今年は個人的にも社会的にも節目の年なのかも知れません。 節目といえば、 "Open Source"という言葉も今年の2月3日に0x10歳の誕生日を迎えます。オープンソースのこれまでの沿革を振り返り、これからのことに思いをはせるには絶好のタイミングとも言えます。これまた偶然にも、その8ヶ月後に私は一児の父となりました。私にとって、オープンソースが育っていた月日は娘たちが育っていた日々と重なっています。 ただし同い年の長女とオープンソースには違いが一つあります。「オープンソース的」なものはすでに長らく存在していて、なかったのはオープンソースという名前だけだったのです。 俺のサーバーがこんなに売れないわけがない いわゆるLAMPを構成する

SAStruts＋DBFluteでの開発が終わり、またCOBOLで書かれたシステムの保守が始まる・・・。 あぁ、楽しかったSAStruts、楽しかったDBFlute、楽しかったJava。 ということで、この辺りで一度、COBOLから学んだことについてまとめてみようと思う。 僕が今、主にかかわっているシステムはクライアント側がVB(Windows)、サーバ側がCOBOL(UNIX)で出来ている。そして更にバックボーンには、メインフレームが構えている。メインフレーム側の構成は主にPL/1＋JCLで、もちろんDBは階層型だ。 そんなシステムを２年近く保守してきた中で気付いたことを書いて行こうと思う。 カプセル化やスコープの重要性 今更何を言っているのかと思う方もいると思うけど、マジなんだ。僕が初めて学んだ言語はC言語でそれからC++、Javaと続き、その後LL言語にも手を出し始めた。C++を始め

事業の周りに人材を集めるのではなく、人材の周りに事業ができると考える私たちにとって、採用は生命線です。 採用は、一緒に新しいサービス、新しい「Delight」を生み出して行く仲間探しです。また、階層的秩序よりも新しい発想を徹底して重んじるDeNAは、典型的な日本企業の文化に浸っていない新卒が頑張って独特な企業文化を築いて来ました。その意味でも、新卒採用は極めて重要で、創業以来、いっさい妥協せず、社をあげて取り組んで来ました。 今では新卒だけでも毎年数万人がエントリーしてくれるようになりました。そのこと自体はとてもありがたく感じています。 しかし選考の中で少し不思議に感じることがあります。わが社を受けてくれる学生は皆、とても優秀で頭もよく、面接も上手にこなします。でも何か不思議と違和感がついてまわるのです。 この違和感とは--？ どうも、学生の皆さんが、会社を受けた理由も、会社選びの重要な情

New Task Users Name Point yuca 13 Show kei 5 Show Tasks Name Completed at Point User お料理 2013-09-16 12:00:00 +0900 3 yuca お掃除 2013-09-16 10:00:00 +0900 2 kei 風呂掃除 2013-09-17 11:14:00 +0900 1 yuca お料理 2013-09-17 22:49:00 +0900 3 yuca お洗濯 2013-09-17 22:50:00 +0900 2 yuca ごみ捨て 2013-09-17 23:31:00 +0900 1 kei お皿洗い 2013-09-17 23:31:00 +0900 2 kei お洗濯 2013-09-19 20:13:00 +0900 2 yuca お掃除 2013-09-19 22:5

「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価

「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ

先日の記事の補足として。 今、思春期の後半と言われている20代後半〜35歳ぐらいの年齢には、思春期という言葉と表裏一体だったはずの、モラトリアム*1という言葉があまり似合わない、と思う。それぐらいの年齢になっても進路や生き筋を自由選択できる幸運とタフネスを持った人もいないことはないが、あくまで幸運だったりタフだったりする比較的少数の人達である。大半の人達においては、三十路を迎えた頃というのは、色々な事がかなりのところまで決まっている or 決まりつつある最終段階に相当する。決まりつつある、という意味ではぎりぎりモラトリアムとも言えなくもないが、夏休みに喩えるなら、八月三十日や八月三十一日を夏休みと呼ぶのと同じようなものではある。 実際には、三十路を迎えた大半の人は、自分の人生のかなりの部分を既に選んでしまっている。まだ会社は変えられるし、恋愛経験のある人なら結婚相手を選べる可能性もある。し

日本が世界で勝つかを考えていたら・・・ 先日、とある雑誌の対談をしたのですが、そこで「アメリカ的な文化というものは、そのまま『グローバル』というものにつながっているけど、そのグローバルな時代に、日本が勝つにはどうしたらいいか？」みたいな話題がありました。 そこで僕は「それぞれの国が持っている文脈（コンテキスト）を活用したものでないと、世界では到底ユニークにはなれない」という風な発言をしてたのですが、「いやいや、そもそも日本が今まで勝ってきたものの共通点は何だっけ？」と思ったのです。 いろいろ考えたのですが、アメリカは「ハッカー文化」であるが、日本は「オタク文化」であり、オタク文化とは「手段を目的化することで、ユニークなものができる」という仮説にたどり着きました。 というわけで、そのことについてブログを書いてみます。 アメリカ文化とはどういうものか では、まず対比として、アメリカ文化について

３月に入ったので、今年もまた新入生向けの記事をはじめよう。 最初は「学生のときに知りたかった」と言われた記事をまとめてみた。 １　大学はどういうところか？ 文献学からはじまった　→　研究する大学と専門分化した科学の起源 大学で学問研究をするという今では当たり前のことは、19世紀初頭ドイツに端を発する。 これは研究と教育とを結び付けて行う新しいタイプの大学（研究大学）によるものである。 研究大学は、ゼミナール方式を採用し成功させることで、研究と教育とを結び付けるという理念を実現した。 ゼミナールでは、参加者は知識を伝授されるのでなく、自分で研究を行いゼミナールで発表し、他の参加者から批判的吟味を受け、討論することが求められた。 このためゼミナールは研究者を育成するのに優れ、また批判的吟味の習慣から議論の厳密化や研究の実証性が追求される傾向が生まれた。 ゼミナールはまた、実験室を大学に持ち込む

三菱造船、アンモニア分解水素の船舶利用に関するフィージビリティ・スタディを完了　アンモニア発電ソリューション技術を有する... 2024-06-28

エンタープライズのOSSについて こんなこと書くとOSSなモヒカンな人にぶん殴られるわけです。読み手の方で、自分はOSSを引っ張ってきたと自負されている方や組織のかたや、OSSは商用より無条件で優れていると思っている人は気分が悪くなるので、読まないでください。非常に個人的なメモですので。以下の考えは基本的にソフトウェア・ビジネスとしての考えなので、自分で作って、自分で利用して、ムフフな人はあんまり考えてないので、そのつもりで読んでね。自分利用OSSはそれでいいと思うので、それでいいかと。 [まずAsakusaについて] まずAsakusaがなぜOSSかということを明確にしておきます。非常に単純です。Asakusaは様々な人の意見を集約してできています。これは別にNautilus-technologiesのメンバーというわけではなく、Hadoopコミュニティに参加した方の意見を相当取り入れて

久々の更新なのでちょっとは刺激的なことを書いてみる。 今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。 しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。 そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。 そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、