  |
はてなキーワード: 工数とは
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以外にも、君必要なの？何やってる人なの？打ち合わせには参加してるけど、ただの工数食い虫じゃね？みたいな人もいるのです。
社会人になってからのぼんやりした目標でITを極めたいという思いがある。
一分野に特化したタイプではなくIT領域におけるオールラウンダーのような総合格闘家のような存在。
まずITを極めるとは具体的にどういう状態なのか。そのためには何をすればいいのかを考察する。
まずITを主要トピックに大別する。必ずしもMECEではない。
そしてどういうことができたらITを極めたと言えるかを思いつく限り列挙してみる
次は具体的に列挙した例について解像度を上げてどの要素に分類されるものかを考えた上で、それを極めるには何をすればいいかを考える。
https://twitter.com/satetu4401/status/1788854969711661464
一連のポストがあまりに的外れにも関わらず、「ほんまそれ」「耳が痛い…」みたいな反応があって、お前ら騙されるな！と思ったので書く
なお、私は仕事でバックエンド開発やデータ解析を行っている者です(要するにITエンジニア)
確かに経営者は「仕事をしたら給料を払います」と言うけど、それは労働者との契約なので断言するのは当たり前です
確かに飯屋は「この新商品は美味い！」と言うけど、美味いかどうかって個人の感覚によるので、実はこの発言はあまりリスクを取っていないです
「今月中に納品します！」と断言してきっちり今月中に納品する、これは信頼に繋がります 「今月中に納品できるかもです」と言って今月中に納品するよりも心証は良い
でも、普通の不織布マスクが「100%花粉を防げるマスクです！」と謳ってたらどうでしょう？
法律うんぬんを一旦置いておいても、100%花粉を防げるとは考えにくいし、な〜んか胡散臭いですよね
このように、断言することが誠実さに繋がらない場合もあるわけです
そしてデータや理論に基づいて仕事をする人は、「断言しない誠実さ」を示すべきシーンによく遭遇します
じゃぁ技術者は断言しないのか？と言うとそんなことはなく、しかるべき時にはちゃんと断言します
PL等から「すまん！来週までの予定だったタスク、今週中に出来ないだろうか…いろいろ手を尽くしたのだが」なんて言われたら、覚悟を決めて「今週中にやります」と断言しなんとか今週中に終わらせることはあります
今週中にできる確証はないにもかかわらず、です
「責任から逃れ」続けている技術者なんて少数で、場合によって使い分けてる人が多数なはずです、少なくとも弊社はそうです
.
さて、他にも有言不実行は危ないーとか調査に必要な工数がーとか言いたいところだけど割愛します、なぜなら一番言いたいのは↓これだから…
そもそも、砂鉄自身が「根拠の薄い断定」をするキャラとしてフォロワーを集めた人間ですよね
「自分が成功した方法は人にも適用できるはず」と考えるバイアスが働いていたとしても不思議じゃないです
そうじゃなくても、「あいまいな言い回し」について何かフォロワーが喜ぶ言説を言えないかな〜とインフルエンサー砂鉄として考えた時、自然とこういう論調になるでしょう
インフルエンサーが自分にとって耳触りのいい考えばかりを言っている時は、自分が手のひらで踊らされている可能性を考えたいものですね
.
.
.
てなわけで、砂鉄の一連のツイートは一つの偏った考えに過ぎないので、みんなは鵜呑みにしないようにしようね！
数年前転職してきた（具体的な年数は記載しない。「a few years」の数年前）上司が飛んだ。もちろん形式上は通常の手続きでの自主退職だけど、引き継ぎなども特になくクロージングもなく「いなくなった」。
私もサラリーマン人生長いから、今まで「鳴り物入り」の同僚や上司が来て、淡々と去っていくのを見てきた。中でも今回の「飛び」は印象深かったから、個人や場所を特定されない話として残しておこうと思った。
推薦図書を全員にメールで送ってきた。結局ほとんど誰も読まなかったらしいけど、私は「上司の推薦図書＝実質義務」だと思っているから、アマゾンの中古本と図書館で借りることで一冊（アマゾンでも高かった）除いて全部読んだら「本が好きらしいので」と5冊持ってきて結局「義務」が私だけ5冊増えた。想像つくとは思うけど結局「読まなかった人へのペナルティ」も「読んだ人へのアドバンテージ」も特に無かった。もちろんそのあたりも最初から想定していたので特段の感慨はない。
感想？「何冊かは『読む』本じゃないよね」ということ。
仕組みやシステムを構築する時、困ったり抜けを確認するために該当箇所に当たってチェックする本だなというのが感想。
就任後一ヶ月くらいで、私を呼んで分析用のデータの作成を指示してきた。
「網羅すべき内容は？」「全部」
「どのくらいの期間で？」「できるだけ早く。3日位で」
これを聞いた瞬間に感じた。
（ああ この方自分で読んでそして我々に推奨してきた本の中身を理解してない）と。
推奨図書のうち一冊には「なんでもそうだけど 内容を明確にして対処するのが一番大事だよね」的な書物があったんだけどな、ついでに自分の仕事人生の中で「全部」と言われたデータが役に立った例は古今東西あった例はないな…と思いながらデータを取りまとめる。
…想像通り3日で作ったデータは死蔵品と化して、最後まで日の目を見ることはなかった。
推薦図書の中に「全てのデータを取得してアウトプットして活用する」的な本もあった。
だけど上司のアウトプット＝資料を殆ど見たことがない。強いて言うなら文字位置がガタガタなPowerPoint位と画像貼り付けノートとして使われてたEXCELくらいかな。
データ使いこなすと言うならまずはMicrosoft Officeを使いこなしてほしいかな、と思っていたけど流石に直接そう話すわけにもいかなかった。
予感はしていたのだけど「ここ（現業）は◯◯が低迷し…」から始まった瞬間、皆の顔が微妙に歪むのを観察していた。私も現職で数社経験しているから身にしみて知っているのだけど、私が努めてきたどこの職場でも「課題も問題もある。それは皆わかってる。でも別に好きでそうなってるわけじゃないし誰かがサボってそうなってるわけでもない」。そこまでの経緯や体制など色々な原因が横たわっているからそこを改善しないとどうにもならない。それをさも「怠惰」が原因であるかのように話をしてもどのプレイヤーも得をしない。
予想はつくと思うけど、その後も会議はたくさん招集された。だけど上司から出てくるのは「課題」「問題」「事象」。いや、上司に求められているのはその3つに横たわる「原因」を分析する能力なんだ。それら３つはもう全員が理解してる。だからすぐに「会議を開くこと。そして上司の話を聞くこと」が会議の目的と化した。そして上司は目的語が大きかった。業務を遂行するうえで、顧客のどの層を想定するかは割と大事なポイントなのだけど、常に上司の口からは「お客さん」というワードだけが出てきた。それとなく傷つけないように目的語を会議中に修正した事は何回かあったけど結局最後まで変わらなかったな。
私の嫌な予感は的中し、上司の話を聞き流す人が着実に増えていった。
その結果どうなったか？上司はコミュニケーションの機会そのものを自分で減らしていった。立場上忠実（にならざるを得ない）直属の部下のみを招集しての会議のみがやたらと増えた。直属の部下は上司との会議のすぐ後に他部署との会議や自分の業務を抱えて辛そうだった。そのなかで上司はいつも5時になるとすぐログアウト。そして退社するのがルーティンになっていた。
いいか悪いか、は別として、現職の経営層は管理職に「プレイングマネージャー」であることを望む傾向が強い。仮にプレイングマネージャーでなかったとしても、課題も問題もあるわけだから暇な訳が無い、だからポジションを募集して貴方が来たんでしょう？と思うのはごく当たり前のこと。だから「イマイチ何をしているのかわからないが毎日定時で退社する上司」が現職の職場で目立ち始めるのに時間はかからなかった。
私の現職の部署はやや職場の位置が特殊で、本社の中枢部分に数人のデスクがあり、分館みたいな所で私を含む大部分のスタッフが働いている。
そんな中で、上司は分館の会議室に脇目もふらず直行して会議だけ行い（内容は少し聞こえてくるのだけど、何かが決まっている雰囲気はあまり感じられなかった）会議が終わるととてつもない速さで分館からいなくなり、分館スタッフと話す事は殆どなくなった。
コミュニケーションを嫌がる（怖がる、かもしれない。少なくとも私にはそう見えた）ものだから、メールの返信もいつも一行から三行位。「ふわっとした」疑問形で返されることも多かったから、メールの案件が上司が介入した結果結論に到達せずに途中で止まってしまう事が多かった。
承認書類も途中で止まるようになった。上司の承認が止まるものだから業務も案件も滞る。その中で招集された会議で上司の承認待ち案件について「あの案件が停滞しているのは何故？」という発言が当の上司から出てくるというギャグみたいな状況に数度直面した。
でも両方とも魔法使いじゃない。外部業者やコンサルと打ち合わせを行うと、初回で外部業者が必要しているデータをそもそも持ち合わせていないことがわかり数回の打ち合わせで大半が立ち消えとなり、事前検証や打ち合わせの時間分の工数が消える結果となった。
おそらくは経営陣側が「上司の力量に一旦は任せてみよう」という判断になったのだと想像している。その一方でこうも思った「後日経営陣は確実に費用対効果を確認してくるだろう。まあ私が問われるわけじゃないからいいけど…」。
良くなかった。
基本的には与えられた条件の中で新たな費用を発生させないことを前提としているが、どうしても少額の費用（最近はサブスク的な月1000〜2000円とかの定期支払いが多い）が必要になる時があるが、そういう少額費用の決済が恐ろしく渋くなった。どれだけ費用対効果を説明する資料を作っても駄目。
その中で「稟議通過したこの件だけど、まだまだ足りないからもっともっと金を使うぞぉ」的な資料を見つけてしまいため息しか出なかったのをよく覚えている。
会社は数字でのリターンを求めてくる。でも部下とのコミュニケーション同様「ふわっとした」説明しかできなかったらしい。資料を作って見せるスキルもないからすっかり経営層から「マーク」されたらしい。
その結果、上司が分館に来て誰とも目を合わさないテーブル（デスクではなく）で黙々とノートPCと向かい合って「何か」をして、5時になると姿を消す姿を連日目にするようになった。
だけど一つだけやっておきたいことがあった。
着任後半年くらいしてから「現業の未来像をどうするか」でブレーン・ストーミング会議を行いたいと言われてメンバーが招集されたことがある。
結局はブレーン・ストーミングでもなんでもなかった。
「役員が”将来像”は『A』になると言っているから、皆『A』にするための方策を考えて」だった。
私は基本的に官僚スタッフなので、方向性として示された事をいかに実現させるかに頭を絞るのが職務だと捉えている。だがこの件は看過しているとまずいと考えて話をさせてもらった。「『A』はできない訳ではないのですが、会社の体制と対応そのものを変える必要があり現職の状況には沿っていないと考えます。恐らくなのですが『B』という考え方があり…」とホワイトボードを使って説明した。参加者全員が納得してくれ、上司も「まあいいでしょう」と話をして次の会議予定を設定した。
次の会議になった途端、上司が『A』の話をし始めた。私から「先日お話した『B』の話は役員にしていただけましたか？」と話したところ「役員は『A』と言っているから」の一点張り。結局この将来像は、微妙にどうなっているかわからない状態になっていた。
上司の退職が決まって10日後位のこと。この”将来像”とは別案件で当の役員が来ることになった。別案件とは書いたが、この別案件の作り込み方は”将来像”によって180度に近いくらい作り込みが変わってくる。私もそれで悩んで色々な絵図面を散々描いては直し、を繰り返してきた。
私が事前に”将来像”について役員に直接確認する必要があるよねという話をしていたので、自ずと役員を前にその話題に流れていくことになった。
『B』だった。
私が話した内容とほとんど一致していた。
誤解しないでほしいのは、別に自分の自慢をしたいわけじゃないということ。
少しだけ捕捉すると『A』は「０か１か」の案で、『B』は「濃淡をつける」案。
外部の方からするとどっちも似たようなものに見えるのだが、実際は業務の作り込みから顧客への応対からシステムから何もかもが違ってくる。
恐らくなのだが、役員が『B』で話したのを、上司が忖度して「役員の期待？に応えるためにはもっと厳しくしないと！『A』じゃないといけないだろう」と脳内変換したのではないかと推測している。
念の為だけど上司を責める気はまったくない。誤認や勝手な忖度は初めての案件の場合よくあること。問題はそこからどう修正するかであり、それを可能にするのがコミュニケーションだと思っている。
その会議には退職間近の上司も参加していてほとんど何も喋らなかったが、役員が『B』を笑顔で話している時に上司をちらりと見たところ、ずっと下を向いていた。
会議後、役員は次の会議に向かった。そして上司はそっと席を立った。その時、他部署の方が「◯年前にさっきの話を聞いていればこんなに時間かからなかったのに…」と言っていたのが全てを表していたと思う。
その日から10日間、上司はほとんど別館のテーブルノートPCをおいて「何か」を見ていた。手は殆ど動いていない。誰かと会話する時間は一日10分程度。それでも定例の直属部下とのミーティングは開催されるし、案件の会議には一応「出た」。そしてほとんど何も喋らなかった。
外部業者（ほとんど実現可能性のない案件を相談）から次の打ち合わせの打診がメールで入ってくると「◯◯が設定します」の一行メールで返信が入ってくる。当該◯◯さんに「どう進めます？」と聞くと「話聞いてそれで終わりだねー」と「せやな」で返すしか無い見解をいただき安心した。つまり上司が片っ端から声をかけてきた外部業者やコンサルトのルートはほぼすべてがクローズされるという結果となった。
やっと手が出るようになったのだが、他部署に関わることのため話の持って行き方をずっと考えていた。何とかうまく「敵に回さないよう」話ができた後、上司から話しかけてきて「やっぱりダメだよね◯◯部署。ところでXXのデータには当たってみた？」
‥いや違うんだと。◯◯が怠惰でやっていないのではなく、現職の業務体制で手が出ていないだけでそこに「悪」は存在しないんだと。そして私がやるべきなのは問題提起と提案まで。実務は◯◯に依頼しなくてはならないから、私がXXに当たる意義はほぼないんだと。何より私はただ一件の話をしているのではなく、背後に眠る数百件の類似ケースとその検証に手を回せない体制を改善しようとしているんだと。
純粋な親切心でそこまで言おうかなと迷ったが、意味も意義も無いのでやめた。
（退職メールではなく、普段から自分の口と文章と資料で経営陣とも部下ともコミュニケーションを怠らず「わかってもらう」努力を欠かさなければ結果が変わったかも…）と思いながら返信。
返信した30分後位に挨拶に来た。
聞いてみたところ、メールを出してすぐログアウトしたので返信は見ていないとのこと。
なので私の画面で返信をお見せした。
私の返信を要約すると「理論は大事。だけど現実とリンクさせないと殆ど無駄打ちに終わる」「コミュニケーション不在はやばい」となる。できるだけ親切に描いたつもりだった。
上司からの感想はなかった。「頑張ってください」の一言だけだった。
私も想定内だったので「ありがとうございます」と挨拶した。話を聞く限り返信を返したのは私だけのようだ。
恐ろしいのはここから。
上司が退室して10分後には「なんの支障もなく回る活発な職場」「上司がかつて通した稟議案件は（経営陣が追加コストを嫌気して）廃止になるかもしれないから準備をしておこう、と話すスタッフたち」の姿が。
…そう、最初からそんな人は「いなかった」んだよ。という扱い。
程度の問題ではあると思うんだけど、人間には承認欲求というごく当たり前の感情があるはず。これが怖くない人はいないと思う。
そのために何をすればいいか、という自戒も込めてここに残しておく。
デカいプロジェクトのPMを中途入社1年の奴がやってるんだが、びっくりするような事しかしないからずっとびっくりしてる。
まずツール選定。社内の状況のヒアリングもしている様子は無く当初は「確認するまでもなく把握してるのか〜すごいな〜」と思って眺めてたんだけど単純に何を確認すべきか分かってなかった。当然既存ツールとの連携方法やメリデメも確認していないし開発工数も分かっていない。
見積もりで比較して経営会議にかけたと言うので(事前共有無し)見積書を見せてもらった。5000万の決裁を取っていた。見積もり依頼するための要件が実態に則しておらず、慌てて確認すると恐らく3倍の費用が必要になる。1.5億。なんでこんな見積もりになったのかと聞いたら、「○○さん(部下)が以前別のプロジェクトで使っていた資料から引用した」と。本人に確認は取っていないらしい。それに○○さんのプロジェクトは限定的なものだったので当然見積もり要件も異なる。しかもこのプロジェクトの性質から考えれば○○さんではなく部下にもっと適切な見積もり要件を出せる人がいるのに、その人には何の連絡もしなかったらしい。何故かと聞いたら「なんとなく」。開いた口が塞がらない。
しかし同じ条件で見積もりを取っているならある程度金額感での比較はできるかもしれないと思い、他のツールの見積書を見た。確かに一見高く見えるが、3倍にした時に重量課金分の比率が低いツールもあり、コストで考えると導入を決めたツールの分が悪い。
更に目に入ったのは同僚がPMをやっている別のプロジェクトで使用しているツールの見積もり。関連するプロジェクト同士なので同一ツールを使うのはメリットが大きい。予算も悪くないし、新規導入じゃないので見積もりから削られ項目も出てくる。しかし俺は目を疑った。同僚のプロジェクトを名指しして「○億円の赤字」と書かれている。算出根拠の資料を見たけど、どれもこれも実態に則していない。どこからこの数字から出てきたのか聞いたら「エイヤで出しました」とドヤ顔。
俺も関連するプロジェクトのPMをやっているんだが、危機感しかない。関わりたくない。しかしGW中だと言うのになぜか会社携帯が鳴っている。名前はもちろん例の人。憂鬱。
今思い出しても腹が立つ。
しかし、人間関係に波風立てても良いことないので思いを書き出して供養しておく。
---
私と苦手な彼は同じサークルに所属しており、会員は皆イベンター的な側面を持っている。
そこで私は苦手な彼と出会った。
初対面から苦手な人だな〜と思いつつも、同じサークルにいるから当たり障りなく過ごしていた。
苦手な彼と言いつつも彼は悪い人ではない。
私は苦手な彼の軽口に傷つけられた経験があるので、個人的には発言にもう少し配慮があると良いなと感じる程度。
苦手な彼は別サークルで仲良いグループ作って遊んでるから、私が苦手な側面であっても他の人は気にしない側面かと考え、深く考えることなく距離をとって過ごしていた。
サークル内で「何々が大変だよね〜」とか雑談してる時、「俺のイベントは、あなたのイベントよりも100倍進行が大変」（要約）と軽口を叩かれた。
良い大人だからとその場はスルーしつつも、腹の底に押さえきれぬ怒りを抱えてその日の活動は終えた。
苦手な彼のイベントは、事前準備も大変だし当日もリアルタイムの即興対応の負担が多く管理が大変だ。
私のイベントは、事前準備も同様に大変だが事前準備で大部分は管理できる範囲な大変さだ。
ただ私は、今もハラワタが煮えたぎっている。
感情的な側面としては、私も工数かけて準備して皆が楽しめるようイベント開催運営に腐心してる事実に対し、私の行動が矮小化された気持ちになり私の大変さは大したことでないと、否定された気持ちになった。
それぞれが大変と思ってることに対して、比較する必要があったのか？
反論できたろう。私の大変だと思った内容を理解を図るため、言葉で伝える選択肢もあったろう。
ただ私は伝達する気持ちにもなれなかった。
苦手な彼とは同じサークルで顔は合わすだろう。
---
今回を振り返ると、私は議論が苦手なのかも。
最近仕事では、目的をもって良い選択肢と行動を取るために話し合うスキルを獲得できた。
しかし、今回のように答えのない事柄に対して、相手を説得し合う言葉の応酬するスキルがないのかもしれない。
いや違うな。自分の好きなイベントを議論して自分のイベントを否定されるような結論の可能性もありうるから、結論を出したくなかったのかも。
議論した結果を受け入れ合えるような関係を持ってたら、私は話し合える勇気があったかもね。
ロリータが男ウケしない理由より、お疲れダル着社畜女に男が寄ってくる理由から説明したほうがいい気がするなあ。
端的に言うと、「ヤれそうだから」。
そもそもまず面識のない女に道端で声かける男って「普通の男」じゃないんだよな。
いかに少ない工数でどれだけ効率的に女とヤるかを競ってるような、ナンパとか恋愛工学とかそういう連中ね。
そういう視点で見ると疲れた女ってちょっと優しくしたらヤれそうだなって思うわけよ。
なんならボサ髪目の下クマﾀﾞﾙﾀﾞﾙパーカーとかでも寄ってくるだろうね。
逆につむじからつまさきまでばっちりロリータでキメてる女とかそんなん絶対工数かさむでしょ。そりゃ避けるよ。
普通の男からみたらどうかというと、ロリータはなんか独特の世界観持ってそうだなってみえるんだよね。
当たり前だが、普通の男の場合は断られるのを恐れてるんだよね。
これは女でも分かるでしょ、アプローチして空振りしたら普通にへこむわけで。自尊心が傷つく。
（ナンパとかやってるやつはヤった女とやらせてくれなかった女を見下すことでいびつな自尊心を保ってるわけだけど、まあこれは別の話だな）
逆に、服装がロリータでも女の側から気さくに接すればギャップがウケるとおもうよ。
べつに男にモテたいわけじゃないらしいし、どうでもいいだろうけど。
あと、これはわかってるとは思うが、「見えてる地雷」とか「メンヘラっぽい」とか書いてるのは、アニメとゲームと漫画を摂取しすぎてこじらせたオタク君だから「男ウケ」とは完全に無関係な。
何をどう間違ったのか、超大手のITコンサルタント会社に入ってしまいました。
今までは事業会社でマネージャーをやってました。ITツールはそれなりに使っていて、Salesforceも使ってました。
しかし、これまで開発の経験はなく、自分でPythonとPHPを少し勉強したぐらい。基本情報技術者試験も受験したけど落ちました。
ITコンサルタント会社でマネージャーとして稼働していますが、はっきり言って何も分かりません。
ITコンサルタントのマネージャーというのはどういったスキルを持っている人なのでしょうか？
例えば 新規にプロジェクトを導入したいとなった場合見積もりを出さなければなりませんが全くアタリもつけられません。
システム開発の場合どのようなことを知っていれば 見積もりが作れるのでしょうか？
ITプロジェクトの場合どういったシステムを導入するか、という話になると思います。
特にSaaSであれば、どの製品を使うのか？という話になると思いますが、ITコンサルタントのマネージャーというのはどんな製品であろうと、あるていど見積のアタリをつけられるのですか？
各製品のことを知らなければ、開発の難易度もわからないし、どのくらいの期間が必要か、もわからないと思うのですが、どうやって乗り切っているのでしょうか？
それとも、ITコンサルタントのマネージャーというのは、ある程度ジャンルを限定した経験を、テスターなどから積み上げている人達のことなのでしょうか？
正直苦しくて仕方なく、ずっとモヤの中をさまよいながら仕事をしているような感覚です。
要件定義は当然わからない、開発は進捗がどうなってるか、くらいは確認できるのでなんとか出来る。でもその工数が妥当かどうかもさっぱりです。
一体なにを学べば、PoC、要件定義、開発見積、というのが出来るようになるのでしょうか？
こういう話しをすると、まずお前が何したいか？とかそんな話になるのですが、正直やりたいことが何か？というのも無いです。
ITコンサルタントのマネージャーとしてちゃんと稼働出来るようになりたいです。
例えば、GCPやAWSの資格取得を目指したらある程度わかるようになるのでしょうか？
インフラ系？ フロントエンド？ バックエンド？ いまいち違いもわかりません。
なにかの言語を学べばわかるようになるのでしょうか？
一体、私は何を学べばITコンサルタントのマネージャーとして一人前になれるのでしょう？
知恵袋に投稿しようと思ったけど、はてなの方が経験者多そうだと思い投稿しました。
グリコの件でSAPが話題を目にするようになり、だいたい評判が悪いシステムであるようなのだが、「SAPは経営層のためのシステムであって、末端の社員のためのものではない。統合DBにより経営層が判断をするんだ！」という記事があった。
いやいやいや、SAP導入したとこで、JTCの無能経営陣が何を判断するんだよ(笑)
SAP的な統合システムを導入していれば失われた30年は無かったのか？
どんだけいい情報を揃えても、どんだけ早く情報を上げても、ろくな判断しないだろ(笑)
SAPなんて導入したら現場の工数は増えるのに、「ERP導入したから人減らせるだろ！！！」って"判断”する未来しか見えないわ(笑笑笑
遅れてるって思われたら良くないからって、提出するのは予定どおりに進んでるっていう事前に決まった内容。
逆に進んでるときも、余裕あると思われたら追加の要望が来たり、工数取りすぎとか言われないように予定の通りの数字にする。
そのために数字をいじって進捗率の辻褄合わせてるだけ。
全体工数と今の日付から決まるだけの資料になんの意味があるのか。
そもそも専任で製造なんてしてないんだから、空いてる時間にまとめて製造を行う。
実際の進捗は徐々に上がるものではなく、0%が続いて一気に半分以上まで行って、あとはゆるやかに、100%まで進めるといった形だ。
すごいね
そのへんは工数書けてまでやりたいかとか相手側が決めることだからなー
大手で部署超えて使うとかだと社内のものでも厳しくしたいことはあるけど、そうでもない小さい会社や大きいところでも使用箇所が限定された小規模なものなら割とゆるい感じ
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
いくらRemixやらNext.jsやら最新鋭のフレームワーク使ってても、クソコードで書いたらクソが出来上がるだけだ。
一方、僕が集めてきたプログラマーはプログラミング未経験の頭の良さそうなネットゲーマーだけです。
なので初期のドワンゴは、森さん率いる天才ハッカー集団からなる超強力な開発チームと、僕の率いる廃人ゲーマーによる即席プログラマーメインの弱小開発チームの二つからできてました。
僕と森さんで最初に考えたドワンゴのビジネスモデルは単純で、優秀な僕ら（といっても森さんチームだけですが）は控えめにいっても普通の開発会社の半分以下の工数でソフトウェアを開発できる。
なので、実際にかかる工数の2倍で見積もりを出せば、半分は利益で丸儲けのはずだ、というものでした。
とても簡単な算数ですが、後から振り返るとそこが「理系のずるさの限界」でした。
僕らはドキドキしながら2倍の見積もりを出したんですけど、本当は10倍ぐらい出すべきでした。じゃないと儲からない。実際は想定よりも工数がかかることがあり、2倍じゃ利益出なくてめちゃくちゃ大変です。
ドワンゴが大きくなってから当初のドワンゴぐらい実力があって良心的な下請けが欲しいと、心から思いました。当時のドワンゴが出してた見積もりのさらに2倍の金額払っても、同等の仕事をしてくれる下請けなんて、なかなか見つかりません。
でも、文系経営者の中には平気な顔して100倍の見積もりとか出せる人もいたんですよね。僕らの感覚ではもはやそれは詐欺で、とてもできない。
最近、工数のかかりそうな仕事が舞い降りて、必死になっております。
こういう場合は、見積もりをクリティカルパスの3倍以上にでもしておけばいいのです。
さて、最近趣味を探していた私ですが、何をするにも気力や体力を使うので「食べる」ことが趣味になってしまいました。
といっても、歩きと電車で1時間以内に行ける範囲になるので、店も限られてきます。
トマトラーメンはお気に入りですが、こればかり食べると飽きそうなので他のバリエーションもほしいですね。
インドカレー屋に行くとたまにコカインのような草が入っていて信用できないので今は行っていません。
マクドナルドもお気に入りでしたが、最近は賃上げのせいで質(大きさ等)が落ちています(気のせい？)。
ところで、Dota2というゲームがあるらしいですね、Ubuntuでも実行できるらしいです。
やってみたいと思ったのですが、やはりこれも「気力」を使うのでなかなかやる気が起こりません。
ついこの前まではギターをやっていましたが、近所に下手な演奏が響くと思うと音害だと思うのでやらなくなりました。
「なにかおもしろいプログラムを作る」というのも趣味にできますが、プログラミングは仕事だけで十分です。
自分のミクロ経済学の勉強ノートを公開したWebサイトを作ろうとも思いましたが、やはり「気力」が足りません。
気力がなければ趣味につながらないようです。厳しいですね、世の中は。
長期案件の運用プロジェクトではどのタイミングでやればいいのかわからんな…
まるで九龍城
途中で参画させてもらったからまだプロジェクトリーダーとそこまで信頼関係がない
プロジェクトリーダーも他の案件をやったことがないのか、今まで見た事がない歪さをところどころ感じる
その先のクライアントはあまり開発スキルが無さそうだけど、変に技術者のプライド高いからか根本的な解決方法にならない要件を言ってくる
その両者間で仕様設計をするから工数的には無理がないのだけど、浮世離れした設計だなという感想
このシステムを使うユーザも、以降参画するエンジニアも不憫だな…って思ってしまう
偶々出向してきたエンジニアだからあーだこーだ言うのもアレだけど中々独特な開発環境でハラハラしている…
経験上、突っ込んでいっても碌なことにならないから静観して、自分の意見を求められた時に説得して発言力を高めるのが正解なのかな
気が遠くなる話だよ…
アイドルマスターシンデレラガールズ、もはやバンナムも扱いづらい「お荷物」になってるんじゃないかな
ミリオンライブの39+13人、sideMの49人でもだいぶ苦心してやってるはずなのに、190人分に対して最低限の工数かけつつ収益見込めそうな子で課金促すってスタイルからして無茶苦茶してる
実際ある程度はそれで熱を繋げてきた作品だけど、モバマスが終わってもなお満足できないユーザーの「あれやれ」「これやれ」って声を聞きながら色々やってるの辛いまでありそう
オワコンとまで言う気は無い（言いたくない）けどバンナムも一時期よりたぶん予算絞ってると思うし、それより成長を見込んでそうな他ブランドに力入れるのは当然だ
他作品に比べれば恵まれた環境だったと思うが、それでもまだ開拓しきれなかったとしか思えないしこの先の展開もあんまり想像できないし、先が見えないどころか暗闇に包まれてる気しかしてない
ただでさえ、ボイスが無く、ゲームという場ですら登場機会が少なく、誰かの歌声を聴きながら少ない個別衣装と色んな汎用衣装を着せ替えて踊らせることができるだけまだ恵まれてるって子たちもいる中で、ゲームが終わってキャラビジネスとして回してくとなった時に、
少なくとも今後一回でも「メイン」を張るような仕事に190人それぞれがありつけるかと思うとそんな甘い話は無いだろ
そんな手厚いことを今のバンナムがするわけないと思えるくらい、期待なんかしてない
だからこそ、最近の方針変更でことあるごとにサ終だなんだとみんな言ってるわけだ
あの年末の方針変更のお知らせも、ユーザーは「サ終に向けた準備」と読み取る人がいるとバンナムは理解してるはずだろう
それでもあのお知らせを出した
それが本当に悲しくて
喋ってほしかった、歌ってほしかったとはまだ言いたくない、諦めたくない
ベンダーロックインとは、特定のベンダーの製品を使うことにより、その仕様に合致した周辺環境やコードを設定してしまい、移行が困難になるような現象だ
最近、BigQueryを使うことによってこのベンダーロックインにぶち当たった
「使うにはコストと制限があるから、やっぱ自鯖にしよう」となったわけである
BigQuery特有の機能を別の環境に移行するには大幅な変更が必要になる
ベンダーロックインの臭いを嗅ぎ取ったら早めに判断し、避けた方が良い
もし後から「やっぱこれ使いたくない」と言ってすでに依存状態にあるシステムから移行しなければならない場合は、
BigQueryであれば何らかのNoSQLを使うか、スキーマを無理やり抽出してmysql等に変換する方法もあるだろう
そのようなことを自動的に行う有料のサービスも存在するかもしれないが、新たなベンダーロックインとならないよう、注意深く仕様を見た方が良い
経営者としてお答えしよう
ファック死ね
業務時間を割いてなにかやってるのは知っていが注意すると拗ねてモチベ下げるので黙っているが、管理職には絶対に上げないフラグを立ててるからな
持続可能性
頼むよ、これを意識してよ
仮に５秒短縮が当該業務担当５人、１０回／日だとして年間１６時間。。。
ん？わりとデカいな。
頑張れ
違う違うちがう
どうせ空いた時間は給湯室でくっちゃべってるだけだ
知るかボケ
あのな、頑張って勉強して業務効率化に寄与してくれるのはありがたいが、
オマエ死んだらどーすんの、連想配列が保守メンテできるスタッフ他にいる？
ワークシート上のセル式ならなんとか追いかけられますが、VBAでややこしいことやれたらわかりませーん、だよね？
VBAでゴチャゴチャやられるといざ業務拡大近代化の時に余計な工数もかかるの。
ワークシート上で処理完結してて適度にコメントも書いてくれてたらそれがそのまま要求仕様、ドキュメントになるの。
プログラム化されちゃうと要求仕様はそこから紐解かなきゃならない、そんだけ余分な工数がかかる。
残業して連想配列してるのは分かってるが、さっさと帰って婚活でもして、ブサイクな嫁とアホの子供でも作って、あぁもう迂闊に会社辞められねぇ、ってなってくれたほうが会社はありがたいの。
美しくない？
知るかボケ
どこにどれほどリソース割くべきか
こっちもアホでは無い、経営多変数パラメーターを加味して妥協し方向性と優先順位決めてるんだ
頼むから言う事聞いてよ
