「開発プロセス」を含む日記 RSS

はてなキーワード: 開発プロセスとは

2021-09-02

労働時間を抑えながら成果を出すSIerさんになるための4か条

労働時間を抑えながら成果を出すSIERさんになるための4か条を紹介している。ルールは増やすのではなく「変える」「研ぐ」意識で作りましょう。タスクではなく価値フォーカスし、静的解析にして人為ミスをなくす。

システム開発では問題対応のために何かとルールが足されていきがち。しかし、ルール棚卸し最適化したり減らしたりする運動は少ない。開発の歴史と共にルールは積み上がり非効率開発プロセスになっていく。

バグへの対応策としてダブルチェックからトリプルチェックに強化します」

2021-06-17

エンジニア()所詮この程度の視座の低さなんだよね

anond:20210617075257

私は一流SIer上級管理職をやってるけど、こんな要素技術なんて結局意味がないんだって何回いったらわかるんだろうね日本エンジニア()は。この程度を勉強したところで結局派遣SES関の山なんだけど本当にそういうのを目指したいのか?本当の意味エンジニアになりたいのならとにかく顧客とのコミュニケーション要件定義の仕方、そして進捗管理の報告、ちゃんとした開発プロセスを学び、次に機能設計、詳細設計をもれなく記載する技術を学ぶべきで、Docker()なんてどうでもいい。

不勉強な人ほどウォーターフォール馬鹿にするけど、結局すべての開発プロセスというのはウォーターフォールが基本だし、その中で要件定義機能設計重要性を勉強する。こういう正統な成長の道があるのに最も価値の低いコーディングから入るのは愚の骨頂。

2021-02-05

COCOA不具合って言うけどさ

そりゃもちろん開発プロセス上の問題は当然としてあるけど、運用としての問題は?

COCOA、どれくらい効果を発揮してるかなって誰も見てなかったってことだよね?

あいも変わらずのハコモノ行政といえば、そうなんだけどさ。ひどすぎない?

2020-11-24

事業のわかるエンジニアSIerに腐るほどいるがその結果がいわゆるSIer

https://www.megamouth.info/entry/2020/11/23/233104

夢を語れるとかそういう話はおいておいて、顧客業務ちゃん理解してシステムに落とす、それはSIerの最も得意とするところ。

から未だにウォーターフォールでJava8(ひどいところはJava6やCOBOL)を使いIE専用の業務システムで出力した神Excel仕様書PPAPでやり取りする。

これは全部顧客業務ちゃん理解し、理詰めでビジネスプロジェクトを構築した結果なんだ。

まあそれはそれとして一番どうしようもないと私が思うのは上記の点を持って

「俺達は正しいことをやっている。Web系とか流行りを追いかけてるだけで実がない。GAFAなんて大したことやってない。」

揶揄とかではなく本気で思っている人が多数いることだ。ほんとか?と思う人はアクセンチュア日立CTCなど、最上流のSEをやっていると思われる

Twitterアカウントヲチしてみるとよい。私はそもそもそれらの中の人なのでよく分かるが、そういった上流SIer管理職かになるような人は

本気でそう思っている。またそういう人は「俺も本当は技術が好きなんだよ。でもビジネスってものはね云々」っていつも語っていて、

好きだといつも主張している技術の話はほとんどしてない。Twitterではビジネスがどうとか開発プロセスがどうとかばっかりなんだが、

本当に技術が好きなのかは謎。

2020-11-20

デスマーチの歩き方

努力不足でSESしか行けなかったというツイート話題になっていますね。

件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。

簡単自己紹介

業界に入って十数年、メガベンチャーで働きGAFA関連企業から1X00万円のオファーを貰うくらいのスキル経験はある。もちろん開発のスペシャリストとして。

学生時代メンタルをやり10年程通院。

多浪してFラン大学に入り四年間通うが卒業できず中退

フリーペーパーで未経験歓迎SE求人をみて応募。

新宿雑居ビルオフィスのある中国人経営するSES会社からキャリアスタート最初会社雇用保険も払ってなかった。

紆余曲折あり現在に至る。

想定読者

新卒または第二新卒文系または数学が苦手、プログラミング経験者でスクールサロンに入ってプログラミングを身につけて働きたいと思ってるひと。

理系プログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いかスクリプト業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。

プログラミングは誰にでも身につけられるか?

たこラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)

要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。

学び始めてすぐに判断を下す必要はないですが、スクールカリキュラムを終える頃には周りとの成長スピードの差で自然理解できるかと思います

しかし、もし適正がなかったとしても悲観するのはまだ早いです。

プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjMUIデザイナー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企業を考えてみましょう。GoogleNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。

ここであなた採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう?どちらを採用したいですか?

まとめ

ここまで書いたことを理解して謙虚面接を受ければそう悪い結果にはならないと思います

残業は大したリスクではありません。

現場技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやす環境を探しましょう。

面接ではチームのアウトプットを高めるために最大限努力するという姿勢を見せましょう。

2020-09-10

よくある話

会社の昔の大黒柱だった部門。近年のビジネスの規模の割に妙にリッチに開発をしていて、決算報告を見る感じではまあ悪くはないんだけど良くもないよね、みたいな感じだったけれど。

コロナ騒動あたりで明らかにヤバい気配が出た。

流石に上層部も見過ごすことができなかったのか、部門を縮小していく方向に舵を切った。

そうするともちろん人が余る。この国では簡単に首は切れない。

そこそこ利益を上げていて、でも忙しく、とにかく人手が欲しいと言った自分部署に人が上記部門の回されてきた。

部門が縮小されるからと行って、第一線で働いている人を動かせるわけがないので、管理職おっさんが回ってくる。

「私は○○と○○と〇〇の開発に携わってきました。」なるほど。よくわからん

こちらの開発業務説明すると、眉根にシワを寄せるおっさん

「この開発プロセスおかしいのでは……?」

ああそうだ。明らかにおかしい。計画がまともに機能していないし何もかもハチャメチャだ。

しかしこの分野では顧客へのレスポンス第一なんだ。

評価実験機を大急ぎで作って顧客に渡して、「ここらへんの性能データないの?」と言われたら1ヶ月でデータ取りしてその結果を営業に教え込む必要がある。

それで顧客から「ふーん、いいじゃん」の声をもらって受注につなげるのが大切なんだ。

開発プロセスの遵守は大切なのは重々分かるんだけれど、その余裕がない。

正直面倒くさいし、それを落とし込める改革はやりたいやつがやってくれ。

思いつきで考えた設計と2週間で作った実験系、そのデータが予想以上のパフォーマンスを見せたときの楽しさはたまらんぜフハハ。

駄目な開発者だ俺らは。そして駄目な開発現場だここは。

実験室に案内すると5Sの徹底などを説かれる。まあわかる。でもギリギリ遵守してるだろ。

あと、実験系の検出器の精度について指摘される。

さすが長年開発に携わってきただけあって分かるのだろう。そうだ。そこはヤバげだ。2年前に気づいていた。

しか要求を満たす高グレードなものは500万円くらいする。予算を通すのが結構キツい。

予算取りに時間をとるくらいなら今の実験系の精度でゴリ押しして保証できる性能を出したほうが楽だ。

その上検出器そのものメーカー公称のスペックも疑ってかからないといけない。検出器の評価には時間がかかるんだ。そんな余裕ないぞ。

よくある駄目なパターン

おっさん自分立場こちらの現状が十分わかっているのだろう。

ドラマの悪役のような高慢ちきな振る舞いはしてこない。

何とか自分知識立場できる改善を考えてまとめてくる。

しかし、こちらはそれに付き合っている余裕がない。

そのプレゼン資料は見たぜ。立派だな。わかりやすい。俺でもできそうだ。でも、あと半年待ってくれ。

半年待ってくれ」はこれからもずっと続きそうだ。すまん。

2020-08-15

SEってソフトウェアエンジニアの略だと思ってんのかよ!

クソみたいな愚痴

どいつ(転職サイト)もこいつ(増田)も、SEといえばソフトウェアエンジニアのことだと思いやがって!

SEシステムエンジニアであって、ソフトウェアエンジニアSWEだろ!

元来(この業界では?)、SEは回路設計出身者が務めてたの。全ての基本である電源回路や昇圧・降圧回路ですらも、基本的な回路を分かってないやつにSEは務まらないの。わかる?

それを回路図は読めません、ブロック図も読んだことがありませんって、SEとして終わってるだろ。

しか簡単微積もできない(らしい)から、回路だけじゃなく制御もできないし。

制御必要となる回路ブロック設計できなければシステム設計できないじゃん。

それなのにSEとして俺よりも最低200万円以上年収が高い職位で他業界から転職してきやがって!

内定を出した上司上司だし、このまま仕事が回らなければチームメンバー転職してきた人も会社も損してlose-lose-loseなの分からないの?

あげく、SWEとして期待してみれば、回路図が読めないしオシロ電流プローブも使えないかテストはできない。

コーディングしてもらおうにも、Cは読み書きできてもアセンブリ言語は書いたことも読んだこともありませんって、ありえる?

他のコンパイラメーカーアセンブリ言語は書いたことがあるけど、うちで使ってるコンパイラメーカーアセンブリ言語については書いたことも読んだこともありませんなら全然分かる。この業界で使われるコンパイラメーカーは4社くらいあるもんね。

けど、一切触ったことないって大丈夫

コンパイラには不具合が含まれているって前提すら無い人なの?

それだと業界標準の開発プロセスすら回せないよ?

それともCで書けば処理速度が担保されると思ってる最適化オプション信者なの?

コスト要求が厳しくて高性能なマイコンが買えないのに性能要求が高いこの業界で、その前提はおかしい。

Cだけだと処理負荷要求を達成できないから、この機能アセンブリ言語で書こうとか普通にあるよ?

コーディングができないなら、設計ができるかというと、それも得意ではない模様。

エラー検出ロジック検討についても、FTTIを考えないか妥当性を検証できないし、FTTIを考えたとしても電子部品スペック表と回路図が読めないからかハード側のFDTIとFRTIを検討から外すし、そもそも単一エラー検出ロジックしか考えないか業界の規格を満たせない状態で、その回避策も用意しない。

あげく、設計レビュー担当した機能では、この業界タブーとされる「テスト工程でのバグ出し」を前提としたレビュー実施しており(複数名でレビューできなかった組織体制も悪)、案の定テスト工程バグが見つかって、客先に設計レビュー体制についての改善策を提示するハメに。

まあ、これは「マイコンバグノイズ・熱の影響以外の動作不具合設計工程で全て潰す」という業界暗黙のルールを伝えていなかったこっちが悪いので、言いがかりではある。

それは置いといて、色んなことがあって、転職者がたった4ヶ月でチームメンバーヘイトを集めまくっている。

ほんと、何でSWEも満足にこなせないこの人がSEとして入社し、基本的電気メカソフト制御知識不足で俺には取得できない社内資格認定されていて、俺よりもお給料が200万円以上高いんだろう。

そして、何でうちの会社新卒5年目の俺よりも(少なくともうちの会社では)役に立たない新卒15年目の人に、俺よりも200万円以上高いお給料を払ってるんだろう。

2020-08-09

やはりデザイナーIT知識ゼロで生きていると思った

上流とか下流とか呼び方がどうのとかって

こんなものウォーターフォール開発プロセスから出てきた呼び方なんで

当たり前のITスキルがあればガヤガヤ騒ぐようなもんじゃない

同じデザイナー仕事している身からするとみっともないからこういう人はいなくなってほしい

https://note.com/asamieee/n/n850d93a2e147

2020-05-26

anond:20200526002227 情報処理技術者試験なんて簡単で案外役に立ちます

情報処理技術者試験なんて、実務、特にマネジメントなんかやっていると役に立つことが多いです。

前提が違う気がしますよ?

まず前提の捉え方がちょっと違いますが、「情報処理技術者試験」とは国家試験でありながら、医師国家試験危険物取扱者試験などの国家試験とは異なり、

別に持ってなくても実務に従事できるって言う不思議国家試験であること。

なので、別にこの試験がなくても、情報処理技術者としての仕事にまったく支障はないです。

 

じゃあなんで試験なんか受けるの?

情報処理技術者試験は、ちゃん情報処理のこと勉強してますよ!ある程度の知識は修めてますよ!って言うためのものでしょう。

名刺資格もってるよマーク載せてIT系なら任せてよアピールをするためのものでしょう。

たこ資格を持っていることで、ちゃん勉強している人間なのか、その指標にもなるのでマネジメント一助になるです。

なので、エンジニア同士の共通言語って位置付けな気がします。

 

そんなにひどい問題が多いの?

ご指摘の通り、暗記問題ばかりで実際の業務には何ら役に立たないように思えますが、

一方で実務以外のコンピュータ技術本質的な設問であったり、法務関係問題もあったりして、

マネジメントの他、教える立場になったときや、企画開発なんかで広く浅い知識必要になったときには役に立つかと。

 

そもそも逆なんですよね。この問題を解けたら良い設計ができる、とか、優れたコーディングができるんじゃなくて、

まともな設計知識を持っていたら、このくらいの問題は知っていますよね?ってのが技術試験の一面です。

※あと、「コードが書けるわけでも、良い設計ができるわけでもありません。」って否定をするなら、せめて応用のほうから持ってきてくれないと・・・w

 

ちなみに、UMLの基本や、開発手法MPEGなどの標準規格名称なんかを覚えるのは、設計コーディングにおいて「超大事」なことです。

そうした名称をもとにして開発を進めていくわけで、いちいち「要求分析から実装までの開発プロセスを繰り返しながら、

システムを構築していくソフトウェア開発手法」でやります!みたいな説明しなくても「今回はスパイラルでーす」って一言で終わるじゃないですか。

基本情報技術者試験レベルメンバー全員が資格取得してくれていれば、「スパイラルでーす」で終われるってすばらしい。

 

情報処理技術者試験なんて簡単に取得できます

合格率は基本情報技術者試験で3割弱、応用情報技術者試験で2割強となっています

なので、一見難しそうに思えますが、非常に簡単です。覚えればいいんですから

そもそも基本情報なんて、非IT系会社勤務の方の合格率が、IT系会社勤務の方の合格率を超えているという・・・)

なのに合格率が低いのは、みんな真面目に勉強(暗記)していないからと思われます

試験会場にいくと分かるのですが、まずスタート時点で1割強は机の空きがあります。とりあえず申し込んでいるだけなんでしょう。

会社によっては予算取ったから行って来いよ、みたいなところもあるのでしょう。

暗記試験で引っ掛け問題も少なく、広く浅い問題範囲なので、1~2か月真面目にやればだれでも取得できますよ。

ただ、さすがに150分座ってるだけで取れるような試験ではないことは確かです。

範囲は広いですし、勉強してなきゃ聞いたことがない言葉なんてザラです。

 

情報処理技術者試験は案外役に立つ

上記を言い換えれば、真面目にコツコツ勉強してくるやつアピールが出来ます

合格率2割の国家試験を、通常業務をこなしながら取得してくるだと・・・!?化け物か! みたいな

雰囲気でとらえてくれるおじさんは、まだまだいっぱいいますよ。

 

受験だってそんなに高くないし、そこまで噛みつくような試験でもないと思いますけど。

情報処理技術者試験なんて何の役にも立ちません

情報処理技術者試験資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術無関係ものを含まないということです。

なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります

オブジェクト指向におけるカプセル化説明したものはどれか。

  1. 同じ性質もつ複数オブジェクト抽象化して,整理すること
  2. 基底クラス性質派生クラスに受け継がせること
  3. クラス間に共通する性質抽出し,基底クラスを作ること
  4. データとそれを操作する手続を一つにして,オブジェクトの内部に隠ぺいすること

https://www.fe-siken.com/s/kakomon/19_haru/q42.html

こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。

数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。

ひどい問題は挙げればキリがありません。

UML2.0において,オブジェクト間の相互作用時間の経過に注目して記述するものはどれか。

  1. アクティティ
  2. コミュニケーション
  3. シーケンス
  4. ユースケース

https://www.ap-siken.com/s/kakomon/22_haru/q44.html

図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそもUMLなど別に技術者として知っておくべき知識でもありません。

要求分析から実装までの開発プロセスを繰り返しながら,システムを構築していくソフトウェア開発手法はどれか。

  1. ウォータフォールモデル
  2. スパイラルモデル
  3. プロトタイピングモデル
  4. リレーショナルモデル

https://www.fe-siken.com/s/kakomon/23_aki/q50.html

これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題いかに、この試験エンジニアリングプロジェクト管理本質関係いかがよく分かります

極めつけはこれ。

次の画像符号化方式のうち,携帯電話などの低速回線用の動画像の符号化に用いられるものはどれか。

  1. JPEG
  2. MPEG-1
  3. MPEG-2
  4. MPEG-4

https://www.fe-siken.com/s/kakomon/17_haru/q52.html

地方公立中学校定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字語句対応を覚えることが重要だと思っているのでしょうか。

情報処理技術者試験で測れる能力は以下の2つだけです。

  • 内容の理解はともかく、ある用語を「聞いたことがある」かどうか。
  • 150分間、落ち着いて椅子に座っていられるかどうか。

まり、ある種の発達障害ではない意識高い系ポエマー認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。

そもそもコンピュータプロジェクトマネジメントの技術を、資格試験勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。

2020-02-15

anond:20180929221805

そもそもアジャイル開発でやる気がないのだろう

若いエンジニアは「新しい技術・開発手法は優れている」というドグマを、なぜか頭から信じ込んでる場合が多いが、

ウォーターフォールだろうがアジャイルだろうが、ミスなく早く開発できればなんでも良いし、

ウォーターフォールモデルにチームが習熟しているなら、そっちの方が良いに決まってる。

アジャイル真理教宣教師でもあるまいし、金貰ってる仕事なのだから、わざわざ今まで経験したことのない開発プロセスを試して危険を犯す必要がない

可能性としては

1.偉いさんがアジャイルアジャイルうるさいから、なんちゃってアジャイルモデル適当お茶濁しとけと思ってる

2.チーム全体にアジャイル開発の経験値がないので、失敗しないように今回のプロジェクトウォーターフォールでやりつつ、

アジャイルモデルに習熟する時間を稼いでいる。

どっちかだろう

2019-09-29

リーダーの部下に怒りが収まらず悩んでいる

長いので最初にまとめ

愚痴です。

ざっくりいうと、

という話です。詳しく書きすぎて身バレしそう。

これまでの経緯(長い)

私は、昨年とある小さい企業入社し、入社10ヶ月ほどで管理職となった。入社直後の配属先は5名前後の開発チームで、タイトルの「元リーダーの部下」とはそのときにチームリーダーを務めていた人物である

入社先の会社自体設立から10年程度経過しているが、当初は社長のツテなどで社員を雇っていたようで、開発チームにはいわゆるプログラマとして働く人のみで開発のマネジメント経験のある人はひとりもいなかった。ちょうど数年前から事業ちゃん収益化しようとしているところだったが、これまで社長自身の旗振りによって動かしていた開発チームも、社長多忙となり直接見られないことから一応リーダーとして立っていたようだった。

私は前職ではそれなりの規模の企業で、受託案件プロマネを数年間やっていたこともあり、今の会社面接の際はそのマネジメント経験を非常に買ってもらえた。そういう経緯もあり内定をもらい入社したので、最初はやってる業務内容を教えてもらいながらこちらもチーム運営ヒアリングしたりして状況把握につとめた。初っ端、タスク管理方法について聞いてRedmineを見たところ更新されているチケットほとんどなく、営業チームから要求がたまに書かれるだけのものになっていて「おぁ・・・」となったが、そういうところから運用ルールを決めて周知して回して…と地道に進めてきた。

2〜3ヶ月もすると、開発チームのメンバーとしてマネジメント会議に私が参加するようになり、他部署との依頼や業務調整など、すべて私を通してやってくれるようになった(それまでは、営業部門の人が開発メンバー個別に聞きに行く、という形で情報共有もされていなかった)。

それでも、名目上、チームリーダーとしては彼を立ててはいた。もはや彼のリーダーとしての仕事は進捗確認するためにチームメンバー招集すること(進捗確認自体は私がやっていた)と、全社会議で開発チームの進捗をみんなに報告することだけであったが、私が管理職になったことを機にその仕事も私が引き取り、他のプログラマたちと全く同じ立ち位置になった。

話は変わってチーム全体のことだが、開発チームにはさまざまな勤務形態で働く人がいることと、私の前職ではデスマーチ的な働き方が横行していた反省から、チームメンバーには極力割り込み業務をさせない・会社全体の状況はできるだけこまめに共有する・定期的にメンバー個別に話を聞ける時間を作る、などメンバー安心して働ける環境づくりを心がけてきた。また、開発プロセス品質についてそもそも知識がないメンバーもいたので、個人個人能力底上げができるよう、タスクの洗い出し方から設計書の書き方、テスト項目の作り方など教えながら一緒にやってきた。実装インフラ設定などは逆に私よりも知識能力がある人たちだったので、道筋を作ってあげることでこれまで「それなりに動く程度に作って終わり、バグが報告されたら手が空いたときにやる(結局できない)」みたいな感じだったのが徐々に改善されてきたと感じている。

ただ、彼だけは例外だった。最初の数ヶ月で、彼自身ハンドリングさせる仕事を振ってはいけないと分かってはいたため、彼にアサインする仕事は必ず私が最初に介入し、進め方・タスクの洗い出し方・スケジュール…とすべて打ち合わせで明確にし「いつまでに何をする」をきっちり決めて(スケジュールは彼の見積りさらバッファを山積みして)あとはやるだけ…な状態に持っていく。また、彼は誰かにまれごとをするとそちらが最優先になる自分タスク管理をできない人なので、一切他のタスクを振らないようにしていた。それでも期日になると、成果物が出てこないか、終わってないものが出てくるか、そもそもタスクがなかったことになっている。終わったと本人が言っていても、当初やることに合意したはずのもの実装されていなかったり、適当実装だったり。リリースすると客から指摘が来て、それの対処にまた数週間かけるのである(次の開発を開始できないためまた遅延する)。

そんな状態なので、開発工程ど真ん中でも頻繁に介入して立て直しをする必要が出てくる。立て直しをするときにはできるだけ彼の心を折らないよう、「このまま進めても遅延するリスクが大きいので」と伝え、振り返りの体で「ここでもう少し見積りのための調査を詳細にやっておくべきだったね」「次はこうやってみよう」と立て直しのために必要作業を一部実際に自分でやってみせ、他の部分を明日いっぱいぐらいで作ってね、作ったら一緒にレビューしようね、という風に毎回新人教育のような気分になりながら進めるのである。当然私自身が持っている仕事に支障が出るので週末にやるのである

長くなってしまったが、ここまでは日常業務光景であり、組織作りや案件炎上しないための立ち回りなどは私の仕事だと認識しているので努めて冷静に対処しているつもりである。怒鳴ったことは一度もない。

私が怒りを覚えていること

私が怒りを覚えてしまうのは、彼の仕事上での振る舞いである。

発言が、仕事茶化すようなものだったり、自分タスク他人事のように言ったりする。そしてそれは状況がシリアス(彼の能力不足に起因する遅延が発生している状況など)になっても変わらないため、非常に癪に障る

これまでのことをすべて列挙するときりがないが、直近に行った、彼が進めているプロジェクトの仕切り直しのための打ち合わせ(私と彼の一対一)での発言特にひどく、タイトルの通り怒りが収まらない状態が続いている。

  • 遅延しているプロジェクトを立て直すためにタスク課題の再洗い出しを指示すると「それやらないといけないの?」「何日かかるかわかんねえな」「洗い出してちゃんとやろうとすると終わらねえよ」(立て直すためにそれを指示しているのに)
  • 課題なんて実装してみないとわかんねぇだろ」(調査期間にやったことの振り返り時)
  • その立て直しの打ち合わせ(冒頭で、スケジュール見直して仕切り直す旨を伝えた)が終わると、周りのメンバーに「スケジュールが延びた〜」とうれしそうに話す(私が事前に営業さんたちに説明して頭下げて…という話をしたにも関わらず)
  • それを指摘するとヘラヘラと笑いながら「いやいや言葉のあやだから〜」と返事する

よくブチ切れずに済んだなと思いながら、このように調子に乗ったままだと彼は負債再生産を繰り返して会社に害為す存在になることがわかっているため、きっちり〆ておく必要があるのかなとも思う。反射的にそういうアクションをとれない自分が恨めしい。とはいえ過去就業規則全然守らないことに対して説教したときヘラヘラしてたし、金銭的な処分をする権限はないし、自分には彼をどうにかするのは荷が重いな…と迷いに迷っている週末。

人手不足の折、やるべきタスクはたくさんある中で、彼の手もまた人手だと思いながらやってきたけど、私の負担けが増えてモノができないなら思い切って切る判断もあるのかなと思う。結論が出てこないけど、直近指示したことが予定通り出てこないならまたそれに対して立て直しをしないといけないと思うと心が重い。彼を担当から外すにしても今他に空いている人はいないし、彼にさせる仕事も思いつかない。担当から外したら外したで「身軽になった〜」と喜ぶのだろうか。それを想像してしまいまた怒りがこみ上げ無限ループに陥るのやめたい。

2019-08-02

[] 8年間働いた某自動車部品会社退職しました

あらまし

自動車部品会社で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代で転職を迷っている方は興味があればこのタイミング自動車業界トライするのもいいかもしれません。うまくいかなければ、他の業界転職すればいいと思います。一度は自動車業界に来たものの別の業界転職していった方や、別業界からの出戻りもあるようです。

8年働いてどうだったか

不条理世知辛い業界ではありますが、個人的に携わったテーマは楽しく取り組めたので、自動車業界で働いたのは間違いではなかったかなと思います。緩やかにですが変わっていく業界ではありますので、近い将来に今よりは働きやす業界になると思います。今後の伸びしろもあり、まだまだ楽しむ余地がありそうですので、転職先も自動車業界しました。ただ、国内世界的某大手自動車部品メーカーも受けましたが、面接をしている最中にここも結局は同じか………と感じてしまたこともありましたので、外資系企業しました。

最後

すいません、皆様が知ってるって感じのうんちくを垂れ流しただけで、全然退職エントリーではなかったです。

2018-03-05

いろんな意味やばい開発会社に入った話をしようと思う。+α

とにかくいろんな意味やばいIT系の開発会社に入ったからぜひ話を聞いてほしい。

自分は21歳で2社経験してるけど入った会社全部がやばい会社(いわゆるブラック?)だったりでいろいろ苦労したか

就活生や転職活動してる人の参考になればと思ってこの記事を書いてる。

んで今回はIT系会社についての話。

読むのめんどくせえって人用にまず3行でまとめてみる

1、「うちは今度から完全週休2日制に完全に切り替える」と言われてたった3か月で完全週休2日制が撤廃になった。地獄

2、自分以外の開発メンバーのずさんさがやばい。ゴールが見えない。地獄

3、話合いが全くできないので何一つことが決まらず進まない。以下地

わかりづらかったらマジゴメン

こっから本題

1、「うちは今度から完全週休2日制に完全に切り替える」と言われてたった3か月で完全週休2日制が撤廃になった。地獄

 入社した当初は週休2日制で土曜出勤とかもあったんだけど、つい最近経営者から「よし!うちも完全週休2日制に切り替える!」

と言われて確かに完全週休2日制になったんだけどどうも

法律上、うちは休みが多すぎるって判明したから調整した結果、完全週休2日制は今月いっぱいでなしね」

とかよくわからんこと言い始めて(そもそも法律休みの上限とか聞いたことないけど)たった3か月で撤廃になった。

この事例からアドバイスできるとしたら

ちゃん休日関係確認したほうがいい、完全週休2日制とか謳っておきながら箱の中身を見てみたら嘘だった

なんてこともざらにあるから気を付けてほしい。

あと転職活動何度かしててわかったけどに「休日数1〇〇日以上!!」とか見出しで謳ってるような会社も基本ろくでもない会社が多いって感じたから参考程度に

覚えておいてほしい。

2、自分以外の開発メンバーのずさんさがやばい地獄

 正直今回一番書きたかったのはこの項目。とにかくここが一番やばい

基本的開発プロセスって(例外とかは抜きにした基本的な順序)

1、要件定義 → 2、外部設計 → 3、内部設計 → 4、開発開始 → あとはテストやら公開準備やら……

って感じだと思うんだけどうちの開発者場合

1、開発開始 → 2、要件定義 |(ここでクライアントとか経営者ものすごい怒られる)| → 3、外部設計 → 4、内部設計 |(ここでクライアントとか経営者ものすごい怒られる)| 3、外部設計  ……

これが永遠と繰り返されるんだ。マジで。書いてる自分でも訳がわからなくなっていく、つまりゴールが一生ないってこと。

設計書作らない、新しく入った人に引き継ぎしない、仕様書すら作らない。そんな会社です。

それで今どきの開発会社で手作業バージョン管理してるんだぜ?やばくね?

ようは古いファイル(上書きが必要ファイル)は「ファイル名_20180305(今日の日付)」とかで管理してるんだぜ?地獄じゃね?

だって自分修正したファイルがさ自分が知らないうちにその開発担当者上書き保存されて消えてるんだぜ?

そのくせ「治ってないじゃないか仕事怠慢だ!」とか言われるんだよ。俺にどうしろっちゅうねん

そこでさ、俺さすがにこのままだとやべえなと思って開発担当管理者提案したんだよ

Gitの導入検討しませんか?」

って。いやだって作業よりマシじゃん?ないよりマシじゃん?

そしたらさなぜか知らないんだけど2,3時間くらい「Gitは難しくて~」とか「導入するとコストが~」とか

クソみたいな言い訳並べて導入したくないみたいなんだよね。だから上司上司に直談判して導入を強制してもらったのよ。

そしたら案の定その上書き保存事件収束したわけ。

なんだけども、

ここからさら問題

普通Gitってさブランチ複数に分けるじゃん?

master develop feature …… 大体多くても3~5とかに分けるよ普通

でもさうち

「master」一本なんだよね。商業でやってる会社がmaster一本て聞いてことないよ。

そこですかさずまた俺は提案したんだよね

ブランチ複数に分けませんか?」

ってそしたらさ開発担当管理者になんて言われたと思う?

「は?効率が悪くなるからダメでしょ」

って言われたのよ。この後に及んで効率取るか?普通

だってもうお前のせいでリリース3回延期してるんやぞ(この際にもいろいろあったけどもっと長くなるので割愛

しかもお前俺以外の開発者全員ソース問題が残ってる状態でなんにも確認せずに「できた!」とか言って

コミット&プッシュしてくれるんやぞ?生き地獄だぞこっちにとっちゃ。

んで一応それがだめならと思ってせめてこれは通ってくれと願いながら

「Pull Request使いましょう?今のままよりマシではないかと」

って提案したら

「面倒くさい」

で一蹴りされた。俺、ここでこの会社辞めるの決意したんだよね。

今まで他担当者タスク管理とかやってあげたり来た指示書の具体的な内容の確認とか全部やってたの自分なんだけど

管理者じゃないのに。それに他に任されてたプロジェクトだってあるのにこっちがあまりにもやばいからっていう理由

太刀で来たのに。悲しくなったよ……。

今この会社には今年の3月いっぱいで退職予定なんだけど、次の会社(もう内定はもらってる)に面接に行った時つい辛すぎてこのこと愚痴ったら

「数年に1件見るレベルの酷さ、頑張ったね……」って言われたよね。「良かった自分感覚間違えてなかったんやな……」って

ちょっと泣いた。

とまあ、これが現実。ちなみに地方会社からね。地方の開発会社はこんなレベルだと思ってもらっていいよ。

都内から3~5年遅れてるって言われてるし。

そもそもなんやねん実績じゃなくて「実務経験3年以上」っていう基準なんの基準やねん。(これは今回関係ないけどこれも愚痴

3、話合いが全くできないので何一つことが決まらず進まない。以下地

 基本的に話し合いが成立するのって問題解決するために、立場・考えなどを述べ合うことだよね。

うんまあこれも普通ならただの話し合いなんだけどさ。

Aさん「今こういう現状で問題が続いているのでこのようなルールを作るべきではないでしょうか?」

って改善案を出すとする。すると健全な話し合いであれば

Bさん「であれば自分意見はこうでこういうルールだったらいいのではないかな?」

これであれば互いの意見いいところを取って互いが納得したルール改善案が出せる可能性は高い

だけどうちの開発者場合

「お前の意見はここがダメだ、ここもだめだ。こうだから絶対ダメ

否定しかしないんだよね。もうこの時点で同じ土俵に立ってないわけ話し合いとして。

んでそういうやつに

「では改善案はありますか?」

って聞くとしどろもどろして何もかえってこないのよ意見がどういう思考回路しとんねん。

基本的否定する暇があったら改善案意見述べてくれねえかなって思うのよ。まあ人によってはこれが意見だ!っていう人もいるけど

否定改善は違うからな。

んでこれがずっと入って1年間続いたわけそこで俺気づいたんだ。

この会社開発者対話すらできないんだって

他の会社はどうかしらないけど大体の大人ってこんな感じだよねテレビに出てる批評家とか辛口専門家(笑)とか。

何が言いたいかっていうと

いくら頑張って改善を試みようとしても無能上司や頭のおかしいやつに蹴られたらおしまい

ってこと。正直者が馬鹿を見るっていうけど本当、当たってると思う。

最後就活頑張ってる人とか転職悩んでる人に伝えたいこと

自分の若干21歳でもう転職2回もしてるから世間体で見ればろくでもないやつって思われるかもしれないけど、

辛い時期もあったけど案外どうにでもなったし頼れるところはいっぱいあるから頼れるものは頼ったほうがいいよ、

親とか友達とか、行政だっていう手もある(求職者支援訓練で検索)。

ネットとかリアルの友人がクソみたいな会社に振りまわれてるの見ると自分まで辛くなるし力になりたいって思うけど

なかなかそういう機会もなくてあれかなと思って今回この記事を書いた。

この情報デマだ!って言われたらそりゃ所詮ネット情報だし信じるか信じないかは……になるけど

でも確かに自分経験した体験談からここに書いてるのは承知してほしい。

んでこんな自分から伝えたいことがいくつかある

1、真面目に生きると損する

これ3年間社会人やってたどり着いた心理。そりゃ責任感は捨てちゃだめだけどさ

世の中の大人って呼ばれる人たちまあおおざっぱだし適当だよ。

自分学生の頃「社会に出たらもっとしっかりしなきゃ……」って思ってたけど

今になっては「真面目に生きるのもアホらしい」って思うくらい。

本当好きなこといっぱいやったほうがいいよ。

2、求人は基本信頼するな

 これも転職活動しててわかったこと。

正直求人情報よりもネット情報がまだ正確だったりする(某掲示板とか)

かといってネット情報鵜呑みにしすぎるのも危ないから気を付けてね。

一番いいのは会社訪問させてもらうこと。あとOB訪問とか。

3、難しく考えすぎないこと、逃げ道はいくらでもあること

 さっき上にも書いた通り真面目に生きるだけ損するから嫌だったら辞めてもあながちどうとでもなるから安心してほしい。

上京した人とかは大変かもしれないけどそれこそ親頼ったりとかしてもいいんだし逃げ道はあるから気にしないほうがいい。

自分最初会社は3か月ちょっとパワハラ受けて精神病院行きになってやめたけど今は多少ぴんぴんしてる。

転職したいな~って思ったら迷わずハロワに行くなり、転職エージェントやら就職支援サービス登録しておけば企業からスカウト

来たりするしいい求人来たら面談してみるとかでもいいし。逃げ道作るのもいいと思う。

あともし転職するなら多少忙しいだろうけど在職中にした方がいいよ。収入が絶え間なくなるからおすすめてかそうして。

っとめちゃくちゃ長くなったけど言いたいことは言えたのでよし、

現状こんなIT系の開発会社謳っていながらこんなやべえ会社あるんだよっていうのと

自分が苦しんだからあとの世代には気楽に生きてほしいってことを伝えたかったんだよね。

まあこの記事に対する反応とかは

「うちはもっとこんな風にひどいから気を付けろ!」とか

就活はこうすると良い!」とかアドバイスがいっぱい来ると嬉しいな。

それじゃまたどこかで

2017-08-29

Jアラートと、改善バージョンアップの違い

幸い、今朝のJアラートがならない地域に住んでいたので、やはり当事者意識は弱めなのだが、だからこそ、第三者的に見て、色々どうかな?という面も多々あった。

 

要するに、「地下に逃げろ」「コンクリート建物の中に逃げろ」と言われてもそんなところなどない、みたいな話があり、全くもって笑い話にならないのだった。

 

地域ごとに出るメッセージを適切に変えれば良いだけだと思うのだが。

ケータイ基地局の判定するなどして、そこから割り出すとか出来ないんだろうか?

 

最初から上手くやれ」とは言わないが、少しずつシステム改善して欲しい感じはある。

 

で、ふと思ったのは、どうも、日本プロダクトは「作っておしまい」みたいな部分が大きい気もする。

不具合修正はするとしても)

 

もちろん、「改善」の語源から考えると、日本はその元祖的な部分もあるのだろうが、日本の「改善」は、例えば、開発プロセスなど供給者内の製造方法論みたいな話が多い。

 

それに対し、例えば、顧客体験としてのはてブバージョンアップは「改善」というよりも、「刷新」的な意味合いを感じてしまう。

 

逆に、アメリカ製プロダクト、例えば、YouTube動画サムネイルマウスカーソルを合わせると動画が動いたり、動画の長さがサムネイルに表示されりするなどして、顧客体験の地道な改善をしている印象がある。

2chアメリカ業者に乗っ取られてから、専用ではない通常のブラウザで見てみるとかなり使い勝手改善されている。

 

もちろん、日米の違いを一概にそう言えるか?と言ったら、違うと思うが(フラットデザインとか)、意識の強弱の差はハッキリと見て取れると思う。

 

繰り返すが、「最初から上手くやれ」とは言わない。

でも、少しずつ顧客体験改善していく方向で進めればより良いシステムを作ることが出来るようになるのではないか

2017-04-18

http://anond.hatelabo.jp/20170417202931

手に職を付けたい理由お金技術をもって自由に稼ぐハッカー

まず、前者なら大手SIer鉄板です。なぜなら、給与が圧倒的に高いからです。中小比較すると同年代で100~200の差は出ますあなた結婚したころにはその重みが分かることでしょう。

後者なら、残念ながらもう手遅れです。そういう人は小学生くらいから自ずとプログラミングをして、高校生くらいで何らかのコンテストに出ているような人かと。あなたくらいの年齢では、もう起業しているか企業からの取り合いになっていることでしょう。今、それをしていないということは、あなたはそういう人ではないということです。

大手SIの良いところは以下のとおりです。聞こえがいいとかそういうのはどうでもいいことです。

・外部の研修をある程度自由に受けられる

企業システムのある程度精緻に作られたソース設計書を見れる

SI開発プロセスを学べる

 「技術」とは何もコーディングだけではないことを知るいい機会になります

給与福利厚生中小に比べて圧倒的に勝っている

転職に困らない

バカ管理者比較的少ない(中小はその比ではないと思われる)

手に職と言いますが、それを持ち得て必要とされるような能力の持ち主は非常に稀有です。

からそれを目指すということはそれなりの覚悟努力する才能が無ければ難しいかと。

研修が手厚い会社を探しているとのことですが、

システム開発全般について、体系的に教えられる人を外部の講師含めて、ほとんど見たことがありません。

自主的に学ぶ場合は上流から下流工程までを見渡せる大手SIがいいです。

新卒カード中小企業に切ったら、次は中小企業カードスキルのある人カードしかないです。

大企業に切れば、新卒に準じる大企業カードか、大企業スキルがある人という強いカードになりえます

良く悩んでください。

2016-06-25

[] ウォーターフォールメリット

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

冒頭,

まず、「ウォーターフォールは何のメリットも無い」は嘘です。何のメリットもないもの存在するわけないので。

とあって,メリットを語ってくれるかな,と期待させるが,結局「スコープが確定しているならウォーターフォールでいい」,という消極的採用理由が述べられるだけで,メリット積極的採用理由は述べられていないように見える。

ウォーターフォールメリット

ではウォーターフォールメリットは何なのか?

それを語る前に,まずウォーターフォール定義しておく。現在日本ウォーターフォールとして認識されているプロセスは,国防総省式の「戻りの線」なしのものである。即ち,確定した要件なり仕様なり(以下まとめて「スコープ」と呼ぶ)は変更しない。「ウォーターフォール」という名前自体が,この一方向性に由来している。従って,ウォーターフォール定義としては,「(フェーズゲートを超える際に)確定したスコープは変更しないプロセス」で良いだろう。

この定義に沿わないプロセスは,「偽ウォーターフォール」であり,以下に述べるウォーターフォールメリットを受けることはできない。メリット享受できないだけでなく,この種の「偽ウォーターフォール」は(「偽アジャイル」同様)大きな害悪を撒き散らす。

さて,「確定した要件仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが,手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者/受注者含め何がうれしいのか。

答は

納期 and/or コストぶれるリスクを小さくできる」

である

すごく当たり前のことなのだが,これが書かれている記事が見当たらない。

そしてウォーターフォールメリットはこれだけで,それ以外にはメリットと言えるものはおそらく存在しない。

やはりウォーターフォールにはメリットなどほとんどなかった

ここで,前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。

よく見るとこれらは,いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく,本来意味での「品質」,即ち利用者の役に立つか,使いやすいか,ということまで含むものであるスクラムアジャイル)を知る人であれば,「トレードオフスライダー」の「品質」に相当するものだと理解してもらえればよい。

そうすると,前節のウォーターフォールメリットは,以下のように言い換えることが可能である

ウォーターフォールメリットは<品質を固定することで>コスト納期ぶれるリスクを小さくできる点にある」

これで問題が明らかになった。要するにウォーターフォールは,コスト納期のために品質二の次にするプロセスなのである

その結果,これまでどんなことが起きてきたか

あくまで変更を行わなかった場合

開発の途中で,要件仕様問題が見つかったとしても,あくまウォーターフォール定義に殉じると,出来上がるのは「使いにくい」「使われない」システムである

事業会社IT会社に転生させることが、これからSIerミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に,その実例らしきものがでてくる。

禁を破って変更を行った場合

これを行った瞬間からウォーターフォールはその(ほぼ)唯一のメリットを失い,混沌が始まる。

最も多いパターンは,発注者側が(もはやスコープ品質を固定するという前提が失われているにも関わらず)納期コストの確定というメリット享受を譲らず,プロジェクトデスマーチ化する,というものであろう。あるいは,コストは譲るが納期は譲らない,というパターンの方が多いかもしれないが,いずれにせよデスマーチ化につながりやすいことは間違いない。

そしてこの副作用として何が起きたかというと,受注者側がそれを見越して納期コストバッファを積むようになった。当然それは見積もりの不透明感につながり,発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。

うまくいくのは非常に限られた条件が成立する場合のみ

スコープの変更の必要が生じたら,どちらに転んでもいい結果は得られない。となると,ウォーターフォールがうまくいくのは,「スコープが明白で,変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので,そのような案件がどの程度あるかはわからないが,直感的には「ほとんどない」のではないかと思う。なぜなら,そこまでスコープが明白であれば,今はパッケージSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。

もう一つの可能性としては,スコープが変更不要になるまで,とにかく事前の準備と調査を徹底的に行う,というパターンもありうる。しかし,これは「準備と調査」の過程事実上いろいろ試作することになる(そうしないと変更のリスクが消せない)ので,もはや作業プロセスの大半が実はウォーターフォールではない,ということになるだろう。

アジャイル銀の弾丸ではない

ではアジャイルプロセスを導入すれば,これらの問題はすべて解決するか,というとそういう話ではない。ウォーターフォールメリットが(ほとんど)ないことと,アジャイル有効であることとは,独立議論である

そもそも「アジャイル」というのは考え方であってプロセスではない。だから,考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって,害悪を撒き散らすことが多い。

アジャイルの考え方は,主に以下の2点でウォーターフォールと大きく異なる。

1. スコープの変化がありうることを前提としている

2. スコープ品質=役に立つこと(=使えないものを作らないこと)が最優先であり,そのためにコスト納期が変化を(ある程度)受け入れる

この考え方こそアジャイル本質であって,CI/CDやDevOpsなどは,変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし,CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。

また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために,スコープはできるだけ確定する努力をする,というのはアジャイルでも変わらない。変えるべき時は変える,という点が違うだけだ。なんでも後で決めればいい/変えてもいい,というのは「偽アジャイル」であって,害悪しかない。

もちろんこれがあれば何もかもが解決する,という類のものでもない。上述の2点があるだけで(少なくとも今のたいていの開発案件において)ウォーターフォールよりマシになりうるとは思われるが,別の問題(例:納期コストの変化をどう扱うかという問題)も,同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり,これが「納期コストの変化」と絶望的に相性が悪い。

もっとも,今の「ウォーターフォール」によるソフトウェア開発が,請負契約の成立条件である契約時にスコープを確定(し,変更しない)」を厳密に守っているわけでもない以上,これだけを理由アジャイル否定するのはどうかとも思う。

契約については,IPA等でも取り組みがあるようだが,いずれにせよ契約を行うのは発注者と受注者であり,受注者側だけでどうこうできる問題でもないので,発注者側の意識の変化を期待するしかいかもしれない。

2015-08-15

http://anond.hatelabo.jp/20150815144407

開発プロセスはたいてい上流が偉くて責任とらなくて

下流に責任押し付けるだけだな。

上流の無能は、まじで死ねよと思うわ。

2015-06-21

夢のあるシステムに関わりたい。

夢のあるシステムに関わりたい。

いわゆるプログラマをしているが「屑システム」にかかわりたくない。

「屑システム」とは以下だと思ってる。

なお、一応言っておくと、私がかかわっているシステムすべてが以下に当てはまるとは言ってない。

自分が開発にかかわってるが、開発が進んでも自分利益にならない。他人の懐具合がよくなるだけ。

安月給はもらってるから、それで満足しろということになるわけだが。

その安月給は当然あがることはない。私から見れば立派な「屑システム」だ。

枯れた技術けが使われ、そのシステムにかかわったことが何の宣伝にもならない。

例えばいまさらsyslogが使えます、とかsnmpが分かります、とか意味なす。

いまならビックデータとか、クラウドとか、機械学習とか。

かいNoSQLとかクライアントサイドJavascriptとか。

次につながるようなシステム開発がしたい。そういう意味で「屑システム

システム」とは、プログラムのものだけを意味するわけではない。

プログラムを開発する、開発プロセスのものも「システムである

プログラマに丸投げしておけばシステムができるわけではない。

プログラムを開発するシステムが「屑」だとやる気が出ない。

例えば、ある作業をやったら、諸事情無駄になるようなのが「屑」な開発プロセスだ。

責任者に、リーダシップがないせいだ。あるいは、プログラマに何の権限もないと起こる。

人間から、全部有効な作業というわけにはいかないが、そんなんばっかりだとやる気にならない。

なお、リーダーシップというのは権限とセットだ。責任とセットなわけではない。

適切な権限があってこそリーダシップが発揮できる。

プログラムを作る責任だけあっても、その責任を全うできる権限がない以上

どんな提案をしても無駄になる。

そんなものは「屑」としかいいようがない。

上と被るかも知れないが、一週間に一回も会議を行わないようなのも「屑システム」だ。

確かに会議だけしても意味ないが、しなくても全く情報共有ができず、プログラマは何していいかさっぱりわからない。

また、各作業員の間で信頼関係がないのも、なかなかにシステムだ。

真の意味コミュニケーションが取れていない。というかそんなものそもそもない、ということなる。

2014-10-17

ソフト開発は認定試験の類を必須にして欲しい

情報処理はもちろん、言語とかDB関係とかベンダー試験も。

あとオブジェクト指向とか開発プロセスとか、コードの書き方みたいなやつも。本を1, 2冊読めば合格できるレベル試験でいいから

試験合格してないと開発にはかかわらせないようにして欲しい。

試験合格して当たり前だろ」とか言う人いるけど、職業プログラマには合格できないレベルゴロゴロいるから。

PHP入門書の一冊も読んだことないだろってレベル人間PHPコードレビューしてるとかギャグのような状況が日常

で、そういう客観的に見たらどう考えても水準に達してない人に限って自分レベルの低さを自覚してない。

自覚してないどころか「おれ10選手から」みたいに経験年数の長さだけを根拠に、むしろレベル高いと思ってる。

いや、普段の言動をみてると自分レベルの低さはうすうす感じてるのかもしれない。

学生時代にかじってた新人は変なクセがついてだめだ。なにも知らないやつのほうが素直で教えやすい」みたいなことをいいがちだけど、これって新人にも自分は負けるって自覚があるからその防衛反応だろうし。

認定というか免許制度にすれば、とりあえず、そういう素人レベル排除できるのにって妄想してしまう。

2014-07-10

http://anond.hatelabo.jp/20140710082319

そんなことないよ。シリコンバレーエンジニアの数も求職数もものすごく多く、裾野がかなり広いので、実力レベルは上から下までさまざま。博士号なんてもってたら給料が高くなるから雇用側もあえて学士程度を望んだりするケースも多い。すーぱーぷろぐらまーレベルがどうしても必要会社なんて一握りだし。一部の花形企業以外は、実力はそこそこでいいから$80Kで来てくれますありがとうみたいなところは多いと思う。

会社スタンスもさまざまで、純粋CSでやってきた人じゃなくても、新しいプロダクトを作るセンスがあるとか、HTML/CSSJavaScriptに強いとか、NginxとかNode.jsを使って仕事したことあるとか、IT土方だけどJavaだけは人並み以上にできるとか、インディー系で携帯ゲーム作ってたとか、アジャイル開発プロセスに明るいとか、色んなタイプの人が評価される。何か得意なこと持ってれば、そういう人を探してる会社は必ずある。シリコンバレー最先端で尖ってるっていうイメージもあるけど、枯れた技術での固い職ってのも多い。JavaとかPHP仕事なんていくらでもある。Flashですらいまだに結構ある。ほんとに裾野が広い。多くの人が、それなりの実力でそれなりの仕事をしつつ、家族との時間自分時間を大切にして人生楽しんでる。

会社によっては、平均的な日本人の勤勉さを知っていて、そういう面で重宝されるケースもある。世界中から人が集まってるので、勤務態度も様々で、その中では日本人の真面目さは割と有利。まあ、日本人英語しゃべれないとも思われてるけど。逆にちょっと話せればかなりインパクト強い。

結局、

大学高専出てるか(出てないとビザが厳しい)・・・できれば理系、できればCSメジャー

英語で最低限のコミュニケーションができるか

採用したらすぐ来れるのか

くらいじゃないのかね。

2014-04-19

アジャイル開発プロセス

顧客:「お客様向けのシステムが全部止まってるんだけど。なんとかしろ!」

営業:「すみません。原因調査中です。早期復旧を最優先に現在対処中です。」

営業:「はやく、なんとかなんないの?。顧客、怒ってんだけど。」

PM:「すみません現在、原因調査中、及び復旧優先で動いています。」

PM:「なんか、わかんないだけど、早く復旧して。」

プログラマー:「はい。原因調査中です。(なんか休日だけど・・・)」

プログラマー:「原因分かりました。バグです。こうこうしたら、復旧・・」

PM:「復旧優先で、あとで直しておいて、リリース明日。」

プログラマー:「明日法事休みをもらってまして・・」

PM:「はぁ?お前しかからないんだから、お前直せよ。で、すぐにリリースな。」

プログラマー:「・・・

PM:「属人性排除しないお前が悪いんだろ、ドキュメントもないし。誰も引き継げないだろ。明日までにやっとけよ。」

プログラマー:「・・・

PM:「お客さん困ってんだよ。やれるだろ?」

旅立つには十分だった。

2014-04-10

プログラム中級者が感じる関数型の違和感

なんだか話題になってるから書く。

やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。

1 圏論かいらないんじゃないの?

Haskellが短いコードプログラムを書けるというのは分かる。

forループmapやfoldで抽象化する利点も分かる。

それでやりたい処理のほぼ全てがまかなえるということも実感している。

副作用のない小さな関数を合成して大きな関数を作る利点も分かる。

再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。

ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。

むしろ邪魔なんじゃないかと思う。

ファンクターやモナド概念圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。

圏論必要なのはHaskell設計する人であって、使う人ではないと思う。

なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。

Linux上で開発環境整えるのにカーネルコードを読めって言うぐらい的外れだと思う。

いや、知識として持っとくのはいいだろうけど、役に立たんだろ。

2 言うほど新しい機能ないような?

Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語オブジェクト指向言語とそこまで違いがあるような気がしない。

純粋言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。

その無名オブジェクトもっとあれこれデータ関数詰め込めば、いつの間にか普通にJavaC#で使うようなクラスのできあがり。

その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。

関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。

上級者はデザインパターンdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。

デザインパターンオブジェクト指向言語欠点を補うための苦肉の策じゃないよ。

関数プログラミングの基礎的なパーツだと思う。

からちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。

3 なんか選民思想にとらわれて無い?

関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。

もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。

けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。

役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。

せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。

開発プロセスとかを見直す方が仕事を楽にしてくれるんじゃないのかな?

ログイン ユーザー登録
ようこそ ゲスト さん