読み物

ソフト業界の労働環境

ソフトウェア業界

一般

  • 業務系エンジニアはどうしていくべきか? 2012.6.19
    • 腐るモノを素早くつくる能力と残るモノをかっちりつくる能力は違います。Web系は前者で、業務屋は後者です。前者も後者も極めればそれなりに潰しが効きます。(前者は専門外なので、そのへんのブログとか漁ってください。よくわからんけど、凄い人は凄いのはわかります。)安易に専門外に転職するのではなく、まずは必要な能力をちゃんと普通に通用する水準までもってくるべきです。いま、なんでか知りませんが、普通の事ができない人が多いので、「普通にできるようになる」といいと思います。
  • 「こいつは成長しないな」と思う7の特徴
    • 1:調べずに聞いてばかりいる
    • 2:確認をせずに指示があるまで動かない
    • 3:時間配分が悪い
    • 4:差別意識が強い
    • 5:取捨選択しない
    • 6:当たり前のことしか認識できない
    • 7:些細なことにこだわる
  • 優秀な人が非常時にダメになる理由 2011.3.23
    • 「非常時にこそ人間性が出る」とはよく言われますが、上に立つリーダーは、非常時にこそ“捨てるもの”を明確に決断する必要があります。さらに、この決断によって生じる結果に責任を持つ覚悟と姿勢が求められます。そうでなければ、誰もメンバーはついて来ません。平時ですら“捨てるもの”を明確にできなければ、組織の力は分散してしまいます。非常時はなおさらでしょう。
  • 成長につながる五つの習慣 2011.3.18
    • 1.恥ずかしがらずに質問する
    • 2.借りた本をすぐに返す
    • 3.良いところはマネをする
    • 4.担当外の作業に目を向ける
    • 5.マネジャーのツッコミを押さえる
  • ある程度の年齢を迎えたプログラマが生き残るには 2010.9.23
    • ぶっちゃけ戦略は一番重要なことではなく、一番重要なのは、常に自分の価値を高めるために努力し続けることです。
    • 努力や挑戦をやめたら、自分の価値はどんどん陳腐化して下がっていくのは当たり前なのです。
    • これは、実はプログラマに限った話ではなくて、どんなことにでも言えることだと思います。常に自分の価値を高めるために挑戦し努力し続けることが重要だということです。
  • あらためて、プログラマなんかで終わりたい 2010.1.7
    • システムエンジニア的な仕事(マネージメント、コンサルティング、システム設計etc.)とプログラマ的な仕事(プログラム設計、コーディングetc.)を高水準で両立させることができるのは、かなり優秀な方に限られるんじゃないんでしょうか。
  • プログラマの生産性とは? 2009.12.27
    • プログラマが最も効率性を発揮するのは、コードを書くことを回避する時だ。たとえば、自分たちに与えられた課題は本来解決すべき課題ではなく、顧客の要望が実際の需要に一致していないことに気付く場合だ。あるいは、彼らの課題を解決するには、あの再利用ないし再編集可能なコードを使えば良い、と気付く場合だ。あるいは、誤魔化しをする場合だ。しかし、プログラマが最も生産性が高い時に、「おお! 正面から問題に取り組んだ場合に比べて100倍の生産性を上げたね。昇給ものだ。」と言ってくれる者は誰もいない。「グッド・アイディア!」と声を掛けて通り過ぎるのがせいぜいだ。ある人が決まってそういった時間節約的な発想をもたらしてくれることに気付くのには時間が掛かる。逆の言い方をすると、別のある人が一所懸命になってプログラムを書いているが、何も生産されていないことに気付くには長い時間が掛かる
  • 管理職は技術者か 2009.12.23
    • 「ほとんどの管理職は,学習は日課になっていない.」
    • 「ほとんどの管理職は,管理職になる前もなった後も伸びていかない.」
  • リーダーとして生き残る技術 職場の荒廃、30歳の危機
    • 組織で生き残る技術のないリーダーの特徴とは次の7つです。
        1. ビジョンを持っていない
        2. 自分の言動が他人に自分がどんな影響を与えるかを自覚していない
        3. 事実を見ることができない
        4. 観察する力がない
        5. 自己概念が低い
        6. 人を決めつける
        7. 存在の承認をしない
  • 副業失敗で消費生活センターに相談するという… 2009.11.20
    • 1.楽に儲かる話はよくてバクチ、悪くてインチキ。どっちかしかない。
    • 2.ビジネスを始める際に高額の一時金を払うことを要求されるケースは高確率でインチキ。←昔NIFTY-Serveの在宅ワーキングフォーラムでそういう回答したのを思い出した。10年以上経っても世界は何も変わっちゃいない...
  • もくもく会ポータル
    • もくもく会とは喫茶店やカフェなどに集まって各自もくもくと勉強したり仕事したりする会です。家ではどうも仕事や勉強に集中できない、さぼってしまいがち…というフリーランスの人や学生の人におすすめです。気軽に参加(もしくは開催)してみてください。
  • IT業界で楽しく仕事をするための10カ条 2009.3.11
    • 其の一、本や雑誌を買って読むべし
    • 其の二、分からないことは、なるべく自分で調査するべし
    • 其の三、お気に入りのWebサイトを見つけて読むべし
    • 其の四、社内外に向けて情報発信するべし
    • 其の五、勉強会やセミナーに出席するべし
    • 其の六、専門家であるべし、さらに多くの“基本”を網羅的に知っておくべし
    • 其の七、誰が何を知っているのか、人的ネットワークを広げるべし
    • 其の八、自分のコンピュータと気に入った新しい携帯電話を持つべし
    • 其の九、1つのプログラミング言語だけではなく複数の言語を使いこなすべし
    • 其の十、適切なメモを取るクセを付けるべし
  • プログラマーの誇りを見せ付けろ 2009.2.11
    • この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。
    • 新人〜3年目が悪いわけじゃない。
    • ベテランがコードを書かなさ過ぎる。
  • 徹夜をしてはいけない理由
    • 恩着せがましくなる 例: 朝のミーティングで「先ほどやっと完成しました」
    • 先のことを考えている人間に対する怒りが芽生える 例: 「そんなこと言っている時間があったらちょっとは手伝ってよ」
    • 被害者意識を持つ 例: 「この会社でまともに仕事している人間は自分しかいないわけですから」
  • ドットコム・ブーム期とは違う人材不足が深刻に 2008.3.21
    • ITとビジネスの両方を理解する人材の不足が深刻な問題になってきている。それが,ビジネスの成長を脅かしつつあるのだ。従来型の技術的なITスキルだけでは,ITとビジネスの両方を発展させたいという企業の要求に応えられない。
    • 必要なのは,プロジェクト管理やビジネス・プロセスの分析,アーキテクチャやプロセスのモデル化に長けた人材だ。加えてリーダーシップも必要になる。
  • コミュニティは「知り合い系」から「出会い系」へ変化する 2008.3.12
    • 「昔はツールやネットがそれほど発達していなかったので、何かイベント(飲み会)をやるぞ!といったときに、自分の知っている範囲の身内でしかコミュニケーションが取れませんでした。いまは身内じゃなくても簡単にコミュニティに入れるという点が大分違うなと思います。特にtwitterなんて、それまで全然会ったことがない人とコミュニケーションが取れます。昔は『知り合い系』のコミュニティだったのに対して、現在は『知り合うため』のコミュニティなのかもしれないと思います。別のいいかたをすると『出会い系』といえるかもしれません」
  • Aクラスの奴はNoを言わない上に褒めるのが上手い 2008.3.8
  • ”技術者”の解放 2008.3.7
    • ソフトウェア技術者の世界は脅迫に満ちている。「xxを読んでいないと駄目だ」「yyを経験していないやつは使えない」「zzは教養だ」など。ただ、こういう事を言っている本人はxxを読んでいるし、yyを経験しているし、zzを知っている。つまりこの手の脅迫は単に話し手の自己肯定の為に発せられることが多い。
    • こうした理由から、真に学ぶ価値がある技術は自分で見つけなければならない。それを誰かに教えてもらうことは不可能である。ただ言えることは、”誰かが知っているから学ばないといけないような気がする技術”を学ぶことに翻弄してはいけないということだ。
  • COBOLエンジニアの苦悩、将来はない? 2008.3.6
    • 私自身は、近藤さんの経験は金融系システムエンジニアとしては順当で、このままスキルアップ、キャリアアップしていけばよいのではないかと感じました。COBOLエンジニアは、この10年ほどで若手を中心に随分と減りました。そこに2000年問題や2007年問題だので、その時々で需要があり、エンジニア数が減っているのと相まって、一定のスキル以上のCOBOLエンジニアであれば、オープン系エンジニアどころではない売り手市場になっているのです。
    • 転職市場においては、一貫して一定のスキル以上のCOBOLエンジニアであれば、要件定義前の段階でのクライアントとの折衝スキル(コミュニケーションスキル)や、大規模なプロジェクトでのマネジメント経験が重要視されます。しかも、この傾向は今後も変化はないでしょう。
  • SEはSEの常識を再点検しよう
    • SE以外のビジネスマンから見た“SEの常識”
      • (1)  顧客や営業担当者が言う通りに仕事をする
      • (2)  売上額や利益などビジネス目標を知らない
      • (3)  顧客やビジネスより情報技術(IT)を優先する
      • (4)  「ITに強いSEが優秀なSE」と考えている
      • (5)  SEマネジャは特定の顧客だけ訪問する。また現場のSEは担当顧客の部課長と話をしない
      • (6)  「顧客の担当者よりITをよく知っていれば顧客から信頼される」と思っている
      • (7)  プロジェクトで自分の受注した範囲は考えるが,顧客の担当範囲まで考えない
      • (8)  ソフトなどのトラブルは解決に時間がかかっても自分で直そうとする
      • (9)  データベース担当がネットワークの基本を知らないなど自分の担当外のことを知らない
      • (10) 相手のIT理解度に関係なくIT用語を使って話す
      • (11) 顧客の業界の動向やアプリケーションを知ろうとしない
      • (12) 「これは自分の仕事,これは○○の仕事」とすぐ他の人と仕事の壁を作る
      • (13) 会議などで自分の意見をなかなか言わない
      • (14) 分かりやすい資料を作ろうとしない
      • (15) プロジェクトで問題が起こると往々に「注文を取った営業担当者が悪い」と言う
  • 10人のエンジニアが見せた開発者コミュニケーションの最前線 2008.2.20
    • モバイルファクトリーの松野徳大氏はIRC ClientやLimeChat、オリジナルのタスク管理システムや社内ブログなど、社内で使っているツールについて軽く触れた後、社内のイントラブログについての問題点を指摘する。松野氏はイントラブログについて人々が気を使い過ぎて上っ面だけの本音のコミュニケーションがされていないと語り、タバコ部屋での会話のような気軽で本音を語るコミュニケーションの重要性を説いた。ただ、松野氏はタバコを吸わないので、これに変わる物として毎日1時間「帰りの会」、毎週1回「週次レビュー」を行っていることを紹介した。
    • 大事なのはそうやって会議の時間を余らせることで、そうしたタバコ部屋に似たダラダラした時間やグダグダした話し合いの中からこそ重要な話が出てくるのだという。
  • イメージを形にできない人は減衰する 2007.11.6
    • しかしきついから逃げないで職に打ち込んでいると、ある日気がつくのである。自分がどれだけ鍛えられているかを。こりゃ堪らんよ。堪えられないよ。こいつは残念ながらどこにも売っていない。職人が作ったものなら金だせば買えるけど、自分でつくれなかったものがつくれるようになった時の気持ちは、どこにも売ってないんだぜ?
  • ITエンジニアの能力は午前11時がピーク 2008.1.31
    • オシム氏は2007年11月に不幸にして脳梗塞になりました。報道によると、午前2時ごろに自宅の2階に上がろうとして倒れたそうです。なぜ彼は、夜中の午前2時過ぎまで起きていたのでしょうか?その訳を推理してみましょう。
    • オシム氏が午前3時に就寝するとすれば、平均睡眠時間である7時間寝たとして、朝10時に起床することになります。人の脳の活動は、起床してから 5時間後ごろにピークになります。するとオシム氏の脳の働きは、午後3時ごろにピークを迎えると計算できます。午後3時は、サッカーの試合の真っ最中です。そのとき最高に上手い指揮ができるというわけです。このことを彼は長い経験から知っていたのではないでしょうか。そこでわざわざ午前3時ごろに寝るように身体のリズムを整えていたのではないかと思います。
    • (引用者注:単に夜中じゃないとヨーロッパの試合見られないってだけでは)

メンタルヘルス

  • 会社が壊れ社員が折れる、その前に… 2009.12.17
    • たとえば、「会社がつまらないから、転職しようと思う」といった相談(この不況でこんな相談も激減したが…)が来ると、「つまらないから、というだけで辞めても失敗する。自分が何をやりたいのか? 今の仕事の何が問題なのか?を考えてからじゃないと、転職しても意味がない」などと、自らの経験も加味し、問題型対処、ストレッサーへの対処をやれ!とついつい言ってしまう。その人の心の状態が折れる寸前まで弱っていたら、まずは凹んだココロをもとに戻さない限り、問題解決などできるわけないのに、 “ごもっともなご意見”ばかりを言ってしまうのだ。
  • 「適応」することが正常?苦痛も喜びも麻痺してしまう精神的「去勢」 2009.11.26
    • 体制の側に立って見た場合には、容易に「適応」してくれて体制の役に立つ人間が重宝されるでしょうし、そちらを「正常」として考えることでしょう。
    • しかし、仮にこれを偏狭な独裁者が支配する全体主義的国家の中にでも場所を移して想像してみると、「適応」イコール「正常」と断ずることがいかに危険であるかがわかります。実際、人類の歴史を振り返って見ると国家的犯罪や組織的犯罪などは、常に体制に「適応」した「正常」な人間たちが忠実に責務を遂行した結果、ひき起されたものでした。
    • ですから、私たちは「適応障害」の原因を本人のストレス耐性の弱さに帰結させる前に、その環境がはらんでいる問題点について一度丁寧に検討してみる必要があるのではないかと思います。
    • そして、その環境に問題がある場合には、そこに不感症的に「適応」している人間を「強い人間」とか「大人である」として称揚してしまうような価値観から、私たちは脱しなければならないと思うのです。
  • エンジニアと欝
    • 長時間労働
    • 先が見えない
    • 見返りがない(金銭的、精神的)
    • 個人にかかる責任が重すぎ
  • 限界を超える対価
    • 確かにがんばれてしまうものだな、限界を超えられる物だな、と自分の経験を振り返って思います。そこには自分の想像を超えたスゴイ自分がいます。
    • でも、それと同時に 頑張れてしまった結果 自分が壊れてしまうというのも経験できてしまったのでした。

資格

  • 情報処理技術者試験は終わった 2020.5
    • 無意味な手書き、無意味なハンコ、無意味な紙。これを、なんと簡易書留で送らなければいけない。
    • しかも登録証(紙)の原本を同封しなければならない。
    • 書類の不足があった場合は、電話・メールで連絡が来る・・。
    • 情報処理技術者試験も、学校などの教室に集めて、3密の状態で紙とえんぴつだけで試験するという、全然ITを活用していないレガシーな方法で運営していた
  • 示現塾
    • 情報処理試験の過去問、回答用紙、回答例
  • 独学で資格試験に合格するための効率的な勉強法
      1. 問題が解けるようになることを目標にする。「要点を見極める」
      2. 問題を理解しながらたくさん解くこと。「量をこなす」
      3. 問題がわからなければすぐ答えを見ること。「解けないのものは解けない」
      4. 問題を解いた後に参考書を見直す。「理解を深める」
      5. 大事なポイントは書き出して説明する。「要点は重点的に」
      6. 勉強する科目は順番にルーティングさせる。「ルーティング式時間割」

人生設計など会社員一般


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-10-17 (日) 22:50:30 (6d)