  |
はてなキーワード: ベンダとは
アップルのジーニアスって、あまりジーニアスだと感じた事がない。
スペシャリストという肩書きの人も、会話中の早い段階で諦めを感じてしまう。
こちらがわからない事はわからない、というのでは、時間の無駄で、
それならあなたのフィルターが邪魔になるので直接こちらから問い合わせした方がいい、と内心思う。
結局、海外のフォーラムに書き込みして訊いてみるのが一番早いのは、
アップルの場合は、なんていうか雰囲気とドヤ顔でごまかしているようにしか見えないんだよね。
わざわざ予約して時間作って行っても、ドヤ顔の客と店員の高い意識の雰囲気は私には暑苦しい。
でも、そんなアップルストアが好きな人も多いのも理解はしている。
ちなみに、マイクロソフトは、チャットでそのまま話を聞いてくれて解決も早かった。
PowerMacで漢字トークを使って、ResEditでリソースフォークをいじりつつ、
RealBasicでプログラムを書き、HyperCardスタックを作って遊ぶ。
暇つぶしにMKLinuxをインストールしたりしてた、過去のパワーユーザにとっては、
歴代で一番好きな好きなノートパソコンは、PowerbookG3。
ジョブズが戻ってきて、人気の出たスケルトンで5色のiMacは好きでなかった。
Palmを持って、iPod第三世代にLinuxをインストールしてお茶を濁したりしてた頃、
VAIOとクリエを持っていた回りの人間は現在は皆、iPhoneとMacBookAirを持っていて、
表面に変なシールを貼っている。
最近は互換性を気にしてるようだけど新しい書き方ですとか毎回言われるストレスが半端ない
プログラミング言語みたいな土台となる技術がそんな変わって何も違和感覚えないやつらがどうかしてる
rbenvやらBundlerで完璧にベンダリングできますってそんな誇れることなの？
バージョン依存が激しいのでそうしないとバグりますって言ってるようなもんじゃねーかｗ
まだpython2,perl5で書いた方がまだ良いわ(Perlは文法が糞だから書かないけど)
多少言語に粗があっても互換性を維持してくれた方がよっぽど重要なんだけど（少なくとも俺は）
フルスタックフレームワークでなんでもできるぞ！とか言ってるけど理解できない
自分が使わない機能がたくさんコードに入ってて使わない機能に脆弱性がありましたアップデートあります
って毎回言われてどう思うの？
モックアップみたいなのをササッと作るには良いかもしんないけど、こんな異常なアップデート地獄に付き合わされて
結局Railsのマジックで作ったような気になってるだけで後に来る保守問題を先延ばしにしてるだけじゃねーの？
退職から一年が経過し、新しい職場（WEBベンチャー企業）での仕事に慣れたこと、
また、富士通の同期入社の友人から頻繁に転職の相談を受けるようになったこともあり、本エントリを執筆する。
はじめに、筆者の退職理由を簡単に述べると、富士通という会社に未来を感じなかったことと、やりたい仕事はできないだろうと判断したためである。
参考までに、筆者は公共機関向けのシステム開発部門に所属していた。
担当していた業務は様々で、小規模なシステム開発や、子会社・下請企業の管理であった。
富士通には、人材キャリアフレームワークという社員評価制度があり、現場には、入社何年目はこのレベルの仕事、といった暗黙の了解がある。
本人の能力や意欲とは全く無関係に、入社後の経過年数で、仕事の裁量の幅が大きく制限される。
このことはいわば、学習指導要領ならぬ、業務指導要領があるようなものだ。
このような枠組みや暗黙の了解が存在すること自体が問題なのではなく、その枠組から逸脱した人材を想定しない・評価しないことが問題なのである。
筆者がお世話になった優秀な先輩方は、この業務指導要領の要件を満たして手に余った人、
いわば天井にぶつかった人から先に、より大きな仕事がしたいという理由で辞めていった。
筆者もその一人である。
既存産業の大きな成長が望めなく、社員個々の多様性が重要視される昨今の経済情勢において、
高度成長期における横並び思想をもとの作られたやり方が未だに社内を謳歌しているのは時代錯誤というほかない。
富士通への提言として、これからの時代は、年齢も在籍年数も関係ない人材評価制度を作っていくべきである。
そして重要なのは、会社の既存事業でいかに利益を上げたかについての評価ウェイトを下げ、
いかに新しい発想で新しい事業を提案したか・実現したかという評価項目を設立するべきである。
なお、富士通には社内ベンチャー制度があるが、これはうまくいかない可能性が高い。
なぜなら、社内ベンチャーを承認するのは旧式の人材の典型例である高齢な経営層であるからだ。
いままで数十の社内ベンチャーの審査結果を見てきたが、彼ら経営層に事業の将来性を判断する能力はないと痛感した。
また、他の理由としては、富士通の既存事業と衝突すると社内ベンチャーが潰されるということがある。
将来性のない既存事業を残して、将来を託すべき社内ベンチャーを潰すという企業風土なのだ。
富士通という会社には多数の既得権益集団がいる。そして、社内のルールは彼らが決して不利にならないように作られている。
なぜなら、ルールを作る権限は、先頭を走る集団、1980年代に大成功を収めた既得権益層がガッチリ握っているからだ。
いわば、前を走る人を抜かしてはいけないレースのようなものだ。
このような出来レースで若手社員のモチベーションが続くはずはないことは明らかだ。
筆者は、決して年功序列主義を批判したいのではない。
既得権益層が年功序列を悪用して、部下の手柄を自分の手柄にし、部下の失敗を部下に押し付けている実態に対する批判である。
ノブレスオブリージュ、権利を有するものには義務がある、という思想がある。
富士通の既得権益集団には会社の技術力や社員を率先することで、企業としての地位を向上させていく義務がある。
実態は、社内の後進に抜かされることを恐れるあまり、後進の他社に抜かされている。
ちなみに、この既得権益集団に有利なルールが生み出した現状については、
同じく富士通OBである城繁幸氏の著書「若者はなぜ３年で辞めるのか？」（光文社新書）が詳しい。
経営学において「ヴィジョナリーカンパニー」という名著がある。
この本によると、会社が永続的に成長・発展していくためには企業理念（ビジョン）を社員ひとりひとりが持つことが必要不可欠であると指摘している。
富士通の企業理念は、変革に挑戦し続ける姿勢や、よりよいICT社会づくりに貢献することを掲げている。
しかし、富士通という会社の現状として、このヴィジョンを失っている社員、とくに管理職がとても多い。
30代を過ぎて会社に定住することを決めた社員に変革に挑戦しようという熱意ある人物はひとりもいなかった、
そういう人々にとってICTで社会づくりなどどうでもいいのだ。
ただ顧客の要求を聞いて、それを子会社や下請けに作らせて予算や利益を達成することにしか興味がない管理職が大半であった。
元GEのCEOであるジャック・ウェルチ氏は、たとえ成果を出していようと企業ビジョンを共有しないものはクビにしろと自著で語っている。
このポリシーを導入したら、富士通の管理職の80%はクビになるであろう。そのくらいに富士通の管理職は夢や熱意のない人物ばかりであった。
そのような人材が将来的に会社を破壊する、というウェルチ氏の指摘の正当性を、富士通という会社の惨状が示しているのは皮肉という他ない。
富士通への提言として、ウェルチ氏のやり方を実行すればよいのだ。
成果によって管理職のクビを決めるのではなく、ヴィジョンを共有できているかでクビを決めるのだ。
このやり方を実行すると既得権益を握って離さない経営層や管理職が一掃される。
既得権益にしがみつくだけの人物こそ、ヴィジョンを持たない人物である割合がとても多かったことを付け加えておく。
経営コンサルタントの大前研一氏は、日本の生産性がアメリカの半分しかなく、もはや発展途上国にすら負けていると指摘している。
その原因について、日本では業務標準化が全く進んでいないためであると述べている。
自分の住む自治体と異なる自治体のマイナンバーのITシステムを比較してみてほしい。
ここで、自治体が異なればITシステムも異なることに気づくはずである。
はたして自治体ごとに個別のマイナンバーシステムを作る必要があるのだろうか？
答えはもちろんノーである。全国どこでも一律の業務であるべきであり、同じITシステムを導入するべきである。
自治体ごとに業務フローが異なるために、別のITシステムを使用した時に業務がこなせないという事態が発生する。
そのため各自治体が個別にITシステムをITベンダーに発注することになる。
そこでITベンダーは各自治体ごとに個別のITシステムを作ることになる。
ITベンダー側からすると一度作ったことがあるものをカスタマイズして、業務の順番を入れ替えたり、扱うデータを多少変更するだけで済む。
それなのに膨大な金額を請求するわけだ、ITベンダーとしてはボロ儲けである。
（なお、主要ITベンダー決算書を見ていただくとわかるが、ITベンダーの利益率が高いわけではない）
特に自治体のITシステムは国民の税金で作られているわけである。
各自治体は、このような現状を放置していて、国民に申し訳ないと思わないのであろうか？
このことは、決してITベンダーにのみ責任があるわけではない。
総務省が陣頭指揮をとって各自治体の業務標準化・統一化を進めなくてはいけないのに、それが全くなされていないのは監督官庁としての責任放棄である。
このように業務標準化が全く進んでいない現状は自治体に限らず、民間企業においても同様である。
会計パッケージにおいて、世界のデファクトスタンダードになりつつあるSAP導入に失敗する事例を数多く見てきた。
失敗する理由は、個々の企業の業務に合わせてSAPをカスタマイズしており、そのカスタマイズでは対応できない業務フローが存在するからである。
問題なのは、そのような業務フローは、決して必然的な業務ではなく、過去の慣習から存在しているだけであることがとても多い。
ここにおいて、ITシステムが業務に合わせるのではなく、ITシステムに合わせて業務の方を変えていかなくてはいけないのだ。
このことは、サービス・流通業の顧客からSAPのカスタマイズで無理難題があがってくることが特に多いことと無関係ではないであろう。
富士通は、既存顧客の業務標準化およびデファクト・スタンダードとなるITシステムの開発の陣頭指揮をとる役割を果たすべきだが、その望みは期待できない。
なぜなら関係が深い企業において、業務が効率化すると大量の社内失業者を出すことになるからだ。
そのような"顧客との良い関係"を崩すようなことはやらない会社である。
日本という国のあるべき姿を長期的に考えた際に必然的なことであるにもかかわらずである。
富士通の企業理念である、よりよい社会づくりに貢献するとは、まさにこの業務標準化を推し進めることなのではないのか。
富士通には外国籍の社員が相当数在籍している。しかし、彼らに求められる日本人への"帰化圧力"がとても強い。
同期入社の中国籍の友人は、対外発表会のために完璧な日本語の発音の練習をさせられていた。
完璧な日本語の発音は日本人に任せるべきで、中国に精通しているというメリットを活かせる部署に配置転換するべきである。
なお、残った外国籍社員をみると、小学生から日本にいるなど、生まれたのが海外というだけのほぼ日本人だったりする。
外国籍社員の離職率が高いことに対して、本部長が提示した対策が、
長く働きたい会社とはどのような会社か、というテーマで外国籍社員を集めランチタイムにディスカッションさせるというものだった。
この席で「無能な人が本部長にならない会社で長く働きたい」という大喜利でもすればいいのだろうか。
富士通はグローバル企業を表明しているが、このような組織で海外進出などできるはずもない。
なぜならば富士通の利益構造では、海外において利益を上げられないからだ。
このカラクリの解説は大前研一氏が詳解されているので、参考にしていただきたい。※1
６．富士通の良いところ
ここまで富士通に対する批判と改善の提言を述べてきたが、富士通の良いところについても触れておきたい。
まず、個々の社員の仕事力や組織力といった点では、他の大企業と比較して遜色ない。ただし、富士通の主要グループ企業に限るが。
数十を超える大企業および中小企業と仕事をしたが、やはり大企業は個々の社員のレベルが高く、組織力も高い傾向にある。
顧客として他社と仕事を進めていくうえで、大企業の方が優秀な担当者に遭遇することが多く、仕事がとても進みやすかった。
この理由について、大企業の社員育成能力が高いことはもちろん、社内チェック体制が整っているからではないかと思う。
社内で質の悪いものは弾いており、社外に出さないようにしているのだろう。
また、富士通は顧客主義がきちんと徹底されている会社であると感じた。
筆者と富士通の顧客主義が異なっていた点はあるものの、顧客起点に立つという考え方は大事なことである。
柔らかい人が多く、職場の雰囲気はとても良かった。お世話になった直属の上司や先輩方は、優しく丁寧なご指導をいただいたことに感謝している。
７．おわりに
最後に、立花隆氏の著書「東大生はバカになったか」（文春文庫）から名文を引用したい。※2
「いま、この辞めたい気持ちを逃したら、この会社に骨を埋めて、あそこにいる連中と同じになってしまうと思った。」
結局、筆者の退職理由は、偉そうな顔をしているがロクなビジョンも打ち出せない富士通の上層部のような人間になりたくなかったからである。
富士通という会社に必要なのは、優秀な若手の育成などではなく、無用な老害の排除である。
筆者には、富士通という会社は、沈みゆく泥船にしか思えなかった。
※1「産業突然死」の時代の人生論、第44回 談合をなくす二つの妙案－"便利なゼネコン"はいじめの温床
http://www.nikkeibp.co.jp/sj/2/column/a/46/
（この記事のゼネコンをITゼネコン（ITベンダー）に置き換えていただきたい。）
※2 引用にあたり、語尾を改めた。
補足１．城繁幸氏の著書「内側から見た富士通」（光文社）についてのコメント
この本は富士通が先んじて導入した成果主義が、名ばかりで社員のやる気を奪う結果に終わったという実態を告発した本である。
この本について、いくつか述べたい。
まず、本題である、成果主義が経営層のご都合で導入されて、社員のモチベーションを奪うという最悪の結果に終わったという指摘はまさにその通りである。
また、この本が出版されてから10年以上経つが、実態は改善されていないし、する気もないのだろう。
（そもそも経営者のご都合成果主義の導入を失敗だと気づく能力が欠如しているのかも知れない）
管理職の仕事は、部下の成果を評価することではなく、予算内におさまるように部下の評価を調整することであった。
なお、成果主義の導入を評価している現場社員は誰もいなかった。
（成果主義を批判する幹部社員はいなかった。おそらく批判すると何らかのペナルティがあるのではないかと邪推している。）
補足２．転職について
筆者の転職について、考慮したことをいくつか述べる。
まず、次の会社・仕事の選び方および交渉の進め方については、山崎元氏の著書「会社は二年で辞めていい」（幻冬舎新書）を大いに参考にした。
転職は考えていなくとも、今の時代を働く考え方、人材価値のセルフマネジメントなどは一読の価値がある。
富士通という大手を辞めたはいいが、次の会社で苦労している人が多いという意見についてコメントしたい。
筆者に言わせれば、それは転職のツメが甘いのだ。
現職のどこに不満を持っていて、そのうち、どこが改善の余地があり、妥協するべきであり、次の職で改善を期待するのか、についての思慮が浅い。
社会のルールをわかっていないで転職したとしか思えないケースもある。
そもそも富士通という会社に勤めているにもかかわらずITゼネコンの生態系を理解していない社員がとても多い。
下請け企業にいけばもっとやりがいのある仕事ができる、などという浅い考えで転職する人はいる。
ITゼネコンの下請けを生業とする会社の社長は、中間管理職と何一つ違いはない。
上の指示（元請けの発注）を受けて下に伝達するだけであって、自身で新しい事業を生み出す能力のない企業である。
新しい会社は、自社で新しい事業を生み出す能力があり、きちんと利益を上げている。
転職において改善したかったこと、専門的な業務ができること、自分のアイディアを事業に活かすことができること、それらがすべて達成できた。
客からすれば安いほうがイイわけだけど、安くすれば時間も短くなり、できることも少なくなる。
なれた客だと、見積もり時には要件はミニマムで、安く見積もらせておいて、後出しであれこれ要件やタスクを増やしていくといった手法をとる。もちろん、見積もり金額が決定した後では、追加工数は認められないの一点張り。
逆に、いい客は文句言いつつもカネを出してくれる。スケジュールも長くとってくれる。多くは無いがそういう客も存在する。
そういう客にはディスカウントしたいと思うんだよね。タスクのボリュームに対して長いスケジュールを組んでくれれば、作業は余裕が出るし、品質も向上するし、何か問題が起きてもリカバリしやすい。
営業や会社はイヤだろうけど、開発の現場からすればカネより時間が重要じゃん？。
タスクのボリュームに対してスケジュールが長いと判断できればディスカウントする。そういう仕組みがあれば、客も長めにスケジュールを組むモチベーションになるので、客と現場は ウィィィーーーーン/ウィィィーーーーンじゃないですか。
カネ的には一見ベンダ不利だけど、現場が疲弊しにくい状況になれば、人材補充/教育のコストも減るので、中長期的にはそんなに不利でも無いとか言う可能性もあるし。トラブルによる炎上なんかも、時間さえあればボヤで済むケースも多いしね。
どっかにそういう取り組みの実例ないかね。
http://jvn.jp/jp/JVN81094176/index.html Android OS がオープンリゾルバとして機能してしまう問題
ってやつね。
報告者の森下さんが「とある方から私個人宛で報告をいただき」と言っているので、その「とある」人として少し背景を書いてみようと思う。
https://twitter.com/OrangeMorishita/status/581314325853306882
発見のタイミングは、Android 4.2 のソースコードが出て少しして、ぐらい。この時点では、Android全てが修正されていなかった。当時、 CVE-2012-3411 (dnsmasq が libvirt の特定の config で使うときにオープリゾルバとなる) が発表されていて、これと同じ問題があるのでは、と調べた結果だった。Android のテザリングは、framework の指示を netd という daemon が受け取りネットワークの設定を変更して実現されている。で、テザリングのクライアントにDHCPでプライベートアドレスを配りDNSのリゾルバを提供するために、必要に応じて netd から dnsmasq が起動される。
そのころ、Android端末の製品開発で、スケジュールに珍しく余裕があり、わりと好き勝手できる状況だったので、AOSPのソースコードを精査していた。
いくつか、セキュリティ問題をみつけて、ものによって単に修正、修正と並行して Google に会社から報告、あるいは単に Google に会社から報告、ぐらいの対応をした。
この問題は、Google に報告だけ、の対応をとった。なぜかといえば、 次のような事情があった。
で、この報告の結果なのか、他の報告もあったのか分からないが、Android 4.3 のリリースに修正が含まれていた。もっとも、国内のほとんどのスマートフォン端末は Android 4.3 はスキップした。森下さんへの個人的な連絡の最初は、Android 4.3 発表より前。
正直、この問題のリスクは、端末ベンダ、および端末ユーザにとっては相当に低いものに見えた。3GやLTEの国内キャリアで、外から端末へ DNS query を許すところはほとんどないだろう、というのは直感的には思っていた(これが間違っている場合は、影響がケタ違いに大きくなるところだった。上流も下流も Wifi という構成のテザリングをAndroidは持っていないので、上流を Wifi と仮定すると、残るのは USB と Bluetooth だけになる) 。NAT される場合ならなおさら。
ただ、ネットワークインフラにとってのDDoSというのは、個々にとってはリスクが低くても、それが何百万台、何千万台とあれば影響が出てくるんじゃないか、という気もした。ちょうどそのころ、森下さんが DNS リフレクション攻撃に関してベンダ等への啓発を始めていたのが目に留まったので、森下さんに連絡してみた。脆弱性対応としてハンドリングするのがIPA や JPCERT/CC になるとしても、ネットワークインフラへの影響ということであれば、表に出ない話も扱える方が報告したほうが適切だと思った。私は原理的には分かってもネットワーク運用に関しては業界の外にいるからね。
事情は知らないけど。
ひとつの可能性としては、「対応未定」の端末、おそらくは対応しないことになるのだろうけど、それらの現役感がなくなってきたからじゃないかな。Android 4.2系が端末のラインナップとして長生きしすぎたせいで、けっこうOSバージョンアップではなくセキュリティ修正としての対応をする製品が多くなったのかなぁ、という気もするけど。
もうひとつの可能性としては、当初よりもインフラへのリスクが上がっているのかもしれない。Android 4.2系の端末で修正リリースが去年の秋とか、これからの近未来とかのが多い、という状況からするとね…。
要するに PackageInstaller が権限チェックするタイミングと、実際にインストールするタイミングの間に、対象の .apk を置き換えてしまうという手法となります。(Google Play ストアからのインストールの場合は、一時的な .apk は /sdcard などではなく端末内のセキュアな場所に置かれるために、書き換えることができません。)
また Android 4.3 以降は、権限チェック時に AndroidManifest.xml のチェックサムを記録しておき、インストール時にももう一度それを確認するように PackageInstaller が修正されているようです。(一部のベンダの端末では 4.3 でもこのチェックをしていないので脆弱性の影響を受ける)
さらには、4.4 以降であれば、上記のチェックサム確認の他に、そもそもアプリが自由に /sdcard を書き換えることができなくなっているので、.apk を書き換えること自体ができなくなっていますね。
ユーザにできる自衛策としては、Google Play からのみアプリをインストールする、といったところでしょうか。
あるいは、/data/local/tmp はアプリからは書き換え可能でしたっけ？
できないのであれば、PC で .apk ファイルをダウンロードしたのち、adb install でインストールする、という手もありなのかな。
あ、ちなみに Amazonアプリストアアプリ (ややこしいな) は既にこの問題に対処しているようなので、Amazonアプリストアは安心して利用しても大丈夫かと思います。
今はまだ、っつうか、20～30年くらい前に、ソフトウェアも労働者をちょっと訓練すれば誰でもできるようにして工場で生産する製造業みたいに効率あげてこうぜっていう試みがけっこう真剣にやられてたんよ。その名もソフトウェアファクトリー。(最近マイクロソフトが言い出したソフトウェアファクトリーとは違う)
日本のベンダが結構色々やっていて、アメリカさんとかはその前の日本の製造業の発展を知ってるから、結構気にして研究したりしてた。例えばMITの経済学者が"Japan's Software Factory: A Challenge to U.S. Management" なんて本を書いたりしてる。
でも結局、あんまりうまくいかなかった。今と比べて技術的に色々未熟だったとも言えるだろうけれど、やはりソフトウェアの構築というのは製造業とは性質が大きく違うんじゃないか、という見解が一般的なんじゃないかなあ。
牛乳に含まれている乳糖は、チーズになるとほとんどなくなります。日本人には、乳糖を分解するラクターゼという酵素の働きの弱い人が多く、牛乳を飲むと下痢をしやすくなります。
また、少し飲み過ぎただけで下痢をしてしまう人でも、チーズは乳糖を含んでおらず消化も良いので、安心して食べられます。
では、ドイツの人は、いつもウンコが臭いのかというとそうじゃないのです。
ハイル! フンデルベン! ミーデルベン! ヘーヒルト ベンデル!
フンデルト モレル ケッツカラデルド! フンベン モルゲン!
チーズは嗜好品として、たしなむ程度にしておきましょう。もし、大量に食べてしまったら、分解酵素を多く含む、野菜か、果物を同時に食べてください。
「もう図書館は語りたくない。行くことに疲れたし、肝臓も壊した。おまけに会社も辞めることにしました」
そう語るAさん（40代）は、元人気図書館系ブロガーだ。かつては毎日図書館に行き、カレントアウェアネスほか図書館系雑誌を欠かさずWebと冊子体で読み，年間500館は訪問していたいたことも。そして図書館好きの間でも一目置かれていた存在だった。しかし、あることをきっかけに精神的不調に陥り、うつ病と診断され、現在は務めていた大手市立図書館を休職中だという。
「職場の飲み会の席で『Aさんって図書館に詳しいんですよね』と女の子たちに聞かれて、僕のおすすめを教えてあげたんです。最近のトレンド、館長の人柄、コスパに優れた図書館システムなど様々な側面を考慮して、女子にも受けのいい図書館をです。またゼロ年代からの図書館のニューウェーブ系（指定管理系・ディスカバリーサービス）の歴史もわかりやすく教えてあげた。知り合いの図書館員に僕の紹介だと言えばサイン入りの利用者カードぐらいオマケしてくれるんじゃないかとも言いました」
Aさんにそんな話を聞いてきたのは会社の20代の女性社員3人だった。だが翌日、図書館のおはなし室に入ろうとした時、彼女たちがAさんの話をしていたという。
「酷いことを言っていたんですよ。『図書館ぐらいであんなに得意になれるって終わってる』『彼女もいないし、図書館と結婚したんじゃないの』『息がフィルムコートと紙魚の臭いがする』なんて。その場には僕の後輩の男性図書館員たちもいたみたいで、みんな笑っていた。その日は図書館を早く退庁して、家に帰ったらめまいがして」（Aさん）
電話取材を行っていると、この話をしているうちにAさんは嗚咽をもらしはじめた。国内のOPACも全ベンダ制覇するなど図書館に尽くし、恋愛、友人、仕事（休日の出勤も図書館に行くために断っていた）を犠牲にしてきただけに、周囲の心ない言葉が響いたようだ。
「図書館は結局、僕になにも与えてくれなかったんです」（Aさん）
こういう事例はAさんにとどまらない、筆者がかつて取材協力をお願いしていたある図書館系ブロガーは、他のブロガーたちと競うことに疲れ、彼は現在図書館業界を語り出すと吐いてしまうという程精神不安定になっている。またもう一人は、知り合いだった図書館関連協会の事務局から『事務局運営にまで口を出すのはやめてください。もうウザいからこないでください』と言われたことを機に、過食に陥って、もともと80キロだった体重が現在は120キロになっている。彼は現在外出恐怖症だと言っており、家で「図書館員になろう」を大量に読み漁り、健康状態も心配だ。
2000年代前半から2010年代にかけて、多くの図書館系ブロガーたちが生まれ、図書館を語ることに情熱を燃やしてきた。彼らの多くは図書館の自由を語り尽くすことをステータスにしてきたから、語り過ぎて身体を壊すのはわかるが、まさか心まで壊してしまうとは。まあ、ツタヤには罪はないのだが。
ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。
Ｘは記名捺印 拒否
Ｙは，Ｘに対し，内容証明郵便で，たびたびＸが仕様の確定を拒否し，追加費用の支払いに応じることなく仕様の確定を遅延させることは信義則に違反するとして，契約を解除する旨を通知した。Ｙは，契約金額等を返金した。
Ｘは，Ｙには債務不履行（履行不能）または告知義務があるとして，システムの完成を前提として支出した費用等の損害賠償約1.2億円を請求した。
なんなのこれ・・・
裁判所の結論
むしろ，（Ｙによる追加費用の申し出）を全く受け入れることなく，当初の契約金額による本件ソフトウェアの完成を要求し，これに固執したＸの対応こそが不合理なものというべきである。
まぁ、要件定義は、実はスキルのいる仕事で、要件定義できない顧客による事故というのは某銀行も含め耐えないね。
見ながら変える。という 請負契約に有るまじき案件が多すぎだ。
こういうつもりじゃないというやつ。（どういうつもりかを明文化する義務は発注側に有ると下請法で決まっています。）
なので、発注側には、案外 エンジニアスキルを持った正社員という物が要求されることがあります。（既存のよくあるものでない限りは）
などというフレーズが日常的に飛び交う現場で3年目の夏を迎えた。
小さい会社だ。独立系ITベンダの皮をかぶっているが、何次請けなのかも分からないような仕事を丸投げされて、数名単位のグループで現場に送り込まれるという、典型的な人出し派遣零細企業だ。俺も本社にいたのは研修期間の最初の半年だけで、それ以降は海の近くの巨大なビル街のあちこちを転々としている。プロパーの目を気にしながら食べる昼食の味にもすっかり慣れた。
最初の1年で2人やめた。理由。1人は「公務員試験を受ける」。もう1人は「仕事についていけないから」。
前者は同期数名だけのささやかな送別会の場でこんな事を言っていた。「毎日遅くまで残業させられる上に、20も30も年上のベテラン社員がペラペラの安っぽい背広を着て若手と同じような仕事をしてる。あれが俺たちの未来の姿だと思うと耐えられない」。懸命だと思う。その後、何度か彼とはメールのやり取りをしたが、公務員になったという話はついぞ聞かない。知らせがないということは、芳しくないということなんだろうと思っている。
「仕事についていけない」後者は、俺たち同期の目から見ても、プログラミングという仕事が向いていない男だった。コードが書けないだけでなく、「どのような処理が求められているのか」ということすらなかなか理解できない。体育会系で気持ちのよい男で、入社直後は朗らかにみんなの輪の真ん中で笑っていたのだが、研修が進むにつれてだんだん笑顔が減っていき、暗い顔で研修室に毎晩居残るようになり、何とか研修期間が終わって現場にアサインされた数日後には本社に突っ返されてきた。彼もきっとすぐに辞めて懸命だったのだ。ここは彼がいるべき場所ではなかった。と言うより、誰もがこんな場所にいるべきではないのだ。
彼らの頃は、まだ「あいつ、会社やめるってよ」というフレーズがショッキングな響きを維持していた。その後に、「何もやめること無いのにな」という言葉が続いたりもした。
2年目には6人やめた。1つ上の代で、胃に穴をあけて倒れる先輩、心を病んで休職する先輩、誰にも何も言わずに消えた先輩が3人立て続けに現れたことが引き金になったのか、6人中4人はわずか2ヶ月の間に立て続けにやめてしまった。そのうちの1人、女性なのだが、泣きながら「このままだと病気になる。今すぐやめさせてほしい」と談判して、結構な火の吹き方をしている現場からそのまま離脱退職したそうだ。俺は、彼女もまた懸命だと思う。俺たち若手の代わりなんて幾らでもいる。燃え盛っている火の中で心身に大火傷を負いながら得られるものなんて、安っぽい達成感と、上長からの「こいつは無理がきく」という評価だけだ。そんなもんガソリンぶっかけて火をつけちまえ。
その頃には「あいつ、会社やめるってよ」が、まるで時候の挨拶のように軽い響きのフレーズへと成り下がっていた。だけど、俺は誰かの退職を知るたびに心の中でこう思っていた。「あいつ、やめるのか。うらやましいな」。そう思うのなら、俺だってやめればいい。簡単な話だ。だけど、俺はやめられなかった。怖かった。ろくに貯金もなく、技術もなく、経験もなく、はっきり言って社会性も大してない。ついでに言うと、俺以外の連中もその辺りの事情は大差なかった。何のことはない。この会社は他の会社では通用しないような人間をかき集めて、頭数を揃えて、泥臭い作業要員として使い捨てにしているのだ。ここを抜けだしたとして、他にもっとマシな場所があるのか。その先にあるのは、さらに深い下請けの下層ではないのか。この会社に居続けることが不正解だということは分かっている。だけど、会社をやめることが正解だとも思えない。
そして3年目。同期で残ったのは俺ともう1人だけだ。もう1人、便宜的にそいつのことを「増田」と表現してよいだろうか？紛らわしいことは承知の上だが、他に適切な名前も思いつかない。
増田はずっと、本社の経理にいる。簿記の資格を取っているということで、他の同期がJavaの研修などを受けている1年目の5月、6月の時点で経理に配属されて、そのままそこで働き続けている。毎日、ゆっくりと出社して、昼は社長と昼食に出かけて、夕方は定時に帰る。会社全体規模で行われる飲み会には必ず参加して、常に社長の近くで酌をしたり、社長の話に懸命に相槌をうったりしている。要は、増田は社長から殊更の寵愛を注がれていたのだ。増田は年不相応に幼く、ともすれば中学生ぐらいにも見える。そんな増田が、ゴルフ焼けした老ゴリラのような社長とべったりしているさまは、一見すると祖父と孫のようでもあり、それでいて2人に間を飛び交う視線にはどこか湿った情念のようなものが常に漂っていて、それがひどくグロテスクに感じられた。
そんな増田が8月いっぱいで会社をやめる。さすがに今回ばかりは「増田、会社やめるってよ」という言葉が、驚きと好奇心を伴いながら現場中を蔓延した。社長に新しい愛人ができたのか、はたまた増田にもっと別の若くて甲斐性がある彼氏ができたのか、あるいは地元に帰って見合いでもするのではないか、様々な噂が飛び交った。俺も表面上は周りの社員とそんなゴシップ話に興じてみせるのだが、心中はいよいよ穏やかではない。とうとう、俺だけが残されてしまった。俺だけが逃げ遅れた。そんな焦燥感に駆られながら、俺は煙草くさい先輩社員達が繰り広げる増田に関する下品な噂話に精一杯の作り笑顔で受け答えしながら、冷や汗をかきながら、この会社での3年目の夏を終えようとしている。
最近いくつかPC向けネトゲいじってみたけどあれはダメだろ。ソシャゲに駆逐される運命にあると思う。
まずはじめるまでが面倒。アカウント作成→クライアントダウンロード→インストールで1時間以上かかる場合もある。
そして操作が面倒。ゲームごとに操作系が違うから慣れるまで時間がかかる。面倒くさいので10分程度いじって即ヤメしたゲームがいくつも。
それらを乗り越えたところで結局すぐに飽きがくるから徒労感が凄い。
お前らが廃人どうのとか騒ぐからどれほどのものかと思ったけど全然糞だったわ。ソシャゲのほうがよっぽどましですね。
ソシャゲ(特に携帯の)は凄い。GREEやらMBGAのアカウント持ってれば、新しいタイトルはワンクリックで利用可能になる。
操作は基本1ボタン。画面構成とかもわりと一般化されてるからユーザの負担が異常に少ない。
気軽にいくつも試せるからユーザがそれぞれ自分にあったタイトルに行き当たる可能性が高い。
しかも開発コストがコンシューマに比べて低い。収益的に微妙だったらすぐ引っ込めればいいわけだけど、その判断に迷いが生じないくらいの安さ。
だいたいたかがゲームやるために専用機器やらパソコンやらの電源入れてクライアント起動してログインしてってどこの土人だよ。
あー理解した。「いつものようにFlasherが顔を真赤にしてんなー」とか思われてたのか。だからポジショントークって言ってたのか。
あ、ごめんなさい、そういう風に読めなかった。
そらFlasherのポジショントークだと思われてたら、読めるわけがない。
HTML4には標準じゃない方言（DOCTYPE）が70種類以上ある。それはもはやWeb標準を踏まえてたといえるのか。
HTML5はこの反省を踏まえて、極力方言を作る必要が無いように慎重に仕様が策定されてるわけだけど、それはあくまで「現在のインターネットにおいて」であって、将来にわたって各ブラウザベンダがおとなしくしている保証はどこにもない、というか、ブラウザシェア戦争がある以上、おとなしくしている訳がない。ネットに向いてないは言い過ぎました、すいません。
Web標準のHTML5を普通に使っていこうよ、ってのは特に意識しないでもそうなると思う、というか嫌でも使わざるをえないのがWeb標準。
いいたかったのはシンプルなことでして、「スペコンって必要なの？ それ誰が見てるの？」みたいなことです。Flasherのポジショントークに対して。
100％同意。変態Flasherは基本的にユーザーなんか眼中に無い、ただひたすら己の技量を磨く事を恍惚としてる。まぁそこらへんの人種はそっと遠巻きに眺めておけ。
ただ、お仕事Flahserはちゃんと考えてると思うよ。というか、お仕事Flahserは大概HTML5もFlashも両方使える。変態Flasherは大概HTML5でも変態。まぁそこらへんの人種はそっと遠巻きに眺めておけ。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
つまり、「生産性の高い言語」は、人間の不注意やミスを言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
Cで開発してるチームなら絶対に持っている、自前のライブラリ群や
それらが十分に品質が高く、容易に利用できるものならいいんじゃないかな。
Javaの場合、ユーザのフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
あなたは、その解決を「生産性が高い言語」だけでしか話していないけれどね。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
Cで開発してるチームなら絶対に持っている、自前のライブラリ群や
それだけでメッセでイベントが開催できるほどの開発ツール群はすべて無視して、
