■[W-ZERO3(es)][lifehacks] Pocket Mindmap　(とJUDE/Think!)

MindManagerというマインドマップツールを出している会社から、

W-ZERO3[es]で利用できるマインドマップツール

Pocket MindMapが発売されていた。

価格は　\6,800-　也

高い・・・

モバイル端末用ソフトウェアにその金額は投資できないという感覚は、

一般的な感覚だと思う。。。

欲しいけど、高くて手がでないので値下げして頂きたい。。。。

JUDEの要望にも出してみたが、

JUDE/Think!のWM5対応版を低価格で提供して頂けたらすぐに購入してしまいます。

チェンジビジョンの方々、

よろしくお願いします_(。_。)_

Permalink | コメント(6) | トラックバック(0) | 18:00

■[購入]アジャイルソフトウェアマネジメント

　

　分厚いので各章ごとに書評を書いていこうかと。

Permalink | コメント(0) | トラックバック(0) | 02:33

■[購入]アジャイルモデリング―XPと統一プロセスを補完するプラクティス

　設計・開発してた頃に、同僚に借りて読んだ記憶が。

　内容に記憶が無かったので購入。

　これも分厚いので読みつつ書評かな。

Permalink | コメント(0) | トラックバック(0) | 02:33

■[ウィッシュリスト]業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題

　データモデリングを１から勉強したいなぁと。

Permalink | コメント(0) | トラックバック(0) | 02:45

■[ウィッシュリスト]間違いだらけのシステム開発

　買わなくても良さそうだが、一応クリップ。

Permalink | コメント(0) | トラックバック(0) | 02:45

■[ToDo][lifehacks]　Try tools

bluewind

GTD Style Wiki

紙

あとで読む

Permalink | コメント(0) | トラックバック(0) | 18:55

■[Agile][Consulting]アジャイルな

アジャイルシステム開発に関しての潮流が

いつの間にやら大きなものになっているのに気付いた。

2003年後半の約半年間はeXtreme Programmingでの開発を経験したが、

その後は大規模な開発プロジェクトに約2年間携わっていた為、

アジャイルな情報にはまったく疎くなっていたのだ。

SE2〜3年目の時にアーキテクトな先輩や、

プログラミング好きな先輩達がXPやSCRUMを勉強していて、

それに影響されて自分も興味を持ち始めたのが、

アジャイル開発に携わるきっかけでもある。

その頃から、アジャイルを担いで(表現が悪いですが)いた方達が、

いまも頑張っておられるからこそ、徐々にではあるがアジャイル開発の

知名度や影響度が上がってきているのだと感じる。

私自身もその有効性というか、可能性について非常に実感している。

しかし、プログラマオリエンテッドで若干プログラマのエゴと

捉えられがちな面や、少し宗教ちっくな・原理主義的な雰囲気が

肌に合わないと思っていたし、ユーザーに対しての訴求の低さに

繋がっていたと思っている。

当時から思い続けていることだが、

上流工程と呼ばれる業務分析・要件定義のフェーズから

　アジャイルに、

　シームレスに、

　誰でも同じコトバで

といった思想がないと、システム化で最重要な変換ポイントである

　「業務モデル」→「システムモデル」

の変換でコミュニケーションロスが発生してしまうだろう。

SIerのビジネスモデルは人月ビジネスであり、

難しいものを難しく捉え、そこに段階を作り、

それぞれの段階で特有のコトバを使うことで、

各段階の担当を別けて人を多くつぎ込んで、

様々なコミュニケーションロスをコストに織り交ぜ、

"次の段階の人の為"の設計書をコストに織り交ぜ、

・・・・・etc

こういった無駄を省き、

顧客の要求スピードに見合うパフォーマンスを出し、

永久なβ版であるシステムをイテレーティブに構築し、

顧客の利益を生み出していく為には、

今までのSIer、コンサルがやっているような上流工程でなく、

アジャイルな開発につなげる

　Agile Consulting

　Agile Analysis

　Agile Modeling

がより重要になってくるのではないだろうか。

そして開発までを含めたアジャイルマネジメントと、

その為のプロジェクトファシリテーションがキーになってくると考えている。

コンサルティング会社に入ってわかったことだが、

コンサルでシステムに携わっているような人たちは

大規模なシステム構築しかやっていないような人が多く、

アジャイルなシステム開発にそもそも好感を抱いていなかったりする。

コンサルティング会社に入った一番の理由は、

　システム開発領域に留まらずにコンサルティングをしていきたい

という思いからだが、やはり、当初は下積みとしてシステム開発に

関わる仕事に多く携わっていくことになる。

だからこそ、前職の経験から抱いた問題意識と、

アジャイルの可能性を見つめて、

新しいアジャイルコンサルティングを極めてみたいと考えている。

#別に誰かに読んでもらって評価してもらいたいわけでもないので

#まずは発散だけするエントリ。

#読みにくい文章はご容赦ください。。。

・アジャイルコンサルティング

　ーアジャイル分析

　ーアジャイル設計

・アジャイルシステム開発

・アジャイルマネージメント

　ーファシリテーション

これらの要素の抜け漏れ、関連性、位置付け、

そして既存のITコンサルティングとの違いを明確にして

どれだけメリットがあるのか、

適用できる範囲(業務、契約、規模、期間、スキル)を定義していきたい。

　　　　

Permalink | コメント(0) | トラックバック(0) | 01:41

■[Frameworker]Frameworker1.0からFrameworker2.0へ

Exciteブログで"I'm Frameworker"というブログを書いていましたが、

忙しさとやる気の無さと、そしてOutputするものが無いという

ひどい状況の為、更新が滞っていました。

　Frameworker1.0(SE)　⇒　Frameworker2.0(Consultant)

というキャリアチェンジを行い、

気持ちを新たにブログを書いていこうと思います。

#はてなが大分こなれてきたなぁ・・ということでExciteから移行しました。

#Frameworkerというアカウントはいろんなとこで確保してあったりｗ

#テクノラティプロフィール

Permalink | コメント(0) | トラックバック(0) | 10:32

■[過去]カテゴリ

Exciteブログの方でUPしていたEntryの中で、

(比較的)まともで読めるものだけ[過去]カテゴリとしてUPしておきます。

Permalink | コメント(0) | トラックバック(0) | 10:32

■[過去]なぜFrameworker？(2004-02-03 13:08)

これをつかった仕事をしているからです。

主な仕事は、「システムコンサルタント」と呼ばれる仕事だったり「システムエンジニア」と呼ばれる仕事だったり、「プログラマー」、「テスター」などなど・・・。

そんな私の日々考えていること（主に仕事関係・・なはず）をアップしていこうかなと思ってます。

Permalink | コメント(0) | トラックバック(0) | 10:42

■[過去]リッチクライアントで紆余曲折(2004-02-03 13:19)

いま業務の中で、リッチクライアントアーキテクチャの選定に迫られてます。

というのも、お客さんからのRFP(Request For Proposal)の中にはJavaでWebシステムと書いてあったのに、ふたを開けてみるとユーザビリティの高いアプリケーションが良いなんていい始めて、んでいくつかのアーキテクチャを候補に上げて提案しています。

もちろん、Frameworker的には.NETでのアプリケーション構築を提案してます。

そんな状況の中で考えていたのが、「使って何ぼ」ってことでした。

どんなに立派なモデルを描いても、使われなければただの無駄遣いで終わっちゃいますもんね。

#過去使われないシステムを二度ほど作ったことがありますが・・

Permalink | コメント(0) | トラックバック(0) | 10:42

■[過去]ゆとり(2004-02-08 23:50)

こないだデブサミに行ってきました。

お目当てはもちろんDeMarco ｎight！！

翔泳社のブースで本沢山売ってて、デマルコ関係買うと、シリーズ本用のしおりがおまけでついてくるので「熊とワルツを」を買っちゃいました！笑

さて、デマルコの講演ですが、実は講演内容の「ゆとりの法則」という書籍はまだ読んでないんです。

「構造化分析とシステム仕様」(Structured Analysis and System Specification)という書籍はシステム構築者のバイブルと呼ばれてますが、これも読んだことがありません・・・。

んでもDFD（DataFlowDiaglam）は書いてます(笑)

講演の内容はかなりはしょりますがこんな感じ↓

現在、企業はもっと早くしかも低コストで、効率よく、高い品質のソフトウェアを開発する事を求めてられている。

しかしこうした多忙さゆえに、最適化を追求し、さらなる効率化ばかりを追求して“変化すること”を厭うのは危険である。

効率を追求した企業は変化に対応する俊敏さがなくなってしまう。

「ゆとり（Slack）」こそが変化に対応しクリエイティブな製品を生産できる手段である、と。

そして「ゆとり」を生み出す方法を５つ挙げた。

・変化するために、効率を落とすことを実践する

・不要なもの(プロジェクト)を省いてプロセスを軽くし、

　俊敏な変化を身につける

・不要なものを見つけるために、プロジェクトに完全な優先順位をつける

・プロダクトを作る場合は役に立つものをつくり、役に立たないものを

　減らさなければならない。そして世界を変革するものを作るべきだ

・人的資源に投資する

この講演を聴いて思い浮かんだのがTOC（TheoryOfConstraints）、制約条件の理論でした。

ザ・ゴールが発売されて読んだ時に非常に衝撃を受けましたが、生産工場を舞台にしたものであり、自分のプロジェクトに適用できるとは思えませんでしたし、著者のエリヤフ・ゴールドラットはTOCは全ての産業に適用できると言っていますが、信じられませんでした。

クリティカルチェーンを読んで多少適用できるかも！？（←プロジェクトバッファとか・・）なんて思いましたが、改良の余地は沢山ありそうで、実際には適用してないし。。。

そんな時にデマルコの講演をきいて、SIerでのTOCはこれだっ！！

なんて思った次第です。

XP（eXtreme Programming）はちょっと違う側面（開発者の気持ち?）から入ってる感じの方法論だし、すこししっくりこないなぁと言う感じでしたが（というか、実践した時のメンバーが最悪だったとも言うが　笑）、デマルコがいう「ゆとり」をぜひとも実践したいと思う今日この頃です。

#そのまえに「ゆとりの法則」読まなくちゃ(笑)

「トム・デマルコ」

ニューヨークとロンドンを拠点に置くコンサルタント会社、The Atlantic Systems Guildの会長。1979年以来、生産性管理、プロジェクト管理、企業文化などに関する講演や執筆、コンサルティングを国際的に行っている。1986年に、情報科学における優れた業績によって、J.D.Warner賞を受賞。著書に「ピープルウェア」「ゆとりの法則」「構造化分析とシステム仕様」（いずれも日経BP社刊）など多数。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]アーキテクチャとは何ぞや(2004-02-09 10:08)

要件定義の中で「アーキテクチャ記述書」を書くことになっているが、そもそも”アーキテクチャ”ってなにもの？

ということで、調べてみました。

architecture

新英和中辞典 第６版

1 建築術，建築学.

2 建築様式.

3 [集合的に] 建物.

4 構造，構成 〔of〕.

Insider's Computer Dictionary （ICD）

「architecture」は「構造、構成」という意味。コンピュータ関連では、ハードウェア・システムやOS、ネットワーク・システムの構造や構成などを指してアーキテクチャと呼ぶ。具体的には、コンピュータ・アーキテクチャ、OSアーキテクチャ、ネットワーク・アーキテクチャなどというふうに用いられる。このアーキテクチャを決定する人（設計者）を、「アーキテクト」と呼ぶ。

スリーアミーゴの一人 Grady Booch 氏

（Booch法:オブジェクト指向分析と設計）

"Architecture is the set of significant design decisions that cover the structural components and their behavior, their organization and their style."

→アーキテクチャとは一連の重要な設計判断であり、コンポーネントの構造と、それらの振る舞い、組織、様式をカバーするものである。

(オブジェクトの広場から)

ってーことで、システムの構造や構成全般を指すんですね♪

H/W、N/W関係にからきし弱いので、きっとアーキテクトにはなれないです。。。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]使われないシステムはただの箱(2004-02-09 12:43)

使われないシステムは“ただの箱”

前にも書いたけど、まさにその通り。

このリンクではユーザー教育が重要といってるけど、それ以上に画面のプロトタイピングとか、画面設計が重要かと思われ。

ってか現実的に、そこまでユーザー教育にコストを掛けさせてくれることなんてあんまりないし・・・。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]キャリア再考(2004-02-10 10:17)

小学生の頃は商売人になりたかった。

高校生の頃は商社マンになりたかった。

大学生の頃は経営コンサルタントになりたかった。

どれも中途半端な願望（あこがれ）のため、すべての業界を受けた。

商社は興味の無い専門商社しか受からなかった。

小売は好きになれそうなアパレルしか受けず最終で落ちた。

コンサルは、入社してもただの頭でっかちになるだけで、あまり役立つスキルが付かないかもという思いから入らなかった。

そしてなぜか中途半端な大きさのSIerに入社した。

コンサルもやり、パッケージも売り、イベントもやって、そして受託開発もする。

入ってみたらやっぱり中途半端な会社だった。

#「なんでもできる」は「なにもできない」に等しいとはよく言ったものだ。

そんなこんなで4月で4年目になってしまう。

だらだら過ごしてきたわけではない。

逆に同期の誰よりも良い仕事をしたつもりである。

それでも自分のキャリアビジョンの希薄さが招いた弊害はとても大きかったように思う。

「弊害」がどんなものであるかはあいまいだが、充実感がなかったり、何かに没頭したり、と言うことができなかった。

今年一年は自分のキャリアビジョンを明確にしていかなければなぁとつくずく感じている。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ITアーキテクト(2004-02-10 10:28)

アーキテクチャとは何ぞや

に引き続き、アーキテクチャ関連ネタ。

ITアーキテクト宣言

@ITにITアーキテクトというカテゴリができた。

「ITアーキテクト宣言」では、私がこの業界に入社してから現場に漂う雰囲気、状況、課題がすべて書かれている気がする。

キャリア再考に関連するが、、、

おれは本当にこの業界にいていいのか・・？

と良く考える。

今やってる業務を継続した先にはアーキテクトというポジションが待っている。

ITアーキテクト宣言に書かれている事は、知らない業界の人から見ればかっこよさげな言葉が羅列されているように感じるかも知れないが、泥くさーい話ばかりである。

（泥臭いなんて書くとどこかの社長さんの講演みたいになってしまう・・・w）

羽生田さんにしても漆原さんにしてもその他の似たような会社の社長さん達は、みなバリバリの技術者あがりだ。

おれはそうなりたいのか？

アーキテクトを目指しているのか？

入社してから、「俺はPGやSEにはならない。エンジニアなんて呼ばれたくない！」

なんていってたことが懐かしい。

今はばりばりのエンジニアやないかい・・。

ん〜　やっぱり俺はアーキテクトになりたいわけじゃないんだなー　なんて。。

#それでも最近アーキテクト的な仕事が面白いと感じてみちゃうからタチが悪い(笑)

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ペーパープロトタイピング(2004-08-30 17:48)

いま参画しているプロジェクトで採用させてもらった開発手法の一つは、プロトタイピングによってアプリケーションのUIを決定する手法である。

といっても、ちゃんと勉強した上で採用したわけではなく、

あくまでも経験則によってやりましょうといったわけで・・・

ますは紙ベースでデザイン(ラフスケッチと言ってた)を起こして、

チーム内で揉んで揉んで揉んで...

んでそれをユーザーのキーマンに確認してもらう。

って事を何回か繰り返した後に、

ラフスケッチからプロトタイプ画面を起こして、

ユーザーとのヒアリング時のネタとして使ったり、最終的なUI確定に使ったりしていった。

プロトタイピングでUI設計を進める手法は多くの事例があるようだが、

紙を使ってプロトタイピングを行う手法もあるらしい...

ペーパープロトタイピング

ペーパープロトタイピングで

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]4拠点でのシステム開発...(2004-09-02 15:53)

いま請け負っているシステム構築案件は、

客先で要件定義〜外部設計

自社(東京)、自社(地方)、パートナー(地方&中国)で内部設計〜ITa

の4拠点(実質5拠点)での体制をとっている。

システム構築はコミュニケーションが命。

拠点が離れている＝コミュニケーションロス

となるのは言うまでもない。

なぜこんな体制を計画したかというと、

・顧客からのRFPにオフショア開発によるコスト削減

という要望が明記されていたからだ。

しかし、要件が複雑でかつ要件が決まらない(お決まりパターン)為、

客先から程近い自社(東京)での開発も行う事となった。

続く...

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]4拠点でのシステム開発...（２）(2004-09-03 16:03)

弊社がオフショア開発を行える体制にあったのかというと、それは"否"である。

"コネクション"はあるものの、実際にコストの安い海外での開発実績は無く、

今回のプロジェクトがはじめて。

で、そこにはリスクが沢山あるため、その回避策として中国ショアの工数は少なめ、

地方支社で請け負う工数を多めに配分するような提案を行った。

という事で、

客先：常駐して要件定義及び外部設計

東京本社：基盤及びアプリケーションの一部を開発

地方支社：アプリケーションの一部(オンライン系機能)を開発

パートナー(地方、中国)：バッチ系アプリケーションを開発

といった分担となったのである。

ちなみに私は客先にてユーザーヒアリング、顧客との調整、外部設計、プロトタイピング、

自社とのコミュニケーションに従事していた。

体よく使われているというか、他に臨機応変に動ける人がいないというか、

いわば潤滑油的なポジションで働いてます。

(一番キツいポジションっすね)

元々外部設計以降のPMになる予定でしたが、それまでの私の役割を他の人ができないので

PMになる事はなく、そのまま潤滑油になりつづけてますｗ

こーんなシステム構築案件の現場で発生した問題点をいろいろと書いて見たいと思います...

つづく

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]右脳派左脳派どっち(2004-09-05 10:11)

私はどっち！？

診断結果：

あなたは多少右脳寄りです。

物事を論理的に捉えるよりは、直感的にとらえる方が得意のようです。腕時計もデジタル式（数字による表示）よりもアナグロ式（針による表示）の方が好みではないでしょうか？皆と食事に行った時の注文も他人の意見に同調するのではなく、率先して自分の好みを注文する方です。あなたが今後成功していくためには、右脳と左脳の両方のバランスを取るように心がけて下さい。その為には、何か問題に出会ったら情報を収集して分析をする方法で解決してみましょう。あなたにとって新しい発見があるはずです。

脳は右派(笑)かもしれんが、これに性格が加わって日々の行動につながっているのだね。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]うちの会社の強みって・・(2004-10-31 22:39)

入社以来ずっと考えてるけど(たまにね・・)、

結局のところ、わがままなお客から逃げ出さずに、

いろ〜んな要求を飲んで対応してる所なんじゃないかなと思った。

強みとはちがうな。

客との信頼関係とでもいうか。

ただ、競合他社が抱えてる顧客を奪うほどの競争力はないし、

一見の客が飛び込んでくるほどの知名度もない。

そして、規模はそれ程でかくないから、

大型案件でのリスクを取れる器もない。

(まぁやりかたにはよるけど)

で、こんな記事を見た。

システム・インテグレーション事業における対デフレ戦略

SI企業の興亡 --　トータルソリューションの終焉

>不用意な拡大政策は決して成功には結びつかない。

>また、この拡大の過程は、各社の特徴を薄める過程でもあった。

>結果、中途半端に何でも出来るが、あまり特徴のないSIベンダー群が誕生した。

>しかし競争の激化した今、「なんでも出来ます」は顧客に響かない。

>顧客に「おたくは何が強いんだ？」と問われたとき、「昔は...」と余計な接頭語を

>付けたくなる人も多いのではないか。　

まさにうちだね。

キャリア再考でも書いたけど、

「なんでもできる」は「なにもできない」に等しいとはよく言ったものだｗ

江島さんの言う選択肢を考えてみると、

1. M&Aにより規模の拡大を目指す

2. 得意分野のキーワードでマーケティングを行う

3. プロダクト開発に投資する

うちの会社がこの選択肢の中から選ぶとすれば、

２の得意分野(かつそれが成長分野じゃないとね)を絞ったのちに、

その分野で相互補完できる企業とアライアンスもしくはM&Aを行って、

その分野に向けてリソースを集中し、競合他社に対して規模で上回っていく

ことが最良の選択肢であるきがする。

(深く考察したわけではないけど...)

幸い、うちのTOPはアライアンスとかM&Aが好きそうなのでｗ

あとは選択と集中をする度量と成長分野を見極められるかどうかだな。

いずれにしろ、

>「いずれのアクションも起こさない」企業にとってSI事業は「斜陽産業」になると指摘する。

>その通りだと思う。もう１つ加えるとすれば、中途半端に３つの選択肢をそれぞれ

>実行する企業にとってもSI事業は「斜陽産業」になるということだ。

>トータルソリューションの時代は終わりである。戦略とは選択をすることなのだ。

というのは、入社以来つねに思いつづけている事である。

今後は自分が主役となって選択していきたい。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]仕事って(2004-11-07 03:52)

サービスだと思ってます。

仕事って何かの成果を生み出すものですよね。

その成果を受け取る（もらう、享受する、利用する）人がいて

初めて成立するものですよね。

その前提が違う人が沢山いる気がするんです。

仕事って自己満じゃないっすよ。

誰かに自分が評価されるために仕事するわけじゃないけど、

成果に対して評価してもらうわけです。

ソフトウェア業界の人って特にこの前提が違う人が多すぎです。

モノつくってりゃいいわけじゃないと思うんです。

顧客あっての仕事な訳です。

技術者はわがままだから・・

とか

プログラマはモノ作るのが仕事

だとか、、、

なんかおかしくないですかね？

お客さんに満足してもらって初めて報奨があると思うんです。

最近はやりのプログラマオリエンテッドな考え方は共感できる事や

参考にしたいことは沢山あるけど、決定的になじめないのは

こういった視点が欠如してるように感じるからなんです。

（不勉強なだけなのかもしれません。。。）

仕事に対する哲学？は人それぞれといってしまえばそれまでですけど、

仕事はマスターベーションじゃないんだと強く思う今日この頃です。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ソフトウェアビジネスの世界にいるんだ(2004-11-13 16:48)

自分はソフトウェアビジネス(自分の定義：システム作って稼ぐ業界ｗ)にいる。

当然、そこはビジネスの世界であるわけで、

　　他の業界と同様に競争が発生し、

　　既存のパイの取り合いをし、

　　新しい市場を探し出し、

　　新しい技術でイノベーションを起こす事を画策し、

　　生産性を高めてコストを削減し、

　　企業規模を大きく・利益率を高くする

といった努力が必要な業界な訳です。

他の業界と同じように、自分の競争相手に対して差別化をはかり、

競争優位なポジションに立つことが成長する上での基本的な戦略です。

(えっと、不勉強なので突っ込まれると痛いですｗ)

まず、この基本的なことを考えていない経営層に問題があり　＜弊社

そして、そういうビジネスの場にいるという事を認識していない

社員にも問題がある。　＜もち弊社

まぁ、大半の社員が技術者上がりな訳で、

さらにITバブルにのって上場しちゃって、

あんまりうだうだ考えなくても成長して来れたから

考えない人が多くなっちゃったのかと推測してます。。

てことで、この後のエントリは少し長くなるが、自分の頭の仲を整理する為に、

対外、対内の二つの視点で自分の会社を分析してみたい。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ソフトウェアビジネスの世界にいるんだ【対外的視点】(2004-11-13 16:57)

【対外的視点】

ソフトウェアビジネスの業界はいくつかのカテゴリに別けられる。（思いつくままに...）

　A．パッケージソフトの販売とカスタマイズ

　　　１．業界のカテゴリ

　　　２．対象業務のカテゴリ

　　　３．仕組み（ASPでの販売、カスタマイズ、）

　B．システムのスクラッチ開発

　　　１．顧客のカテゴリ（大手ベンダー、エンドユーザー、二次・三次請け）

　　　２．技術のカテゴリ(Web?C/S?リッチクライアント?ホスト系?etc)

　　　３．対象業務のカテゴリ

　C．技術者派遣

　　　１．技術のカテゴリ

　D．教育、コンサルティング

　　　１．業務コンサルティング

　　　２．システムコンサルティング

　　　３．プロセスコンサルティング

　　　４．技術教育

　E．デザイン

　　　１．Webデザイン

これだけのカテゴリがある中で、

　「じゃどの土俵で戦うわけさ？どの土俵なら幕内に昇進できるわけなのさ？」

てことを考えなければならない。

ちなみに弊社は中小企業(一時期ベンチャーだと謳っていたが)だが、

ABCDEいずれにも手を染めている。

ITバブルの頃にSIPSという言葉が流行ったが、

SIPSになれる要素は備わっているわけである。（やってるわけではない）

で、

「うちは何でもできまーす♪」

ではない、自社だけの強みを持つには、

何かに特化してリソースを集中させる事が肝要なのである。

（何でもできますだと大資本にかなうわけが無い）

自社が抱えるリソースを分析し、

どの土俵で戦えるのかを把握し、

どういう工夫をすればその土俵で三役に入れるのかを考える。

これが経営層に求められているタスクなのである。

強みがないから営業で負けるわけで、

競争で負けるから、

寝技で客を寝取って、

客と握って（上司の言葉でいうなら「客の金玉を握って・・ｗ」）

で、いけいけどんどんで開発していかざるを得なく、

（計画が無いまま厳しい条件で受注するから）

その為現場が疲弊していくのだ。

自社の技術者が疲弊しきっているのは経営層の責任であると言い換えることができる。

ん〜、新入社員の頃に叫んでいた事と同じなんだよなぁ・・・（悲）

まだ自分の中で結論が出ているわけではないので、

ここでは分析だけに留めておく事にしよう。。。（あははっ）

やっぱり、思いつくままに書くのではなく、

一度まとめないといけないな。

まぁBlogは発散する場と勝手に決め付けているので

ここでは自分の頭の中を言語化するだけで満足♪

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ソフトウェアビジネスの世界にいるんだ【対内的視点】(2004-11-13 17:31)

先日のエントリ　「仕事って」　にて触れたが、

そもそもそういったビジネスの世界にいるってことを認識しない(知らない、どうでもいいと思ってる、自分は技術者だから関係ない)人が沢山いる。(当社比ｗ)

いや、認識してるけど自分はビジネスしてるんじゃないと思っているのだろう。

別にそれを否定している訳ではないけど、

ビジネス的な観点で話をする事ができないとなると、

仕事をする上でコミュニケーションの壁ができてしまう。

コミュニケーションは基本的に同じ定義の言葉を使わなければ意味が通じない。

ビジネスの世界にいる以上、技術者はビジネスよりな観点での

話しができるようになることは重要なスキルだと思ってる。

　　っと、のっけから少し愚痴っぽい話になってしまったので方向修正。。。

技術者のモチベーションを高め、生産性を向上させる為には、

以前のエントリで述べたゆとりが必要らしい。(技術者じゃなくても当然だと思うけど・・)

さらには、技術者の心をくすぐるキーワードがアーキテクチャに

含まれているとなおさらではないだろうか。

逆に、コストの話をしたり、生産性を高めろ的な話をしたりビジネスの話をすると、

右肩下がりにモチベーションは下がっていくｗ

ソフトウェアを開発する企業である以上、

優秀な技術者を確保することは重要なタスクであり、

また技術者が離れていかないようにする為の努力は惜しんでは行けない。

会社(経営層)のベクトルと技術者のベクトルが同じ方向を向いていれば、

努力などしなくても離れていかないのかもしれない。

両者が同じ方向を向く為にはお互いにやりたい事、実現したい事を発信し、

経営層は会社の方向性を、技術者は自己実現の方向性を、

いまの環境(自社)で見出す努力をしていかなければならないのではないか。

一方的に経営層が決めた方向性では誰もついていかない。

技術者の自己満で作業されては利益は一向に出てこない。

技術者の自己実現の方法を聞き彼らに対して活躍の場を与えることがとっても重要。

さらに技術者は、技術のプロとしての自信をもち、やりたい事を経営層に発信していく事が重要。

会社ってなんだよ。会社って誰だよ。

と、言われる事がたまにある。

「それは上のほうの人」って言うのがこの場合には適切で、

何らかの判断を下して組織としての決断につながっているような人は

みんな会社なんだ。

会社に不満がある＝判断を下した人に不満がある

と同様だ。

(とっても御幣があるように聞こえるでしょう)

不満があるなら話せばいい。

自分がしたいことを伝えればいい。

そしてお互いが納得して進めばいい。

言っても理解してくれないなんてのは逃げているだけだと思う。

自分はコミュニケーションができません宣言をしているようなもの。

会社に伝えて、会社を説得する事も重要なスキルだ。

論点が定まらずに書いてきたが、

結局のところ、対内的な視点でソフトウェアビジネスの世界を考えると、

個人個人のコミュニケーションに問題が集約されるような気がしてならない。

(人によっては単なるこじつけにしか聞こえないと思う。。)

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ソフトウェアビジネスの世界にいるんだ【まとめ(簡単に)】(2004-11-13 17:50)

繰り返しになってしまうけれど、

やっぱり仕事ってサービスだと思います。

ソフトウェアビジネスもサービス業なんです。

だからお客さんがどうしたら喜ぶのかを追求しなけりゃいけないと思うのです。

お客さんが要求することを提供すれば顧客満足が得られるわけじゃなくて、

(そもそも要求することを提供する事もままならないか・・・)

お客さんの問題点を解決してあげて、成果物を納めることが顧客満足につながる訳です。

多分、うちの会社が他社との競争優位なポジションを築く為には、

顧客へのサービスを軸にした戦略をとることが第一なのだと思います。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ソフトウェアビジネスの世界にいるんだ　を読み返してみて(2004-11-14 17:38)

ん？

オレが新人の時に言ってたこと(上司に提案した事)とかわってねーぞ(汗

オレが成長していないだけか？

それとも会社が成長していないのか？ｗ

どちらにしろ、入社してから3年半、

問題が解決されないままここまで来ているという事だろう。

いま、うちの会社は若い人間(若くなくても)に権限委譲しようとしている。

(そうしない人もいるが、少しずつ変わってきている)

いまこの会社にいるのはチャンスだと感じているのはオレだけだろうか。

上場企業にいて権限を持って動く事ができるなんてそうできるわけじゃない。

もう一度自分の頭の中を整理して、準備をしなければいかんなぁ。。。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]業務システム開発は伝言ゲーム！(2004-11-21 02:35)

だからとってもストレスが溜まる。。。ｗ

〇いままでの経緯を伝えて、

　いまの現状を伝えて、

　発生した問題点を伝えて、

　で、一緒に解決する方法を検討する

〇タスクが埋もれてないか、

　簡単に解決できる問題を一人で抱えていないか、

　そういったことをひろっていく。

こういう動きができるSEが極端に少ない。

フットワークが軽い人といったほうが分かりやすいかもしれない。

業務がフクザツだから、

だからこそよりコミュニケーションを取らなければならないのに、

やって当然でしょ

とか

やってもらえると思ってた

とか

ふつーはそういうもんでしょ？

とか

コミュニケーションを取らずに勝手に満足してる人がおおい。

人に伝えるって体力がいるし、

考えが違う人を説得するってストレス溜まる。

それはよくわかる。

でも、コミュニケーションを取らないと何も解決しない。

体制やコミュニケーションフローをいくらしっかりと作ったところで、

個々人が意識して、コミュニケーションを取るようにしないと

どこかでボロがでる。

コミュニケーションツールを導入してうまく運用されてても、

どこがで埋もれる問題がでる。

オレの今の仕事は伝言ゲームで勝つことなのかもしれない。

Permalink | コメント(0) | トラックバック(0) | 10:43

■[過去]ガツンときた文章(2004-12-07 10:56)

あなたと会社の恋物語

オレはどっちのコンテキストで読んだのだろうかｗ

どっちのコンテキストで"ガツン"ときたのだろうか。

仕事であるとかプライベートであるとか

そんな線引きしたくないと思っていたけれど、

いつの間にか線引きしている自分がいたりします。

仕事の延長線上にプライベートがあり、

プライベートの延長線上に仕事がある。

いまは偏りすぎた配分で生活しているけれど、

それはそう長くは続かないっす。

頭が持たないからね。

　　　どんな相手と付き合っていくにせよ、理解しあう努力なくしては続かない。

　　　自分が変わる覚悟なくしては求めるものは得られない。

最近、少しずつ変わっている自分に気が付いた。

自分を押し付けて、相手に無理なことを求めていたのは分かってたけど、

少しずつ理解できるようになってきた。

人間系が成長してきたのかなｗ

システムを生業にしてても結局相手は人間ですからね。

こういう話をしてると"サービス"という言葉に行き着いてしまいがちなのが

最近のオレですが、上の言葉はいまのオレにとってはとても重みのある言葉です。

Permalink | コメント(0) | トラックバック(0) | 10:43