  |
はてなキーワード: フレームワークとは
誰も言っていない
ただ、面接などで俺はできるやってきたと言うやつは山ほどいるので
じゃあフレームワークは？等の質問でゴリゴリやって怪しいやつは弾くのが業界標準なわけ
細かいこと聞くと大体バレる
いやフレームワークも使わないで素のPythonでファイルサーバーにファイルをあげるクローラーをマイクロサービスって言う人君しかいないよ
真昼間に書いてんのも君だし
https://anond.hatelabo.jp/20240530065636
はてな民がこれ毎回完全に間違えてるのを訂正しても一向に直らないんだけどさ
今どきのはてな民はブルデューも読まないとかマウント取るつもりはないけど、ググればわかることですよね？AIに聞くのでもいいけどさ
Objectified:楽器、絵画、本など、物理的な実体があるもの。物理的な資本
Institutionalized:学歴などシステムが担保するもの。制度化された資本
Embodied:能力、センス、言葉の使い方など、ハビトゥス。身体化された資本
だが結局どれもそれが最終的に「個人」に紐づいて継承され再生産され格差を生み出しっていうところが一番の論点なわけ。
「東京」vs「地方」みたいなまとめブログのネタみたいな糞みたいな解像度の話を何回やっても意味も価値もない。
東京の世界ランクなんかよりまず気にするべきはお前の世界ランクだ。
いや本気で学術的にやれば多少は意味はあるかもしれんが、お前らが目の前のレスバに食いつくのは
自分の置かれている現状から目をそらすために使ってるに過ぎないからしょうもない。
実際に東京/地方で実際にお前やお前の子供は何にアクセス可能で何を継承して何を保有していて何の能力を身につけたい/身につけさせたいのか？
そんな話はしたくない？
githubでなにか作ったものをアップロードするのは、自分向きではないことに気がついた。
私が仕事で作っているようなwebアプリケーションというのは、誰でも使える一般性の高いものではなく、もっと特定のビジネスに依存した特殊なものである。
だから一般的な誰でも使えるようなものを作るというのにはあまり慣れていないのだ。
なにか作る場合はkaggleのほうが遊び場として向いていると思っている。
kaggleで「コンペ」に参加するつもりはないし、あれはBERTが出現したぐらいからは、少なくともNLP(自然言語処理)界隈は不毛な場となってしまった。
指標があれば不毛なハックがある。それが現実というものである。
それに業務で実用レベルで使えるモデルというのは、もっと運用のしやすいシンプルなモデルである。
モンスターアンサンブルで精度がSOTAでーすピロローン！なんてことには興味がないが、コンペはそれを目指している。
ではなぜkaggleが良いかと言うと、データセットが転がっていて、notebookも簡単に作成できるからである。
「このデータをこうやって使うとこういうツールが作れる」「このデータをこうやって分析するとこういう知見が得られる」というのは、「web開発用のMVCフレームワークを作ります」よりも具体性がある。
そして特定のデータに対するモデリングをするために論文を調べるようなことになった場合は、勉強にもなる。
私は昔、自然言語処理のブログを書いていたが、実験したことのコードを載せるタイプの記事が多かった。
ところが自称データサイエンティストや自称NLPエンジニアがツイッター上で「ゴミのようなブログを書くな」と言っていて、自分が言われている気がして怖くなったのでブログを閉鎖した。
そういう「政治おじさん」との接触を最大限減らすには、ブログというフォーマットではダメだと思うわけである。
私のマグカップには"Talk is cheap, show me the code."と書かれている。
これはリーナストーバルズの名言だが、政治おじさんが近寄らない場所というのは、具体的なコードが存在する場所であると言えよう。
IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。
SESを脱退し、そこそこ大手のIT企業の正社員になれた。しかし、そこはこれまでのSESで客先常駐していたような企業とは違い、あまり体制的には良くはなかった。
工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。
1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。
工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計、実装/単体テスト、結合テスト、総合テスト、などのサブ番号に分割して、工数を登録することである。
さらにセキュリティ教育などは個々の案件と無関係なことが多いので、維持管理用の工数番号が振られていることもある。
リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。
さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業したかを15分単位などで記載する。
工数管理のいいところは、作業をサボりにくくなることだ。作業効率が客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。
工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベルで工数を消費する。あとトイレなどにつける工数などもない。
しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。
その形式上すら煩わしいらしく、若手の意見をバリバリ言う人から、
・工数管理は全く意味がない。適当な工数を入力していても誰もチェックしていないのか、何も言ってこない。
・工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システムは不要である。工数管理システムと勤怠システムを一本化すべきだ。
などの意見が出ていた。
そりゃあ工数管理が根付いてない企業に工数管理を行えばそうなるでしょう。
工数管理は業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。
結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。
つまり、当社はよく言えば従業員の意見が通りやすい、悪く言えば従業員のわがままが通ってしまう企業なのだ。
従業員の意見を尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務は改善できない。
これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。
工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員のわがままが通ってしまうのだ。
(まあ当社の工数管理はテキトーだからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的に業務は改善していたと思うが。)
PDCAはPlan, Do, Check, Actionの頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。
実行した後は必ず振り返り(Check)を行いなさい。
当社もPDCAの概念はあるし、週報という形でそれを実現している。
しかしその概念は根付いておらず、週報以外ではPDCAは無視している。
つまり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。
振り返りも当然実施しない。実行のみがある。Do, Do, Doである。
これは作業者レベルでそうであるし、案件レベルでもそうだ。案件はたしかに最後には振り返りの資料を作成する必要がある。しかし、これは単に作成しなきゃいけないから作成してるだけで、綺麗事をまとめた振り返りである。
本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去をグダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽な対策が記載される。
当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。
私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの？」と詰められて終わりだ。指摘するなら十分な資料の作成と具体的な対応策の準備、そして責任と人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。
と書かれていた。
本来は、業務改善は個々のチームだけの問題ではないので、上層部でマニュアル化してルール化すべきではないのか？
アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか？
それをなぜ、個々のチームに依頼する？
業務改善といえばマニュアルの作成や設計書フォーマットの作成だ。
それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである。
しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。
フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。
当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。
これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者に相談しやすくもなる。
こういった業務改善は本来は上層部が率先して枠組みを作るべきだ。しかしやらない。
上層部に知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。
当社はとにかく従業員の声が大きい。強い。
業務改善などの施策を出しても、従業員が納得しないと続かない。
そういう文化を変えるのは並大抵のことでは出来ない。
環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。
仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。
仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。
2024/05/15 10:48
工数管理すべきなのは、成果物ではなくサービスを提供する人なのかもしれない。例えばPMなど。
当社の開発チームは、開発者やPM以外にも、君必要なの？何やってる人なの？打ち合わせには参加してるけど、ただの工数食い虫じゃね？みたいな人もいるのです。
使ったことがないのならまずはオズボーンのチェックリストを使おう。
手っ取り早く例を挙げる。
あなたの脳内でいつもあなたを励ましてくれるかわいい女の子の魅力を書きたいとしよう。
1. 転用してみる
かわいい女の子にさらに魅力が追加されるとしたら、どんな属性があるか考えてみよう。
元々想像していたのが黒髪で巨乳で運動神経が鈍い料理上手な女の子だったとする。
ここにさらに他に得意なモノやコトがあるとしたら何があるか考えてみるといいかもしれない。狙撃とか。読経とか。
2. 適合・応用してみる
料理好きのかわいい黒髪女子に匹敵する魅力のあるモノは他に何かないだろうか？
かわいい料理上手な黒髪女子に対抗意識を燃やす平行四辺形や水死体が存在したら、何が起こるだろうか？
3. 変更してみる
黒髪で巨乳で運動神経が鈍い料理上手な男の子を登場させてみるとどうだろうか。
4. 拡大してみる
ネタを壮大にしてみよう。
死神が宿る漆黒の髪をなびかせ、アカシックレコードを秘めた乳房を持ち、家の外に一歩も出たことはないがその腕が生み出す料理は建物を土台から吹き飛ばすことができる宇宙一の美少女の話にしてみたらどうだろう。
5. 縮小してみる
逆に控えめにしてみよう。
茶色っぽい黒髪が特徴で、やや胸が大きいことを気にしていて運動はすこし苦手だが料理人の父を持っていて料理上手になりたい女の子である。
なんだか急にリアリティが生まれて、これはこれでなんだか物語性を感じないだろうか。
6. 代用してみる
元ネタを直接書かない、登場しないとしたら誰が代わりになるだろうか。
例として「黒髪で巨乳で運動神経が鈍い料理上手な女の子」に恋する人物、例えば前頭三枚目になりたくて異世界から来た不死鳥の甥がいたら、どのような主人公になれるだろう？
7. 再配置してみる
例えば、巨大料理を作りたくて市民運動をしている乳牛大好きな色黒の女の子がいたらどんな物語が生まれるだろうか？
8. 逆転してみる
金髪で低身長で運動神経がいい料理下手な男の子を登場させたらどんなシナジーが生まれるだろうか？
9. 結合してみる
いままで挙げたアイデアを合体させてみよう。
例えば、黒髪で低身長な平行四辺形の猫が市民運動を展開する前頭三枚目の乳牛に恋をしてアカシックレコードと水死体を料理する話があったとしたら、それはどのようにドラマチックにできるだろう？
いかがだろうか。
「黒髪で巨乳で運動神経が鈍い料理上手な女の子」という例から少し極端なアイデアを作り出してみたが、ありふれたフレームワーク（オズボーンのチェックリスト）を使うだけでも恐ろしいほどにたくさんのアイデアを作り出せることがわかっていただけたと思う。
ここまで極端でなくても、身近なものを上記のように捻るだけでいくらでも書きたいものが生まれると思う。
あなたが仮に政治に興味があるとしたら、自民党の党首が仮にアメリカ生まれのブロンド美女だったらどうなるか、考えてみてもいいだろう。
野球なら、横浜ベイスターズを異世界魔導ギルド球団に、読売ジャイアンツを異世界冒険者ギルド球団に置き換えたらどのような選手構成に置換できるだろう。
もっと身近なもの、例えばXとInstagramとTiktokが巨大大陸だとしたら、それぞれどんな民族が住んでいて、どのような文化を形成しているだろうか。
思い返してみれば、上記のような「少し違う」何かを混ぜたフィクション作品はたくさんあると思う。
他にも似たようなアイデアを生み出すためのフレームワークはたくさんあるので探してみてほしい。
時代はつねに進み、移り変わっているので、新鮮さやなつかしさも同じように少しずつ移り変わっている。
