チェンジビジョンの平鍋さんに誘って頂き、ヌーラボの橋本さんと３人で行ってきました。イベントの詳しくは平鍋さんのブログに詳しいです。
http://blogs.itmedia.co.jp/hiranabe/2010/07/tanabataus.html
tanabata.usでは、ライトニングトークスのような発表の場があり、シリコンバレーで働くエンジニアやスタートアップの起業家、投資家の前で、SonicGardenとyouRoomについて発表してきました。そのときの資料は以下です。
astah* や cacoo と違って実績も少ないので、コンセプトを伝えて、あとはデモを見せるような内容にしました。ビジネスモデルとして、Freemiumというのは一般的な様子でした。
今回は、このイベント以外にもシリコンバレーやサンフランシスコ周辺のスタートアップ企業やソフトウェア企業を訪問してきました。そのあたりについては、また別のエントリで。
]]>一方で、SKIPという企業内で使うSNS、いわゆる社内SNSもあったりする。こちらは、見た目はTwitter風ではなくレガシーなSNSに近いため、気軽に使えるという印象が弱くなっているように思う。（Twitterが広まったことで、ブログが相対的に重厚な印象を持つようになったように感じてます）
youRoomとSKIPで、どちらがどう使うか、違いは何か、というところについて、作った我々はわかっているつもりだったけど、ちゃんと整理していなかったので、以下の図のように整理してみました。
横軸に目的や用途で分類し、縦軸では特徴的なポイントで分類してみました。精密に考えると違っているところもあるかと思いますが、雰囲気は伝わると思います。（SKIPとyouRoom以外のツールは私の勝手な見方です）
youRoomでは、メールのような1on1ではなく、ある程度テーマで括られた複数人のグループの中での情報共有を考えて作りました。そこのルームへの書き込みは、自分の呟きや日記というよりも、そのルームに参加しているメンバー全員へ向けたメッセージになります。なので、あまり自分だけで完結するような独り言は書きにくくなっていると思います。逆に、そのルーム全員が見てる中で連絡・会話をすることが出来るので、チーム内で起きていることを自然と共有することが出来ます。だから、youRoomはメーリングリストの今風への置換えになることを目指しています。機能は違いますが、立ち位置はグループウェアにも近いかもしれません。
SKIPでは、youRoomと違って、会社などといった組織で用意された「場」の中での個人の発言にフォーカスをあてています。SKIPでのユーザ自身の発言（ブログ等）は、誰かに向けたものではなく、あくまで自分自身で完結する独り言に近いものになります。特定の誰かに向けたものでないということから、気軽に書き込みをすることが出来ると言えます。メールで全社員に向けて勉強会の案内をするのは気が引けるけれども、ブログで案内することは気軽に出来るはずです。興味のある人だけが見れば良いからです。送りつけるのではなく見にくる、という感覚です。SKIPでは、組織内で個人と個人を結びつける役割を果たします。
そうして考えると、SKIPは「会社のビル」のような場であり、そこで話される内容は、業務も含みますが、どちらかというと会社や仕事に関する雑談が交わされる場。youRoomは、「プロジェクトルーム」のような場であり、そこで話される内容は、業務などの特定のテーマに限った話をする場、とすることができるかもしれません。なので、SKIPではセクションをまたぐ横の連携、youRoomではセクション内での縦の連携に使えそうです。
一方で、今のSKIPは、旧世代的であり、レガシーな機能と見た目をしているのは事実です。よって、前述のような使いかたと機能の違いで見れば、SKIPが向いているようなものでも、youRoomを使おうと考えてしまう場合もあり、混乱を産んでます。そこで、SKIPもバージョン2を目指すという段階で、右下のポジションを目指した改良を実施しようかと考えています。ただ、そこにはすでに、Chatterやyammerがいそうな気がしてます（笑）逆に、youRoomは、その辺りと本当は競合しないんですが、見た目で誤解されてることが多いです。
]]>2月17日号には「幸せを呼ぶアジャイル開発」の連載で、SonicGardenを取り上げて頂きました。112pです。号全体がクラウド特集ということで、クラウドサービスをアジャイルに開発している私たちにお声をかけて頂けました。取材で好きなようにだけ喋ったんですが、うまくまとめてくださってます。http://coin.nikkeibp.co.jp/coin/nc/special750/
3月3日号では、同様の連載で、XP祭り関西2010でお話させて頂いた内容を掲載して頂きました。XPの10年を振り返る、というテーマで話した内容です。こちらは、ぐっとアジャイルにフォーカスした話です。
「アジャイルマインドを育もう」というテーマで開催された今回のXP祭りに呼んで頂いて、お話しする機会を得ました。「アジャイルマインド」という曖昧なテーマではあるんですが、私なりの「アジャイルマインドとは何か？」を探るために、eXtreme Programmingが誕生してからの10年を、コミュニティの歴史と共に、私自身のXPライフについて振り返ってみました。そのエッセンスから、参加された皆さんに、私が考える「アジャイルマインド」について感じてもらおうと考えました。以下、資料です。（言葉で補足しないと伝わらないかも）
スタッフのみなさん、本当におつかれさまでした。
http://www.pref.fukuoka.lg.jp/f17/rubyforum2010.html
http://itpro.nikkeibp.co.jp/article/NEWS/20100127/343813/
【受賞理由】
ユーザの意見を迅速に反映しながら運営する必要があるSNS（ソーシャル・ネットワーキング・サービス）の開発に、Rubyが有効であることを証明し、今後、同種のビジネスへの適用が期待されることが高く評価された。
頂いた賞に恥じぬよう、引き続き精進して参りたいと思います。
プレゼンテーション審査の際に使った資料を公開します。
私たちSonicGardenは、今回、優秀賞を頂いたオープンソースSKIPを、クラウドで提供する"SKIPaaS"というサービスを提供しています。アジャイルとクラウドの相性の良さについては別途エントリで記事を書こうかと思いますが、アジャイルとクラウドのそれぞれにおいて、今回Rubyを採用したことは私たちにとっても、とても重要な選択だったと思いますし、その選択は間違いなかったと思っています。
]]>Webで何か新しいサービスを考えようとしたときに、必ず立ちはだかるのがGoogleです。面白そうなアイデアを思いついたとき、「Googleがやっているのではないか？」「Googleが始めたらどうなるか？」を考えてしまいます。
私たちも、youRoomという「メーリングリスト+Twitter」のようなコミュニケーションツールを提供していますが、GoogleGroupsとの違いであったり、Googleの今後の動きは気になっています。
Webの世界におけるGoogleの存在感は、今となっては圧倒的とさえ言えます。10年前であればマイクロソフトが握っていた巨人のそれです。なので、何かWebで始めるときに、Googleを意識しない訳にはいきません。
先日も、bit.lyをはじめとする、URL短縮サービスにGoogleが参入するニュースが話題となりました。既に始めているURL短縮サービスにとっては、戦々恐々とする思いかもしれません。
一方で、YouTubeのように、GoogleのGoogle Videoと正面から戦った上で、買収されるという結果もありますね。必ずしも、Googleが勝つとは限らないのがWebの世界の面白いところです。
では、今もっとも勢いがあるWebサービスと言えば、Twitterでしょう。1500万ドルでGoogleと提携したというニュースもありました。そこで一つ疑問が湧きます。
なぜGoogleはTwitterを作ることが出来なかったのか？
Twitterの基本的な仕組み自体は非常に簡単なものなので、特別な技術が必要な訳ではありません。裏側のスケーラビリティの確保が技術的に困難であるのはわかりますが、そこはGoogleの専門分野と言っても良いでしょうから、さほど問題にはなりません。つまり、テクノロジの問題ではなさそうだと考えました。
20%ルールを持つGoogleですから、技術者の時間という問題でもなさそうですし、「リアルタイムWeb」というコンセプトも、あの天才集団で思いつかない訳はなさそうです。実際にGoogleWaveを作り上げています。だけど、Twitterのようなものは作っていない。何故だろうか。
その疑問をTwitterでつぶやくことで、色々と反応を頂いた中で、@huehara88さんとのやりとりが面白かったので転載します。
放っておいたって勝手に作ってしまいそうな技術者がわんさかいる中で、GoogleからTwitterライクなサービスが出なかったのは「ミッションでないから」という理由は、もっともな気がしました。あっているかどうかはともかく、一応すっきりしました。
Google の使命は、世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることです。
この有名なミッションに従って、Googleがサービスの提供開始のデシジョンをしているとして、あれだけの社員がそのミッションを理解して働いているのだとしたら、Googleの強さの理由もわかるような気がします。あの規模で、その企業文化を維持できているとしたら、それこそがGoogleの真の強さの源泉と言えるかもしれません。
どんな新しいWebのサービスも「Googleがいるから」と言い訳にしないで、始めてみないとわからない、ということだし、Googleのミッションとは違うことなら、参入してくる可能性も低い、かもしれません。
・・・と言ってるそばから、「Googleなう」なんてサービスが始まったりして。
]]>eXtreme Programming（通称XP）というアジャイル開発プロセスを、日本に広めるための活動をしている「XPJUG」というコミュニティが開催しているイベントです。2002年に初めてのXP祭りを行い、毎年秋頃に開催してきました。ソフトウェア開発、IT業界で働くプログラマーやエンジニアを中心としたベンダーに依存しない独立した活動です。また、関西に在住のエンジニアの方々を中心に立ち上がった「XPJUG関西」というコミュニティもあり、関西でも「XP祭り関西」が行われてきました。
そして、今年2010年に、2つのXP祭りが予定されています。
まずは「XP祭り関西2010」です。「アジャイルマインドを育もう」というテーマで開催されます。
講演者の面々として、
の木下さん
の岡島さんまた、私も昨年のXP祭りで、XPJUG代表の引退を表明させてもらいましたが、今回は私とXPの出会いのきっかけから、経験したこと学んだことなどを振り返りつつ、引退に至まで、お話させて頂く予定です。
東京での「XP祭り2010」は、秋頃に開催の予定です。その実行委員会のキックオフが、早くも開催されます。
なぜ、今からキックオフで、なぜ、委員会の参加を募集するのか？それは、昨年のXP祭りのふりかえりをスタッフで行った際に、XPJUGの存在意義について語り合った中で出たアイデアが発端です。XPJUGとして「XP祭り」は非常に大きなもので、逆に言えば、XP祭りを開催することこそが、XPJUGの意義ではないか、と考えたのです。すなわちXPJUGとは「XP祭り実行委員」のことである、と。
XP祭りは、スポンサーを付けずベンダ色のない、あくまで現場のエンジニアの方々を中心としたイベントとして行ってきました。そのため運営スタッフと参加者の境が非常に薄く、運営スタッフも参加者として楽しむし、参加者の皆様にも運営をお手伝い頂くなど、非常に良い関係が築けています。そこで、次の2010年に開催するXP祭りでは、よりもっと参加者の方々との関係を深め、運営についても、よりもっとオープンにしていくことを考えました。
そこで、「XP祭り2010」からは、「XP祭り実行委員会」のスタッフになってくれる方を広くオープンに募っていき、その方々と共に、XPJUG（XP祭り実行委員会）として開催に向けて準備をしていきたい、と思っています。コミュニティ活動は初めて、という方もこれを機に参加頂ければ幸いです。
参加申し込みはこちら・・・XP祭り2010実行委員会キックオフ
また、youRoom上で、オープンなディスカッションを行っています。youRoomへの参加登録は必要ですが、自由に参加できますので、興味のある方はご参加ください。
]]>2009年は、TIS株式会社の中でSonicGardenという社内ベンチャーを立ち上げた年でもあり怒濤のように過ぎ去った一年でした。多くの出会いがあり、色々な方々に支えて頂きながら、ほんの少しですが前に進めることができたと思います。
SonicGardenとしては、去年に引き続き、企業内SNSとしてSKIPを提供させて頂いています。SNSの本質は人と人の関係構築にあると思います。そこに情報を載せることでナレッジとなり、そこに思いを載せることでビジョンを共有でき、そこで個性を発揮することでセクショナリズムを解消することができると考えています。もはやSNSというキーワードはバズワードを通り越して、とりたてて注目する言葉ではなくなっているかもしれません。しかし、企業内におけるソーシャルネットワークとコラボレーションの重要性は、これから益々増してくると確信しています。SKIPでは、思いを同じくして下さる皆様と共に、単なるツールだけでない情熱共有基盤を提供させて頂き、皆様のお役に立てればと考えています。
また、企業内SNSで培ったノウハウと部品群を活かし、youRoomという新しいウェブサービスも始めました。youRoomでは、企業内に限らず、より多くの方に多くの場面で使って頂くために、無料のインターネットサービスとして提供しています。まだ実験的な取り組みではありますが、「あなたにとって世界（ソーシャル）は一つではない」というテーマで「ソーシャル」の次に来るものを確かめるために試行しているサービスです。お試し頂ければ幸いです。
組織として、社内ベンチャーという形はいびつであることは確かですが、だからこそ出来ることは何かを考えつつ、今年も進めていきたいと思います。
個人的には、2009年は迷ったり惑ったりすることがあり、反省することも多い一年でした。何事も自分で経験しないと痛さや辛さのわからない性格でもあり、無駄が嫌いな割に無駄なことも沢山してきました。性格はすぐには変えられないので、省みることで、次につなげていけるよう努力していきたい所存です。
どうぞよろしくお願い致します。
]]>SlideShareに資料をアップしました。プレゼンテーションZenに多少影響を受けてるので、講演時の説明がないとわからない部分があるかもしれませんが、その辺りは、今後のブログで補足していきたいと思います。
今回のテーマは、同じIT業界と言っても、受託開発（SI）とサービス提供（SaaS）では、すごく大きな違いがあるということを、「ソフトウェア開発」という観点で伝えようというものでした。
まとめとしては、受託開発やパッケージは「製造業」であり「Point of Sales」の考え方を基底においてビジネスをすべきで、そこでは、１度の「納品／出荷」が顧客へ提供できる瞬間になるのに対し、ソフトウェアサービスビジネスでは「サービス業」であり「Point of Use」の考え方でビジネスをするためには、一期一会の精神でユーザが「使う瞬間」を大事にしていかなければいけない。サービスを実現するためには、常に改善／維持を繰り返す必要があり、繰り返すために、色々な要素を「小口化」して、「小口化」することで「日常にしていく」ことが大事ですよ、ということを具体例を交えて話しました。
私自身は既に毎日の業務としてのプログラミングをしていないので、この内容で、DevLOVEという場所で聞く人に価値を伝えられるか、不安だったんですが、papandaから頼まれた時に、「Fusionだから良いんですよ！」という言葉を胸に、講演してきました。
そんな訳で、今回は、蘊蓄や抽象的なことを語ることもしないし、熱いメッセージを伝えることも封印するという、ある意味、最近の私らしくない内容になっています。（でも、今回のような事例発表は、私の原点でもあります。）
淡々と、私が経営する社内ベンチャーのSonicGardenという組織について、そこで、どういった形で「ソフトウェア開発」をしていて、何に気付き何を学んだのか、事例を話しました。私のやっていることが正解かどうかなんてわかりませんが、聞いて頂いた方々の中で何かの発見に繋がれば良いな、と思っています。
資料作りには苦労しましたが、人に伝えるということをきっかけに、自分なり色々と整理することができたと思います。このような機会を与えて下さった、DevLOVEのスタッフの皆さんに感謝します。DevLOVE2009は、とても良い会だったと思います。おつかれさまでした。
]]>システム開発で、顧客からこう言われた時、どうするか？
SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。
ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。
冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているから出る発言だろう。
さて、この話の前提として、タイミングは「仕様」がまだ完全に固まっていない状態であり、ここで言う「仕様」とは、ユーザから見たシステムの挙動（正しい動き）のことを指している。開始前に「仕様」が完全に固まった（夢のような）プロジェクトは見たことがないため、おそらく一般的な話。
また、発注者と開発者の２つのロールがあり、「仕様」を決めるのは発注者の役割で、「仕様」に従ってプログラムを作るのが開発者の役割、また、完成したプログラムが「仕様」に沿ったものかの確認をする（検収する）のも発注者の役割、としている。
この前提が違う、という場合は、この話は当てはまらない。しかし、発注側とした役割もSIerがやっている場合があるだけで、ソフトウェア開発の工程／手順としてはそれほど違いはない筈である。
改めて。そんな状況で本当に開発者の開発速度がボトルネックになるのだろうか？コストをかければ、完成が速くなるのか？「仕様」が完全に固まっており、発注側による「検収」を含まない、ということであれば可能かもしれない。しかし、「仕様」が完全に固まっていることって本当にある訳がないし、きちんと「検収」されていない状態を完成とは呼ばない。しかし、「要件定義」->「開発」->「検収」という流れが１度しかないウォーターフォールであれば、そう考えたっておかしくない。
しかし、今はアジャイル開発におけるボトルネックの話をしている。アジャイル開発であれば、その流れは何度も繰り返されるし、ただ単に作るだけで完成かといえば、そうではない。本当に発注側が欲しいと思っているソフトウェアが提供されてこそ完成と言える。
繰り返しながら、「仕様」を決め「開発」をし「検収」していくとしたら、開発する速度と同等の速度で、仕様を決めていかねばならないし、作られたソフトウェアの確認をしていかなければならない。そう考えたら、かなりの時間を発注側が割かねばならないはずである。おそらく、開発と同等かそれ以上のコスト（工数）がかかるのではないか。つまり「オンサイト顧客」という状態だ。
そう考えると冒頭の言葉はありえない。お金を出して時間内に開発側が作れる量を増やすという解決策だけでは駄目で、発注側にも、コストをかける用意が必要になる。しかし、発注側の人間は多くの場合、色々なプロジェクトや業務に携わっていることがあり、容易に沢山の工数をかけることは実質不可能なはず。そう考えると、開発にいくらコストをかけても、仕様の決定と成果の確認が追いつかなければ、意味がなく開発側も持て余すことになる。
実際に、週に２〜３度の２〜３時間の打ち合わせで、開発側と発注側のコミュニケーションが間に合うかというとそんなことはなく、発注側からの回答を待つために、無駄なスイッチングコストが発生したり、回答結果によっては無駄な開発をしていたことが発覚したり、ということを経験した方は沢山いるのではないだろうか。私はある。
逆に今、私は発注側として仕様を決める作業と確認の作業をしているが、開発側の速度を最大限にするために、平日の朝までに、毎日の確認と仕様の決定を行い、なるべくリアルタイムで開発側からの質問に答えるようにしている。ここで速度の限界は、発注側である私の速度になっている実感がある。
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
開発における生産性だけを考えるだけでなく、全体としての視点を持ちたいものである。
]]>立命館大学を卒業して10年が経ちました。立命館の学部、そして大学院と、学生として過ごした6年間よりも長い時間を社会人として過ごしてきた訳ですが、今でも学生時代の頃のことはよく覚えていますし、今の私を作り上げた基礎はやはり、大学での経験だったのだろう、と改めて思います。
今、私はTIS株式会社の中で、社内ベンチャーを立ち上げて経営者をしています。TISは、いわゆるシステムインテグレーターであり、顧客に情報システムを提供しています。私が立ち上げた社内ベンチャー「SonicGarden」は、TISがまだ取り組んでいない新規事業に取り組むための組織です。
SonicGardenでは、主にSaaS（Software as a Service）を中心に事業を展開しています。今の主力サービスは、大企業向けの「セクショナリズムの解消」を実現する「社内SNS」である「SKIP」というソリューションです。企業風土の活性化に悩みをもった企業に対し、SaaSとコンサルティングを提供しています。
私は、SonicGardenの中で経営者として日々、事業経営を行っています。経営の仕事、とはいえ大層なものではなく、少人数のベンチャーなので、できることは何でもやるといったスタンスです。今でこそ、経営者という立場ですが、元々は、学生時代は理系でしたし、入社後もプログラマやシステムエンジニアとして仕事をしてきました。むしろ、プログラミングは大好きで、私にとって天職とも思える仕事だったし、それができるという理由で今の会社を選んだのでした。
では何故、そんな私が事業経営に従事することになったのか、社内ベンチャーを立ち上げようと考えたのか、その説明には、立命館での学生時代の経験まで遡ることになります。
大学時代、私は２つのことに没頭した記憶があります。１つは、知り合いの学生が立ち上げたベンチャー企業でのアルバイト。もう１つは、研究室の仲間とともに作って公開したフリーソフトです。
ベンチャー企業でのアルバイト経験は、私にとって、プログラミングを仕事にすることの楽しさ、クリエイティブな発想を実現する方法、そしてビジネスに対する考え方の基本を学ぶことのできる機会でした。なによりも自分より何十倍も優れた人たちに囲まれて仕事ができた経験は、なにものにも代え難いものでした。
研究室の仲間と作り上げたフリーソフトは、当時普及の兆しが見え始めたインターネットで公開したことで、日本中のユーザに使ってもらうことができ、しかも、使ってくれた利用者から直接メールなどで反応をもらうことができ、大興奮をしたことが記憶に残っています。反響も大きく、雑誌などで取り上げられ、関連書籍も出すことができました。そこで、自分たちのアイデアでソフトウェアを作りあげること、利用者からの直接のフィードバックを得ることの楽しさを覚えました。
そして大学院を卒業した後、現在の会社に入り、プログラミングの仕事に従事することになりました。お客様のシステムを作り上げる仕事は、とても学ぶことの多い仕事ではあったのですが、自らのアイデアを実現する仕事とは少し違っていました。そこで私は、その自分がやりたかったことを実現するために、社内で企画を作り提案を通すことで、社内ベンチャーを立ち上げました。自らが経営者の立場になることで、本当にやりたかった仕事を得ることができました。
こうして、今の私があるのは大学での経験が礎となっています。改めて、そのような経験の場を与えてくれた立命館には感謝の意を表したいと思います。ありがとうございました。
]]>その時に、行うべき作業が見えていなかったり、スタッフ同士で共有できていなかったらどうでしょう。行うべき作業が重複していたり、手戻りが発生したり、やるべき作業が抜け落ちたり・・・
そこで、多くのプロジェクトでは、そのプロジェクトで行うべきタスクや課題について、一覧で管理していると思います。まずは、それがプロジェクト管理の第１歩です。
しかし、多くのプロジェクトでは、その課題やタスクの管理の一覧化に使っているのが表計算ソフトのExcelだったりします。タスクや課題の一覧化と共有が、プロジェクト管理のキモであることはわかりつつも、その管理ツールといえば、Excelが多いようです。
Excelの場合、ファイルで共有をすることになるので、共同で編集することが困難です。タスクの状況や進捗状況などについて、プロジェクトマネージャだけが編集するようにしていれば大丈夫ですが、各担当者もコメントを記入したりするようにした場合、人数が増えれば増えるほど共同での編集が困難になってしまいます。一方でプロジェクトマネージャだけが編集できるようにしたとしたら、それはそれでプロジェクトマネージャの負担が大きくなりすぎるという問題が出てきます。
そうした問題を解決することのできる可能性をもったツールが、「Redmine」です。Redmineは、Webのアプリケーションで、課題の登録から一覧での管理までを、複数のユーザで同時に行うことができます。ソフトウェアで言えば、不具合の管理もすることができるような、課題管理／不具合管理のツールです。
Redmineは、オープンソースで公開されたソフトウェアで、無料で試すことができます。しかし、セットアップであったり、操作方法であったり、初めての方にとっては、Excelよりも敷居が高いことは否めません。
そこで、Redmineの導入や最初の一歩を進みだすための情報をまとめて書籍にしてみました。それが、「Redmine -もっと手軽にプロジェクト管理!」です。
Redmineで手軽にプロジェクト管理を始めてみませんか？
- 「Business Blog & SNS World 2009」 http://www.idg.co.jp/expo/bbsns/2009/
私の所属しているTISでは、社内SNSを導入したことで、会社が変り始めました。
風通しがよくなり、社内にどんな人がいるかわかってきて、社員同士が近くなってきました。
でも、決してそれは、社内SNSがあったからではなくて、会社で働く社員たちの意識が変ったからでした。
なので、社内SNSがあれば必ず効果が出るなんてことはありません。
それでも、きっかけは社内SNSから始まったのは事実です。
これは、TISに限ったことではなく、社内SNSを導入した企業で起きつつある現象です。
では、多くの企業が導入しつつある中で、うまくいった企業とうまくいっていない企業で、どんな違いがあったのか？
その辺りについて、実際に導入して奮闘している企業の担当者の方との対話の中から、答えを見つけていきたいと考えています。
そんなパネルディスカッションをする予定です。
詳しくは以下から。
- http://www.skipaas.jp/topics/bas_2009
まだ事前登録間に合います。
サービスサイト： http://www.skipaas.jp/
プレスリリース：http://www.tis.co.jp/news/2008/090618.html
社内SNSの導入というと、中々うまくいかない、導入したけれども活用できていないという話を聞く機会があり、そういった皆様へのサービスとして、弊社での導入経験を元にしたコンサルティングのサービスを提供させて頂くことにしました。
一般的にコンサルティングというと、ズバッと問題解決をしてくれるようなイメージがあるかもしれませんが、SKIPサービスで提供するコンサルティングは違います。社内SNSは、導入する企業ごとの文化や風土が非常に色濃く反映されるもので、その文化や風土にそった形で導入して活性化させていかないとうまくいかない、と私は考えています。
もしこの仮説が正しければ、コンサルティングサービスとして、活性化代行をするというのは、本当は出来ないはずです。会社の文化や風土といったものを本当に理解しているのは、その導入企業の中の人間だけで、コンサルタントが話を伺うだけで理解できるものではないはずです。
そこで、私たちの提供するプロフェッショナルサービスでは、導入担当者の方々が、社内SNSの活性化や運営をしていく中での困った点などの相談にのらせて頂き、ともに考えて、その担当者の方の中から答えを導きだすようなサービスをさせて頂こうと考えています。あくまで、答えは企業の中の人が持っているもので、私たちのサービスは「コーチング」を通じて、答えを引き出すお手伝いをさせて頂こうと考えています。
]]>SKIPを使っての、OpenIDでの実装の紹介記事になっています。実際にサービスとして提供している部分のソースコードを使っての説明なので、割と参考になるかと思います。
