女子力高めのデザインに変えた
とりあえずPC用のデザインを女子力高めのデザインに変えてみました！
やってみたい事を書いてみようと思う
とりあえず、しばらくに書いてみたい、ちょっと自分で調べものとか動かしてみたりとかしてみたいことを書き出す。まあ、ちょっとここに書いておけば、やらないといかんなーという気になっていくと思うので。
Jenkinsを使った自動ビルド・テストとカバレッジデータの収集。これをちょっとやりたい。多分次の仕事でこれをやらないと死ぬ。テストの対象はUTできるような感じになっていないので、バッチ処理に限定。カバレッジの収集は、VisualStudioから実行すれば取れるのは知っているけど、スケジュールされた一括処理としてやって、あとからデータを抜いて集計するにはどうしたらいいのか知らない。ここは勉強しないとイカン。
Trac + Subversionでのバグ追跡、イシュー管理。やっぱね、Excel管理は上位マネジメントへの報告資料にするのに必要なんだけど、速さが必要だったり、みんなが同じ情報を共有するって事がすばやくできた方がいい。Tracはいたずらで何度か入れたことがあるんだけど、ユーザ管理がよくわからなくてそこがおかしくなっていた。この辺もなんとかしていきたい。
こーいったあたりを事前にしらべたり、実地でやったりして、日記にかけたらなーとか。
RE:どちらも両立すること（シンプルにテクノロジーを追求する事と、人々に便利で価値になるという観点を持つ事）が重要かと思っているのですが、実際どうなんでしょうか。
ちょっとはてブで気になる記事をみつけて、コメントつけたわけです。元記事↓
で、私のコメント。
@rinta100 コメントありがとうございます！また、ブログ拝見させていただきまして、とても勉強になりました。私自身、どちらも両立すること（シンプルにテクノロジーを追求する事と、人々に便利で価値になるという観点を持つ事）が重要かと思っているのですが、実際どうなんでしょうか。
どちらも両立すること（シンプルにテクノロジーを追求する事と、人々に便利で価値になるという観点を持つ事）が重要かと思っているのですが、実際どうなんでしょうか。
私は、組織がその両方を持っていればいい、と思う。
「シンプルにテクノロジーを追求する事」というのは、技術と工学の視点で技術者が自分自身の能力を高めていくという事だと思う。簡単に「作りだす力」と呼ぼうか。これは新田さんの会社のミッションだと理解している。これはもちろんそれでいい。
「人々に便利で価値になるという観点を持つ事」というのは、世の中に貢献していくのか？ という事でこれももちろん大切な事だ。これは「ビジョンを示す力」としよう。
この２つは対立する考えでもないしどちらも追い求めていくべきことだと思う。誰が？という点はちょっと置いておいて。
高いレベルで両方ができる人というのは、きっと数少ない例外で、たとえば昔のビル・ゲイツ、いまどきだとセルゲイ・ブリン、マーク・ザッカーバーグってことになるんだと思う（id:shi3zさんなんかも含まれるのかもね！）。
ここで、すごく矮小でリアルな話をすると、そんな人は例外中の例外で、世の中の多くのエンジニアと呼ばれる人たちは（私も含めて）後者の「ビジョンを示す力」は持っちゃいない。たとえば、Microsoftなんかはトップクラスのエンジニアを相当な人数抱えていると思う。でも、そこに「ビジョンを示す力」をみんな持ってるの？というと、んな事は多分ない。でも、ナデラCEOはきっとビジョンを示してくると、おじさん信じてるよ！
別に一人の人が「作りだす力」と「ビジョンを示す力」の両方を持っている必要はなくて、それぞれを持った人が出会って、いっしょに働ければそれで世界に少しの価値を提供することはできる。きっとAppleはそんな会社だったんじゃないかな。
まず、返事をもらった部分に対する、私なりの答えはこんな所。
で、エンジニアのemployabilityとか、employee satisfactionとかそーゆー所も気になるんだけども、今日はもうそろそろ眠いので明日以降の宿題にします。送信！
エンジニアリングの話と、ビジネスの話を混ぜるとよくわからなくなるよね
はてブ経由で読んであまりにも面白かったので、ちょっと日記に書く。
【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」: プログラマの思索
やっべ、はてな記法忘れかけてるｗｗ ま、それはいい。
いろんな指摘があるけど、ホントそう思う。ただ、そこはエンジニアリングという範囲での話で、下の部分で、ちょっと思うところがあって、久々の日記書きということにする。
本来はユーザ企業でも内製化したい。
自分たちの業務システムを作りこむことで、自分たちの業務をスピーディに強化できる。
自分多たちの業務システムの技術や運用ノウハウも社外に流出しない。しかし、自社で内製化しようとするとハードルが高い。
ユーザ企業が若い社員にプログラム開発をさせるが、ある程度育つと設計や運用に回り、プログラム開発しなくなる。
若い社員も、単価の高い設計や管理などに向いてしまう。
プログラム開発の楽しさが伝わらない、など。皆さんは色々話されていたけど、僕は違う意見を持っている。
おそらく、ユーザ企業に限らず、日本のIT企業はプログラミング技術を軽視している文化があるから、人が育たないのだ。
ここ、ユーザ企業で内製できない理由が、ちょっと歯切れが悪いと思った。私に言わせれば、それは経営の観点で、人件費をシステム部門の為に投下できないからだ。日本の雇用環境ってのは、一度正社員で人を採用するとそう簡単には人を切れない。福利厚生もあるし、マトモな会社なら社会保険の負担とかかなりのコストが毎月かかる。外注すればそこを考えなくていい。これは全くエンジニアリングの問題じゃない。日本における雇用の流動性の問題が根幹にあると思ってる。米国では内製が多いなんてのは、ＩＰＡの報告書なんかにも書いてあったと思うけど、それが出来るのはプロジェクトが終わったら、余剰人員はサヨナラって言って、言われたほうもじゃあ次へってさらさらと動く環境だからじゃないかな。日本ではその代わり、外の会社にその時だけの契約で（まあ、実際には保守継続してくれないと困るから付き合いは続くけど）一過性の費用計上だけで済ませる。経営者にとってはありがたい仕組みなんだよ。
その、人を抱えるリスクを負ってでも内製化する事のインセンティブがあるなら、それをやるだろうけど、一般的な企業でそこまでのものはないよね。例えば、銀行、保険会社、鉄道会社、電気事業会社、官公庁。こんなところは、内製化のインセンティブないでしょう。ネット証券やゲーム事業やってるような所で、コンピュータシステムがお金を発生させる原動力なら内製化のインセンティブは強いし、実際そーゆー所は内製多いんじゃないの？
コンピュータシステムが金を生むかどうか。それで内製か外注かがわりとハッキリと割れると思う。これはエンジニアリングじゃなくてビジネスの話。そこのところがもやもやした感じになっていると、良くないなーと思ってちょっと書いてみた。よし、送信！
...さっきの内製化インセンティブが薄いところの例示が一般的とか加筆しておいて一般的でない気がしたので、もうちょっと例えばと書いてみるか。小売りや卸業、飲食店なんかは、「一般的」と言えるんじゃないかな。食品、アパレル、事務用品とか。あと、ちょっと大ぶりな所では、機械なんか。そーゆービジネスにおいて、コンピュータシステムというのは金を生む仕組みじゃない、という事ですよと。
コンピュータシステムとか書いたけど、端的に言えば、事務の道具だからなあ。IBMの社名は、端的にそれを示している。
