東京周辺の賃貸料金をマッピングしました - IT業界で気づいたことをこっそり書くブログ
そろそろ引っ越し時期ですね。 私も今年は引っ越さなきゃいけないし、知り合いも引っ越すらしいので、前からやりたかったマッピングをしてみました。 地域の相場感をなんとなく把握するのにどうぞ。 成果物全体 参考にした条件 30平米〜35平米、築30年以内、マンション、風呂トイレ別。 管理費込み、礼金は24分割して足しています。 色と賃料の対応 30万円以上 黒● 20万円 赤● 15万円 オレンジ● 12万円 黄緑 10万円 緑● 7万円 青● 5.5万円 水色● 4万円 白◯ あと、緑の円は大体駅から徒歩10分くらいです。 赤いラインは路線です。 以下、細かな所感 10万円以下に絞った地図 埼玉方面 千葉方面 神奈川方面 東京 主要な路線に沿って分布してますね。 ベッドタウンを見ていきましょう。 大宮 東川口、越谷 西川口、川口 川越方面 柏、流山 町田付近 千葉方面はずっと連なっている、賃料
アプリ開発市場の現状と今後の予想（2023〜2026） - IT業界で気づいたことをこっそり書くブログ
最近、ブログで長文を書く体力が落ちてきているので、かんたんに書こうと思います。 Flutterが流行ってるようです Flutterエンジニアが足りてないようです iOSエンジニア、AndroidエンジニアはなぜFlutterをやらないのか？ Flutterはどのくらい工数を圧縮できるのか？ Flutter案件は今後更に増えるか？ iOS/Flutterエンジニア、めちゃくちゃ少ない説 Android / Flutter / iOSで分断が起こるのでは？ SwiftUI+combineは増えてる？ iOSエンジニアが問われる、SwiftUI or Flutter 結果、人材不足が予想される 新人に期待はできるか？ まとめ 補足 Flutterが流行ってるようです 流行りそうとか、そういう「かもしれない」ではなく。 ベンチャーの新規アプリ案件のFlutter率が明らかに高く以前より上がっている
フリーランスエンジニアの単価と「安すぎる」というコメントの謎 - IT業界で気づいたことをこっそり書くブログ
この記事が目についたんですが。 qiita.com 良いか悪いかで言ったらQiitaでそういうのは見たくないというのは個人的な感想なんですが。それは置いといて、毎度恒例、はてブでは「安すぎる」というコメントが多く見られました。 [B! エンジニア] エンジニア200人に聞いて、業務委託単価表を作りました - Qiita こういう「単価出してみました」に対する「安すぎる」というブコメは何年も前から大量に見つかります。果たしてこのQiitaは安いんでしょうか？ 私は「妥当」派です じゃあこの「安い」と言ってる人達は何者なんでしょうか？ 仮説：会社間の人月単価と混同している？ 会社間の単価、フリーランスの単価、正社員の給料の差 正社員の給料と、フリーランスの報酬はなぜ差があるのか フリーランスの報酬と、会社間の単価はなぜ差があるのか 正社員とフリーランス、額面で何倍の差があるか？ あと、CTOっ
技術的負債ならぬ、仕様的負債について - IT業界で気づいたことをこっそり書くブログ
技術的負債っていう話、プログラマーは大好きです。 こいつらはコーディングの邪魔をし、プロジェクトを遅れさせ、残業を増やします。 だから皆嫌いなので技術的負債をどうにかしようと議論します。 技術的負債 - Wikipedia ただし、概ね技術的負債を減らす術を身に着けてくると、それでもコードの複雑性が解消されないことに気づきます。 リーダブルに作っても、疎結合に作っても、SOLIDで作っても、どうしてもコードがぐちゃぐちゃになり、相当頭がいい人でないと全体を理解できない代物に成っていくでしょう。 あるいは新しく参画した、優秀なプログラマーたちによって作られたプロジェクトのコードが理解できずに悩むことで気づくかもしれません。 技術的負債の他に敵がいるということに。 その一つは仕様側の複雑性の問題です。 多くのプログラマーが気づくけど、中々手を出せず、それどころか議論にすら成りづらい仕様的負債に
転職後２ヶ月目に高確率で揉める説 - IT業界で気づいたことをこっそり書くブログ
わかりやすく転職と書きましたが、正確にはジョイン後です。私の場合はフリーランスなので入場と言ったほうが良いですね。 すでに動いているプロジェクトに中途で入った場合、2ヶ月目か3ヶ月目あたりにそこそこな確率で1回喧嘩になり、その後一定の割合でそのまま退場するという法則に気づきました（揉めるけど退場しないケースもあります） これって私だけですかね？私だけかもしれませんが、他の人でもある気がしてます。 かれこれ10社以上やってきて見えてきた法則です。もう何回これで辞めたことか。 とりあえず2ヶ月目クライシスとでも名付けましょう。 2ヶ月目に揉める原因 ベテランでも発生する 2,3ヶ月目を脱すれば徐々に安定していく 問題は揉めた時の対応 2ヶ月目クライシスで辞めるのってもったいなくない？ とりあえず心構えをしておこう 似たような記事 ベテラン技術者が新しい環境で大失敗した話 - Speaker D
サービス・事業・活動の考え方まとめ：誰をどこまでアップデートするか - IT業界で気づいたことをこっそり書くブログ
メモです。 サービスや事業を考える時に「どういう人をどういう状態まで改善するのか」という観点があると思いますがここについてまとめている情報を見たことが有りません。 ちょっと何言ってるかわからないですね。具体的に書いていきます。 １．「困ってる人を助ける」というモチベーション ２．「誰かの助けにある機能の１つを提供する」というモチベーション ３．「マスに対する改善」というモチベーション ４．「成功者・専門家に対して新しい価値を提供する」というモチベーション ５．「新しい価値・考え方の提供」というモチベーション アイディアを考えても大抵１〜５のどれかに偏る １．「困ってる人を助ける」というモチベーション 援助、介助 恵まれない人を、通常状態にするというモチベーション。 「恵まれない人に救いの手を」というやつです。非常にわかりやすいです。 救助 助けを求めている人を助けるというモチベーションです
ベテラン＋初級者の組み合わせは案外パフォーマンスが良いという話 - IT業界で気づいたことをこっそり書くブログ
システム開発というのは非常に時間コストが掛かる作業ですが、何にそんなに時間がかかっているかといえば、試行錯誤や手戻りに時間がかかっているんですよね。 最初に見積もりする時はだいたい一本道の正解ルートを辿った時のコストで考えてしまいます。 しかし僅かな仕様の差やバージョン差などで、Aという方法で上手く行かないということがあります。それでBという方法やCという方法を試したりして時間が掛かってしまうわけです。 体感ですが、すんなり正解の方法をとった場合のコストを80だとすると、見積もりで100を提示します。予想から漏れていたタスクが30増えて、試行錯誤で30増えます。結果160くらいで60％くらい上振れることが昔は多かったです。 最初に思い切って80の2倍の160と見積もればよかったんですけど、中々難しいですよね。頭の中では正解のルートを選択している想定なので。 実際は、Aルート、Bルート、Cル
ITスタートアップ/ベンチャー企業に就職したい人向け！調達から会社の状況を推測する - IT業界で気づいたことをこっそり書くブログ
一般的に就職するときには、その会社を不変のものと捉えることが多いのではないかと思います。 特に大企業であれば、入った時と10年後でそこまで大きな変化は無いのかもしれません。 しかしスタートアップやベンチャーは非常に早いスピードで変化が生じます。わずか1,2年で別物になり取り組む課題や組織が変わっていきます。 なのでそこに就職したり参画する場合は「今どういう状態か」「近い将来どうなっていくか」を予測する必要があります。会社の成功に賭けるようなものです。 とは言え、外から見てるだけで会社がどうなるかなんてわからなさそうですよね。 そこで重要になるのが資金調達です。 上場や会社売却を考えているようなスタートアップ・ベンチャー企業は似た課題にぶつかり、似たように資金調達をして乗り越えていきます。裏を返せば資金調達から会社の状況がある程度推測できるわけです。 基本の知識 出資と融資の違い 投資ラウン
エンジニアに立ちはだかる3つの壁 - IT業界で気づいたことをこっそり書くブログ
ちょっと考えました。 メモ。 エンジニアは3つの壁があると思います。 これらはどのような方針で攻略できるかでまとめました。 1つは普通にプログラミング知識やエンジニアリングの知識です。発展型として設計力があると思います。 2つ目は、所謂上流系のスキルと細かな開発テクニックの経験値です。 3つ目は、学術的な調査力や、特殊な専門性の高いスキルです。 最も簡単に攻略できるのは「プログラミング・エンジニアリングの知識」 本にも書いていますし、学校でも教わることが出来ます。先輩にも教えてもらえます。 ここらへんは3000時間も頑張ればモノになるんじゃないでしょうか。 ただ、ここの知識だけでフリーランスになるのはちょっと危険だと思います。 どうしても2つ目、3つ目のスキルが要求されてくるのと、フリーランスになってからここを伸ばすのが難しいので、組織の中で頑張るのが良いと思います。 上流系のスキル、開発
コロナ再自粛に備えようという話（2020/7/23） - IT業界で気づいたことをこっそり書くブログ
※素人の意見です 都内の感染者数がついに300人の大台に！！！！！！！！！ みたいな報道にそろそろ世間が飽きてきてる頃かと思いますがいかがお過ごしでしょうか。 最初の世間のコロナショックの時（4月前後）は、未知の病気に対する恐怖と海外の流行っぷりに戦々恐々としたと思います。その熱湯が喉元過ぎ、どうやら日本人の多くにとっては対岸の火事っぽいなという雰囲気になってからは、もはやコロナもどこ吹く風と言う感じで、一部の業界が苦しむ以外は平穏を取り戻したかのように見えます。 指数関数的に増えていく陽性者数 検査数が増えているだけ？ じゃあ安心じゃん、とはならないっぽい 順調に伸びていったら 対岸の火事じゃなくなり再自粛へ？？ 感染リスクよりも再自粛リスク 追記：7割自粛（2020/07/26） 追記：1000人突破（2020/07/29） 指数関数的に増えていく陽性者数 しかし、PCR検査陽性数のグ
不安や劣等感と向き合う方法（エンジニア以外でも使える） - IT業界で気づいたことをこっそり書くブログ
何だか最近「凡人」とか「劣等感」のようなワードを見かけたので、個人的な不安との向き合い方を理屈っぽく書きたいと思います。 珍しく自己啓発っぽい話。 エンジニアの劣等感との付き合い方 - Qiita 【JTF2020】凡人エンジニアの生存戦略 - Speaker Deck 仕事は日々不安や劣等感との戦い 現状はどうしようもない 行動できると安心する そうじゃない人もいる 現状把握＋計画＋行動→安心 計画→ゴール設定→行動→計測→ピボット ピボット時にあり得るパターン 努力の成果が出たら劣等や不安感は減るか？ 常に不安材料を直視させられるパターン 行動アイディアが出ないパターン 行動できないパターン 「ストイックですね」「上昇志向が強いですね」「真面目ですね」 おわりに 仕事は日々不安や劣等感との戦い 仕事は、というか人生は全部不安や劣等感にまみれていますよね。 私は過去いろんな不得意なことを
時短フリーランスでエンジニア転向はたぶん無理 - IT業界で気づいたことをこっそり書くブログ
プログラミング学習がブームになりつつあります。 そしてエンジニアは結構儲かります。 となると他業界からエンジニアになろうというという人が結構出てくると思います。 その際、どうスタートを切るかですが 前の業界の仕事をしつつ週3くらいでエンジニアをして成長していく というプランはたぶん破綻すると思います。 もっと具体的に条件を絞り込む 上手く行かない理由 成長するために必要な要素 上手くいってる人居るよ、俺知ってる さすがにいきなり週5で仕事するのはキツイ どうしても週3くらいで成長したい おわりに もっと具体的に条件を絞り込む 正社員になる → うまくいく可能性あり 派遣で常駐 → うまくいく可能性あり フリーランスで常駐 → ちょっと難しい 時短フリーランスで常駐 → 難しい 時短フリーランスでリモート → かなり難しい 上手く行かない理由 勉強量、経験量が圧倒的に足りない（慣れるまで50
新人エンジニアを育てるメリットと難しさ - IT業界で気づいたことをこっそり書くブログ
最近エンジニアの新人を真剣に育てているのですが、メリットと、現実的な難しさをまとめます。 曖昧な知識を明確にするきっかけになる よりリーダブルなコードが書けるようになる 指示出し、タスク管理の訓練になる 営業の訓練にもなる 楽しい しかし、綺麗事では片付かない新人育成の現実 育成レベル １．アドバイザー ・・・ 委任的 ２．メンター ・・・ 参加的 ３．教師 ・・・ 説得的、教示的 ４．コーチ ５．師匠 近年のエンジニア育成事情 育成という名のふるい落とし コーチ・師匠は確実にコストがメリットを上回る 学習者にも強いモチベーションが必要 まとめ おまけ：人を増やしチーム化するのは有り？？ メリット 曖昧な知識を明確にするきっかけになる よく言われることですが、知識を断定できるくらいに鮮明にしておかなければ教えるのが難しいです。 そのため基礎的なことについて改めて調べるきっかけになり、自己の
エンジニアが一人前になるための必須スキル - IT業界で気づいたことをこっそり書くブログ
ひょんなことから、最近同僚にプログラミングを教えています。 元々ITとは関係なかった人なので、どこからわからないか探り探りです。 プログラミングを教えるのってけっこう大変ですよね。これできる人は限られるのではないかと思います。 プログラミングを例えば1年程度教えることは可能ですが、もちろんいつまでも教え続けるわけにはいきません。 どのようになれば一人前（＝放っておいても継続的に成長できる状態）になるできるでしょうか？ そこらへんを少し考えました。 エンジニアとういうシステムの機能要件みたいなもんです。 最低限のプログラミング知識と、IT知識 問題を解決するための情報源を確保 調べて分からなかったときの解決法を持つ 手動テストスキル ・デバッグスキル わからないものを論理的に一歩ずつ「わかる」にしていくスキル 解決できるまで諦めない根気とモチベーション 今は全部あれば詰むことはない時代 最低
ベンチャーの経営状態を探って入社リスクを減らす - IT業界で気づいたことをこっそり書くブログ
いちから株式会社、御社大丈夫？その２です。 前 otihateten.hatenablog.com 私は直感で「お、大丈夫か？？」と思ったんですが、その直感が数字的に合ってるのかどうか、ちょっと調べました。 参考情報 shikin-pro.com initial.inc 資金調達時の会社の評価額と、従業員数を見比べてみる 決してこれだけで全部わかるわけでは無いんですが。 ベンチャー企業の多くにとって、重荷となるのはやはり人件費です。 評価額はおおよそ粗利額や利益額に相関するはずですから、そこと人件費（従業員数）を調べると傾向は出るはず・・・だと思います（私はプロじゃないので断言できませんが） するとこうなるんです。 「あっ」ってなりませんか？いや分からないですけどね。 グラフの元データ 従業員数が多くても大丈夫な会社 数字を見て「あれ？」と怪しいんだら、もう一段深く見ていくべきです。 ひょ
NoCodeはさほど伸びないし関わらない方が良いと思う理由 - IT業界で気づいたことをこっそり書くブログ
note.mu ノーコードがバズってるみたいですね。何度か複数の記事を見ました。 ノーコード系の記事を読むとすごく良さそうに見えてきますが、個人的にこれ系がユーザー企業以外には上手くワークしないのではいうのは数年前から思ってました。私の認識を書いておきます。 ・・・ とやる気を出してみたは良いものの、ちょっとこの話だるいですねこれ。 「SaaSもそろそろ頭打ちだしエンジニアが絡んでもしょうがないでしょ、PaaSならともかく」で全部済むと思うんですがどうでしょうか？（投げやり） サービス界隈はどうなっているのか？ SaaS文脈のNoCodeはエンジニアの介在する余地がない そもそもSaaS規模が大きいわけでもない 新しい◯◯業界は見つかるか？ EC業界はそもそも特殊 PaaS文脈でのNoCodeはどうか？ 誰にとってNoCodeは有益か 投資家 NoCode提供側 デザイナー・コンサル ユー
エンジニア・プログラマーのタイプを考えてみる - IT業界で気づいたことをこっそり書くブログ
昔書こうとしてイマイチしっくり来ず放置していた話。 プロジェクトが上手く行っているか、上手く行っていないか。 その人の行動が正しいか、正しくないか。 などというのは、一意に決まらないものです。 プロジェクトには非常に多くの評価軸があるため、人や案件によって「正しさ」が全く違ってきます。 エンジニアのタイプ 社会派タイプ 事業家タイプ 解決思考タイプ 職業人タイプ ものづくりタイプ 技術好きタイプ 科学者タイプ 「素晴らしい技術が発表されました」に対する反応 主な生息域 どのようにタイプが決定されるか 話が合う相手 締め こういう点はフリーランスのほうが感じているのかもしれません。 30代正社員となれば、経験社数はせいぜい1〜3社と言ったところでしょうが、フリーランスになると取引する会社は二桁に及んだりします。 二桁も会社を経験したら法則性が見えてくるのかと思うのですが、価値観は会社や人によ
誰のために寄付をするのか - IT業界で気づいたことをこっそり書くブログ
京都アニメーションが義援金の振込先が設定されました。 www.kyotoanimation.co.jp この機会に、以前から考えていることを書きます。 何のために寄付するのか、お金を払うのか 最近、YoutubeLiveでスーパーチャットという投げ銭ができるようになりました。 他のプラットフォームでも、以前よりは簡単にお金を支払えるようになりました。 それで、自分はなんのためにお金を払っているんだろう？と疑問に思うことが増えました。こういうのはアメリカとか寄付が盛んな国ではもっと自然なのかもしれません。 普通、私達は商品を購入するためにお金を払います。商品はモノであったり、権利かもしれません。ギャンブルだとそれはチャンスや可能性なのかもしれません。 しかし、寄付や投げ銭はそういったものとは少し違います。 お金を払うことで明確な何かが返ってきません。払っても、払わなくても自体は何も変わらない
意識高い系の正体、ダニング＝クルーガー効果説 - IT業界で気づいたことをこっそり書くブログ
意識高い系の正体、ダニング＝クルーガー効果説 ふと思いつきました。 ダニング＝クルーガー効果 ダニング＝クルーガー効果 - Wikipedia ダニング＝クルーガー効果（ダニング＝クルーガーこうか、英: Dunning–Kruger effect）とは、能力の低い人物が自らの容姿や発言・行動などについて、実際よりも高い評価を行ってしまう優越の錯覚（英語版）を生み出す認知バイアス。この現象は、人間が自分自身の不適格性を認識すること（メタ認知）ができないことによって生じる[1]。 こう言う話はけっこうあります。 例えば「完全に理解した」みたいなものです。 www.thedailystar.net パイロットの学習と自信の曲線も面白いですね。 The pilot learning curve. Credit Jay Robinson #avgeek #aviation #pilots pic.t
どのデザインパターンを使うか、4つの観点（思想） - IT業界で気づいたことをこっそり書くブログ
半分愚痴です。 MVCやMVP、なんちゃらアーキテクチャなど、色々ありますが、あれらのコード全体の構成を決める所謂デザインパターンうち「どれを使うか」「使わないか」というのは大体４つの観点で決まると思います。いや、決めるべきだと思います。決められていないことが多々あります。というお話。 ※もう少し上のレイヤーのアークテクチャーや、デザインパターン、フレームワーク、開発手法郡・ツールにも似たことが言えると思います 大前提、デザインパターンを適用するデメリット １．テストを書くかどうか ２．完璧なプログラムか、スピードか ３．誰がプログラムを書くか、誰最適か ４．プロジェクトの規模や目的 デザインパターンを決めるフロー 例外：部分的に使用する 例外：メリットが上回ると信じている場合 デメリット・コストは誰に降りかかるのか理解する 普通に組んでも結構よくできるよ デザインパターンの思想だけ理解す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
