栞/#work
勤務時間の20%を自分のプロジェクトに費やすことができて、それを汲み上げる社内の仕組みがある。
皆で同じ方向を向くと、他の人の視線を気にしなくてすむのでいいかも。
あとでもう一度くわしく調べてみる。
「一緒に仕事をしやすい、頭の良い人間を雇う」のが全ての前提だろうな。
標準化も大事だけれど、それですくい取れない部分をどう評価していくかを考えなくては。
社員数が多くなっても機動性を確保するためには、どうしたらいいだろうか。
ワークグループ的な仕事の進め方と、チーム的な仕事の進め方と。どちらも一長一短あるけど。
こういう感覚がわかる日本の企業は少ないのではないか。
コードの品質がシステムの品質に直結する、ということから目をそむけ続けてきたことの功罪。
そもそもSE／PGの区分は人月単位の単価の等級に過ぎなかったりするわな。
アーキテクチャを見る人とPMの役割分担をどうすればいいか考えてみる。
コーディング力のない人は使い物にならない。とんでもない設計とか平気でするし。（自戒含めて）
いいね。技術を継続的に磨いていけるような環境を業界が作り出していけるかどうか。
横着をしようと努力して実はただの現実逃避になっている。…たまにあります。
気をつけよう。
XPは一度やってみたいな。新人研修とかにもよさそうだ。
自動生成はいいのだけれど、完全には信頼できない。ツール自体がオープンソースならいいかな。
賢くて、結果に結びつけられること。面接をする側になるかもしれないので参考に。
別に優秀な技術者でなくても管理業務はできる。そして優秀な技術者にはきちんとした対価を支払う。
知的財産の共有化、という文化的背景。そしてそれを発信できるだけの情報スキル。両方が必要なのよね。
存在感があるのに、正しく評価されない人から会社を辞めていく。
プレゼンのちょっとした工夫集。伏字はいいよね。拍手。
PerlやPHPでは「あり」かもしれないれど、Javaでフレームワークなんてかったるくて自作してられない。
ここで開発されたフレームワーク（Strutsベース）、使ったことがあります。
Webアプリ開発にはJavaは向いてない。ただみんなが知っていて、なんとなく安心できるから使っているだけ。
全部適用できるわけではないけど、できそうなことはやってみようかな。
でも、成果を評価するプロセスを欠いた人事システムというのもありえないよね。落としどころが難しい。
フレームワークは、レベル7ぐらいの人がわかるように作るのがいい。
「エンジニアを確保し、継続的に働いてもらうため」という明確な目的意識を持っているのが強みかな。
SESもいいんだけど、社内での知の集積・蓄積が進みづらいかもしれない。