  |
はてなキーワード: シニアとは
3人のソフトウェアエンジニアでチーム開発をしているんだけど、3人には技術レベルに差がある。極端に表現するなら、一人がシニアで、他がジュニアレベルだ。こんな構成だともちろん一人しかいないシニアがコードレビューで時間がかかってしまうし、レビュー時の真意が必ず伝わることもないので、シニアから苛立ちを文面から感じることもある。ジュニア側もきついよなーと思って見ている。シニアが孤軍奮闘しているこの状況に継続性もないし、新しい人が入っても同じように、シニアから自信を奪われてすぐに辞めるんだろうなと思う。優秀なエンジニア、ハードル上げすぎ問題あると思います。事業のフェーズによるが、メンバーをスケールしたい時にシニアがいると足を引っ張るよ、という話です。つまり、インターンを安く使ってぴよぴよコードを書かせるのは合理的だ。
特にマネジメントの一部も持っていってくれるSIerさんのレビューがきつい。いや、ありがたい一面もあるんだけど…
特に、アサインされたての発注側/受注側エンジニアからの指摘が非常にしにくい。急に来て「何こいつ」と思われないかどっちも不安になる。
双方、同じ会社の人からのレビューであれば、成長を促す目的で実装者の視座を高めるようなコメントをして考えさせる余地を残したほうがいいと思うが、他社の人からそんなコメントを貰っても「何様だよ」と思われそうで思っていることを長々と全部書くことになる。
その結果、発注側のエンジニアの意見ばかり通ってしまう（こういう言い方したくないが、SIer努めでもここで発注側に噛みつけるくらいの人であればどんどんキャリアアップしていくという肌感がある）。
成長みたいな余地が、会社同士で閉じているのがもったいなさすぎる。だからといって、受注側が開発したコードを受注側のマネジャー・リード・シニアの人だけがレビューするわけにも行かない。
発注側のレビュアーの技術力もジュニアレベルだと、指摘内容に抜け漏れがあった場合、受注側が言われたとおり実装しちゃって後で問題になる、みたいなケースも往々にしてある。すべてリード・シニアクラスのレビューができればいいんだろうが、それができないから外注するわけなので現実的には厳しい。
準委任契約だからといってうまくいくんじゃなくて、やっぱり受注側のエンジニアがプロジェクトに「精神的に」どこまでコミットしてくれるかで、こっちもぶっちゃけトークみたいな指摘ができる気がする。発注する側だけがあけっぴろげでも、場合によってはパワハラと思われかねないやり取りに発展しかねないし、やっぱり大きく出にくい。難しい。
「書評が書けない」という投稿を読んで、いつか自分が言語化したいと思っていたことだったので整理したいと思います。
https://anond.hatelabo.jp/20211010201513
---
https://anond.hatelabo.jp/20211010213345
これはこれで少し躓いている人には良いアドバイスだと思うのですが、
私の「書けなかった」のはかなり深刻なので、下記のブコメに納得していたところもあります。
そのため筆を執る気になったということも付記しておきます。
----
こういうのは「得意だったタイプ」の人のアドバイスよりも、「壊滅的にできなかったけど教えてもらったらそこそこできるようになった」みたいな人のアドバイスの方が欲しい気がする。|「なんとでも書け」ないんだよ
----
私も大学生の途中までレポートが全く書けませんでした。そこそこの大学に通っていたのでそれなりに学力はあったとおもうし、その後書けるようになってからは書くことが楽しくなって今ではムダにFacebookに長文を書いているぐらいなので、つまづきのポイントは自分の中では明確になっています。
私の場合の結論から書くと、「読み手がどう思うだろうか」「読み手が気分を害さないだろうか」という配慮が働きすぎて、怖くて文章が書けない（主張ができない）というものが原因でした。
自分は少し毒のある家庭環境で育っていたので、正直に自分の考えたことを吐露すると家族に叱られる。みたいなことがよくありました。（今となっては少し社会的配慮が足りてなかった側面は否定できませんが。）
今回の「書けない」方の状況に必ずしもマッチしているかどうかわかりませんが、参考になれば幸いです。
一般的に対話において過度な配慮をするような性格の持ち主は、日常的なコミュニケーションでもつい遠慮がちに話したりするので聞く側もそれなりの配慮が必要になるケースもあります。
何れにせよ、そういう性格、気質の持ち主の場合は「自由に書いていいんだよ」ということを伝えても内在する遠慮が邪魔してなかなか改善されません。
私の場合問題の解決につながったことは、私の場合は大学の途中でマーケティングリサーチの会社でアルバイトをするようになったことがきっかけでした。
最初は報告書に使う帯グラフなどをExcelでシコシコつくるような作業をしていたのですが、その後の工程でその集計結果を見てかんたんなコメントを書くようになりました。
「ウマ娘をプレイしている人についてみると、女性より男性が20ポイント高い」みたいなコメントです。このようなほぼ事実を記述する内容はほぼ怒られる心配はありません。
単純な文章ですがその作業を任されるようになって楽しくなりました。
一般的なマーケティングリサーチの報告書ではそれらの単純な集計結果を統合して、「ブリーフィング（まとめ）」を書きます。
これはそもそも調査の目的が、いまとある商材を売っているメーカーが今後どんなプロモーションをしたらもっと売れるようになるか？みたいなケースが多く、ある種の問題意識や仮説が明確です。
その仮説を検証するためにアンケート調査を設計して、結果を分析しているので概ねまとめは書きやすいものが多いです。
もっともまとめはある程度シニアなリサーチャーが書くので、バイトが書くものではありませんでしたが。
私はこれらの経験・作業を通じて、自分の意見を主張する、考えを披露するということに関する自分なりのパターンを掴みました。
整理すると下記のようになります。
４）解釈をまとめて、問題意識に対する自分なりの見解を書くこと。
結局、私はバイトで経験したマーケティングリサーチが面白かったので、その後色々あってアンケートやスクレイピングデータを用いた実証的分野の大学教員になるのですが、文章を書くときの考え方の基本は一緒です。
もっとも、実証的な研究というのは論文の価値にしめる実証データの存在が大きいので、上記の考え方を当てはめやすいですが、実証という考え方が存在しない読書感想文や書評のケースでは困ってしまうかもしれません。その場合の「事実」はその本に書いてある表現や書き手の主張として考えてもらえると良いのですが、自分が大学教員としてレポートを指導していても書けない学生にはなかなか伝わらないことも理解しています。
そのため、下記のような思考実験をやってみてもらえませんか？
A）自分が興味がある対象を選ぶ（漫画でも鉄道でもいわゆる趣味と呼ばれているものが良いと思います。）
B）その対象において自分の選択を振り返る（例：少年漫画より少女漫画が好きだ。）
C）その理由について考えて、構造化する。（自分が少女漫画が好きな理由は〇〇である。）
世の中の読書感想文のよくある問題は、読み手が全く興味がない本でも読まされて何か意見を表明しなければならないことだと思います。
すくなくとも、同好の士との対話を想像して、自分がそれなりに語れる（周辺知識と単語が内在している）ジャンルを選んでください。その語りの内容をテキストに落とすことを考えます。
もちろん書評の場合は、自分が興味のある本をA）の対象にしてください。
また、読み手の読解力に比べて記述内容が難解な本の場合はなかなか感想が出ないことも一般的だと思います。
（例えば村上春樹は私にとって面白い小説であるが、感想をかけと言われてもとても困る題材だったりする。そのあたりは個人によって異なる。）
Withコロナの時代になり、私もフルリモートで勤務していますが、知識労働としての適切に文章のまとめられる能力はますます重要になってきていると思います。
少し書評とは異なるかもしれませんが、元増田さんの書けないが改善されることを願ってやみません。
知恵袋やってたときは哲学カテやシニアカテの中での常連質問者のキチガイっぷりが自分の中で存在感を大きくしてたんだけどなあ。
ここでは俺が有名人だと思ってたtwesgiや白鳥には全然言及されない代わりに日々表現の自由とかフェミみたいな話題で血気盛んな感じで議論が戦わされてる。
また数年経って別のサイトにはまったらまた別の印象を持つんだろうなあ。
何が言いたいかっていうとネットは平和とか殺伐としてるとかそういう印象ってツイッターのタイムラインに代表されるように全部観測範囲問題でしかないよなあってこと。知恵袋で質問しまくってたころは増田で話題になってるようなことは頭の片隅にもなかったというかそもそも知識として無かったもんなあ。
アホは田舎の小金持ちと一緒にきゃっきゃ愛国ごっこを出来たら満足で
つか、日本よりも社会活動家が武闘派で日本よりも公正な欧米でも
年がら年中、ITを始めるのは遅すぎるか？とか増田でやってるので
何歳からのチャレンジも遅く無いの増田で引用したblogの人は
日立でめっちゃ社歴が長かったシニア・マネージャーだったみたいだぞ
その経験を持ってなお、手を動かせれば職はあるかなぁ程度の様だ
💻 56歳のプログラミング初心者 💻 としての自分を完全に受け容れられるようになる前の私は、
クリティカル・インナー・セルフ（内なる自分）と上手く付き合わなければならなかった 🙄
内なる自分：なんでこの年でプログラミングの勉強を始めたんだい？
わたし ：本当に言いたいのは、あとどれくらい生きられるのか？
そして、プログラミングで稼げるだけの時間が本当に残っているのか、だろ？
わたしはアメリカ人だから平均寿命は 78.8 歳だ。とするとまだ 22.8 年生きる可能性が高い。
20歳の人間からするとそんなに長いとは思えないだろうけど、わたしは56歳でストリートで踊れるくらい元気だ。
内なる自分：すべてのテック企業は大学を出たてのガキを雇いたがるものじゃないの？
わたし ：それは大した問題じゃないな。わたしはシリコンバレーに住みたくもないし、巨大なテック企業で働くつもりもないから。
内なる自分：今やってること全てが時間の無駄ではないと言い切れる？
わたし ：本当はこう聞きたいんだろう？
「もしプログラミングを学んだ後でフルタイムの給料をもらえなかったらどうするつもりなのか？」と。
わたしの答えはこうだ。
「だから何だ？」
ーーーーーーーーーー
【原文】[Next Avenue] VM Vaughn - 56 and Learning to Code
https://www.nextavenue.org/learning-code-56/
【日本語訳】[Medium] 56歳からコードを書き始めて食べていく方法
「やめとけ」と叫び続ける内なる自分とひたすら言い争ってみました
https://medium.com/japan/i-am-learning-to-code-at56-37054b5dc8ce
そんなこんなで、組織に向いていようがいまいが全力で組織にしがみつく方針は維持しつつも(外資か公的な仕事になるだろうな)、
その時に日本がみんな貧乏だったら中国か新興国相手のビジネスをしなきゃならない
高校野球。夏ですね。
かくいう私も数年前高校の野球部でマネージャーをやっていました。
推薦枠なんてないし、地元の中学とかシニアとかで野球やってる子たちが集まる普通の部活。
とは言え、練習は平日授業が終わって（16時くらい）20時まで、土日は練習試合が必ず（遠征とかもあるので朝から夕方まで）と言った感じだった。
強豪校に比べたら練習時間も少ないのかもしれないけども、私の高校の中の部活では一番練習時間も長くキツかった。
高校時代ほんとに部活のメンバーの方が家族よりも長い時間を過ごしたんじゃないかってくらい。
マネージャーの仕事はおそらく漫画とかドラマのそれで大体合ってると思います。
ドリンク作って、練習に使う道具とかマシンを準備して、練習が始まったらマシンにボールいれたり、ノックのボール渡ししたり、試合形式での練習でボールカウントをしたり
ちなみに私の学校はユニフォーム洗ったりとかはなかったなあ。家でお母さんたちが洗ってましたね。
甲子園なんて行ったことないし、予選も２回戦勝てたら全然いい方って感じ。
渡したらわりと喜んでくれて嬉しかったのを覚えてる。
私は甲子園に憧れて野球部のマネージャーになったので、地元の弱い公立高校なんて試合の時の応援もブラスバンドなんていなくて、部員も少ないし（全体で３０人いない時もある）ベンチに入らない数人の部員たちと応援歌を声を出して保護者の人たちと応援したり、、、、
私が入部する前の想像とはだいぶかけ離れていたけど、マネージャーやらせてくれてありがとう！
甲子園は当たり前のように行けなかったけど、遅くまで練習したり、大会の関係で学校行事に出られなかったり、ミーティングしてもただ無駄話してるだけだったり、あなたたちのマネージャをやれて良かったな。
マネージャーって当たり前だけど選手がいないとできないもので。マネージャーにならせてくれてありがとう。
