  |
はてなキーワード: 開発プロセスとは
アジャイルがどうの、ドメイン駆動開発がどうの、マイクロサービスがどうのと、開発プロセスについての情報が巷にあふれている。
しかし勘違いしないほうがいい。あなたの現場にとって最適な方法を追求できるのは、あなたの現場の人間だけだ。
外の世界の「これがうまく行った」論は、文脈を無視しては話にならない。企業Aの文脈と企業Bの文脈が全く別のものであるなら、開発プロセスの成功法則に再現性がないのである。
「開発でこういうことが困っている」ということがあれば、それを列挙するところから始めるべきだ。現場の人間は「問題」がはっきりすれば解決策を考え出すだろう。
「モジュールの独立性について困っている」という話をしているときに、「マイクロサービスとして独立させよう」という情報がググって出てきたら疑ったほうがいい。
GPT-4はまだ開発中で、どのような仕様や性能になるかは不明です。しかし、現時点で公開されている情報に基づいて、以下にGPT-4とChatGPTの違いをまとめてみました。
1. 言語処理能力の向上
GPT-4は、より高度な自然言語処理能力を備えることが期待されています。GPT-4は、GPT-3の40倍以上のパラメータ数を持ち、さらに高度なニューラルネットワークアーキテクチャを採用することが予想されています。これにより、GPT-4は、複雑な自然言語処理タスクをより正確かつ高速に実行することができるようになる可能性があります。
2. 応答速度
GPT-4は、より高速な応答速度を実現することが期待されています。GPT-4は、より高速な処理速度を持つ可能性があり、より短い応答時間でより多くの自然言語処理タスクを処理することができます。
3. コンピュータリソース
GPT-4は、より高度な自然言語処理能力を備えるため、より多くのコンピュータリソースを必要とする可能性があります。これに対して、ChatGPTは、より少ないリソースで動作し、比較的低速な応答速度を持っています。
4. 学習データの利用
GPT-4は、より大規模なデータセットを利用することができるため、より高度な自然言語処理能力を備えることが期待されています。一方、ChatGPTは、限られたデータセットで学習しているため、限定された範囲での自然言語処理タスクに適しています。
5. 開発プロセス
GPT-4は、大規模な研究開発プロセスを経て開発されるため、より高度な自然言語処理能力を備えることが期待されています。一方、ChatGPTは、オープンソースのニューラルネットワークモデルであり、誰でも利用することができます。
続けてください
6. タスクの多様性
GPT-4は、より多様な自然言語処理タスクに対応できるように設計されています。例えば、対話、文章生成、質問応答、文書要約、機械翻訳など、幅広いタスクに対応できる可能性があります。一方、ChatGPTは、対話タスクに特化しています。
7. モデルの利用者
GPT-4は、ビジネス、政府、研究機関、大学など、幅広い分野の利用者に向けて設計されています。一方、ChatGPTは、個人の利用者が利用することが多いとされています。
8. デプロイメントの容易さ
GPT-4は、ハードウェアやソフトウェアの両面で、より効率的かつ簡単なデプロイメントを可能にすることが期待されています。一方、ChatGPTは、比較的単純な構造を持つため、デプロイメントが比較的容易であると言えます。
以上が、GPT-4とChatGPTの主な違いです。ただし、GPT-4はまだ開発中であり、公開されている情報は限られているため、今後の情報開示によっては、上記の違いに変化がある可能性があります。
ご指摘ありがとう。ごめん「GPUに直接」って書き方が悪かった。だったらディスプレイ出力すらできないよねって話になるよね。DirectXの説明しても99.999%の人にはなんのこっちゃだろうから「直接」って表現をしたまでよ。言いたかったのはProtonの発表が2018年で、ごく最近のことだっていうこと。「これは恥ずかしい」っていうタグでわざわざ畳みかけるように指摘されてるのは、それを専門にしている開発者の矜持なんでしょうな。いい仕事してそう。
ValveがWindowsゲームをLinuxで動かす互換レイヤー「Proton」を発表
2018.08.23
PCゲームプラットフォーム「Steam」でおなじみのValve社が8月21日、Codeweavers社と共同開発したWindows専用ゲームを動かせる互換レイヤーを発表した。この互換レイヤー 「Proton （プロトン）」はLinuxユーザなら誰もが知っているWineを改造したもののようだ。
Protonはかなりの改造を施されており、いろんなところからかき集めたプログラムや技術が詰め込まれている。
ProtonにはDirectX APIコールをリアルタイムでVulkanのそれに変換するレイヤー（DXVK）が組み込まれているため、DirectX APIで作られたゲームでも割と軽快に動作する。
もともとVulkanとDirectXには機能的にそこまで大きな違いがないためだろう。相互に移植するのも難しくはないと言われている。
またOpenVRへの対応や ゲームのフルスクリーンモードの取り回しを改善、Steam対応のコントローラのサポートも改善している。
ProtonはオープンソースとしてGitHubに公開されているので誰でも中身を見ることが出来る。ベータの段階でこんなにいろんなプログラムをSteamに統合できたことに驚いたが、2年の開発期間を要したそうだ。
https://slacknotebook.com/valve-releases-compatibility-layer-for-linux-proton/
SteamユーザーがLinuxに切り替えても不自由なくゲームを楽しめるよう開発された「Proton」でプレイできるタイトル数が1万2000本を突破
PCゲームの販売プラットフォームとして絶大な人気を誇るSteamを開発するValveは、Windowsユーザー以外にも幅広くPCゲームを遊んでもらうために、Windows向けのゲームをLinux上でもプレイできるようにするためのオープンソースソフトウェア「Proton」を開発しています。
ProtonDB | Gaming reports for Linux using Proton and Steam Play
2018年8月にリリースされたProtonは、Steamの開発元であるValveとソフトウェア開発企業のCodeWeaversが共同開発しているソフトウェア。ProtonのベースとなっているのはUNIX系OSでWindows向けのソフトウェアをネイティブ動作させるために作成されたWineであるため、ProtonはWineのフォークとも言えます。なお、Protonはオープンソースのソフトウェアであるため、ソースコードはGitHub上で公開されています。
そんなProtonに関するデータをまとめたデータベースがProtonDBで、同サイトでは「Protonでのゲームプレイに関するレポートの総数」「レポートが提出されたタイトル数」「Protonを用いることで何かしらの修正なしにLinux上ですぐにプレイが可能になるゲーム(プラチナゲーム)数」がまとめられています。
2020年4月時点ではProtonで問題なくプレイ可能なプラチナゲームの数は6502本で、Steam上でリリースされているゲームの約50％がプラチナゲームとしてLinuxでプレイ可能でした。
SteamのゲームをLinuxでもプレイ可能にする互換レイヤー「Proton」のこれまでの功績とは？ - GIGAZINE
2020年12月8日時点でのプラチナゲームの数はさらに増えており、その数は何と1万2753本にまで増加しています。なお、「Protonでのゲームプレイに関するレポートの総数」は10万4508件、「レポートが提出されたタイトル数」は1万6232本です。
なお、Protonはバージョン5.13が2020年11月にリリースされたばかり。アップグレードのリリース時には、CodeWeaversのJames Ramey社長がProtonプロジェクトや会社の現状について語っています。
Podcast With James Ramey - Full Transcript - Boiling Steam
https://boilingsteam.com/podcast-with-james-ramey-full-transcript/
Protonのバージョン5.13では、ゲームの互換性に関する問題で大きなネックとなってくるアンチチートソフトウェアを回避するプロセスについて前進を見せているとのこと。ただし、ゲームが搭載するアンチチートソフトウェアとProtonの戦いは、Protonのリリース当初から続いている問題であるため、バージョン5.13で完全決着を見せるというものではなく、今後も戦いが続いていくこととなる模様。なお、次の次のアップグレードもしくはさらに次のアップグレードあたりで「NTDLLによりブロックされているゲームがプレイできるようになる」とRamey社長は言及しているため、Protonでプレイできるタイトルの数がより増えることなりそうです。
また、2020年に猛威を振るった新型コロナウイルスのパンデミックについて、Ramey社長は「幸い我が社はかなり分散した企業です。我々の開発チームの多くは西ヨーロッパ、東ヨーロッパ、アジアに拠点を置いているため、すでに在宅勤務を行っています。ミネアポリスにあるオフィスでは25人の従業員が働いていましたが、これも在宅勤務へと移行しています。通常時、我々は定期的にオフィスへ通っていましたが、2020年3月の第2週以降は1度オフィスに行ったきりです。元々リモートで仕事がこなせるように会社を設立したため、生産性の観点でいえば、新型コロナウイルスによる影響は皆無です。また、新型コロナウイルスの検査で陽性反応が出た従業員が何人かいたので、その従業員たちは必要に応じて休暇を与えました」と語りました。
さらに、Protonの登場によりLinuxをネイティブでサポートするゲームタイトルがSteam上から減少しているという指摘もあります。以下はSteam上で配信されているゲームタイトルのうち、ネイティブでLinuxに対応しているタイトルの数を示したグラフ。Protonがリリースされた2018年8月以降、明らかにLinuxをネイティブでサポートするタイトルの数が減っています。
これについてRamey社長は「Protonが提供するのは『Linuxでのゲームプレイ』という体験だけでなく、ゲーム開発者がLinux市場に簡単にアクセスできるようになるという機会でもあります。すでにリリースされているWindows版のゲームが、Protonを使用することで再開発なしで第二の市場に投入することが可能になるのですから」と語り、Protonの登場によりゲーム開発者がより手軽にLinuxユーザー向けにゲームを提供できるようになった点が関係ないとは言い切れないと主張。
特にゲームエンジンにUnreal Engineを使用していない開発者は、再コンパイルや変更なしで簡単にゲームをWindows市場だけでなくLinux市場にも投入できることをRamey社長は強調しています。また、Linuxにはさまざまなディストリビューションが存在するため、Linux市場で幅広いユーザーを狙ってゲームを販売することは非常に困難であるとRamey社長。その一方で、Protonを使用すればWindows向けにゲームを開発している開発者が、手軽かつ多くのユーザー向けにLinuxで動作するゲームを提供できるとしています。
また、ますます多くのゲーム開発者がProtonに気づき始めているそうで、Ramey社長は「まだ大騒ぎという段階にはありませんが、多くのインディー開発者がProtonに注目し始めているというだけでなく、大規模なゲーム開発者の多くもProtonに興味を示しています。その大きな理由は非常に低コストで別の市場にアクセスできるという点です。そのため、今後より多くのゲームがProtonで不自由なくプレイできるようになると思います。また、開発者が開発プロセスの段階でProton上でテストを行えるようになる可能性もあるでしょう。そのため、どこかのタイミング(転換点)で『ゲームが機能するかについてProtonの開発元であるCodeWeaversに問い合わせる必要性』が大幅に減少することを期待しています。我々が行っている多くの事柄は、そのための基盤を構築することです」と語りました。なお、Ramey社長は転換点が「今後12カ月以内にやってくる」とも主張しています。
私は一流SIerの上級管理職をやってるけど、こんな要素技術なんて結局意味がないんだって何回いったらわかるんだろうね日本のエンジニア（）は。この程度を勉強したところで結局派遣SESが関の山なんだけど本当にそういうのを目指したいのか？本当の意味でエンジニアになりたいのならとにかく顧客とのコミュニケーションと要件定義の仕方、そして進捗管理の報告、ちゃんとした開発プロセスを学び、次に機能設計、詳細設計をもれなく記載する技術を学ぶべきで、Docker（）なんてどうでもいい。
不勉強な人ほどウォーターフォールを馬鹿にするけど、結局すべての開発プロセスというのはウォーターフォールが基本だし、その中で要件定義や機能設計の重要性を勉強する。こういう正統な成長の道があるのに最も価値の低いコーディングから入るのは愚の骨頂。
https://www.megamouth.info/entry/2020/11/23/233104
夢を語れるとかそういう話はおいておいて、顧客の業務をちゃんと理解してシステムに落とす、それはSIerの最も得意とするところ。
だから未だにウォーターフォールでJava8（ひどいところはJava6やCOBOL）を使いIE専用の業務システムで出力した神Excel仕様書をPPAPでやり取りする。
これは全部顧客の業務をちゃんと理解し、理詰めでビジネスとプロジェクトを構築した結果なんだ。
まあそれはそれとして一番どうしようもないと私が思うのは上記の点を持って
「俺達は正しいことをやっている。Web系とか流行りを追いかけてるだけで実がない。GAFAなんて大したことやってない。」
と揶揄とかではなく本気で思っている人が多数いることだ。ほんとか？と思う人はアクセンチュアや日立、CTCなど、最上流のSEをやっていると思われる
Twitterアカウントをヲチしてみるとよい。私はそもそもそれらの中の人なのでよく分かるが、そういった上流SIerで管理職とかになるような人は
本気でそう思っている。またそういう人は「俺も本当は技術が好きなんだよ。でもビジネスってものはね云々」っていつも語っていて、
好きだといつも主張している技術の話はほとんどしてない。Twitterではビジネスがどうとか開発プロセスがどうとかばっかりなんだが、
本当に技術が好きなのかは謎。
努力不足でSESにしか行けなかったというツイートが話題になっていますね。
件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。
業界に入って十数年、メガベンチャーで働きGAFAの関連企業から1X00万円のオファーを貰うくらいのスキルと経験はある。もちろん開発のスペシャリストとして。
新宿の雑居ビルにオフィスのある中国人が経営するSES会社からキャリアをスタート。最初の会社は雇用保険も払ってなかった。
新卒または第二新卒、文系または数学が苦手、プログラミング未経験者でスクールやサロンに入ってプログラミングを身につけて働きたいと思ってるひと。
理系やプログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いからスクリプトで業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。
ふたこぶラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)
要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。
学び始めてすぐに判断を下す必要はないですが、スクールのカリキュラムを終える頃には周りとの成長スピードの差で自然に理解できるかと思います。
しかし、もし適正がなかったとしても悲観するのはまだ早いです。
プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjM、UIデザイナー、UXデザイナー、カスタマーサクセス、営業、採用、などなどいろいろあります。
なにはともあれ3割くらいは可能性があって外れても選択肢があるんですからポジティブに受け止めましょう。
エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。
さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。
あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？
ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。
そろそろ本題に近づいてきました。
ここまでの話を踏まえてどうするべきだと思いますか？
特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。
あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。
ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。
初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。
ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。
デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ (https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。
様々な点で両者は異なります。
真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。
なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。
また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。
デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。
そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。
翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。
ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？
ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。
現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。
会社の昔の大黒柱だった部門。近年のビジネスの規模の割に妙にリッチに開発をしていて、決算報告を見る感じではまあ悪くはないんだけど良くもないよね、みたいな感じだったけれど。
流石に上層部も見過ごすことができなかったのか、部門を縮小していく方向に舵を切った。
そうするともちろん人が余る。この国では簡単に首は切れない。
そこそこ利益を上げていて、でも忙しく、とにかく人手が欲しいと言った自分の部署に人が上記部門の回されてきた。
部門が縮小されるからと行って、第一線で働いている人を動かせるわけがないので、管理職のおっさんが回ってくる。
「私は○○と○○と〇〇の開発に携わってきました。」なるほど。よくわからん。
ああそうだ。明らかにおかしい。計画がまともに機能していないし何もかもハチャメチャだ。
評価用実験機を大急ぎで作って顧客に渡して、「ここらへんの性能データないの？」と言われたら1ヶ月でデータ取りしてその結果を営業に教え込む必要がある。
それで顧客から「ふーん、いいじゃん」の声をもらって受注につなげるのが大切なんだ。
開発プロセスの遵守は大切なのは重々分かるんだけれど、その余裕がない。
正直面倒くさいし、それを落とし込める改革はやりたいやつがやってくれ。
思いつきで考えた設計と2週間で作った実験系、そのデータが予想以上のパフォーマンスを見せたときの楽しさはたまらんぜフハハ。
実験室に案内すると5Sの徹底などを説かれる。まあわかる。でもギリギリ遵守してるだろ。
あと、実験系の検出器の精度について指摘される。
さすが長年開発に携わってきただけあって分かるのだろう。そうだ。そこはヤバげだ。2年前に気づいていた。
しかし要求を満たす高グレードなものは500万円くらいする。予算を通すのが結構キツい。
予算取りに時間をとるくらいなら今の実験系の精度でゴリ押しして保証できる性能を出したほうが楽だ。
その上検出器そのもののメーカー公称のスペックも疑ってかからないといけない。検出器の評価には時間がかかるんだ。そんな余裕ないぞ。
よくある駄目なパターン。
おっさんも自分の立場とこちらの現状が十分わかっているのだろう。
情報処理技術者試験なんて、実務、特にマネジメントなんかやっていると役に立つことが多いです。
まず前提の捉え方がちょっと違いますが、「情報処理技術者試験」とは国家試験でありながら、医師国家試験や危険物取扱者試験などの国家試験とは異なり、
別に持ってなくても実務に従事できるって言う不思議な国家試験であること。
なので、別にこの試験がなくても、情報処理技術者としての仕事にまったく支障はないです。
情報処理技術者試験は、ちゃんと情報処理のこと勉強してますよ！ある程度の知識は修めてますよ！って言うためのものでしょう。
名刺に資格もってるよマーク載せてIT系なら任せてよアピールをするためのものでしょう。
またこの資格を持っていることで、ちゃんと勉強している人間なのか、その指標にもなるのでマネジメントの一助になるです。
ご指摘の通り、暗記問題ばかりで実際の業務には何ら役に立たないように思えますが、
一方で実務以外のコンピュータ技術の本質的な設問であったり、法務関係の問題もあったりして、
マネジメントの他、教える立場になったときや、企画開発なんかで広く浅い知識が必要になったときには役に立つかと。
そもそも逆なんですよね。この問題を解けたら良い設計ができる、とか、優れたコーディングができるんじゃなくて、
まともな設計知識を持っていたら、このくらいの問題は知っていますよね？ってのが技術者試験の一面です。
※あと、「コードが書けるわけでも、良い設計ができるわけでもありません。」って否定をするなら、せめて応用のほうから持ってきてくれないと･･･ｗ
ちなみに、UMLの基本や、開発手法、MPEGなどの標準規格の名称なんかを覚えるのは、設計やコーディングにおいて「超大事」なことです。
そうした名称をもとにして開発を進めていくわけで、いちいち「要求分析から実装までの開発プロセスを繰り返しながら、
システムを構築していくソフトウェア開発手法」でやります！みたいな説明しなくても「今回はスパイラルでーす」って一言で終わるじゃないですか。
基本情報技術者試験レベルをメンバー全員が資格取得してくれていれば、「スパイラルでーす」で終われるってすばらしい。
合格率は基本情報技術者試験で３割弱、応用情報技術者試験で２割強となっています。
なので、一見難しそうに思えますが、非常に簡単です。覚えればいいんですから。
（そもそも基本情報なんて、非IT系会社勤務の方の合格率が、IT系会社勤務の方の合格率を超えているという･･･）
なのに合格率が低いのは、みんな真面目に勉強（暗記）していないからと思われます。
試験会場にいくと分かるのですが、まずスタート時点で１割強は机の空きがあります。とりあえず申し込んでいるだけなんでしょう。
会社によっては予算取ったから行って来いよ、みたいなところもあるのでしょう。
暗記試験で引っ掛け問題も少なく、広く浅い問題範囲なので、１～２か月真面目にやればだれでも取得できますよ。
ただ、さすがに150分座ってるだけで取れるような試験ではないことは確かです。
範囲は広いですし、勉強してなきゃ聞いたことがない言葉なんてザラです。
上記を言い換えれば、真面目にコツコツ勉強してくるやつアピールが出来ます。
合格率２割の国家試験を、通常業務をこなしながら取得してくるだと･･･！？化け物か！ みたいな
雰囲気でとらえてくれるおじさんは、まだまだいっぱいいますよ。
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。
なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。
https://www.fe-siken.com/s/kakomon/19_haru/q42.html
こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。
数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。
ひどい問題は挙げればキリがありません。
https://www.ap-siken.com/s/kakomon/22_haru/q44.html
図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそも、UMLなど別に技術者として知っておくべき知識でもありません。
https://www.fe-siken.com/s/kakomon/23_aki/q50.html
これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題。いかに、この試験がエンジニアリングやプロジェクト管理の本質と関係ないかがよく分かります。
極めつけはこれ。
https://www.fe-siken.com/s/kakomon/17_haru/q52.html
地方の公立中学校の定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字と語句の対応を覚えることが重要だと思っているのでしょうか。
つまり、ある種の発達障害ではない意識高い系ポエマーを認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。
そもそも、コンピュータやプロジェクトマネジメントの技術を、資格試験で勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。
若いエンジニアは「新しい技術・開発手法は優れている」というドグマを、なぜか頭から信じ込んでる場合が多いが、
ウォーターフォールだろうがアジャイルだろうが、ミスなく早く開発できればなんでも良いし、
ウォーターフォールモデルにチームが習熟しているなら、そっちの方が良いに決まってる。
アジャイル真理教の宣教師でもあるまいし、金貰ってる仕事なのだから、わざわざ今まで経験したことのない開発プロセスを試して危険を犯す必要がない
可能性としては
1.偉いさんがアジャイルアジャイルうるさいから、なんちゃってアジャイルモデルで適当にお茶濁しとけと思ってる
2.チーム全体にアジャイル開発の経験値がないので、失敗しないように今回のプロジェクトはウォーターフォールでやりつつ、
どっちかだろう
愚痴です。
ざっくりいうと、
という話です。詳しく書きすぎて身バレしそう。
私は、昨年とある小さい企業に入社し、入社後10ヶ月ほどで管理職となった。入社直後の配属先は5名前後の開発チームで、タイトルの「元リーダーの部下」とはそのときにチームリーダーを務めていた人物である。
入社先の会社自体は設立から10年程度経過しているが、当初は社長のツテなどで社員を雇っていたようで、開発チームにはいわゆるプログラマとして働く人のみで開発のマネジメント経験のある人はひとりもいなかった。ちょうど数年前から事業をちゃんと収益化しようとしているところだったが、これまで社長自身の旗振りによって動かしていた開発チームも、社長が多忙となり直接見られないことから一応リーダーとして立っていたようだった。
私は前職ではそれなりの規模の企業で、受託案件のプロマネを数年間やっていたこともあり、今の会社の面接の際はそのマネジメント経験を非常に買ってもらえた。そういう経緯もあり内定をもらい入社したので、最初はやってる業務内容を教えてもらいながらこちらもチーム運営をヒアリングしたりして状況把握につとめた。初っ端、タスク管理方法について聞いてRedmineを見たところ更新されているチケットがほとんどなく、営業チームからの要求がたまに書かれるだけのものになっていて「おぁ・・・」となったが、そういうところから運用ルールを決めて周知して回して…と地道に進めてきた。
2〜3ヶ月もすると、開発チームのメンバーとしてマネジメントの会議に私が参加するようになり、他部署との依頼や業務調整など、すべて私を通してやってくれるようになった（それまでは、営業部門の人が開発メンバーに個別に聞きに行く、という形で情報共有もされていなかった）。
それでも、名目上、チームリーダーとしては彼を立ててはいた。もはや彼のリーダーとしての仕事は進捗確認するためにチームメンバーを招集すること（進捗確認の自体は私がやっていた）と、全社会議で開発チームの進捗をみんなに報告することだけであったが、私が管理職になったことを機にその仕事も私が引き取り、他のプログラマたちと全く同じ立ち位置になった。
話は変わってチーム全体のことだが、開発チームにはさまざまな勤務形態で働く人がいることと、私の前職ではデスマーチ的な働き方が横行していた反省から、チームメンバーには極力割り込み業務をさせない・会社全体の状況はできるだけこまめに共有する・定期的にメンバー個別に話を聞ける時間を作る、などメンバーが安心して働ける環境づくりを心がけてきた。また、開発プロセスや品質についてそもそも知識がないメンバーもいたので、個人個人が能力の底上げができるよう、タスクの洗い出し方から設計書の書き方、テスト項目の作り方など教えながら一緒にやってきた。実装やインフラ設定などは逆に私よりも知識・能力がある人たちだったので、道筋を作ってあげることでこれまで「それなりに動く程度に作って終わり、バグが報告されたら手が空いたときにやる（結局できない）」みたいな感じだったのが徐々に改善されてきたと感じている。
ただ、彼だけは例外だった。最初の数ヶ月で、彼自身にハンドリングさせる仕事を振ってはいけないと分かってはいたため、彼にアサインする仕事は必ず私が最初に介入し、進め方・タスクの洗い出し方・スケジュール…とすべて打ち合わせで明確にし「いつまでに何をする」をきっちり決めて（スケジュールは彼の見積りにさらにバッファを山積みして）あとはやるだけ…な状態に持っていく。また、彼は誰かに頼まれごとをするとそちらが最優先になる自分のタスク管理をできない人なので、一切他のタスクを振らないようにしていた。それでも期日になると、成果物が出てこないか、終わってないものが出てくるか、そもそもタスクがなかったことになっている。終わったと本人が言っていても、当初やることに合意したはずのものが実装されていなかったり、適当な実装だったり。リリースすると客から指摘が来て、それの対処にまた数週間かけるのである（次の開発を開始できないためまた遅延する）。
そんな状態なので、開発工程ど真ん中でも頻繁に介入して立て直しをする必要が出てくる。立て直しをするときにはできるだけ彼の心を折らないよう、「このまま進めても遅延するリスクが大きいので」と伝え、振り返りの体で「ここでもう少し見積りのための調査を詳細にやっておくべきだったね」「次はこうやってみよう」と立て直しのために必要な作業を一部実際に自分でやってみせ、他の部分を明日いっぱいぐらいで作ってね、作ったら一緒にレビューしようね、という風に毎回新人教育のような気分になりながら進めるのである。当然私自身が持っている仕事に支障が出るので週末にやるのである。
長くなってしまったが、ここまでは日常の業務の光景であり、組織作りや案件が炎上しないための立ち回りなどは私の仕事だと認識しているので努めて冷静に対処しているつもりである。怒鳴ったことは一度もない。
発言が、仕事を茶化すようなものだったり、自分のタスクを他人事のように言ったりする。そしてそれは状況がシリアス（彼の能力不足に起因する遅延が発生している状況など）になっても変わらないため、非常に癪に障る。
これまでのことをすべて列挙するときりがないが、直近に行った、彼が進めているプロジェクトの仕切り直しのための打ち合わせ（私と彼の一対一）での発言が特にひどく、タイトルの通り怒りが収まらない状態が続いている。
よくブチ切れずに済んだなと思いながら、このように調子に乗ったままだと彼は負債の再生産を繰り返して会社に害為す存在になることがわかっているため、きっちり〆ておく必要があるのかなとも思う。反射的にそういうアクションをとれない自分が恨めしい。とはいえ、過去に就業規則を全然守らないことに対して説教したときもヘラヘラしてたし、金銭的な処分をする権限はないし、自分には彼をどうにかするのは荷が重いな…と迷いに迷っている週末。
人手不足の折、やるべきタスクはたくさんある中で、彼の手もまた人手だと思いながらやってきたけど、私の負担だけが増えてモノができないなら思い切って切る判断もあるのかなと思う。結論が出てこないけど、直近指示したことが予定通り出てこないならまたそれに対して立て直しをしないといけないと思うと心が重い。彼を担当から外すにしても今他に空いている人はいないし、彼にさせる仕事も思いつかない。担当から外したら外したで「身軽になった〜」と喜ぶのだろうか。それを想像してしまいまた怒りがこみ上げ無限ループに陥るのやめたい。
某自動車部品会社で8年ほど働きましたが、思うところあって少し前に転職しました。
なお、基本スペック
これらの事は、どんな会社でも規模の大小によらず多かれ少なかれ共通する点でもありますし、私の恨みつらみを知っても楽しくないと思うので(あるいは、本ポストをご覧いただいている方が求めているのはまさにそういう心の闇なのかもしれませんが)、具体的には書かないでおこうと思います。ここではあまり話題にならない自動車業界の雰囲気を自分が見てきた範囲で書こうと思います。
世間一般でも言われていることですが、ここ数年で自動車業界に他業界（主に、家電、IT）から転職する人が増えましたし、業界内でも転職する人も増えたように思います。極端な例ですが、全員が転職して部署がなくなったという例や、部署のほぼすべてのメンバーが他社からの転職者という例が知る限りでも複数ありました。
車がハッキングされたり、NVIDIAが自動車向けの半導体をリリースしたり、Teslaが電気自動車を販売したり、自動車メーカー各社のプラットフォーム戦略が軌道に乗る等、技術面、ビジネス面での変化があり、従来のビジネス手法や開発手法が通用しなくなったのも世間の評判通りです。一方、価格競争や、納期対応、カーメーカーを頂点にした厳しいサプライチェーンマネージメント等はあまり変化がないように思います。また、価格競争のために、製品原価を1円～10円下げるために数千万円～数億円の開発費・設備投資費を費やすという取り組みや、車種・グレード固有の個別最適化の設計・開発等、自動車業界らしい取り組みもまだ多く残っています。
まずは、実際のところは下っ端～中堅目線でどう変わったかというところを書きたいと思います。
いろんな人材が自動車業界に入ってくるようになり、いい意味で多様性が生まれたように思います。従来の自動車業界は、業界内で少々転職する人がいるぐらいで他業界からの転職者は多くはなかったらしいです。
逆に、新しい流れを受け入れることができず、取り残されている人も一定数います。知る限りでは同業他社も同じ状況のようです。そのため、せっかく生まれた多様性をうまく活かせていないようにも感じていました。ただ、これは現在の自動車業界で働き盛りの40代の方々が若手のころは自動車業界は画一的で発展性がなく、斜陽産業だといわれていたこともあり、解消にはしばらく時間がかかると思います。それに、どこの業界・会社にも新しいトレンドになじめない方はいらっしゃるようですので、ある程度は致し方ないかと思います。足の引っ張り合いの末に死屍累々のあり様の携帯端末ビジネスよりはよっぽどましかと。
従来の自動車部品メーカーの開発は自動車メーカーが主な関係先でしたが、ITに近い技術が利用されるようになり、開発が自社のみで完結しなくなり、業界外や社外とのかかわりも増えましす。そのため、僕が業界に入った時に蔓延していたお客様の言うことは絶対という雰囲気がいくらか軽くなったように思います。また、個人の業務では、ソフトウェアベンダー、コンサルティング会社、欧米のベンチャー企業とかかわることが多かったです。ただ、家電業界が斜陽になった当時、景気がいい自動車業界に参入してきた会社が多数ありましたが、ビジネスモデルや開発手法のあまりの違いや、既存ビジネスへの参入の難しさから、多くの企業が撤退もしくは苦戦しているというのも現状です。
他業界から転職されてきた方に関して言及すると、仕事の進め方や、客先とのかかわり方が他業界とは大きく異なることもあり、年齢・経験によらず苦労されている方や、心が折れてしまった（隠語）方も多数いらっしゃいます。
ここからは、国内自動車業界の本当によくないと思う点なのですが、新しいブームや技術が発生した時に、社内の中堅以上の方が、否定的な見方をしてしまう雰囲気がやはり業界全体に漂っている点があると思います。えてしてそういった考え方や雰囲気は伝染するもので、新しく業界に入った方もそういった考え方に染まってしまったり、現実を嘆いて業界外に転職していってしまうこともあるようです。一方で、家電業界や携帯端末業界の衰退・ビジネスの変化を目の当たりにして、新しいトレンドを取り入れる必要があると考える人も年々増えているように思います。
やや突っ込んだ話になりますが、最近は新しいトレンドをCASE(Connected/Autonomous/Sharing/Electromobilityの略)とまとめて呼ぶことが多いですが、初めに大きな変化を国内の自動車業界にもたらしたのはElectromobilityであったように思います。2010年代から、自動車の電動化により、すべての車がEVもしくはHVに置き換わり、エンジンやトランスミッションの巨大市場が失われ、モーターやバッテリー、充電コンバーターの巨大市場が生まれるといわれていました。ただ、EVの航続距離を延ばす根本的な電池の容量問題への解決策が見えないことや、充電スタンド等のインフラ整備が進まないこと、ハイブリットのみならず、グリーンディーゼルやダウンサイジングターボ等により、EVでなくても燃費改善策はあること等の背景もあり、当初思われていたほどEV関係の市場が伸びないということが2015年ぐらいから明らかになってきました。逆に、自動ブレーキに代表される、既存のACCや車線逸脱警告、周辺監視等の技術の延長に位置するマーケットは大きく伸びたというのが実際のところです。
そのため、当時EV関連事業に巨額の投資を行った方々の間では新しいトレンドは絵に描いた餅という固定概念が植え付けられおり、なかなか手が出しにくい状況になってしまったという点も、新しいトレンドをなかなか取り入れれない原因になっているように感じられます。また、上に書いたことを否定するような文章になってしまいますが、多種多様な製品があるため、大半の製品では新しいトレンドとは無関係に従来と変わらない方法・技術を用いて開発を進めることも多く、変化は全体から見ればまだまだ小さいため、多くの企業がトレンドに乗り遅れていることに対する直接的なデメリットを受けていないという状況のようです。
次に、働いてみてワークライフバランス等はどうだったかという話をしたいと思います。研究・開発職のワークライフバランスは言うほどは悪くないと思いますが、市場不具合対応時や、納期対応時はかなりの残業が必要になることは間違いないと思います。特に、製品リリースの直前には、ストレスや睡眠不足から心身の健康を崩す方も度々いらっしゃるようです。営業や工場の製造部門は納期遅れが業績等に直結してくることもあり、工場とお客さんとの往復や、残業対応が迫られていることが多いようです。さらには、中堅以上の層に暴力的な人も多く、部署によっては罵声や怒号が飛び交うという話も実際にあります。自身も、初対面の人に打ち合わせ開始5秒で怒鳴られたことがありますし、そのまま数十分にわたり罵声を浴びせられたことも幾度となくあります。ただ、最近は世間の風当りがきついことや、容易に転職が可能となったこともあり、そういった雰囲気もここ数年で多少はましになったかなと感じます。
人材育成に関しては、かつては人材の流動性が非常に低い業界であったため、技術や方法は先輩や上司から業務を通じて学ぶ、既存の技術を知っていて当たり前という雰囲気もかなり蔓延しています。そのため、個別の技術に対する系統だった教育プログラムが用意されていなかいという問題もあります。新しく業界に入った方に”そんなことも知らないのか？”という発言をしたり、それを理由に攻撃して精神的に追い詰めてしまう人もかなりいます。何にせよ、全体的に人材育成が苦手な業界ではないかと思います。特に、組み込みソフトウェア関連技術に関しては、かつては客先の要求仕様にのっとってV字開発プロセスを通すことが開発のほぼ全てを占めていたこともあり、C言語の基礎(自動車業界のソフトウェア開発はナビ等の一部を除けばほぼすべてがC言語です)や組み込みソフトウェアの基礎に関する研修はなく、開発プロセスに関する研修ばかりという会社もかなりの数があるようです。そのため、基本が押さえられておらず、基礎設計が悪く、手戻り発生で開発工数が爆発、不具合を垂れ流すというコンボもごくまれに発生している様です。
ここ数年、自動車業界各社の業績が良かったこともあり、春闘のボーナス満額回答や、ベア、過去最高益等の景気のいいニュースが多かったですが、2018年下期から中国市場の減速等により各社が業績の下方修正をする等、景気にやや陰りが見えているのも事実だと思います。まだ、各担当レベルの仕事や、給料への影響はそれほどは感じられませんでしたが、このままの状況が続くと数年程度で何らかの影響が出てくるのではないかと思います。
一方、人材採用という側面では、根本的な人材不足解消の目途が立っておらず、多少の業績悪化があるとはいえ、しばらくは雇用が豊富にある状況は続くと思います。サブプライムショックのような世界的な不景気が発生すると、一旦は雇用が絞られる可能性がありそうですが、その後の景気回復に伴い、数年で回復すると思います。車は数年～15年程度で必ず買い替える消耗品であり、家電製品より高価ということもあり、景気が悪くても最低限の需要と市場が生まれ、景気が回復すると需要が回復する業界ですし、新興国の需要の伸びはこれからなので、中長期的に見れば伸びしろのある業界だと思います。ただ、外資系企業の国内市場進出が進んでいることや、業界内の買収・統合や事業移管が進んでいることもあり、会社によっては価格競争等に敗れ、売り上げが激減するリスクやリストラのリスクはありそうです。また、まだ例は少ないですが、国内で救済的買収を行う会社が見当たらず、外資系ファンドの傘下に入った会社も出始めています。ですので、転職先の会社選びが非常に重要になってくるのは間違いなさそうです。
他の業界の方と一緒に仕事したことはあるものの、他業界で仕事をしたことがないので、何とも言えないですが、自身の業界全体の未来を不安視されている方が業界をまたいで転職してくるのは十分にありだと思います。また、米中摩擦の今後の動向次第では、自動車業界全体の業績に悪影響を与える影響もありますので、30代で転職を迷っている方は興味があればこのタイミングで自動車業界にトライするのもいいかもしれません。うまくいかなければ、他の業界に転職すればいいと思います。一度は自動車業界に来たものの別の業界に転職していった方や、別業界からの出戻りもあるようです。
不条理で世知辛い業界ではありますが、個人的に携わったテーマは楽しく取り組めたので、自動車業界で働いたのは間違いではなかったかなと思います。緩やかにですが変わっていく業界ではありますので、近い将来に今よりは働きやすい業界になると思います。今後の伸びしろもあり、まだまだ楽しむ余地がありそうですので、転職先も自動車業界にしました。ただ、国内の世界的某大手自動車部品メーカーも受けましたが、面接をしている最中にここも結局は同じか………と感じてしまったこともありましたので、外資系の企業にしました。
とにかくいろんな意味でやばいIT系の開発会社に入ったからぜひ話を聞いてほしい。
自分は21歳で2社経験してるけど入った会社全部がやばい会社（いわゆるブラック？）だったりでいろいろ苦労したから
就活生や転職活動してる人の参考になればと思ってこの記事を書いてる。
１、「うちは今度から完全週休2日制に完全に切り替える」と言われてたった3か月で完全週休2日制が撤廃になった。地獄
２、自分以外の開発メンバーのずさんさがやばい。ゴールが見えない。地獄。
３、話合いが全くできないので何一つことが決まらず進まない。以下地獄
わかりづらかったらマジゴメン
入社した当初は週休2日制で土曜出勤とかもあったんだけど、つい最近経営者から「よし！うちも完全週休2日制に切り替える！」
「法律上、うちは休みが多すぎるって判明したから調整した結果、完全週休2日制は今月いっぱいでなしね」
とかよくわからんこと言い始めて（そもそも法律で休みの上限とか聞いたことないけど）たった3か月で撤廃になった。
ちゃんと休日関係は確認したほうがいい、完全週休2日制とか謳っておきながら箱の中身を見てみたら嘘だった
なんてこともざらにあるから気を付けてほしい。
あと転職活動何度かしててわかったけどに「休日数1〇〇日以上！！」とか見出しで謳ってるような会社も基本ろくでもない会社が多いって感じたから参考程度に
覚えておいてほしい。
正直今回一番書きたかったのはこの項目。とにかくここが一番やばい。
基本的に開発プロセスって（例外とかは抜きにした基本的な順序）
１、要件定義 → ２、外部設計 → ３、内部設計 → ４、開発開始 → あとはテストやら公開準備やら……
１、開発開始 → ２、要件定義 |（ここでクライアントとか経営者にものすごい怒られる）| → ３、外部設計 → ４、内部設計 |（ここでクライアントとか経営者にものすごい怒られる）| ３、外部設計 ……
これが永遠と繰り返されるんだ。マジで。書いてる自分でも訳がわからなくなっていく、つまりゴールが一生ないってこと。
設計書作らない、新しく入った人に引き継ぎしない、仕様書すら作らない。そんな会社です。
それで今どきの開発会社で手作業でバージョン管理してるんだぜ？やばくね？
ようは古いファイル（上書きが必要なファイル）は「ファイル名_20180305(今日の日付)」とかで管理してるんだぜ？地獄じゃね？
だってさ自分が修正したファイルがさ自分が知らないうちにその開発担当者に上書き保存されて消えてるんだぜ？
そのくせ「治ってないじゃないか！仕事怠慢だ！」とか言われるんだよ。俺にどうしろっちゅうねん
そこでさ、俺さすがにこのままだとやべえなと思って開発担当管理者に提案したんだよ
そしたらさなぜか知らないんだけど２，３時間くらい「Gitは難しくて～」とか「導入するとコストが～」とか
クソみたいな言い訳並べて導入したくないみたいなんだよね。だから上司の上司に直談判して導入を強制してもらったのよ。
なんだけども、
master develop feature …… 大体多くても3~5とかに分けるよ普通
でもさうち
「master」一本なんだよね。商業でやってる会社がmaster一本て聞いてことないよ。
そこですかさずまた俺は提案したんだよね
だってもうお前のせいでリリース3回延期してるんやぞ（この際にもいろいろあったけどもっと長くなるので割愛）
しかもお前俺以外の開発者全員ソースに問題が残ってる状態でなんにも確認せずに「できた！」とか言って
コミット&プッシュしてくれるんやぞ？生き地獄だぞこっちにとっちゃ。
んで一応それがだめならと思ってせめてこれは通ってくれと願いながら
「Pull Request使いましょう？今のままよりマシではないかと」
って提案したら
「面倒くさい」
で一蹴りされた。俺、ここでこの会社辞めるの決意したんだよね。
今まで他担当者のタスク管理とかやってあげたり来た指示書の具体的な内容の確認とか全部やってたの自分なんだけど
管理者じゃないのに。それに他に任されてたプロジェクトだってあるのにこっちがあまりにもやばいからっていう理由で
助太刀で来たのに。悲しくなったよ……。
今この会社には今年の3月いっぱいで退職予定なんだけど、次の会社（もう内定はもらってる）に面接に行った時つい辛すぎてこのこと愚痴ったら
「数年に1件見るレベルの酷さ、頑張ったね……」って言われたよね。「良かった自分の感覚間違えてなかったんやな……」って
ちょっと泣いた。
とまあ、これが現実。ちなみに地方の会社だからね。地方の開発会社はこんなレベルだと思ってもらっていいよ。
そもそもなんやねん実績じゃなくて「実務経験3年以上」っていう基準なんの基準やねん。（これは今回関係ないけどこれも愚痴）
３、話合いが全くできないので何一つことが決まらず進まない。以下地獄
基本的に話し合いが成立するのって問題を解決するために、立場・考えなどを述べ合うことだよね。
うんまあこれも普通ならただの話し合いなんだけどさ。
Ａさん「今こういう現状で問題が続いているのでこのようなルールを作るべきではないでしょうか？」
Ｂさん「であれば自分の意見はこうでこういうルールだったらいいのではないかな？」
これであれば互いの意見いいところを取って互いが納得したルールや改善案が出せる可能性は高い
「お前の意見はここがダメだ、ここもだめだ。こうだから絶対ダメ」
否定しかしないんだよね。もうこの時点で同じ土俵に立ってないわけ話し合いとして。
んでそういうやつに
って聞くとしどろもどろして何もかえってこないのよ意見がどういう思考回路しとんねん。
基本的に否定する暇があったら改善案・意見述べてくれねえかなって思うのよ。まあ人によってはこれが意見だ！っていう人もいるけど
んでこれがずっと入って1年間続いたわけそこで俺気づいたんだ。
他の会社はどうかしらないけど大体の大人ってこんな感じだよねテレビに出てる批評家とか辛口専門家（笑）とか。
何が言いたいかっていうと
「いくら頑張って改善を試みようとしても無能な上司や頭のおかしいやつに蹴られたらおしまい」
ってこと。正直者が馬鹿を見るっていうけど本当、当たってると思う。
自分の若干21歳でもう転職2回もしてるから世間体で見ればろくでもないやつって思われるかもしれないけど、
辛い時期もあったけど案外どうにでもなったし頼れるところはいっぱいあるから頼れるものは頼ったほうがいいよ、
親とか友達とか、行政だっていう手もある（求職者支援訓練で検索）。
ネットとかリアルの友人がクソみたいな会社に振りまわれてるの見ると自分まで辛くなるし力になりたいって思うけど
なかなかそういう機会もなくてあれかなと思って今回この記事を書いた。
この情報がデマだ！って言われたらそりゃ所詮ネットの情報だし信じるか信じないかは……になるけど
でも確かに自分が経験した体験談だからここに書いてるのは承知してほしい。
これ3年間社会人やってたどり着いた心理。そりゃ責任感は捨てちゃだめだけどさ
自分も学生の頃「社会に出たらもっとしっかりしなきゃ……」って思ってたけど
今になっては「真面目に生きるのもアホらしい」って思うくらい。
本当好きなこといっぱいやったほうがいいよ。
正直求人情報よりもネットの情報がまだ正確だったりする（某掲示板とか）
かといってネットの情報鵜呑みにしすぎるのも危ないから気を付けてね。
さっき上にも書いた通り真面目に生きるだけ損するから嫌だったら辞めてもあながちどうとでもなるから安心してほしい。
上京した人とかは大変かもしれないけどそれこそ親頼ったりとかしてもいいんだし逃げ道はあるから気にしないほうがいい。
自分も最初の会社は3か月ちょっとでパワハラ受けて精神病院行きになってやめたけど今は多少ぴんぴんしてる。
転職したいな～って思ったら迷わずハロワに行くなり、転職エージェントやら就職支援サービスに登録しておけば企業からスカウト
来たりするしいい求人来たら面談してみるとかでもいいし。逃げ道作るのもいいと思う。
あともし転職するなら多少忙しいだろうけど在職中にした方がいいよ。収入が絶え間なくなるからおすすめてかそうして。
っとめちゃくちゃ長くなったけど言いたいことは言えたのでよし、
現状こんなＩＴ系の開発会社謳っていながらこんなやべえ会社あるんだよっていうのと
自分が苦しんだからあとの世代には気楽に生きてほしいってことを伝えたかったんだよね。
まあこの記事に対する反応とかは
「就活はこうすると良い！」とかアドバイスがいっぱい来ると嬉しいな。
それじゃまたどこかで
幸い、今朝のJアラートがならない地域に住んでいたので、やはり当事者意識は弱めなのだが、だからこそ、第三者的に見て、色々どうかな？という面も多々あった。
要するに、「地下に逃げろ」「コンクリートの建物の中に逃げろ」と言われてもそんなところなどない、みたいな話があり、全くもって笑い話にならないのだった。
地域ごとに出るメッセージを適切に変えれば良いだけだと思うのだが。
ケータイの基地局の判定するなどして、そこから割り出すとか出来ないんだろうか？
「最初から上手くやれ」とは言わないが、少しずつシステムを改善して欲しい感じはある。
で、ふと思ったのは、どうも、日本のプロダクトは「作っておしまい」みたいな部分が大きい気もする。
もちろん、「改善」の語源から考えると、日本はその元祖的な部分もあるのだろうが、日本の「改善」は、例えば、開発プロセスなど供給者内の製造方法論みたいな話が多い。
それに対し、例えば、顧客体験としてのはてブのバージョンアップは「改善」というよりも、「刷新」的な意味合いを感じてしまう。
逆に、アメリカ製のプロダクト、例えば、YouTubeは動画のサムネイルにマウスカーソルを合わせると動画が動いたり、動画の長さがサムネイルに表示されりするなどして、顧客体験の地道な改善をしている印象がある。
2chもアメリカの業者に乗っ取られてから、専用ではない通常のブラウザで見てみるとかなり使い勝手が改善されている。
もちろん、日米の違いを一概にそう言えるか？と言ったら、違うと思うが（フラットデザインとか）、意識の強弱の差はハッキリと見て取れると思う。
手に職を付けたい理由はお金？技術をもって自由に稼ぐハッカー？
まず、前者なら大手SIerが鉄板です。なぜなら、給与が圧倒的に高いからです。中小と比較すると同年代で100～200の差は出ます。あなたが結婚したころにはその重みが分かることでしょう。
後者なら、残念ながらもう手遅れです。そういう人は小学生くらいから自ずとプログラミングをして、高校生くらいで何らかのコンテストに出ているような人かと。あなたくらいの年齢では、もう起業しているか、企業からの取り合いになっていることでしょう。今、それをしていないということは、あなたはそういう人ではないということです。
大手SIの良いところは以下のとおりです。聞こえがいいとかそういうのはどうでもいいことです。
・企業システムのある程度精緻に作られたソースや設計書を見れる
「技術」とは何もコーディングだけではないことを知るいい機会になります。
・転職に困らない
・バカな管理者が比較的少ない（中小はその比ではないと思われる）
手に職と言いますが、それを持ち得て必要とされるような能力の持ち主は非常に稀有です。
今からそれを目指すということはそれなりの覚悟と努力する才能が無ければ難しいかと。
システム開発全般について、体系的に教えられる人を外部の講師含めて、ほとんど見たことがありません。
自主的に学ぶ場合は上流から下流工程までを見渡せる大手SIがいいです。
新卒カードを中小企業に切ったら、次は中小企業カードかスキルのある人カードしかないです。
大企業に切れば、新卒に準じる大企業カードか、大企業でスキルがある人という強いカードになりえます。
良く悩んでください。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが，この記事もその反論記事・支援記事も含めて，「ウォーターフォールを採用する（せざるを得ない）理由」について書いてあるものはあっても，「ウォーターフォールのメリット」について書かれた記事が見当たらないのには驚く。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
まずこの記事。「メリットはない」って言ってるんだから，書いてないのは当然なのかもしれないが，アジャイルのメリット＝なぜアジャイルがいいのか，についても書かれていない。これではFUDといわれてもしかたない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
「日本でアジャイルが流行らない理由」≒日本でウォーターフォールが採用される（消極的な）理由は書いてあるが，ウォーターフォールのメリットについては書かれていない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
タイトルから期待して読んだが，「ウォーターフォールの課題と言われてるものは，実は解決されてるよ」という記述が大半を占める。
最後の一節は「アジャイルの問題」として，「変化に人間がついていけない」点が挙げられていて，その裏返しでウォーターフォールがいいよ，ってことを言いたいのかもしれない。しかし，アジャイルは「変化に機敏に対処する」ことが眼目であって，何でもかんでも変化させなければいけない，というものではないので，指摘自体が的外れに見える。
http://arclamp.hatenablog.com/entry/2016/06/23/172941
冒頭，
とあって，メリットを語ってくれるかな，と期待させるが，結局「スコープが確定しているならウォーターフォールでいい」，という消極的な採用理由が述べられるだけで，メリット＝積極的な採用理由は述べられていないように見える。
それを語る前に，まずウォーターフォールを定義しておく。現在日本でウォーターフォールとして認識されているプロセスは，国防総省式の「戻りの線」なしのものである。即ち，確定した要件なり仕様なり（以下まとめて「スコープ」と呼ぶ）は変更しない。「ウォーターフォール」という名前自体が，この一方向性に由来している。従って，ウォーターフォールの定義としては，「（フェーズゲートを超える際に）確定したスコープは変更しないプロセス」で良いだろう。
この定義に沿わないプロセスは，「偽ウォーターフォール」であり，以下に述べるウォーターフォールのメリットを受けることはできない。メリットを享受できないだけでなく，この種の「偽ウォーターフォール」は（「偽アジャイル」同様）大きな害悪を撒き散らす。
さて，「確定した要件・仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが，手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者／受注者含め何がうれしいのか。
答は
である。
すごく当たり前のことなのだが，これが書かれている記事が見当たらない。
そしてウォーターフォールのメリットはこれだけで，それ以外にはメリットと言えるものはおそらく存在しない。
ここで，前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。
よく見るとこれらは，いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく，本来の意味での「品質」，即ち利用者の役に立つか，使いやすいか，ということまで含むものである。スクラム（アジャイル）を知る人であれば，「トレードオフ・スライダー」の「品質」に相当するものだと理解してもらえればよい。
そうすると，前節のウォーターフォールのメリットは，以下のように言い換えることが可能である。
「ウォーターフォールのメリットは＜品質を固定することで＞コストと納期がぶれるリスクを小さくできる点にある」
これで問題が明らかになった。要するにウォーターフォールは，コストと納期のために品質を二の次にするプロセスなのである。
その結果，これまでどんなことが起きてきたか。
開発の途中で，要件や仕様に問題が見つかったとしても，あくまでウォーターフォールの定義に殉じると，出来上がるのは「使いにくい」「使われない」システムである。
「事業会社をIT会社に転生させることが、これからのSIerのミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に，その実例らしきものがでてくる。
これを行った瞬間から，ウォーターフォールはその（ほぼ）唯一のメリットを失い，混沌が始まる。
最も多いパターンは，発注者側が（もはやスコープ＝品質を固定するという前提が失われているにも関わらず）納期とコストの確定というメリットの享受を譲らず，プロジェクトがデスマーチ化する，というものであろう。あるいは，コストは譲るが納期は譲らない，というパターンの方が多いかもしれないが，いずれにせよデスマーチ化につながりやすいことは間違いない。
そしてこの副作用として何が起きたかというと，受注者側がそれを見越して納期とコストにバッファを積むようになった。当然それは見積もりの不透明感につながり，発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。
スコープの変更の必要が生じたら，どちらに転んでもいい結果は得られない。となると，ウォーターフォールがうまくいくのは，「スコープが明白で，変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので，そのような案件がどの程度あるかはわからないが，直感的には「ほとんどない」のではないかと思う。なぜなら，そこまでスコープが明白であれば，今はパッケージやSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。
もう一つの可能性としては，スコープが変更不要になるまで，とにかく事前の準備と調査を徹底的に行う，というパターンもありうる。しかし，これは「準備と調査」の過程で事実上いろいろ試作することになる（そうしないと変更のリスクが消せない）ので，もはや作業プロセスの大半が実はウォーターフォールではない，ということになるだろう。
ではアジャイルのプロセスを導入すれば，これらの問題はすべて解決するか，というとそういう話ではない。ウォーターフォールにメリットが（ほとんど）ないことと，アジャイルが有効であることとは，独立な議論である。
そもそも「アジャイル」というのは考え方であってプロセスではない。だから，考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって，害悪を撒き散らすことが多い。
アジャイルの考え方は，主に以下の2点でウォーターフォールと大きく異なる。
1. スコープの変化がありうることを前提としている
2. スコープ＝品質＝役に立つこと（＝使えないものを作らないこと）が最優先であり，そのためにコストや納期が変化を（ある程度）受け入れる
この考え方こそアジャイルの本質であって，CI/CDやDevOpsなどは，変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし，CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。
また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために，スコープはできるだけ確定する努力をする，というのはアジャイルでも変わらない。変えるべき時は変える，という点が違うだけだ。なんでも後で決めればいい／変えてもいい，というのは「偽アジャイル」であって，害悪でしかない。
もちろんこれがあれば何もかもが解決する，という類のものでもない。上述の2点があるだけで（少なくとも今のたいていの開発案件において）ウォーターフォールよりマシになりうるとは思われるが，別の問題（例：納期やコストの変化をどう扱うかという問題）も，同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり，これが「納期やコストの変化」と絶望的に相性が悪い。
もっとも，今の「ウォーターフォール」によるソフトウェア開発が，請負契約の成立条件である「契約時にスコープを確定（し，変更しない）」を厳密に守っているわけでもない以上，これだけを理由にアジャイルを否定するのはどうかとも思う。
契約については，IPA等でも取り組みがあるようだが，いずれにせよ契約を行うのは発注者と受注者であり，受注者側だけでどうこうできる問題でもないので，発注者側の意識の変化を期待するしかないかもしれない。
夢のあるシステムに関わりたい。
いわゆるプログラマをしているが「屑システム」にかかわりたくない。
「屑システム」とは以下だと思ってる。
なお、一応言っておくと、私がかかわっているシステムすべてが以下に当てはまるとは言ってない。
自分が開発にかかわってるが、開発が進んでも自分の利益にならない。他人の懐具合がよくなるだけ。
安月給はもらってるから、それで満足しろということになるわけだが。
その安月給は当然あがることはない。私から見れば立派な「屑システム」だ。
枯れた技術だけが使われ、そのシステムにかかわったことが何の宣伝にもならない。
例えばいまさらsyslogが使えます、とかsnmpが分かります、とか意味なす。
細かいとNoSQLとかクライアントサイドJavascriptとか。
次につながるようなシステム開発がしたい。そういう意味で「屑システム」
「システム」とは、プログラムそのものだけを意味するわけではない。
プログラムを開発する、開発プロセスそのものも「システム」である。
例えば、ある作業をやったら、諸事情で無駄になるようなのが「屑」な開発プロセスだ。
責任者に、リーダシップがないせいだ。あるいは、プログラマに何の権限もないと起こる。
人間だから、全部有効な作業というわけにはいかないが、そんなんばっかりだとやる気にならない。
なお、リーダーシップというのは権限とセットだ。責任とセットなわけではない。
プログラムを作る責任だけあっても、その責任を全うできる権限がない以上
上と被るかも知れないが、一週間に一回も会議を行わないようなのも「屑システム」だ。
確かに会議だけしても意味ないが、しなくても全く情報共有ができず、プログラマは何していいかさっぱりわからない。
また、各作業員の間で信頼関係がないのも、なかなかに屑システムだ。
