01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
http://d.hatena.ne.jp/hyoshiok/20050223
技術系の企業の場合、成長のボトルネックは優秀な人材をどれだけ確保できるかというところにある。
必要な時に必要な人材を確保できれば事業はスケールする可能性が高まる。
企業買収が有効な戦略になるのは、優秀な人材を束で確保でき、それによって事業をスケールさせることができるからだ。単なるマネーゲームではない。
優秀な人材が流通するためのインフラを整えよう、という心で、
今の仕事をやってるんだけど、なかなか道は遠い。
うちは実業を持ってるけど、便利な場がない。
ベンチャーで同じことを考えてるとこは、便利な場を持ってるけど、
実業がいまいち。
どっちかがどっちかを買収しちゃうのが良かったりする?
http://pitecan.com/presentations/Miraikan2004/TOC.html
「ユビキタスコンピューティング時代のユーザインタフェース」
についての内容。
参考: --> [2004-11-12]
これ行きたかったんだけど、仕事してたのと、
研究会の準備とかしてたんだよね。
参考: 増井さんへのインタビュー --> [2005-02-16]
http://bert.secret-wg.org/Stars/
セミナストリートの Bert、まえむらさんに会う。
Akinori Maemura and Bert have a small discussion on IP policy in general. Berts command of the Japanese language is being met with surprise.
すげー>まえむらさん
追記: Bert は芸者さんとも仲良くしてたらしい。いいな。
http://bert.secret-wg.org/Trips/Apricot2005/
http://www.apnic.net/apnic-bin/whois.pl?searchtext=126.0.0.0
JANOG のメーリングリストで流れてたんだけど、
こりゃすごいや。
24bit つまり 1600万以上の IP アドレスを使う予定がある、
ということね。
まあソフトバンクBBなら不可能じゃない数字ではあるな。
ひょっとすると今後は、8個まとめて配る、とか考えてるのかしら。
BBフォンって実は固定IPなので、BBフォンみたいな、
なにか面白げなサービスをするのも考えられるかも。
単純にBB親子電話とか、BBスモールオフィスフォンとかかもしれないけど。
http://wiki.opennms.org/tiki-index.php
オープンソースのネットワークマネジメントシステム。
勉強や興味のための車輪の再発明、がオープンソースの
多くを占めてるのは事実だと思う。
俺ならもっと良いものが作れる、とかね。
車輪の再発明は悪だ無駄だ、と言う人もいるけど、
個人的には必要だと思うしどんどんやってー、という気持ち。
再発明を阻害するような枠組みは
なるべくなくなって欲しいなあ、と思う。
オープンソースを使いたい、という理由の1つには、
オープンソースは安い、と思われてることがあるんだと思う。
迷信なのにね。
安く上げたきゃ、Yahoo とか mixi とか、
ウェブ上の無料のサービスを使っちゃうのが良いと思う。
グループウェアの機能のほとんどがわりとそれで足りちゃう。
彼らが無料で提供できるのは彼らのビジネスモデルが、
別のところからお金を取るようになってるからで、
いんちきしてるわけじゃない。
情報を預けることのリスクは計算しなきゃいけないけど、
計算してみると、意外とリスクってなかったりする。
必要なら契約で縛れば良いんだし。
ちなみに一般に流通している、パッケージや ASP サービスには
業務上の機能足りないから使えない、なんていう論理は、
たいていはナンセンス。
パッケージにない機能なんてものは、大抵の場合は、
業務上も不要だったりする。
ただし、良く考えた上で、パッケージにはないけど、
業務上、本当に必要なものがあったとしたら、
そこは実は最重要なビジネスコアになりうるので、
そういうところは agile でもなんでも使って、
強力に素早くシステム化をしないといけないのよね。
パッケージ化の流れと agile というのは、
実は共存するもので、一緒にやるとすごく強力に
なりうるんじゃないかと思う。
agile はビジネスコア開発にだけ適用する、とかね。
あと、パッケージや ASP はインターフェイスの機能が
足りない場合があるので、ラッパーの開発とか、
インターフェイスの部分については agile は
相当有効かもしれない。
ユーザ満足度向上は agile の目的の1つだけど、
インターフェイスがユーザ満足度に占める割合は
結構大きいと思うし。
http://nais.to/~yto/clog/2005-02-23-3.html
引用の引用になっちゃうけど。
オープンソースのグループウェア・システムを作ろう!
なんてのはうまく行きっこないでしょう、という話。
まあそりゃそうかも。
グループウェアなんてものは作る側からすると面白いものじゃないし。
作る側の論理で作れるものじゃないとオープンソースソフトウェアは
成立しないような気がする。
作る側の論理というのは、
- 面白いの作った、便利だから使ってみて
- 技術的に楽しい、いじると楽しい
- ちょっとした工夫でこんなに便利、これって COOL ?
- 一緒になにかやろうぜ!
- 便利なの作ったけど保守はやりたくない、後はよろしく
- インターフェイスは適当でOK、ロジックのほうが楽しい
- 作った人が便利。一人で使って便利。
こんな感じの心かな。
他にもあると思うけど。
グループウェアの開発には上の要素ってあんまりない気がする。
ただまあ、オープンソースという仕組みを利用することに
ビジネス的メリットもある、ということがわかってきたので。
商用開発と同じように開発した製品を、
なんらかの目的があってオープンソースにする、
ということはあると思う。
ちなみに、一方でグループウェア等を使う側のユーザはと言うと、
業務に使うアプリケーションは
- 導入コストは少ないほど良い、パッケージGood、ASP最高
- メンテナンスフリーが良い、パッケージGood、ASP最高
- 業務を効率化して欲しい、使う技術はどうでも良い
- インターフェイス重要
こんな観点から選ぶかな。
アプリケーションがオープンソースだろうが商用品だろうが、
わりとどうでも良いことだったりもする。
http://slashdot.jp/article.pl?sid=05/02/23/1114203
黒が最善を尽せば、25目勝ち、つまり白は全滅ということね。
最近碁を指してないな。
職場の近所の席に強い人がいるので久しぶりに教えてもらおうかしら。
2021 : 01 02 03 04 05 06 07 08 09 10 11 12
2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
最終更新時間: 2021-03-02 14:20