goza(ござ先輩 / YUMOTO Michitaka)
記事一覧
アラフォーエンジニアのリスキリングについての駄文
上記めっちゃわかる。特に自分のような10年前に社内SEやって独立しちゃった人間は「今の現場」を知らないから四苦八苦してる。
40歳になってReactすげーーってなっても、40歳のReact未経験ボーイを誰が取るのよ。他のスタックでWebアプリは作れてもって思う。
自分が幸運(?)だったのは、社内システムを開発する機会に恵まれたので、好きな技術を選んで試せたこと。その代わり誰にも聞けないから、S
ここ2年ほどモダン・フロントエンドを頑張っている話
ただあきさんが振り返りを書いていたので、自分ものっかる。
40の手習いでございますよ。わたくし。
自分の特性として、エンジニアの中では話すのが得意で、文章を書くのも得意だった。プログラミング一本で行くイメージはなく、現場監督のほうが向いているかなーと思ってFA宣言したのが7年前。そこから流れに流れて、今はFlutterを書いている。フロントエンドわかりたい。
モダン・フロントエンドの衝撃Fl
ITプロジェクトを立ち上げる技術はどこで身につけられるのか
この辺が少し言語化出来た気がするのでメモる。
顧客にITによる便益を提供するはずのIT企業で、「こういうITを用意するといいですよ」という要件定義や顧客のコミュニケーションを取れる人間がいない。
要件定義や顧客のコミュニケーションが出来る人がいないって話は、ITプロジェクトを立ち上げるノウハウが組織の中に蓄積できていない、と同じだ。これが答えだと思う。
ITプロジェクトを立ち上げるというか、
受託開発における営業と開発の分離は正しいのか問題について
ケンブリッジ白川さんがこんなブログを書いていた。SIerのような業態に置いて、営業と開発を分離しても意味がないと。もうちょっというと、プログラミングと要件定義は不可分ではないのか、と。
受託開発における永遠の課題である、要件定義とプログラミングの関係を整理したので、共有しておきます。
ソフトウェアの要件に関心があっても、人の動きに関心がある人は少ない
受託開発は、当たり前だけど特定の顧客のた
notionで職務経歴書作ってるー
この前、関東に降った雪。寒かった…
この時期になるとスワローズの自主トレで愛媛の松山の話がよく出る。一度やきうを見にいったけど、すごく良い街だった。独り身だったら引っ越してたかも。
![](https://assets.st-note.com/production/uploads/images/69708172/picture_pc_049d7c95186586884161a4df6d2c5d9b.png?fit=bounds&quality=85&width=1280)
業務改善の成否はマネージャの視座が全て
結論から言えば、業務DXの肝はリソース配分にあります。
業務はリソースとイベントで成り立っています。どの依頼(イベント)をもとに、誰が何を使って(リソース)、どうやる(How)のか。そのバランスで成り立ちます。
人間が入力・確認・判断をしている内容をITが変わってくれる状況を作るために、howを見直してリソースの再分配を図るわけですね。そうしないと、生産性上がらないです。
たまに勘違いしてる
東京ヤクルトスワローズ、日本一!
前評判で弱いと言われてた先発陣が大車輪の活躍で、彼らをリードして常に接戦に持ち込んだムーチョがMVP。
ありがとう、ありがとう。感動をありがとう。バファローズも、ありがとう!
業務改善をする(テコ入れする)ポイントは相場が決まってます
業務改善の支援をちょいちょいしている中で、大体テコ入れする箇所なんて決まってるよなっていう気がしてきたので、まとめとく。
ペーパーレス化による転記撲滅紙媒体でやってきた情報は、何らかの形でソフトウェアに取り込む会社がほとんど。そのため、紙の情報を人間が目視して手で入力する工程が発生する。転記と呼ぶ。これが地味に面倒。
ペーパーレス化の本当の狙いは、紙をPDFにすることじゃなくて、紙媒体で表現し
Dockerでビルドしたイメージから、どのDockerFileを元にビルドしたか分かる仕組みないかなぁ。。。
仕事ができる人が疲弊するわけ
小話なんですけどね、最近そんなことを思わせる事態があったので。
仕事ができる人の定義って色々あると思いますが、1つの側面として「与えられた仕事内容に対して、自分なりの創意工夫を凝らす」があると思います。目の前の仕事をやっつけるという責任感があって、自分なりに試行錯誤できるので、自分なりのノウハウを積み上げられる。
ただ、それが業務を回すという視点に立つと、喜べない側面があって。
自分なりのノ