【ノンテク】 最近の活動

ブログを更新することが、なんだかんだ言ってできていませんでしたが、チャント生きてますよ… ロバートです。   本日7月1日からマイクロソフトでは新しい年度に入りますが、相変わらず Premier Field Engineer (PFE) として活動しています。 ですが、タイトルにある通り、今回の (久しぶりの) エントリーは「ノンテク」。即ち、技術的なお話ではありません。(;゚Д゚) ぇ… PFE でありながら、決して技術的なことばかりではない… エンジニアと言う肩書を持っているのに? YES 相変わらずアメリカ、マレーシア、シンガポール、フィリピン、イギリスなどを行き来していますが、ここ1-2年はお客様訪問などの為ではなく、「プロフェッショナル スキル」と呼んでいるソフトスキル・プレゼンテーションスキル・コミュニケーションスキルなどの社内トレーナーとして主に活動しています。   <念のため>  勿論、お客様訪問も継続しています。System Center 案件、Windows クライアント案件、Windows Embedded 案件、Surface 関連の案件、仮想化案件… などなど、相変わらずやってますよ! <いや、ホントに>    では、何故この「プロフェッショナル スキル」の社内トレーナーをやっているか?   トレーニングの対象は、主に僕と同じ役職の Premier Field Engineer なのですが…僕らの仕事の一部はお客様・パートナー様に、技術トレーニングを提供することです。 当然ながら、マイクロソフトのエンジニアとして技術的に高いコンテンツを提供することが大事なのですが、「コンテンツの内容が良い」と「教えるのが上手い」は決してイコールではないんですよね。何かを他人に「教える」と言う行為には色んなチャレンジがあると考えていた中、せっかくの良いコンテンツを、どのように教えることでお客様の「学び」に繋がるかをずっと考えていました。そのような話を世界中の仲間たちとしていると、似たような考えを皆持っているのだと知った訳です。 エンジニアの「教え方」が決して下手な訳ではないことは理解している中、どのようにすればより良い学びを提供できるのか…そのような話が続く中で、コアなカリキュラムとして技術的なトレーニングと、デリバリー スキルのトレーニングは別々にするのが良いと判断し、今の僕の役割としてはデリバリー スキルのトレーニングの講師をしている訳です。   「教える」ことを教えるのって… とてつもなく疲れることであり、非常にチャレンジングです。でも、今は現場にてお客様に技術的なコンテンツを伝授しているエンジニアのスキルアップに貢献し、結果的に現場の皆さんに貢献することができればと言う思いだけに、この活動を続けています。   社外向けには実施しないの? なんて聞かれることもありますが、そこにたどり着くまでは、まだまだ時間がかかるかも知れません。学生さん達を対象に一部のコンテンツを利用して1-2時間の講師をしたことはありますが、そもそも日本のオーディエンスに合った内容に出来上がっているかは、未だ自分の中で分かっていないんです。 英語圏では通用していますが、アジア諸国でもチャレンジや抱える悩みは、色々と違います。日本は日本で、結構チャレンジングです。   今後も幅広く、色んな場面で皆さんと一緒にお仕事できればと思います。 次回の更新は、もう少し早くできるように頑張りますね~‼… Read more

今更、新年おめでとうございます??… そして、ご無沙汰しています

気が付けば最後のエントリーから5ヶ月が経過。2012年になってしまいました。それだけ (きっと) 忙しいんです、僕 (言い訳) … さて、色々とお約束しているネタがあるはずなのですが、時が過ぎると旬なものも旬ではなくなり… 今更書いても良いのかな?? なんて思うこの頃。それに、色んなネタを載せ過ぎると、今度は自分の仕事がなくなってしまうと言う事実も (笑)なんて言いながら、サポートやサービスがいらないくらいユーザー様・お客様に情報が行渡っている状況が本来の理想なんですけどね (多分) では、2012年一発目は何を書こうか…? と考えてみました。 2012 と言えば、System Center 製品群が 2012 ラベルを持ってリリースされる予定の年です。実は、現在も System Center 2012 Configuration Manager のワークショップを開発中だったりします♪今回は、グローバルで提供するワークショップの資料やラボを世界中の PFE と一緒に開発している訳でして、ここ数ヶ月はよりグローバルな活動をさせてもらっています。 正直なところ、別に僕がそんなに優れたエンジニアだからと言う訳ではなく… 察しはつくと思いますが、アメリカ人として英語で仕事するほうが楽だから… なんだと思います (笑)ぶっちゃけ、僕が日本で仕事する中での唯一の取り柄みたいなものですからね… はい。もっとエンジニアとしても頑張ります。   と言うことで、System Center 2012 Configuration Manager… そう、細かなことですが、製品名としては “System Center 2012” が頭につき、個々の製品名はその後にくるようになっています。なので… System Center 2012 Configuartion Manager System Center 2012 Operations Manager System Center 2012… Read more

名古屋、大阪、岐阜と出張してきました: Travel Report

今日は色んなメンバーが僕の地元の一つ (いくつあるんだっ?!) のロスアンゼルスに向かっている中、先週の僕は日本国内を巡っていました。 もちろん、お仕事です。この時期、プライベートで旅行なんてしませんよ・・・ したいけど・・・ しませんよ・・・ うぅ~~   さて、この度は、プロダクト マネージャらしからぬ勢いで、中部・関西の弾丸ツアーな感じでした。 基本、新幹線・電車の中でだけ寝て、以外の時間は仕事・ミーティング・打ち合わせ・お食事会など。 結構体力的にはきました。東京に戻ってからの話ですが。 名古屋・大阪では、特定のお客様先にてお勉強会や製品説明などをさせていただきました。 これまで、東京都内でしかやってきていないことなのですが、社内での声がけをした結果、当たり前のように全国各地で .NET Framework の話、Azure の話、Visual Studio の話、Windows 7 の話などを聞きたいと言う方々がいたので、僕なんかで良いのかと思いつつも、幅広くお話をさせていただきました。 時事ネタとして、名古屋から大阪に到着した水曜日の夜は、駅から近くのカフェでパートナー様とザックリとミーティングをして、ホテルに向かうため改めて駅に戻ったのですが、やたらとテレビ カメラがあったので何事かと思いつつも、翌日の仕事があるのでホテルに。タクシーの運転手さんと、「誰か有名人でも来るんですかねー?」なんて話をしていたのですが、ニュースをかけてビックリ! 市橋容疑者が捕まったのね・・・と。 その午前中は北朝鮮と韓国の間で戦争が始まるんじゃないかと言うような感じもあり、僕がどこかに移動するとろくなことが起きねぇな・・・なんて思っていた矢先でした。 チョットばかりビックリでした。 さて、名古屋・大阪でのお仕事を終えて、次は岐阜。   岐阜県に関しては、NPO の方たちの活動として実施されているアジャイル開発のプロジェクトのヒアリング・インタビューをさせていただきました。 なかなか (本当の意味での) 成功例といったお話は聞けないのですが、人材も成長していく開発プロジェクトと言うものに今回出会い、プロセス改善、ソフトウェアの品質向上、効率的な開発、柔軟なプロジェクト チームと言うものはやればできるのだと言うことを現場の方たちの声を聞きながらも、肌で感じてきました。 よく、「言うのは簡単だけど・・・」などと言われますし、「前例がないのでは・・・」などとも言われます。 正直な気持ちとしては「やってみなきゃ分からないじゃないですか」なのですが、勿論、組織の中で何かをするにあたって (特に今の時代)、実行することに対しての責任を誰を取るのか・・・と言ったところで、話が前に進まなくなるのは事実あると思います。 分かるんです。分かるんですけど・・・考えているだけであったり、構想しているだけで、アクションを取らなければ変えれるものも変わらない。でしょ? 多分、今の開発現場に必要なのは、その一歩を踏み出す勇気であったり、キッカケなんだと思います。 なので、今回はそのキッカケを見つけてきました。   追々、Power to the Pro の特集ページでも、今回のインタビューについてはご紹介することになると思いますが、本当にいい話を聞けましたし、色んな可能性を感じれました。 日本はまだまだ元気です! そして、その元気の源は、意外にも地方にありました。 そもそも、東京を中心に物事を考えなきゃいけないと言うのが違うのかも知れませんね。 いや、違うと言うより、東京だけに答えがあると言う訳ではないと言う事実かも知れません。 ある種の Proof of Concept… Read more

Chief Technical/Technology Officer や Chief Information Officer の役割とは?

現在、父親がアメリカから一時帰国中 (両親は日本人ですから) で、やたらと「結婚」のキーワードを連発されて精神的に追いやられています、ロバートです (涙)今月いっぱい僕の小さな部屋に居るつもりな父なのですが、イコール僕はどんどんヤツレて行くのだろうと想定されます…20代の生活も、残すこと3ヶ月となりましたっ!! 改めてそう言うと、中には「この若造はいつも偉そうなことばかりぬかしやがって」と思う方もいるかと思います。キャリアだけは無駄に長いんですけど、結局日本での業務経験は MS の社員としてだけの4年弱なので、本当に日本のビジネスにおいて分からない (理解しきれない) ことは沢山あるんだと思います。   と、久しく、やや長めの前置きをしたところで、本題です (笑)   CTO や CIO の役割とは何ぞや?そして、僕がこれまで見てきた日本の CTO や CIO (と言っても、余りお会いする機会はないのですけどね…) が、僕がある意味「期待」している像と異なるかについて今日は書きたいと思います。 『そもそも CTO と CIO ってどんな役職?』と思いません?とは言っても、僕は過去に会社をいくつか設立したりベンチャー企業に乗り込んで行った時に、両方の役職を持って仕事をしていたので、それなりに理解している…つ・も・り。です。正直、微妙なラインではあると思いますし、線引きがブレることは少なからずあると思います。何故なら… :CIO = 企業の IT のトップ。CEO や COO 直下が多いですかね?技術をベースに展開するビジネスの方法論を考えたり、IT への投資を決める場合もあると思いますし、ワークフローを決めたり、プロセスを決める…CTO = 企業の技術のトップ。CEO や COO 直下で、CIO の上にいることも、CIO の下にいることもありますね。一昔前の R&D のトップに近いのではないですかね。CIO との線引き、難しいと思います。 どっちが偉いとか、どっちが責任を持つとか言う問題ではないと思いますが、CIO がいて CTO がいない組織と言うのは割とありませんか?CTO は比較的新しい概念ですよね。 僕の最近の識別の仕方としては、CIO は社内が技術をどう利用して運営されるかを考えて、CTO は技術をどのようにお客様に売り込むか考える…のように、外向きか内向きかで見るように (勝手に)… Read more

日本と米国の差: TechEd 登録者

2009年もとうとう半分終わってしまいましたね。僕、ロバートも、これで日本滞在が3年半になりました。長いようで、そうでもないですね… 最近は TechEd への皆さんの参加について色々と書かせていただいていますが、やはり「行きたいけど、そこまでの予算が…」と言うのは良く聞きます。そこで、タイトルの「日本と米国の差」なんですが…   日本の TechEd を含めた有償イベントの参加者と言う方たちは、お勤め先の予算で来られる方が殆どだと思います。でもご存知ですか?僕の母国では、結構な人数が個人出費で参加されると言うことを。驚かれる方も少なくないと思います。正直、参加費用が安い訳でもないので、「よくそこまでやるな」と思うかも知れません。 ですが、決定的な差と言うのは、個人出費で来るか否かと言うことではなく、各国での技術者の評価にあるんだと最近は強く思っています。技術力があって、最新のテクノロジを活用したアプリケーションが作れたり、最新のツールを活用した運用を実装できると言うのはアメリカでは高く評価され、勿論それは個人の昇格・昇給につながります。何故なら、アメリカをはじめとした多くの国々では、Information Technology がビジネスの一部として「必要」なだけでなく、IT を利用したビジネスの拡張と言うことが、多くの業界で可能であると認識しているからです。正直、同じような考え方をされている日本の企業様は、まだ比較的少ないように感じます。 そのような企業がないと言っているのではなく、あくまで比率としては、まだ少ないと言うことです。アジアの他国の方が、実はその辺に関しては力を入れています。だからと言って、その国々が日本より技術的に優れていると言う訳では、当然ありません。ただ、長期的な可能性はそう言うところの方があるんじゃないかとも思うことがあります。   なんで日本では技術者がもっと評価されないんだろう?アメリカでは、大学卒業後に就きたい職種で最もポピュラーなのがエンジニアです。日本はまったく違いますよね? これは、文化・カルチャーだったりするんでしょうね。仕方ないんだろうとは思いますが、もっと技術を活かしたビジネスの展開方法と言うのがあるんじゃないかと思いますし、それを実現していく技術者をもっと評価し、そのようなビジネスを支える技術者も評価されるべきなんじゃないでしょうか?勿論、その分、ネガティブな評価も厳しくされるべき立場だとは思っています。   ただ、日本のもう一つの文化として、基本的にクビにならないと言うのも、大きく影響しているんでしょうね。更には、「出る釘は打たれる」と言うメンタリティにも強く影響されるんだろうな…と思います。 なんだか、やっぱり面白いです。色んな方たちと、色んなディスカッションをする度に、疑問が増え…それらについて説明いただく機会も多くあるんですが、「変化の少ない国」と言うのが最近の僕の中の「日本」です。表面的な、所謂「ポピュラー カルチャー」はどこにも負けないくらい激しく変動しますが、根本的な考え方や物事のやり方は、変わり難いんですね。 それが「伝統」なら素晴らしいと思うんですが、逆にそのようなものは現代では、世界中で失われつつありますからね…どうにか上手くバランスが取れたら良いと思いますよね。   と、いつも以上に飛躍しまくったネタになってしまいましたが…こんなことも含めて、皆さんとお話しして行きたいですね! 「もっと日本を知れ」と思われる方も少なからずいらっしゃると思います。決して勉強をしていない訳ではありません。根本的に、僕の中で消化しきれないことが多くあるだけなんです。否定している訳でも決してないので、それだけは理解して下さい。 基本は「うぅーん、面白い!」と「へぇー・・・なんで?」な感覚で物事を捉えているんで。   技術力アップ=従業員 (技術者) としてのバリューアップ=給料・立場アップ   こうだったら、もっと技術者が頑張れると思うんですけどね?いったい、何が違うんでしょうね?   いやー。面白い。… Read more

祝 100 Post 越え

よくよく見てみたら100回以上の搭載をしていました、ロバートです。 1年弱で100回と言うことで、ペースとしては月に10回前後と言ったところですかね? 先月は、殆ど書いていませんが… 100回目が VSTS2010 英語版β1の一般公開紹介でした… なんだか呆気ないですね。   今月は、もう少し頑張って色々と書いていこうと思っています。 また、逆に色んな疑問などを書くことになるかも知れませんが… (汗)   そう言えば、先日 Tech Ed の話を雑談レベルで話していた時、「Tech Ed のレベル (100、200、300、400) が良く分からない方もいるんじゃない? と言う話題になったのですが、念のために説明すると、これは大学のクラス分けをそのまま応用している数字です。 日本の大学のシステムが良く分からないのですが、恐らく分け方が違うんだと思います。   アメリカの大学は一般的に、General Education のコースを 100 レベルと 200 レベルに分けます。 もっと簡単に言うと、大学1年生=100レベル、大学2年生=200レベル、大学3年生=300レベル、大学4年生=400レベルと言う感じになります。 100 レベルは、一般教養のクラスと言うことで、ある意味「当たり前」のことを学ぶクラスです。 例えば、ベース ラインの数学のクラスだったり、English のクラスだったり、後はどの教科においても「Introduction」とつくようなクラスが基本的に100レベルのクラスになります。 200 レベルも、同じように「Introduction」系ではありますが、もう少し科目を絞った感じの物が多くなります。一般的と言うより、多少サブジェクトを精査した感じのところですね。 300 レベル、400 レベルとなると、自分の専門学科の通称「Upper Level」のクラスを指します。 僕の場合は専門が国際政治+国際法律だったので、European Union のクラスだとか、Human Rights (人権)法律のクラスが、このレベルのところに入りました。   Tech Ed のレベル分けも、基本的にはこれに沿っていると考えていただければと思います。 100~200レベルは、所謂「概要」になるのはこれが理由ですね。 300~400レベルは、もっと突っ込んだ内容だったり、細かい部分に特化した話になる感じです。 500レベルが Deep… Read more

Team Foundation Server を利用してアジャイルな開発を (Part II)

本日は前回のエントリーの続き、ツールの使い道について。 その前に、いつもの前説を… (懲りないロバートです) 先日の凹みはF1観戦ができなかったとか、大学バスケのトーナメント観戦できなかったと言った、大した凹みではありませんでしたが・・・ 今日は… もう… 朝から火傷。早めに出社したのにテレカンのブリッジがいきなり変わっていたので、戸惑いながらテレカンに10分遅れて参加… マシンの調子は不調中の不調。仕事が何一つ手に付かず、一日中デスクでPCに向かって発狂していました。   そんなコケてばかりの一日… よくよく見ると3月も今日で終わり。2009年、早くも4分の1が経過してしまいましたよっ!!   不貞腐れて早めに帰宅し、家のPC (Vista x64 の DELL Inspiron 1720) でお仕事をしています。 でも、よく考えると、日曜日にアップしたポストの続きがまだだった!!   と言うことで、続き (前説長いんです)     アジャイルな開発を実現するために、ツールは必要だと言う話の中で、マイクロソフトの Visual Studio Team System の機能を利用して実現することも可能だと言うところに至ったかと思います。 そして、前回はその VSTS がアプリケーション ライフサイクル管理 (ALM) のコンセプトをベースに作られたこと; ALM の中ではビジネス、開発、運用と言った3つの大きな歯車に注目して、かつ各歯車 (ステークホルダー) によってビジネス バリューと言うものを確認し、要求し、開発し、最終的にはそのバリューを見出すものをデリバリーすると言うことをお伝えしました。VSTS はこれらステークホルダーのコミュニケーション ギャップを退けるために…または、そのコミュニケーションを支援するためにあるものでもあると説明しました。 アジャイルな開発を実施するにあたっても、Agile Manifesto にある通り、ビジネス側の人間と開発側の人間は日々一緒に仕事をする必要があると言った、ごく当たり前のことを実施していかないことには、開発プロジェクトのバリュー (価値) と言うものをきちんと見出すことができないと言うことも…   VSTS には「クライアント」と「サーバー」のコンポーネントがあります。 VSTS に何かしらかかわったことのある方は、クライアント側に… Read more

Team Foundation Server を利用してアジャイルな開発を (Part I)

金曜日のセミナーにご来場いただきました皆様、どうもありがとうございました! いつも以上に笑いもいただけて、個人的にはとても楽しく皆さんと接することができたと思います。 そんな中、本日の F1 オーストラリア GP を見逃して、本国の大学バスケットボール大会の試合もミスって、少々落ち込み気味です (;_; ) なので、ラザニアを作ってお腹も心も落ち着きました♡   そんな余談はさておいて。金曜日に約束しました通り、アジャイルにプレゼンテーションを変えてしまったので、その内容を含めて、こちらで当日のお話の内容をシェアさせていただきます。 因みに、当日のお話のタイトルは以下: 『Team Foundation Server 2008 が支援するアジャイルな開発』   元々は、『マイクロソフト基盤におけるアジャイル開発』と言うタイトルだったのですが、気分でタイトルを変えました。 内容は・・・・・・・・・・当然、当日変わったので、タイトルに拘る必要もないかも知れませんね (笑) さて、アジェンダそのものは特に変更しませんでした。 内容を追加したと言うのが主なところです。 理由としては… 僕の前にお話をして下さった長瀬様と三井様が、「この後の MS さんのセッションで~」と、その時までサラッと触れる予定だった内容を、もう少しきちんと皆さんにお伝えする必要ができ、せっかくなのでアジャイルな話をアジャイルに紹介しようと言う試みでした。   前半は、「アジャイル」と「ツール」の位置づけとして、アジャイルな開発をするにおいてツールをどのように利用すべきかと言うことを話しました。 ただ、ツールの話をする前に、改めて「アジャイル」について。 Agile と言う単語は、開発用の用語ではありません。 普通の単語です。「素早い」とか「機敏」と言う意味です。 よく、スポーツ選手の性能を表現する時に使われる単語です。 どれだけ変化に対応できるか、応用力があるか… なので、僕の中では一番「アジャイルな開発」を説明するのは「臨機応変な開発」だと思ったのです。   考えてもみて下さい。 アジャイルな開発の話において必ず皆さんに認識いただく必要があることは、「物事は計画どおりにはいきません」と言うこと。 まして、計画どおりにしか動かない…変化に対応しないと、プロジェクトは遅れる、問題は解決できない、コストがガンガンと上がって行く。   「でも、そんな臨機応変な対応をプロジェクトにおいてやれと言われても、慣れていないことをいきなり…」   そんなことは絶対ありません。 皆さんの人生で、物事が計画どおりに行ったことって、どれだけありますか? アメリカではこんな言葉があります: “When life gives you lemons, make lemonade.” 人生において、レモンを投げられた時には、そのレモンを使ってレモネードを作れば良い。… Read more

Silverlight 2 の事例も紹介☆

ヤフー様で展開していた Silverlight を活用した Major JP のサイトが事例化されました。 Major JP は世界初で Silverlight DRM を実装したサービスでもあります。   これからも、もっともっと日本からの「世界初」を出して行きたいですね! その為には、パートナーの皆さん、ユーザーの皆さん… 皆さん次第です。世界初は絶対カッコイイっす!! 後、確実にマーケット シェアを握れるところに辿り着きます。 もっと積極的になりましょう!! Microsoft® Silverlight™ 2 を用いた世界初の DRM 対応動画配信サービス マルチ プラットフォーム化によりいっそうのユーザービリティ向上を目指す (http://www.microsoft.com/japan/showcase/yahoo.mspx)… Read more

続・ロバート的疑問

前回のエントリーでは「疑問」から、自分なりの「なるほど」を見つけてみましたが、「自由度の多い」そして「選択肢の多い」現代の開発現場や技術市場においてどんなことをしていくべきなんだろうと考えてみた時、以前ご紹介させていただきましたパフォーマンス チューニングの内容に思考が向かっていきました。 何故かって? 簡単です。 僕が説明したパフォーマンス チューニングの話では、「闇雲にチューニングを実施するのではなく、パフォーマンス目標値をきちんと設定して、そこに向かってチューニングを実施していきましょう」と言った、シンプルなメッセージだったからです。 だから、それとこれと、どう関係あるんだ?ってことですよね? テクノロジーを選択するところが一番難しいところであり、厄介なところでもあると思います。 開発ライフサイクルの、どの部分を重視して利用するテクノロジーを決めていくか…そこが肝な気がします。   開発者として、開発が一番容易にできることが望ましいですか?それとも、新しいことにチャレンジできるプロジェクトが良いですか?とにかく楽して仕事ができて、でも成果を超評価してもらえるようなものが良い…?   プロジェクト マネージャーとしては?プロジェクトが効率よくまわれば良い?レポーティングを簡単にしたい?今まで以上の仕事量が発生しなければ良い?それともコスト?コストの管理が明確であれば…?もしくは、追加コストが発生しないプロジェクトであれば良いんでしょうか?   IT プロとしてはどうでしょう?サポートがしやすいもの?運営が楽なもの?自身の作業が軽くなるもの?要は、最終的にデリバリーされる物に特化しているところを見て欲しいですか?   実ユーザーとしては?業務をより効率よくするものであれば、ぶっちゃけテクノロジーなんて気にしない?決まったテクノロジーを利用して欲しい?自身が利用している製品を使い続けることが目的?同じことをするのに、やり方を変えるのはイヤ?例えそれが仕事を楽にするとしても?   ビジネス オーナーとしてはどうですかね?従業員の効率アップですか?彼らの残業減らして、コスト管理したいですか?プラットフォームのインフラを変えずに (新しいハードウェアなんてもってのほか) 今以上の物事ができれば良いですか?   どれも考えるべきなんだと思いますし、どれも大事だと思います。要は、どこに視点をおくかで全てが決まると思います。とは言っても、最終的には、各自が「安く」だとか「楽に」と言ったところに向かっていくんだとも思います。 決して間違っているとは思いません。僕だって楽してユーザーの皆さんが「Visual Studio Team System 買う!」って言ってくれるなら、楽して「結果出ました」と言ってみたいですよ… (涙) → でも、現実はその真逆に感じてしまうから僕は悲しくなってしまったりする…かも?頑張って、製品の良さを皆さんに伝えているつもりなんですけど… どうも、僕の中にあるメリットと、皆さんがメリットと思う部分が釣り合っていないような… (汗) 本当に、たまに、「え゛~?!そこっ?!」って思います。まぁ、そんな僕のことはさておいて…   選択肢が多すぎる。自由が多すぎる。それが皆さんのテクノロジーに対しての「欲」を逆に「面倒くさい」と言う思いに変えてしまっているのであれば… まずは、パフォーマンス インディケーター (パフォーマンス目標値) から見て行けば良いじゃないですか。 今の時代では、ハードウェアでのパフォーマンス チューニングなんて、なんらスキルもいらない、バカでもできるチューニング方法ですよ。だって、僕自身、そうやって諸々のパフォーマンスを上げてきましたから (爆) 「取り敢えず RAM 増加!」が口癖でした。バカの一つ覚えって言うんですか?そんなんでした。いや、今でもそうかも… (汗) でも、アプリケーションのパフォーマンスから物事を見て行くと、結構面白いと思います。 既存のアプリケーションのパフォーマンスを上げる… ユーザーが「感覚的に」アプリケーションのパフォーマンスが上がったと思うか否かの問題だと思います。 既存のハードウェアの稼働範囲内でスイスイ動くアプリケーションを作る… ビジネス… Read more