すべてのカテゴリ

僕がエンジニアとして生きる覚悟を決めたのは、社会人になってすぐ、ある先輩に言われた一言でした。「こんなことも分からないのか。」胸に突き刺さる悔しさ。自分でも、スキルが圧倒的に足りていないことは分かっていた。でも、それを人に言われると想像以上に痛かった。その日の夜、ボーナスを握りしめてPCショップへ向かいました。パーツを自分で選び、睡眠時間を削りながら必死に知識を埋めていく。「絶対に見返してやる」その感情が、僕の原点です。■ 技術だけでは勝てないと気づいた日新人の頃、とあるWebシステムを任されたことがあります。夜中までコードを書き、サーバーの設定も自分でやり、“技術で戦う” ことが楽しかった。しかし、県内大手企業のコンペに挑んだとき、技術的には勝っていると思っていた自社のシステムが、あっけなく負けました。その瞬間、初めて知りました。「技術が優れているからといって、選ばれるわけではない。」この出来事が、僕が“ビジネス”や“価値の伝え方”の重要性を学ぶ転換点でした。■ 世界を相手にして気づいた、エンジニアの普遍性その後ベンチャー企業に移り、多国籍チームを作ることになりました。ミャンマー、タイ、インドネシア、ヨルダン、アメリカ、ロシア──言葉や文化は違うのに、コードを書き始めると会話が成り立つ。ホワイトボードに書いたフローチャートを囲みながら議論していると、「エンジニアは“国境を越えて仕事ができる”職業なのだ」という確信が芽生えました。この経験から、日本人かどうか、年齢がどうか──そんなものは本質ではないと気づきました。■ 最大の試練：100名規模の炎上ERPプロジェクト最後に訪れた

〜20年の現場経験から「本当に効いた立ち回り」〜ITエンジニアとして働く中で、こう思ったことはありませんか？    「技術はあるのに評価されない」    「真面目に働いているのに損している気がする」    「なぜか周りはスイスイ昇格していく」スキルや努力とは関係なく、「社内での立ち回り方」によってキャリアは大きく変わる のが現実です。この記事では、25年以上の現場でイチ担当者、リーダー、管理職の目線を通して「これは本当に損する」「これをやると得する」と感じた行動をまとめてお伝えします。今日から実践できる内容ばかりなので、ぜひあなたの職場に合わせて取り入れてみてください。■ 損する行動①沈黙しすぎる・聞かれたことにしか答えない    レビューで「大丈夫？」と聞かれ    →「はい、大丈夫です」だけで終わる    会議で発言ゼロ    調査結果を共有しないこうした沈黙は、「不安」 「不透明」 「受け身」 と評価されがちです。◎ 得する行動・進捗の「見える化」をこまめにする「今ここまで調べました」「次はここを進めます」これを言うだけで評価が変わります。■ 損する行動②仕事を抱え込みすぎる真面目で優秀な人ほどやりがち。    自分で全部やろうとする    キャパオーバーでも言わない    結果、期限直前に焦るこれは 「調整ができない人」 と見られます。◎ 得する行動・早い段階で「相談」をする相談は弱さではなく、 「リスク管理能力」 の証明です。■ 損する行動③曖昧な返事で乗り切ろうとする「たぶんできます」「確認しておきます」「なんとかします」→ こういう曖昧さは後から大事故になります。

ITエンジニアとして働いていると、「転職」はいつでも選択肢になります。でも、求人票や面談だけでは、現場のリアルはほとんど見えません。転職に失敗する多くの人が見落としているのは、「会社」ではなく「現場」を選ぶべきだという視点です。年収、福利厚生、リモート体制、技術スタック。表に見える条件はもちろん大事です。でも、本当にあなたの未来を左右するのは、“あなたが毎日向き合う現場の質”これに尽きます。ここでは、20年以上エンジニア・PM・コンサルとして現場に関わってきた経験から「転職前に必ず確認すべき現場の5つの条件」をまとめました。どれか一つでも事前に掴めれば、転職の失敗確率は劇的に下がります。1. 現場の「負荷のかかり方」——残業時間より“質”を見る多くの人は「残業時間」で負荷を判断します。しかし本質はそこではありません。負荷には“きれいな負荷”と“汚い負荷”があります。    きれいな負荷：要件が明確、進め方が整理されている、学びにつながる    汚い負荷：設計不在、決定が遅い、優先度が曖昧、炎上が常態化同じ残業30時間でも、前者は成長につながる時間ですが、後者は消耗するだけの時間です。面談では、次のように質問すると現場の実態が透けて見えます：●「直近3ヶ月で一番大変だったプロジェクトは何ですか？」●「その時、どのような進め方・対策が行われましたか？」●「その問題は今は改善されていますか？」回答の中に「改善」という言葉が出る現場は、概ね健全です。2. PM／PLの質 —— あなたの未来の9割は“上司”で決まるこれは断言できます。転職で一番重要なのは、誰と働くか。PM／PLの質は、あ

技術が高いだけでは評価されにくく、かといって要領だけで渡り歩くのも長くは続かない——。そんな時代において、“評価されるエンジニア”が共通して持っているもの があります。それが、「思考を整理する技術」 です。スキルセットでも学歴でもなく、毎日の仕事の中で「どう考えるか」が結果を左右します。今回は、20年以上現場を見てきた中で“評価される人に必ず共通していた5つの思考整理術” をまとめました。今日からすぐに使えます。1. 目的から考える：最初の1分で差がつく多くのトラブルは、「何のためにやっているのか」が曖昧なまま進めてしまうことから生まれます。評価されるエンジニアは、作業に入る前に “目的”を一度だけ言語化 します。    何を達成したいのか    誰のための作業か    成果は何で判断されるのか    優先すべきものは何か目的が整理されると、作業の迷いが一気に消えます。目的の精度＝仕事の精度。目的を最初の1分で揃えるだけで、その日1日の成果が変わります。2. 問題の“本質”を見抜く：事象より構造を見る現場では多くの「問題」に出会います。ただ、やってはいけないのは、目の前の事象だけを直そうとすること。評価される人は、必ず本質を探ります。    なぜその事象が起きたのか    何が根本の原因なのか    どの構造・仕組みが影響しているのか    再発させないためにはどこを変えればいいのか本質を見抜けると、問題に振り回されなくなり、判断が正確になります。エンジニアリングも仕事も“構造で理解する”人が強い。3. 情報に“優先順位”をつける：全部を追わない情報過多の時代において、全ての情

仕事をしていると、「この人の説明、すごく分かりやすいな」と感じる場面があると思います。それは“頭の良さ”や“話がうまい”からではありません。むしろ──説明のうまさは、性格ではなく「技術」です。20年以上エンジニアとして働く中で、「説明がうまい人」には共通の“型”があると気づきました。今日から使える５つに絞って紹介します。1. 結論 → 理由 → 具体 の“黄金テンプレ”を使う説明が分かりにくい人は、いきなり具体から入る 傾向があります。説明がうまい人は、必ずこの順を守ります。結論 → 理由 → 具体■ よくある説明（Before）「昨日の障害ですが、サーバーの負荷が…。ログを見ると…。ネットワークが…。」→ 情報は多いけれど、何が重要なのか分からない。■ 分かりやすい説明（After）結論：原因はAでした。理由：ログと負荷状況から一致しているためです。具体：再発防止として◯◯を進めます。説明は「順番」がすべて。テンプレ化するだけで伝わり方が激変します。2. 相手の“理解レベル”に合わせて話す説明が伝わらない原因の多くは、相手と粒度が合っていない ことです。    初心者：全体像が知りたい    中級者：背景とポイントが知りたい    上級者：制約・詳細・影響が知りたいうまい人は最初にひと言だけ確認します。「どこまで把握されていますか？」この質問だけで、話すべき内容のレベルが決まります。同じ説明でも、相手によって“話し方を変えられる”人が評価されます。3. 前提を揃える（これだけで9割防げる）会議のすれ違い、レビューの誤解、チャットでの衝突──ほとんどは 「前提のズレ」 によって

こんばんは、とーますです。お久しぶりのブログを書いてます。毎日暑いですよね。今日は転職活動についてですが、転職活動って、「転職したいなー」とか「給料あがらないかなー」みたいな、そんな感じで言葉には良くしますが、中々活動するまで至らないですよね。本当に転職したいときって、そんなこと言ってられなくて、気付いたらエージェントに相談してくるくらいだと思うんですよね。私も最近、転職したいなー、とか思ってます。まだ活動にはいたらないのかもしれないけど、自分の市場価値はいつだってしっておいたほうがよいと思うんですよね。今は（能力のある人の）人材不足でできる人なら引く手あまたな売り手市場だと思います。今の自分の能力の棚卸時期が来ていると思ってます。現状だとSIerにいた時より、スキルは上がっていないというか基本が社内調整やベンダーコントロール、会社全体のプロジェクトを担当しており、テクニカルな部分やコーディング等は中々伸びていません。AWSやサーバー構築、設計、ネットワーク等は日々触る機会もありますが開発プロジェクトにいる人とはやはり違ったスキルが身についている印象ですかね。もっと大きな実績を残して上流にあがり、経営に近いところでのスキル、知見、経験を積んでハイクラス転職しないといけないなと思いました。プログラムは仕事上では触れる機会が少ないですが、プライベートで何か作ればよいわけで、これから何か作ろうと思ってます。結局自分自身が、個が強くなっていかないといけないんですよね。やるかやらないかは自分次第。ここに記しておこうと思います。また定期的にブログ書こうと思います。

このセクションでは、Fletを使用してToDoアプリケーションを開発するための環境を整えます。(公式サイトのURLが禁止ワードになるので省略しましたが、pythonやvscodeは適宜インストールして下さい。)必要なツールとソフトウェアPython：FletはPythonで動作するため、まずPythonをインストールする必要があります。エディタ：コードを書くためのテキストエディタが必要です。Visual Studio Code（VSCode）やPyCharmなどがおすすめです。Pythonのインストール方法Pythonの公式サイトから最新のPythonをダウンロードします。ダウンロードしたインストーラを実行し、インストール中に「Add Python to PATH」にチェックを入れてください。インストールが完了したら、コマンドプロンプト（Windows）またはターミナル（Mac/Linux）を開き、以下のコマンドを入力してPythonが正しくインストールされているか確認します。python --version正常にインストールされていれば、Pythonのバージョンが表示されます。Fletのインストール方法次に、Fletをインストールします。以下の手順に従ってインストールしてください。コマンドプロンプト（Windows）またはターミナル（Mac/Linux）を開きます。以下のコマンドを入力してFletをインストールします。pip install fletインストールが完了したら、Fletが正しくインストールされたことを確認するために、以下のコマンドを入力します。pip show

「は？何で？？今って、人手不足ではないのかなぁ～？なぜに派遣会社の倒産が多いのかな～？よくわからない・・・」という疑問を持ったボク。そういえば、ボクも東京時代とね～「３０才～４０才」位までの広島時代（帰省したのじゃ）はね～、派遣の仕事（プラント設計や施工管理）を主にやっていたのじゃ。でも、東京時代はデータ処理が多かったよ。東京時代は「テンポラリー・センター」とか「マン・フライデー」とか「セントラル・エード」とかの「カタカナ会社名」が多かったぜよ。「プログラマー」でなかったのが、残念じゃ。トホホ；；もっと勉強して、「プログラマー」とか、「システム・エンジニア」とかになると時給がイイし～、なんか「カッコイイ」じゃん。当時は「リクルート」がまだ若い会社だった頃じゃし～、そういえば「派遣先」の会社のすんごい近くが「リクルート社」じゃった。もちろん「リクルート」っていうくらいだからね～、「就職や派遣」の斡旋？を世界的にやっているのじゃ。ただ「リクルート事件」というのが、あってね～、たしか江副社長（えぞえ）が、逮捕された？のじゃったと思うけど、事件の詳細は覚えてないぜよ。「リクルートコスモス」の「未公開株」を政治家だかに「譲渡」した？とかしないとか・・・ま、そんなところじゃ。ゴミン。当時はね～、ボクも「投資ジャーナル」の「面接」に（あれは「日本橋」かな？）行ってみたり、まあ、４０年近く前って、日本も「元気？」というか「勢い？」があったのじゃと思う。「詐欺」とか「収賄」とか、「ワイロ」とか～「献金」とかの色んな事件がいっぱいじゃった。もっと前だと、ボクが入社した「大手造船会社」が東京大手町に

こんにちは、皆さん！hirokiと申します。システム開発って気になりませんか？SEとして働いている私が、見積りについてリアルなお話をシェアしたいと思います！システム開発の見積りの要素とは？システムエンジニアが見積りを行う際に一般的に使用される単位は「工数」です。これは作業に費やす時間や労力を指します。見積もりには「開発の規模」「期間」「難易度」など多くの要素が影響します。開発規模が大きい場合、何十〜百人ものエンジニアがプロジェクトに参加することもあります。期間には、開発だけでなく要件定義や検討、テストなども含まれます。実際には、導入までの段階で細かいテストが行われ、品質の確保に力が入れられます。エンジニアの単価とは？エンジニアの単価は経験や開発分野によって異なりますが、通常は1人あたり60万〜150万円程度で見積もられます。例えば、10人規模の開発で期間が3ヶ月の場合、単純計算で60万円✖️10人✖️3ヶ月 = 1800万円といった具体的な見積もりが出ます。これはかなりの金額ですね(･_･;) ただ、その分テストや障害対応にも力を入れ、品質の高い成果物を提供しています。まとめ：ココナラなら！いかがでしたでしょうか？システム開発のコストには驚かれたかもしれませんね。ココナラでは、スキルや経験豊富なプロフェッショナルが、通常のシステム開発とは異なる価格でサービスを提供しています。もしシステム開発でお悩みのことがあれば、ココナラで相談してみるのも一つの手かもしれませんね。どうぞよろしくお願いします！ 😊✨

はじめまして！あたりんぐです。私たちはWebのエンジニアとデザイナー夫婦です。ココナラでは主にホームページ制作の案件を出品しています。元はといえば、ホームページ制作会社にて5年ほどディレクターも兼任しながらホームページを作ってました。やっぱり、会社に所属していると会社のルールや売上のことを言われ(当たり前ですが)、自分の納得いかない、ホームページを納品しなくてはいけない状況が続きました。私はディレクターも兼任していたので、お客さまの声を直接聞くし、どんな思いでホームページを依頼してくれたのかもお話を聞く機会がたくさんありました。縁あった人たちのホームページくらい結果の出るホームページにしたいと思い、個人的にアクセス解析やSEOについて勉強、実践し、紹介で個人でもホームページの制作に携わらせていただく機会が増え、ついに会社を辞め、フリーランスとしてホームページ制作を仕事にすることができました。今回、ココナラを使い新たなお客さまの出会いを楽しみにしています。長文読んでいただき、ありがとうございました。ホームページ制作のお問い合わせもお待ちしております！

人気の高いプログラマやシステムエンジニア。年収も高いと言われています。他の業種に比べてどのくらい違うのか調べてみました。https://coconala.com/mypage/user初心者向けのプログラミング講座等をご紹介しています。

はじめまして システムエンジニアのCLOVERと申します。 現在、事業者向けのオリジナルの業務システム開発や、 業務システム（予約管理システム等）のパッケージを自ら開発し、導入・保守をしています。 システム開発・導入において、すべての工程を1人でできますが、どのような経歴でここまでになれたかを少し紹介したいと思います。 大学卒業後の経歴を簡単にまとめてみました。 ―――――― 【１】＜2年間ほど＞ 大手通信系のIT企業で、一通りのシステム開発（要件定義、設計、実装、試験、リリース、保守）を経験 【２】＜5年間ほど＞ 地方のIT企業で、より幅広い範囲のシステム開発（見積、進捗管理、設計、製造、試験、運用）を経験し プロジェクトマネージャーや複数プロジェクトの管理も担当 【３】＜2年間ほど＞ 社内システムがない建設系の会社に入り、1人で社内システムの要望ヒアリング、企画、設計、開発、導入、サポートを実施 【４】＜4年間ほど＞ 事業者のオリジナル業務システム開発や、業務システム（予約管理システム等）のパッケージを自ら開発し、導入・保守 ―――――― 社会人になるまでは、プログラミング経験があったわけでもなく、PCに特別詳しいとも言えない単なる若者でした。 そんな状態から就職し、社会とプロジェクトの波に揉まれつつ、おそらく社会人5～6年目あたりにようやく1人でもシステム開発ができるかなという技術がついたような気がします。 それまでの期間は仕事から帰っても、資格の勉強や、技術関連の本を読んだり、自分のPCでコードを書いたりなど、自己研磨に励んでいた気がします。大変すぎて記憶があいまいです

こんばんは、とーますです。 いつもブログを見て頂きありがとうございます。 本日は、仕事は楽しい、についてです。 土日になると平日の仕事から解放されて、ぱーっとなりますが、逆に平日に仕事があるから土日がぱーっとなるわけで、メリハリのある生活をしているから充実するのではないのかな、と日々思っております。 私の場合、土日になっても、あの仕事は今後こうやって進めよう、とか、あのプロジェクトは今度こうやって交渉しようとか、あのシステム企画ではこのサービスを導入しようとか、ふとした時に思いついてしまうため、普段から直ぐメモを取るようにしているのですが、そうすることでまた平日の仕事の時にそのメモを活用できたりして結構役立っていたりします。 。。。 あれ全然休んでないじゃん、とか思いました。 はたから見たら全然楽しくないじゃん、とかも想像しちゃいました。 えっと、、仕事は楽しい、についてでしたね。 上記みたいに普段からずっと仕事のことを考えてしまっている私ですが、仕事というよりはシステムをどうやって入れたらいいかなーとデザインしている時が一番楽しかったりするんですよね。 今も会社の課題を解消するようなプロジェクトを日々こなしていますが、あの課題はどんなクラウド製品が合うかなーとか、あの人が言っていた課題はExcelマクロでも作ったら解消するかなーとか、こういう人材が今後必要になるからメンバーにそういった人を採用した方が良いと上に掛け合おうかなとか。 そういったことって個人で活動していると中々経験できないことだし、もちろん規模によって大きなお金がかかったりしますが、会社の予算をとって実現していけ

IT業界で働きたい未経験の人、経験が少ない人にとって、とても不安になっていることでしょう。もしかすると、ずっとプログラムを書いているイメージを持っている人が多いのかも知れませんが、実はプログラムは、IT業界の一部です。あなたが将来何を目指せば良いかを見つけるためにも、いろいろな視点を身に着けて、柔軟に働いていった方が良いです。IT業界は、広いので、早めに全体像を掴んで、少し意識して、自分がどこで勝負するのかの戦略を考えておくことをオススメします。 とは言え、どんな業界なのか、質問したいこともあると思います。そんな貴方のために、IT業界22年の現役システムエンジニア（PM）が役に立つ知識や経験を踏まえて回答します。仕事の先輩では、利害関係がありますが、第三者として客観的な視点での回答、あなたに役立つアドバイスもできると思います。回答に不満があれば、お金は頂きませんので、安心してください。

朝霞の駅前を歩きながら、ふと自分の手元のノートPCに目を落とすと、画面の中のコードが静かに語りかけてくるように感じた。フリーランスのシステムエンジニアとして日々さまざまな案件に向き合っているが、特にこの街にいると、コードの一行一行が街の空気と呼応しているような不思議な感覚にとらわれる。通勤ラッシュの波に乗る人々、川沿いの木々の葉の揺れ、風に漂うパン屋の香り。これらすべてが、僕が書くプログラムのリズムに微かに影響している気がするのだ。今日取り組むのは、あるWebサービスのユーザー認証部分の改修だ。要件は明確だが、どの言語やフレームワークで実装するかはまだ決まっていない。画面を見つめながら、僕は駅前の歩道橋の鉄柵の影や、電車の金属音、子どもたちの遊ぶ声を思い浮かべる。それらが頭の中で一つのリズムを作り、どの実装方法が最適か、自然と指が動き出す。コードを書く行為は、単なる論理的作業ではなく、街と対話し、環境を読み取る行為にもなっているのだと気づかされる。キーボードを叩くたびに、変数名や関数名が、駅前の風景や人々の動きと微妙に共鳴する。バグを修正するたびに、街のリズムもまた揺らぎを取り戻すような気がする。思考の深さと街の空気が交わると、普段の作業が一つの小さな物語になる。コードの中で起こるすべての変化が、街の時間の中で生きているように感じられるのだ。夕方になると、駅前の雑踏は穏やかになり、ノートPCの画面の光がやわらかく手元を照らす。完成したプログラムは、ただのツールではなく、朝霞という街と僕自身をつなぐ橋のように思える。フリーランスとして働く自由な環境の中で、街のリズムを感じながらコ

山村風太です。フリーランスのシステムエンジニアとして、これまで多くのプロジェクトに携わってきました。大手SIerで基幹システムの保守を7年間担当していた経験から、痛感していることがあります。それは「書きやすいコード」と「保守しやすいコード」は、必ずしも一致しないということです。開発中は動けばいいと思って書いたコードが、数ヶ月後には誰も理解できない「負債」になる。これは個人開発でもチーム開発でも起こります。では、技術的負債を生まないために何を意識すべきか?私が実践しているポイントを3つ紹介します。1. 命名規則の徹底変数名や関数名は、コメントなしでも意図が伝わるように。`data`や`tmp`といった曖昧な名前は避け、具体的な役割を表現します。2. 関数は単一責任で短く保つ一つの関数が複数の処理を担当すると、後から修正する際に影響範囲が読めなくなります。機能ごとに分割し、50行以内を目安に。3. 早めのリファクタリング「後で直そう」は大抵直りません。違和感を感じた時点で手を入れることが、結果的に開発スピードを保ちます。スタートアップ案件では特に、スピード重視で技術的負債が溜まりがちです。だからこそ、最初から保守性を意識した設計が重要だと考えています。長く使われるシステムを作るために、一緒に丁寧な開発を心がけましょう。

システムエンジニアの仕事というと、常に頭をフル回転させているようなイメージがあると思う。実際、要件定義、設計、実装、テストと、考えることは山ほどある。でも最近、僕が一番意識しているのは「考えない時間」をどう作るか、ということだ。つまり“沈黙の設計”である。コードを書いていると、頭の中は常にざわついている。どのフレームワークを選ぶか、パフォーマンスをどう最適化するか、デプロイの手順をどう整えるか。次々に浮かぶ思考を処理し続けていると、知らないうちに脳が飽和していく。その状態でどれだけコードを書いても、エラーは増え、設計の歪みが積み重なっていく。あるとき、その疲労がピークに達して、僕は何も書けなくなった。その日、パソコンの前に座っても手が動かない。マウスを握ったまま、ただ無音の部屋で固まっていた。焦りもあったけれど、不思議と心の奥は静かだった。そのとき、ふと思った。「ああ、もしかして、これも必要な時間なのかもしれない」と。それから僕は意識的に“沈黙”をスケジュールに組み込むようになった。たとえば、午前中の開発が一区切りしたら、パソコンを閉じてベランダに出る。朝霞の空を見上げて、コーヒーを一口飲む。ただそれだけの時間。何かを考えようとせず、頭を空っぽにする。すると、不思議なことに、数分後には自然と「次にやるべきこと」が浮かんでくる。考えないことで、考えが整うのだ。沈黙は、プログラミングにおける“空白文字”みたいなものだと思う。コードの中に空白がなければ読みづらいように、思考にも余白が必要だ。空白があるから、ロジックが際立つ。沈黙があるから、集中が戻る。人間もプログラムも、詰め込みすぎ

ある週末の午後、朝霞市の静かなカフェに腰を落ち着けた。ノートパソコンを開き、フリーランスのシステムエンジニアとして抱えている案件のコードを眺める。普段なら自宅やオフィスで作業するのだが、環境を変えるだけで思考が不思議と整理されることがある。この日は、特に複雑なWebサービスのバックエンド設計に悩んでいた。カフェの窓から差し込む光が、テーブルの上に影と反射を作る。外からは通りを行き交う人々や、自転車のベルの音が聞こえる。その音のリズムが、なぜか頭の中のコードのフローと重なり、乱雑に絡み合っていた関数やモジュールの関係が一つずつクリアになっていく感覚があった。コーヒーを口に含むたびに、頭の中の処理順序が整理され、どのデータをどのタイミングでキャッシュすべきか、自然と答えが浮かんできた。ふと気づくと、隣の席の学生たちが話す内容すらも、頭の中ではデバッグのヒントになっていた。彼らの会話のテンポ、笑い声、カップが机に触れる音が、まるでイベント駆動型プログラムのトリガーのように作用していたのだ。普段は無意識に流れてしまう雑音が、ここでは創造力を刺激するデータに変わっていた。この経験を通して思ったのは、フリーランスとしての仕事は単にコードを書く時間だけではないということだ。環境や周囲の音、光、空間のリズムが、頭の中の情報整理や新しいアイデアに直結することがある。朝霞市のカフェというちょっとした日常空間が、まるでエンジニアの思考を最適化するツールのように機能した瞬間だった。結局、その日のうちに複雑だった処理の最適化は完了し、以前よりも高速で安定したシステムが構築できた。もちろんカフェの内装や外

今は、とある企業で、数千人が利用する業務システムの保守開発に携わっています。日々のタスクは、お客様からの問い合わせ対応や、新しい機能追加のための設計・実装がメイン。そんな中、毎年この時期になると、僕たちシステムエンジニアにとって、ちょっとした「イベント」が起こります。そう、「お盆」です。お盆は、多くの方にとって、ご先祖様を迎え、家族や親戚と集まって過ごす大切な時間ですよね。もちろん、僕もそれは同じです。ただ、システム屋としてお盆を経験すると、ある不思議な現象に気が付きます。それは、システムへのアクセス数が、まるで潮が引くかのように一気に減ることです。普段は数千人の方が利用しているシステムでも、お盆期間に入ると、まるで「誰もいない」かのように静かになります。アクセスログを見ると、まるで幽霊でも出たかのように、ユーザー数が急減しているのです。この現象を目の当たりにするたびに、僕は「お盆って、システムから見ても本当に『あの世とこの世の境目』なのかもしれないな」と、ついつい考えてしまいます。何百台ものサーバーが常に稼働し、膨大なデータがリアルタイムに行き交う日常。それが、お盆の時期だけは、まるで時間が止まったかのように、静けさに包まれる。普段は気づかない、システムの「呼吸」のようなものを感じることができる、貴重な時間です。そして、この静かな時間を利用して、僕は普段できないような「お盆限定タスク」に勤しみます。例えば、普段はアクセスが多くてなかなか実行できないような、大規模なデータベースの最適化や、システムのパフォーマンスチューニング。あるいは、新しい技術を試すための検証環境の構築など。

こんにちは、フリーランスシステムエンジニアの高山慶です。独立して5年が経ち様々なクライアントとお仕事をさせていただく中で、最も重要だと感じているのは「技術力」よりも「相性」だということです。今日はその見極め方について、実体験を交えてお話しします。失敗から学んだ「相性」の重要性以前、技術的には完璧に要件を満たしたシステムを納品したにも関わらず、クライアントから「なんか違う」と言われた経験があります。その時気づいたのは、私が「効率性」を重視していたのに対し、クライアントは「使いやすさ」を最優先していたことでした。相性を見極める3つのポイント1. コミュニケーションスタイル初回打ち合わせで「詳細な資料を求める」か「概要説明で十分」かを確認します。これで仕事の進め方の相性が分かります。2. 意思決定のスピード「じっくり検討したい」タイプと「スピード重視」タイプでは、プロジェクトの進行方法が全く異なります。3. 技術への理解度専門用語での説明を好むか、分かりやすい例え話を求めるかでコミュニケーション方法を調整します。相性が良いクライアントとの仕事は楽しい相性の良いクライアントとの仕事は技術的な課題解決だけでなく、一緒に事業を成長させる喜びを共有できます。結果としてより良いシステムが生まれ、長期的な関係性も築けます。まとめ技術力は基本中の基本ですがそれ以上に大切なのは「一緒に働きたいと思える関係性」です。お互いを理解し尊重し合えるパートナーシップこそが、最高の成果を生み出すのだと実感しています。システム開発でお困りの際は、まず「相性」を大切にする高山にお気軽にご相談ください。

フリーランスとしてシステムエンジニア（SE）をしていると、技術だけでなく、仕事の進め方やお客様とのコミュニケーションがとても重要だと感じています。今回は、フリーランスSEとして大切にしている「仕事を進める上でのポイント」をお話しします。これからフリーランスを目指している方や、すでに活動している方にも役立つ内容だと思いますので、ぜひ参考にしてみてください。1. お客様のニーズを正確に把握するシステム開発では、お客様の求めるものを正確に理解し、それを形にすることが何より大事です。しかし、言葉だけでは意図が伝わりにくいこともあります。そのため、私はお客様との初回ミーティングでは必ず「何を解決したいのか」「どんな結果を期待しているのか」をしっかりとヒアリングします。ヒアリングの際には、お客様が抱えている課題やビジネスの背景を理解することを心がけています。その上で、適切なシステム提案を行い、プロジェクトの成功に向けてゴールを共有します。このステップがしっかりしていると、後々のトラブルを避けることができます。2. 柔軟な対応力を持つフリーランスとして働く上で、常に計画通りに進むわけではありません。開発中に思わぬ問題が発生したり、仕様変更があったりすることもあります。そんな時に大事なのは「柔軟に対応する力」です。私は、予期しないトラブルがあった場合、迅速に状況を把握し、最適な解決策を提案するように心がけています。もちろん、納期や品質を守ることは最優先ですが、クライアントに対して「この変更を提案したほうがより良い結果を生む」と説明できるだけの技術力と柔軟性が求められます。3. 「納期厳守」と「

2021年10月から「適格請求書発行事業者」の登録申し込みがはじまります。インボイス制度発表当初は「まだ、先のこと」と思っていた方も、そろそろ「インボイス制度」を意識し始めるのではないでしょうか？「POSシステム」や「販売管理システム」などでも「インボイス制度」に対応する改修を入れる必要があるケースがあります。そうなると当然エンジニアも「インボイス制度」の内容を理解していないとマズイ状況が生まれます。今回は「インボイス制度ってどんなもの？」ということをざっくりと理解するのにおすすめの動画を紹介します。税理士さんが「消費税」の仕組みから順序立てて「インボイス制度」の概要を説明してくれます。「消費税」の事前知識がなくてもこれを観ればざっくりと理解できるでしょう。国税庁が公開している全4話の解説動画も非常に参考になります。ここまでの動画で「インボイス制度」の内容がざっくりと理解できた方は、国税庁が公開している「適格請求書等保存方式の概要」という資料とあわせて国税庁が行った「インボイス制度」のオンライン説明会の動画を視聴しましょう。YouTubeやSNSでは様々な形で「インボイス制度」を紹介・解説している方がたくさんおります。ただ、中には間違った情報や局所的な情報などもあるかと思います。この先、エンジニアが「インボイス制度」の対応をする際に、そういう情報に惑わされることでバグを生んでしまうこともあるでしょう。今回は「ざっくり理解する」ために有効な動画を紹介しましたが、より詳細に理解するには国税庁が公開する情報など信頼できるところから情報収集をすることをおすすめします。

WEB系のエンジニアを志す若人が学ぶべき「もの」と「順番」を記載します。┌ーーーーーーー┐　・パソコンの歴史│パソコン基礎　│　・パソコンの仕組み└ーーーーーーー┘　・OSの役割　↓┌ーーーーーーーーー┐　・インターネットの歴史│インターネット基礎│　・インターネットの仕組み└ーーーーーーーーー┘　・サーバーの役割　↓┌ーーーーーー┐　・ブラウザの歴史│ブラウザ基礎│　・ブラウザの仕組み└ーーーーーー┘　・ブラウザの役割　↓┌ーーーーーーーーー┐　・HTML基礎│フロントエンド基礎│　・CSS基礎└ーーーーーーーーー┘　・JavaScript基礎　↓┌ーーーーーーーーー┐　・Java│プログラミング言語│　・PHP└ーーーーーーーーー┘　・JavaScript　↓┌ーーーーーーーーー┐　・Gitの歴史│バージョン管理基礎│　・Gitの仕組み└ーーーーーーーーー┘　・Gitの基本操作　↓┌ーーーーーーーー┐　・アルゴリズムの歴史│アルゴリズム基礎│　・アルゴリズムの役割└ーーーーーーーー┘　↓┌ーーーーーーーーーー┐　・デザインパターンの歴史│デザインパターン基礎│　・デザインパターンの役割└ーーーーーーーーーー┘ 　↓┌ーーーーーーーーーーーーーー┐　・プロジェクトマネジメントの歴史│プロジェクトマネジメント基礎│　・プロジェクトマネジメントの役割└ーーーーーーーーーーーーーー┘ 　↓┌ーーーーーー┐　・Linuxの歴史│サーバー基礎│　・Linuxの仕組み└ーーーーーー┘　・Linuxの基本操作※内容は随時加筆します。

おはようございます。こんにちは。こんばんは。ココナラで久しぶりにブログを書こうかとアプリを起動してみたものの、アプリからでは投稿出来ない事に気づくのに時間がかかりました。。。あまり間隔を開けずにブログ投稿はしていきたいと思っていますが、サービス提供自体停止していますので、きちんと答えを伝えられないものが多いのも事実です。せっかく作ったアカウントですし、分からない事や知りたい事のある人で、自分が力になれる人がいればと思い始めたものでもありますので、サービス提供自体は停止しますが、このブログを見た方であれば、DM下さればある程度質問にDMで答えます。DMで収まらない、サービス提供に値する場合のみ、ココナラでの取引で調査や回答など行います。「質問する事自体はサービスには値しない」という形でいければなと思っています。逆に、「質問のDMしたのにスルーされた！！」と言われても困りますが、基本しません。お答え出来ないものは出来ないと言いますし、お答え出来るものはお答えしていきます。時間かかるのでサービスになるならそう言いますし、私個人では対応出来ないものに関しては、「出来る」「出来ない」などの判断を行い、別のココナラ出品者への相談を勧めます。ただ、特定の出品者様との繋がりは一切ありませんので、ご紹介などはご遠慮させて頂きます。その際はご自身で、出来ればココナラ内で見つけて頂ければ幸いです。今も常にココナラからの通知はONにしております。DMがあればスマホから通知が来ますので、PC立ち上げた時しか見ないなどはありません。ただ、こちらは万全ではありません。サービスの価格も正直破格だと思っています

おはようございます、こんにちは、こんばんは。先日、息子の中学の卒業式へ行ってきました。中にはITに興味を持ち、将来は「プログラマ」になるという子もいました。それを聞いた時の私の率直な感想ですが。「プログラマは目指すものじゃない」という事を1番に思いました。確かにデスクワークではありますし、IT系の人材が日本には不足しており、日本はITなどの分野において世界基準よりも下だと思っています。【プログラマは目指してはいけない？】では、なぜ「プログラマ」を目指してはいけないかですが。正直に言いますと、「プログラマ」はITやシステム開発においてですが、「入口」にすぎません。全ての会社がそうではありませんが、システム開発において、新入社員や新人がまず担当するのは「テスター」と呼ばれる他のプログラマが作成したプログラムの「テスト要員」をさせられる事が多いです。バグが無いかを時にはテスト手順書に従いテストを順次行っていく作業です。小さなキャンペーン用のものなどは手順書は無い場合も多いです。専門を出ていようが、全く違う出であろうがまずはやります。その後は会社によってばらつきはありますが、新人にやらせたりするのは、「受注していない案件をやらせてみる」というのを行ってみるのがあります。ただ、「受注していない」とは伝えませんが。内容的には私がプログラムを組んでテストまで完了するのに時間にして1時間程度で終わる内容が多いですかね。ただ、専門出であろうが別出であろうが、スピードやテスト内容まで同等に出来る人材はほぼ居ません。しかし、プログラムを書かせてみると、その人の思考方法がある程度掴めます。私自身は最終

昨日、経営者女性１９６７年生まれ六白からこのような賞賛を得た。宅建もってて法律に詳しく　占いもできてその上　ＳＥなんて　あなた、何物？？？ラノベの女子高生が描くファンタジーのようよんだことありませんその上　訴状も　判決文の＜ひな型＞もかけます学問は向いてませんが　教養くらいならあります前世は　貧乏でも名前のある家柄だけの貴族でしたからええ、昨日の話ですきちんと言って　６時間　きっちり調査してハードウエア　と　ソフトウエア　と　提案しましたさらに　ｄｂも　ドキュメントの共同作業だって出来ちゃうのです安い賃金でつまんない　派遣を受ける気はありませんが昭和バブル前と何も変わっていないそんな感じで　攻撃されても　サーバーに暗号かけられるどころか暗号かけるサーバーは仮想とか　お前なめてんの？っていうような仕組みを作ってまいりましたａｗｓなんてやって一元管理するからこんなことになっちゃうのです