すべてのカテゴリ

おはようございます、Sizu屋です。本日は、Webコーディングで感じることについて記載します。副業としてプログラミングのお仕事に携わり始めてしばらく立ちました。最近思うことは、Webコードやプログラミングは、コードを記載して構築するより、読み解いて解く作業の方が求められている事・・・、そしてそれが結構面倒であると言う事をヒシヒシと感じる様になりました。真っ新な状態からコードを記載するのも大変ですが、そちらの方が自分の勝手にコードを記載出来るので、探す動作必要ありません。しかし、元々あるコードを修正する場合は、そのコードがどの部分を担っているかを確認しにいく必要があります。作業そのものは嫌いではありませんが、何分集中力がいります。自分にとっては絡まった糸を解くような気分です。気が遠くなることもありますが、日々精進と思い頑張って作業を続けている、今日この頃です。

　みなさんこんにちは。ひどい雨ですね。春近しの千冬です。明日はポカポカ陽気なので楽しみです。　さて、今日はギターです。私は高校生の時に友達の影響でエレキギターを始めました。友人はBOOWYが好きだったのでテレキャスを買いました。私はXが好きだったのでモッキンバードを買いました。　高校生なのでアンプもあわせて２万円くらいでしたね。友人は毎日ギターを触ってどんどんうまくなりました。私は勉強と部活が忙しくて、最初の３か月くらいは触りましたが、日々やらなくなりました。　原因はうなくならないことと、コードを学習しなかったこと。もともと不器用で速弾きがうまくできなかったこともあります。自分の理想のピッキングができず、悩んでいました。スコアも買いましたが、速弾きのところは何が書いてあるかわけがわからなかったです。　その後すっかりギターから離れてしまいました。大学４年のときにまた復活しましたが、即やめ。社会人になってから後輩にギターを貰って弾きましたが、またやめ。そして５年前にまた買ってしまいました。ここ２年ほとんど弾いてません。　何がいいたいかと言うと、それなりにコツコツ続けていたら、速弾きはできなかったかもしれませんが、多少はうまくなったのではないかということです。また、今も弾いていれば、おじいちゃんになっても弾けるのではないかということです。　継続は力なり。私の座右の銘です。みなさんも何かそういう経験はないですか？もしあるのならもう一度トライしてみてはどうでしょうか。　では～　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　千冬

こんにちは！ご覧いただきありがとうございます。前回はスケールについて説明しました。前回説明したスケールは「全全半全全全半」と規則的にならんでいるというお話でした。このスケールを知ると何で複雑なコードが弾けるようになるのか。今日は説明していきます。複雑なコードとは私はおしゃれコードと言っています。代表的なものはセブンスコード。これから説明します。「C ７」「C M7」といったコードネームの横に７という数字が出てくるコードです。なんの７かといいますと。Cメジャースケールド　レ　ミ　ファ　ソ　ラ　シ　１　２　３　４　　５　６　７　いつもCで例えてすみません。他のスケールでも同じ考え方です。一応Dでも出しておきます。Dメジャースケールレ　ミ　ファ＃　ソ　ラ　シ　ド＃１　２　　３　　４　５　６　７Eだとミから始まる、Fだとファから始まる音階です。数字を入れました。コード（和音）でお話した１・３・５度のことです。またCで説明しますが。C ７（シーセブン）　C M7（シーメジャーセブン、maj7とも書きます）７という数字がありますが、1・３・５の和音に、このスケールの７の音を足すということです。１・３・５・７の４和音になるということですね。なぜ７とM７とあるのか。ただの７は実は「（ｍ）７」マイナーが隠れています。ただの７はマイナーで、Ｍがついたらメジャーとなります。何が違うか、私の覚え方をお伝えしますと、ただの（マイナー）７は基音の一音（全音）下を弾くＭ（メジャー）７は基音の半音下を弾くと覚えました。結構セブンスコードは出てきます。C7だとド　ミ　ソ　シ♭（基音ドの全音下の音）１　３　５　７

こんにちは！今日もご覧いただきありがとうございます！今回コード番外編とうたっていますが、コードについて私大事なことを忘れていたので、今日はここで番外編と都合のいいように題しまして、忘れていたことをお伝えしたいと思います。笑その忘れていたもの自体これまた簡単なものなので、短めになります。どうぞ最後まで読んでいただけたら嬉しいです。今日は意外と出てくるオンコードです。オンコードとは分数コードと呼ばれるもので、和音と基音が違うものです。楽譜表記にすると「C on B」または「C/B」と記載されています。後者の「〇/〇」といった書き方が多いかな？と思いますがこれら二つはどちらも同じ意味です。ピアノで考えるととっても簡単。左手の基音はB　右手の和音はCを弾くです。オンコードはベースラインを次のコードにつながりよくするためのものなので、ベースラインを弾いている左手のみ。Bを弾くというわけです、右手はB無視して大丈夫。（どうでもいい話なんですが私はいつも弾くときオンコード右手と左手反対に弾いてしまいます。〇/〇って右手で弾くものを左に左手で弾くもの右に書いてあるからややこしいんだもん・・・すみません）これを弾くのに一つだけ注意があります。ベースライン（左手）で基音以外の音も弾くときです。例えばアルペジオで、弾くような曲があるとします。私が今適当に並べたコードから起こしたピアノ譜なんですが、ピアノがある方は弾いてみてください。オンコード並んでいますが、左手の基音以外の音に注目です。そう、左手がBだからといってBの和音を左手で鳴らしているわけではないんです。あくまで基音で一番低いベース音（小節の

今回も開いていただいてありがとうございます。今日は前回の続きを書いていこうと思います。コード（和音）について前回＃１ではコードネームと基音について書きました。C（ド）　D（レ）　E（ミ）　F（ファ）　G（ソ）　A（ラ）　B（シ）でしたね。簡単に言うと基音はベースラインとお伝えしました。では今回は和音に使われるコードについて書いていきます。前回同様　Cコードで説明していきます。この図の右手（青）の部分です。左手とは違って単音ではなく複数の鍵盤を弾いています。なぜCコードはドミソなのか。難しく言うと、Cスケールの基音から数えて３度と５度の音を加えて構成される和音のことです。簡単に言うと、基音（１とします）から数えて３個目と５個目の音Cスケールド（１基音） レ（２） ミ（３） ファ（４） ソ（５） ラ（６） シ（７）これの１・３・５を弾くとコードになるのです。前回述べた基音の話と合わせます。ピアノでコードを弾く場合。左手はベースライン（基音）主に単音右手は和音です。コードを鳴らす際は一番低い音が基音である必要があります。（例外ありますが）ただ逆を言うと一番低い音は左手で弾いているので、右手は必ずスケールの１・３・５度の順、ド ミ ソの順じゃなくていいんです。この図の通り右手は１・３・５度の組み合わせであれば順番は何でもいいのです。「ドミソ」でも「ミソド」でも「ソドミ」でもＯＫ。別に３つの音じゃなくても「ドソ」でも「ミソ」でもＯＫ。組み合わせ自由メジャーコードとマイナコード１つのコードをとっても、たくさんあります。まずは大きく分けて２つあります。メジャーとマイナーです。各コードとこの２

開発現場では、プロジェクトの途中で担当者が変わることは珍しくありません。そのときに発生するのが「コードの引き継ぎ」です。しかし、ここを軽視すると、後任者の生産性を大きく下げたり、最悪の場合はプロジェクト全体の品質低下につながります。この記事では、コードを引き継ぐ際に必ず意識すべきポイントを整理します。1. 「動くコード」だけでは不十分まず前提として、「動くからOK」は完全に間違いです。後任者にとって重要なのは、なぜその実装になっているのか他にどんな選択肢があったのかどこに注意すべきかといった“意思決定の背景”です。コードはあくまで結果であり、意図が伝わらなければ再利用も改善もできません。2. 命名で8割決まる変数名・関数名・クラス名が曖昧だと、それだけで引き継ぎは破綻します。悪い例datatempflag良い例userListisLoggedInfetchUserProfile命名はドキュメントの代わりになります。コメントを書く前に、名前で説明できているかを見直すべきです。3. コメントは「なぜ」を書くコメントでやりがちなミスは、「コードの説明」を書いてしまうことです。悪い例// ユーザーを取得するconst user = getUser();これはコードを読めばわかります。書くべきなのは「なぜこうしているか」です。良い例// APIのレスポンスが不安定なためリトライ処理を入れている理由がわかることで、後任者は安心して修正できます。4. 環境構築手順を必ず残すコードがあっても、動かせなければ意味がありません。最低限、以下は必ず明記してください。Nodeのバージョン必要なパッケー

AIがコードを書いてくれる時代になり、開発のスピードは確実に上がりました。エラーの原因を調べたり、実装のヒントをもらったり、ゼロからのコード生成も簡単にできるようになっています。しかし、だからこそ重要になるのが「AIが書いたコードを自分で確かめる」という姿勢です。ただ動けばいい、コピペして終わり、では長い目で見ると大きなリスクになります。ここでは、なぜ自分で確認する必要があるのかを整理しておきます。AIは正しそうに見える間違いを出すAIは非常に自然な文章やコードを出力します。見た目はそれらしく、説明も筋が通っているように感じます。しかし実際には、・微妙に仕様が違う・古い書き方をしている・エッジケースを考慮していない・環境によって動かないといったことが普通に起こります。特に怖いのは「エラーが出ないけど間違っている」ケースです。ロジックが静かに壊れていると、本番で問題になります。AIはあくまで予測モデルであり、コードの正しさを保証しているわけではありません。だからこそ、人間の目で検証する必要があります。理解せずに使うと成長が止まるAIのコードをそのまま使い続けると、表面的には開発が進みますが、自分の理解はほとんど積み上がりません。結果として、・トラブルが起きたときに直せない・応用が効かない・設計判断ができないという状態になります。エンジニアとして価値が上がるのは「なぜそう書くのか」を理解したときです。確認作業は単なるチェックではなく、学習そのものでもあります。セキュリティやパフォーマンスの問題に気づけるAIは一般的な実装を出すことは得意ですが、あなたのプロジェクト固有の制約までは理

来てくださってありがとうございます♪チャネリングアートのあいです♪☆☆☆今日は、私が見てきた、天と、地球と、その中間地点のことについて書きます。「単なる夢なんじゃない？」って言われるのが怖くてほとんど人に言えなかった。魂っていうか、私本体が、肉体をぬけて見たシステムのこと。そのとき私は、『上』に帰りたくて（天の世界っていうか、宇宙、みなもとのことです）自分の『白い紐』を探してた。天と、地球と、私がつながってる目印みたいなもの。シルバーコードって呼ぶ人もいる。確かにくさりみたいな銀色に近い色してた。天からは、無数の白い紐が束ねられた状態でつりさがってる。天へ戻る人は、自分の紐を見つけ出せていてそれをたどって、天へ帰る。私も帰りたかったのに、見つけられなかった。まだ私は地球にいることになってたから。その場所は、地球からは少しだけ離れてる。「輪廻をまだ楽しみたい」っていう人は、流れるプールみたいな輪廻のぐるぐるゾーンの地球に入っていく。楽しそうに。私は輪廻ゾーンへ行くのは嫌ででも自分の白い紐も見つからないしまだ地球にいることになってるし「どうしたものか…」って思ってた。ほかの人は、天へ帰るなり、地球へ帰るなりはっきりしてた。うろうろしてるのは私だけ…って、ふと見ると、男性がひとり、小さな男の子の頭をふいて着替えさせて、世話してる。その人は、何度も何度も、地球やり直しで学びあった人。（この人との過去生エピソード、今度書きますね）「あー、この人はこうやってここで世話するお役目と、地球と、兼任だったんだ…」ってことを知りました。そして、この中間地点のような場所とシステムの流れを理解したら、

こんにちは、じゃぱんらぶ♡あったか手書きデザイナーです。いつもお世話になっている医療・看護・介護・ケアマネージメント・エクササイズ総合施設のリピーターさんからパンフレットがメインでしたがホームページのリニューアル制作もお願いいただくことになり、このように完成できました。今の時点でデザインはできるけどコードはいまだに学習途上ですが、実際に初制作で感じたことは1.TOPページの場合、一番上は第一印象を表すので複数の画像の変化で見せる印象が効果的です。2.1つ1つ、絵本の挿絵のように一見難しく説明文のイメージを解釈する役割を担います。3.＜TOPの下でそれぞれの中身の紹介ページの場合＞下の説明文章は本当に一般的な文字タイプでOKです！ちなみに【元気づける・希望を持てる】というイメージの黄色がメインカラーとして、朧げながらも（利用者さんが）見ると元気になれるように暖かい絵本のような見せ方のホームページにみせました。このように、主にjimdoやペライチ、wevwly!のデザイン作成も承ります。もしご興味ありましたら、お気軽に【じゃぱんらぶ♡あったか手書きデザイナー】までお尋ねくださいませ♪

【テレビ台設置】 先日やっと雪で配達が延期されてた 待ちに待ったテレビ台が無事到着して さっそく組み立てて設置してみたらテレビの高さが良い位置になった テレビ台が配達される時間は 20時から22時の間だったので この時間にきっちり家にいたけど 22時近くになっても来なかった。 もしかしたらこの日も配達できずまた延期なのかと心配すしてたら 22時直前になって来てくれて ギリギリ間に合ってくれる。 その後すぐテレビ台を組み立て始め30分位で完了させて設置し始めると テレビの下が凄く汚れてたから 掃除をする羽目になってしまった。 そしてほこりを取って雑巾で拭き 絡まったコード類をほどいて テレビ台を設置できるようにすると もう汗をびっしょりかいてた。 ε-(･д･`;)ﾌｩ… 組み立てよりも掃除の方が大変で 無事に設置し終わったった時は 真冬なのに冷房つけようかと 迷うほど熱くなってる。 なので速攻お風呂に入って 汗を洗い流してすっきりし 気持ちが良い状態でテレビの前に座り 俺の新時代の眺めを味わった。 °˖☆◝(⁰▿⁰)◜☆˖° 〓＝〓＝〓＝〓＝〓＝〓＝〓＝〓＝〓＝〓 【プライスレス】 今まで俺のテレビが置かれてた位置は 床に直置きだった為テレビを見る時 目線が下向きになるから首も下に向き 肩が凝ってしまってた。 なので座椅子の背もたれに寄り掛り リラックスした姿勢になると テレビ画面が見えなくなってしまいまた下向き体制になってしまってた そこで座椅子の背もたれに寄り掛かり リラックス姿勢でテレビが見たくて この態勢でテレビの中心部分に 目線が来る高さの物を購入する。 すると最初の

はい、ギター侍です！（ウソじゃ）＾＾実は、数日前から「ギター」の練習を開始したのじゃ。もうかれこれ数十年前から、「ギターとか三味線、三線（サンシン）、バイオリン、二胡（ニコ）」なんかをどれか一つでもやりたいな～♪って思っていたのじゃ。でもなかなか重い腰は上がらなかったのじゃ。それがついに「ギター」を開始することになったぜよ。それで所持している楽器一覧を見ると「ギター２」、「バイオリン１」、「二胡１」という結果じゃ。なんか「楽器」って、手間がかかるというかね～、やろう！って思っても最初に「楽器の手入れ＋準備品の購入」なんかいっぱいアルじゃん。しかも、まだよく楽器に対する知識もナイし。だけど「中古の楽器」は何点かはアルし。弾いて「音が出る」のを楽しみたい気はするけどなんか「用意するまでが、ちょい長い」から、「なんだか知らないうちにやめて」しまう感じじゃね。それが、とうとうボクも「メルカリ」のパワーも借りて、出発じゃ。だけど、「ギター」って、なにやらけっこう種類があるらし～。「アコーステイックギター（フォークギター）」が元祖（親分？）でね～、弦が「ステンレスや銅」の金属でできているという。それに関連して弦が「ナイロン」でできているのが「クラシックギター（ガットギター）」じゃね。知らんかったぜよ。（＾＾；あとね～、すぐに演奏できるかな～と思っていたが、甘かった・・・。「チューナー装置」、「ストラップ」、「ハンガー」、「ブリッジピン一式」、「カポタスト」、「ストリングカッター」、「１－６弦」、「ストラップロック」、「楽器用クロス」等の準備が必要じゃった。ふぅ～（＾＾；あ、あと「ギター教習

耳コピの話題の続きです。僕が耳コピをするときは、・とりあえず通して聴く・サビの盛り上がるところの最初のコードを探る・メインで出てくるメロディーの高い部分がトニックになる傾向などを考えるのですが、まず最初に気にするのはベースの音です本物のベースは持ってないので（厳密にはありますが、耳コピするには音が低すぎる）、ギターで曲の流れに出てくるベースの音をとにかく追いかけます。そうすると段々トライアドの音がわかってきます。何度も何度も弾いているうちに確実なベース音が明確になってきます。まずはベース音を探すのが一番初めの作業ではないかな？と思います。ただ、これがややこしいベースの動きや、ジャズ系の曲だと通用しません。雰囲気は伝わってくるので、全く無意味ではないですがそのまま曲が弾けるかな？というわけにはいかないですね。最近は歌ネットなど、歌詞とコードが掲載されているサイトも多いので、答え合わせ的に見ることもあるのですが、上記のような曲は大概オンコードやテンションコードだったり、初めからセオリーを無視した曲だったりするので、そういう曲のコード分析は難しいですね。これを解決する方法は、また今度書きます。

こんばんは、Sizu屋です。今日は早速本題に入ってしまおうと思います。本日は、説明内容を文章化するのが、難しいという内容です。元々他業界からWeb関連の副業を始めた私にとって、それはもう何をとっても意味が分かりませんでした。それこそサーバーって何？とか、wordpress って何なの？など。そんな初心者の気持ちがよく分かる私は、お仕事をさせて頂いた方、特にあまりホームページ作りに携わったことがない方には、出来るだけ使い方を丁寧に伝えたいと思って、色々と説明をトークなどで送ったりしています。文章で送ることもありますが、画像を上手く使い分けながら説明をしています。そんなときいつも思うのが、Web上で色々説明記載してくれている方・・・、ありがとうございます。なんて面倒な作業を記載してくれていたんだ・・・・と何度も感謝の念を送りました。本当に、作業が面倒なのです。画像付きは特に！！しかし、画像が無いものはわかりにくいので、そこは外せない・・・と思うと、頑張って編集してしまうのが、凝り性の悪い点・・・。そう思うと、分かり易く説明出来ている方々は、もう尊敬以上の思いを抱いてしまいます。現在はサービスを受けてくれた方向けに文章化してあるもの個人さん向けに送っておりますが、コレが纏まりそうなら、自分のサイトにもいくつか載せておきたいな・・・と思います。色々苦労した内容に関しては、メモとして残して置いた方が、自分も助かるので、そのうち作成を検討しております。

近年、ChatGPTやGitHub CopilotなどのAIツールを用いてコードを書く開発スタイルが急速に普及しています。これらのツールは、プログラミングのスピードアップやアイデアの補完などにおいて大きな力を発揮しますが、利用にあたってはいくつかの注意点を理解しておく必要があります。1. コードの正確性を必ず確認するAIが生成したコードは、一見すると正しく見えても、実際にはバグやセキュリティ上の問題を含んでいることがあります。特にエラー処理や境界値のチェックが不十分な場合があるため、必ず自分で内容を確認し、必要に応じてテストや修正を行うことが重要です。2. セキュリティリスクへの配慮AIはセキュリティを考慮しないままコードを提案することがあります。たとえば、SQLインジェクションやXSS対策がないまま出力されるケースも存在します。セキュアコーディングの知識はAI利用時にも不可欠です。3. ライセンスと著作権の確認AIは大量のデータを学習しているため、**出力されたコードに著作権のあるコードが含まれてしまう可能性があります。**商用利用を考える場合は、オープンソースライセンスの確認や再利用ルールを意識することが求められます。4. AIの提案に依存しすぎないAIはあくまで「補助ツール」であり、開発者自身の判断力や設計力が最も重要です。AIの提案を鵜呑みにするのではなく、なぜそのコードが提案されたのか、他の選択肢はないか、という視点を持つことが大切です。5. 学習や成長の機会を奪わないようにする特に初心者の場合、AIのコード生成に頼りすぎると自分で考える力やエラー解決能力が身につかな

前回の記事を読んでいただいた方々、あありがとうございます。 前回はメジャーコードからマイナーコードへ簡単に切り替える方法でした。 今回はメジャーコードからSus４コードの解説をしたいと思います。 Sus4コード このコードはフワフワした感じがとても美しいコードですよね。 そんなコードの構成音を見てみましょう。 Csus4 Cメジャースケール ド・レ・ミ・ファ・ソ・ラ・シ・（ド) １・２・３・４　・５・６・７（単位：度） このスケール委の１と４と５が構成音です。 Csus4=ド・ファ・ソ このコードは企保pんの３和音でありながら３度の音がないんです。 ギターの指板上で見てみましょう Csus4 画像 Dsus 画像 Dsus4は弾き語りでもよく出てきますよね。 簡単に曲を彩ってくれる便利コードです。 どんなコードでも３度の音を見つけて半音上げることで sus4コードになります。 今回も簡単だったでしょ( ´艸｀)

今回もご覧いただきありがとうございます。毎度見ていただいている方はコードの理解なんとなくできたでしょうか？とらえ方としてはもうコードはお話することはないと思いますので今回は実践編！コードがわかっても弾けなきゃ意味がない。ということで今回は実践するためにどうやって弾いたらいいのか、弾き方（リズム）についてお話していきたいと思います。パターンは無限大。なので正直説明するのが難しいですし、言葉だけで理解するのもなかなか難しい。私は大きく分けて２パターンで考えています。ギターを思い浮かべてください。アーティストの「ゆず」の夏色のような（古くてすみません笑）ジャンジャカジャンジャカ弾いている弾き方、ストロークといいます。楽譜にするとこんな感じ。逆に優しい曲や、バラードなどで聴かれるような、一つずつ弦を８分音符のリズムで弾いている、アルペジオといいます。楽譜にするとこんな感じギターを弾くわけじゃないのでこの言葉のイメージさえできればいいです。ピアノを弾くときもギターで言うストロークとアルペジオの２つの考え方をします。ストロークをピアノで表現する場合。こんな感じに、右手の和音を同時にジャンジャンとならします。アルペジオのパターンはこんな感じ。一つずつ音を弾いていますね。これらを土台に色んなリズムで弾いています。パターンがたくさんあります。曲のリズム聴いてを感じとったり、ギターはどうやって弾いているのかなんていうのを参考にして曲を聴いていくとどうやって弾いていったらいいか感じ取ることができると思うので、まずは実践してみてください！「ピアノリズムパターン」と検索すると、リズムパターンを具体的に説

こんにちは！ご覧いただきありがとうございます。いつも見ていただいている方がいたり、いいねをいただけてとても励みになっています。いつもありがとうございます。今回はちょっと複雑なコードパート２です。パート１ではセブンスコードの話をしました。今回もスケールの数字（度数）を使用して説明します。スケール編の＃３をご覧になっていない方は是非そちらも合わせてお読みいただけると話が少しわかりやすくなるかもしれません。よろしくお願いします。今回ののコードは「C sus4」サスフォー「Cｍ7－５」マイナーセブンフラットファイブ「C dim」ディミニッシュ「C aug」オーギュメントこれら４つを説明します。ギターで弾くと難しいコードですが覚え方のコツでピアノでは簡単に弾けると思いますので、是非最後まで読んでいってください＾＾最初に「sus4」です。これは３度の音を４度に上げる。それだけです。４という数字がありますね。この４はそう、４度を弾くという４と覚えましょう。おなじみＣコードで説明します。Ｃsus4ド（１基音）　ファ（４度）　ソ（５度）　となります。曲を弾いていたらたまに出てきます。一つのメロディの終わりに、Ｃsus4 → Ｃみたいなパターンがほとんどです。弾いてみるとわかりますが、一つのメロディーが完結したようなコード進行になります。次にｍ７ー５　マイナーセブンフラットファイブdim　ディミニッシュ２ついっちゃいましょう。この二つ、厳密にいうと違うんですが、私はピアノ弾くときは同じものとしてとらえています。ｍ７－５今までの流れでうすうすわかる方もいるのではないかと思いますが。まずは「ｍ７」を思

　こんにちは！ご覧いただきありがとうございます。　私は音楽を聴いたり、楽器を弾くのが好きで、ピアノ、ギター、ベース、サックス、ドラム（少々）を弾きスマホに録音して一人バンドみたいなことをしています。　スコア譜を購入して弾くこともありますが、いちいち楽譜を購入するのはお金もかかるし、時々スコア譜がない曲もある。そこでアコースティックギターの弾き語りとかで使用されているコードが載っているサイトを見て、そこから音源を作成できないかと思いコードの勉強をしました。　コードで弾き語りってギターのイメージがありますが、実はピアノでもできて、しかもコツを覚えてしまえばギターよりも簡単かも！と私は個人的に思います。昔ピアノを習っていた友人や妻におすすめすると「楽譜がないと弾けない、コードって難しいイメージ」と私の周りの人たちは多いです。　この記事を見てくださっている方で、私の友人のような意見をお持ちの方、またはコードを見るだけで弾けるようになりたい。そんな方は是非見てください。特にピアノ弾ける方、コードも覚えたら最強だと思います。（個人の意見です）　　ちなみに私はすべての楽器は独学で、コードも自分で勉強しました。なので詳しい音楽理論まではわかりません。あくまで個人で趣味の範囲で楽しめる、その程度です。ただこれから勉強したい、コードって何？ピアノでコード弾いてみたい！という人にとっては役に立つ内容となると思います。これを覚えると何ができるようになるか？１．コード表を見るだけで初見でも弾き語りができるようになる。２．知らない曲でも、メロディを聴いたらそれに合わせて伴奏が弾ける。３．移調、転調してもす

ご存知の方、すみません。でも、ご存知なかった方、一度お試しいかがですか？★ギターで普通にEコードを押さえて、薬指を３フレットにずらすだけです。E7の置き換えコードとしてサビ前のアプローチなどにも使えます。★Eメジャー（ホ長調）の場合先程の、薬指を外して、代わりに小指をその隣４フレットに置きます。（ファ＃）以上、”隠し味”にいかがでしょうか？次はAmについても語ってみようかなと思います。では、失礼しました。

はじめにホテルの支配人を13年やった後、フリーランスエンジニアに転身し、今は JINZAI（ホスピタリティ特化の人材マッチングプラットフォーム）を一人で開発している。スタックは Next.js 14 / TypeScript / Supabase / Vercel。正直に言うと、マッチングサービスを作るのがこんなに大変だとは思っていなかった。この記事では、実際に手を動かして痛感した「3つの現実」を書く。同じように一人でマッチングサイトを作ろうとしているエンジニア、またはSaaSを0から立ち上げようとしている人の参考になれば。現実① マッチングサイトのDB設計は「関係者が多すぎる」問題が必ず起きる最初に設計した時、テーブルの数をなめていた。ECサイトなら users / products / orders の3本柱でだいたい話が成立する。でもマッチングサイトは違う。登場人物が多い。JINZAIの場合、主要なテーブルだけでこうなった：profiles // 共通ユーザー情報workers // 求職者プロフィールclients // 採用企業プロフィールjobs // 求人票applications // 応募messages // メッセージnotifications // 通知earnings // 収益・報酬管理documents // 提出書類（在留カード、資格証明など）verifications // 書類審査ステータスそして設計の難所は「誰が誰の何を見ていいか」という権

朝霞市の静かな公園でベンチに座り、ノートパソコンを開いた瞬間、ふと街の中にある日常の動きが頭の中のコードと重なった。私はフリーランスとして複数のWeb開発案件を抱え、業務システムやアプリの設計、実装、保守を一人で行っている。日々の作業は時に膨大で、複雑なコードに向き合う時間は長くなる。しかしこの日は、どうしても解決できないバグに悩まされ、外に出ることで頭を整理しようと決めたのだった。公園に到着すると、子どもたちが遊具で遊ぶ音、ジョギングする人の足音、ベンチで休む高齢者の会話が耳に入ってきた。最初はただの雑音に過ぎなかったそれらが、ふとプログラムのフローとして脳内に再構築される感覚があった。人や動きが、それぞれ非同期で動くモジュールのように見えたのだ。遊ぶ子どもたちの動きはイベントドリブンのトリガーのようで、ジョギングする人のペースは処理速度の参考になる。私はノートパソコンを開き、コードを眺めながら、外で見た動きをイメージして関数の呼び出し順序や条件分岐を整理していった。すると、今まで気づかなかったバグの原因が浮かび上がり、修正すべき箇所が一目で分かるようになった。朝霞市の公園で経験した、この街の日常のリズムが、そのままコードの最適化につながった瞬間だった。この体験から気づいたのは、エンジニアの思考力はデスクの前だけで鍛えられるものではないということだ。街の動き、自然の音、人の行動、すべてがプログラムの理解や問題解決のヒントになり得る。特に朝霞市の公園のように、人や自然が絶妙に混ざり合う空間では、非同期処理やイベント処理を直感的に理解するきっかけが得られる。フリーランスとして柔軟

※このブログは細かいことを書きすぎると延々と続いてしまいますので大まかにしか書いていません。専門の人はこれを見ても怒らないでください皆さんも一度は耳にしたことがある「AIを使って業務を効率化しよう！」という宣伝。私はたまに原稿の修正をしたりするのだが、果たしてこの作業はAIのよって効率化できるのだろうか？そんな疑問の答えを出すためにAIを使って文章校正AIを作った人のお話である。自己紹介機械の操作はできるがプログラミングには一切触ったことのない素人AIに関しては普通の人よりできると思っている。「第一章」Pythonを入れてみるAIを使うにはPythonだ。とよく聞くのでPythonを入れてみた。Pythonの容量は160MBとパソコン容量カツカツな私でも安心して入れることができた。 Visual Studio Codeもいれてここから編集、実行できるようにした。「第二章」とりあえずなんかやってみようプログラミングは一番最初に"Hello world"と表示させるのがしきたりだ(嘘)という話を聞いたのでコードを確認し打ってみた。成功だ。「第三章」プロンプト無事、環境構築は終わったわけだが本番はここからである。コードを覚えて自分で書くのはあきらめたので生成AIを活用してコードを書いてもらうことにした。AIにコードを書かせるには「文章校正AIを作って」と頼むだけではできない。そこでプロンプトからAIに任せることにした。使用したAIはGeminiである。Geminiは日本語に強そう！とかいう謎のこだわりがあるため私は日本語を多用するときはGeminiを使っている。そして完成したプロンプ

こんにちは！今日も見ていただいてありがとうございます。前回＃２ではコードが１・３・５度の音でできていると話しました。今回は各スケールについてお伝えしたいと思います。これがわかると今後の特殊なコードにも対応できると思いますので、是非今回も最後までお付き合いいただけると嬉しく思います。スケールとは？スケールとは、「ドレミファソラシド」ってドから始まって一つずつ音が上がっていくものです。よく知られている、何気なく言われているドレミファソラシドは、ドから始まるCメジャースケールです。でたでた、またここでもメジャーという言葉、マイナースケールもあるんかい。そうです、あります。ただ、コードとスケールの関係を簡単に話したい。なのでメジャースケールだけ説明します。マイナースケール、知らなくても何とかなります。私は何とかなっています。メジャースケールの音階について説明します。ド　レ　ミ　ファ　ソ　ラ　シ　ド〔全　全　半　　全　全　全　半〕全と半が出てきました。これは音の上がり方です。全は１音半は半音　上がっています。ピアノの鍵盤を見てもらったらわかりやすいかと思います。ミ　ファシ　ドの間には黒鍵がありません。なのでミファ　　シドは半音の関係にあります。その他の音は一音上がる、全音の関係になります。このように「全 全 半 全 全 全 半」と規則的に音の上がり方をするものがスケールとなります。Cスケール、ドから始まる全全半全全全半の音　すなわちドレミファソラシドになります。じゃあ他のスケールは？DスケールもEスケールも他全部考え方は一緒です。Dスケール　レから始まる全全半全全全半の音レ　ミ　ファ＃　

国分寺市でフリーランスエンジニアをしている桜井隆二です。大手SIerで基幹系システムの開発に10年携わり、現在は複数のスタートアップでWeb・業務系システム開発を支援しています。独立してから特に実感しているのが、「技術的負債」の恐ろしさです。 技術的負債とは?技術的負債とは、短期的な納期優先で作られた「その場しのぎのコード」が、長期的に保守コストを膨らませる問題のこと。新機能追加のたびにバグが生まれ、改修に時間がかかり、最終的には全体の作り直しが必要になります。 技術的負債を生まないために意識していること1. 可読性を最優先する半年後の自分が読んでも理解できるコードを書く。変数名や関数名は省略せず、意図が伝わる命名を心がけています。2. 適切な抽象化を行う同じ処理を3回以上書いたら、関数化やモジュール化を検討。ただし過度な抽象化は逆効果なので、バランスが重要です。3. テストを書く習慣をつけるユニットテストは面倒ですが、長期的には工数削減につながります。特に重要な処理は必ずテストを書いています。4. ドキュメントを残す「なぜこの設計にしたのか」という意思決定の記録が、将来の自分や他のエンジニアを救います。 長く使えるシステムを作るために技術は移り変わります。でも、本質的な設計思想は変わりません。目先の納期だけでなく、3年後も保守できるコードを書く。それが、プロとしての責任だと考えています。システム開発でお困りの方は、お気軽にご相談ください。

「5、6弦ルートの基本バレーコードを整理して覚える」ことをおすすめしています。整理すると23個の基本形を覚えて、5、6弦のドレミファソラシド（CDEFGABC)を覚えれば、ほとんどの場合で対処できます。(テンションコードやオンコードは基本形からの派生という考え方です。)コード進行を見ただけで、シンプルに弾けるはずです。コードブックの丸暗記とはおさらばして、コードを見ただけで弾けるようになりましょう。

こんにちは。笛を吹いているリョウです。先日、全く同じ内容を上げてしまったようですね。お恥ずかしい。今回は大丈夫なはずー。今日はアイルランド音楽を理論面というか、「曲」にフォーカスを当てて書いてみたいと思います。とはいえ、このへんは自分自身もそこまで深く掘り下げて研究している訳でもないので、ややザックリと書いてみたいと思います。アイリッシュにコードはなかった今でこそ、アイリッシュ・バンドが沢山存在していて、その編成にはギターやピアノ、ハープといった「和音が弾ける伴奏楽器」の担当が1人は在籍しているのが普通です。しかし、アイリッシュの演奏ではもともとこういった楽器は使われておらず、基本的にはフィドルや笛などの「旋律を担当する楽器」のみで演奏され、ハモリなどもほとんどなく、みんなで同じ音を弾く「ユニゾン・スタイル」だったようです。ジャズ・セッションでは奏者1人ずつにソロを回すパートがあったりするようですが、アイリッシュ・セッションではそういったものはありません。原則として常に全員で弾きます。※セッションについては次回書きたいと思います。アイリッシュはリズムが命アイリッシュはコードを使用せず、旋律のみを演奏します。ダンス・チューンでも同様ですが、ダンサーはその演奏に合わせて実際に踊るわけです。なので、演奏のリズムというか、テンポやグルーブが不安定だと大変踊りにくいわけです。そして曲自体も踊りに適したリズムやグルーヴが生まれやすいようにするためか、長い音が使われることはほぼありません。長い音はどうしても停滞しやすく、リズムやテンポ、グルーヴを失いがちで踊りにくいのでしょう。ダンス・チュー

朝のデスクに座った瞬間、キーボードの隙間から微かに聞こえる気配に思わず手を止めた。まるで昨日まで書き散らしたコードが、夜のあいだに勝手に呼吸を覚えたかのように、画面の奥でざわりと動いた気がしたのだ。システムエンジニアをやっていると、コードに人格を感じる瞬間は珍しくないが、この日のそれはいつもと違う種類のざわめきだった。どこか不満げで、どこか訴えかけるようで、そしてなぜか少し照れているようにも聞こえた。私はそっとエディタを開くと、昨日まで「動いていたはず」の処理がまるで拗ねた子どものように挙動をねじ曲げていた。エラーではない、バグでもない、それよりもっと曖昧で人間くさい乱れ方だった。まるでコードが、自分の扱われ方に文句を言いたくて小さく反抗しているように思えた。こんな経験は初めてではないが、今日はなぜかその声がやけに生々しく感じられた。私は画面に向かって小さく問いかけてみた。何がそんなに気に入らなかったのか、どこを直せば気持ちよく動いてくれるのか。しかし返ってくるのは沈黙だけで、ただカーソルがぴくりと瞬きをしているだけだった。コードというのは結局、人間が見れなかった部分を容赦なく反射してくる鏡みたいな存在だとあらためて思う。焦っていると焦ったように乱れ、丁寧に向き合うと不思議なほど素直に動き始める。その日は午前中いっぱい、コードと無言のやり取りを続けた。エンジニアをしていると、こうした静かな戦いの時間がどうにも愛おしい。コードにはコードの言い分があり、それを聞き取れたときの快感は何度味わっても飽きない。ふと気づくと、画面のざわつきはすっかり消えていた。あの反抗的な気配もなくなり、

 はじめにフリーランスエンジニアの大藏(大蔵)陽平です。キャリア10年目を迎え、Webシステムの開発を中心に、要件定義からインフラ構築、運用保守まで、あらゆる工程を経験してきました。その中で、最も成長を感じる瞬間があります。それがコードレビューです。コードレビューは「指摘」じゃない多くの方が、コードレビューと聞くと「ミスを指摘される場」だと思うかもしれません。でも、私が考えるコードレビューは違います。それは対話の場なんです。例えば、あるプロジェクトで若手エンジニアが書いたコードをレビューした時のこと。「この実装、面白いですね。でも、こういう書き方もありますよ」そう伝えたら、彼はこう返してきました。「実は、こういう理由でこの実装にしたんです」その瞬間、私の方が学びました。彼の視点は、私が見落としていたものだったんです。一方的な「指導」では成長しない要件定義からインフラ構築、運用保守まで全工程を経験してきた私でも、常に学ぶことがあります。技術は日々進化していて、新しいアプローチやツールが次々と登場します。だからこそ、コードレビューは**双方向の対話**であるべきだと考えています。「なぜこの実装を選んだのか?」「他の選択肢も考えましたか?」「このコードの意図を教えてください」こうした問いかけを通じて、お互いの思考プロセスを共有する。それが、開発の醍醐味です。ココナラでできること私がココナラで提供しているサービスは、単なるコーディング代行ではありません。技術的な課題解決を通じて、お客様のビジネスの成長に貢献すること。そのためにコードレビューや技術相談を通じて、一緒に最適な解決策を見つけ

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

フリーランスエンジニアとして働いていると、コードレビューを頼まれることがよくある。誰かが書いたプログラムを読んで、改善点を提案したり、動作をチェックしたりする仕事だ。でも最近、この作業をしているときに、少し違う感覚になることがある。まるで“人の話を聞いている”ような気分になるのだ。コードには、その人の癖が出る。命名の仕方、改行の位置、コメントの言葉遣い。表情も声もないのに、不思議と書いた人の性格が伝わってくる。焦っていたのか、迷っていたのか、楽しんでいたのか。人と話しているときと同じように、「ああ、この人はここで少し困ったんだな」とわかる瞬間がある。教師をしていた頃、生徒の作文を読むのが好きだった。文章の中に小さなつまずきやためらいを見つけると、その裏にある感情まで見えてくる気がした。あのとき感じていた「書いた人の呼吸を読む感覚」が、今になってコードレビューという形で蘇っている。プログラミングって、無機質な作業に見えて、実はとても人間的な行為なんだと思う。エンジニアを始めたばかりの頃は、コードを「正しいかどうか」でしか見ていなかった。でも今は、「どうしてこう書いたのか」を考えるようになった。たとえば、非効率な処理が書かれていても、そこには必ず理由がある。制約があったのか、時間が足りなかったのか、別の誰かと調整中だったのか。背景を想像すると、コードの“物語”が浮かび上がってくる。レビューで大切なのは、「間違いを指摘すること」ではなく、「考え方を理解すること」だと思っている。相手が何を大切にしてそのコードを書いたのか。それを理解してから意見を伝えると、会話が生まれる。たとえ画面越し

ある夜、コードレビューをしていた時のことだった。動作確認用に立ち上げたテスト環境で、ログに奇妙な一行が残っていた。「Hello, again.」もちろん、誰かが書いたジョークか、過去の自分のテストの残骸だろうと笑い飛ばそうとした。でも、その文字列が出力される条件を追うと、誰も触っていないはずの関数が動いていた。一瞬、背筋が冷たくなった。だが次の瞬間、なぜか妙にワクワクしている自分がいた。誰か、あるいは“何か”が、自分の作ったコードの中で呼吸しているような感覚。それはバグではなく、生命反応に近いものを感じたのだ。翌日、冷静に解析してみると、原因はシンプルなタイマーのループだった。けれど、不思議なことに「Hello, again.」という文字列はコード上に存在しなかった。そこでふと気づいた。僕らエンジニアが日々書いているコードも、実は“人の痕跡”で満ちているということに。コメントアウトされた古い行、命名に込められた意図、処理順の微妙な癖。どれも書いた人の考え方や癖を残している。コードとは、無機質なようでいて、最も人間臭い記録媒体なのかもしれない。それからというもの、僕は他人のコードを読む時、まるでその人の日記を読むような気持ちになる。完璧を目指しても、必ずどこかに「人」が滲む。焦りも妥協も、思いやりも、ちゃんと残る。そう考えると、コードレビューも少し優しくなれた。エンジニアという仕事は、しばしば論理と正解の世界だと思われる。でも、実際はもっと曖昧で、温度がある。エラーの一つ一つにも、その時の誰かの“選択”が詰まっている。システムは冷たいようで、内側はとても人間的だ。あの夜の「Hel

こんにちは、川口勇氣です。フリーランスエンジニアとして、スタートアップ数社の開発支援を担当しています。「動くけど、誰も触りたがらないコード」こんな経験はありませんか?納期に追われて書いたコード、数ヶ月後に見返すと自分でも理解できない。修正しようとすると、予想外の場所が壊れる。こうした技術的負債は、多くのプロジェクトで深刻な問題になっています。リファクタリングが必要なサイン新卒でSIerに入社後、複数のWebサービス開発を経験する中で気づいた、リファクタリングが必要なコードの特徴です。1つの関数が100行を超えている変数名が「data」「temp」など抽象的すぎる同じような処理が複数箇所にコピペされているテストコードが書けない(書きづらい)構造コメントがないと理解できない複雑なロジック私が実践する段階的アプローチStep1: テストコードを書くリファクタリング前に、現在の動作を保証するテストを用意します。これがないと、変更が正しいか確認できません。Step2: 小さく分割する大きな関数を、単一責任の小さな関数に分解。フロントエンド・バックエンド両方で有効な手法です。Step3: 命名を見直す変数名、関数名を「何をするか」が明確に伝わるものに変更します。Step4: 重複を排除する共通処理を関数化し、DRY原則を実践します。 サーバー構築やAI実装でも同じ特にAI技術の実装では、実験的なコードが本番に残りがちです。動作確認後、必ずリファクタリングの時間を確保することが重要です。価値あるプロダクトづくりには、保守しやすいコードが不可欠。リファクタリングでお困りの方は、ぜひご相談くださ

大手SIerから独立して、最も変わったのは「コードの温度」だと思う。前職では、基幹系システムの開発を担当していた。堅牢性、保守性、安定性が何より重要で、僕が書くコードは常に冷静で、計算され尽くしていた。それは間違いなく価値のある仕事だった。でも、どこか物足りなさもあった。独立してスタートアップの支援を始めてから、その理由がわかった。「誰かの熱い想いに直接触れること」が、僕には必要だったんだ。スタートアップの経営者やプロダクトマネージャーと話すと、彼らの目が輝いている。「この機能で、ユーザーの課題を解決したい」「このサービスで、業界を変えたい」。そのエネルギーが、直接こちらに伝わってくる。そして不思議なことに、僕が書くコードも変わった。以前は「正しく動くこと」が最優先だったが、今は「ユーザーに届けること」を最優先に考えるようになった。完璧を待つより、まず動くものを作ってフィードバックをもらい、素早く改善する。もちろん、堅牢性や保守性は今も大切にしている。でもそれは、ゴールではなく、ユーザーに価値を届け続けるための手段だ。スタートアップの現場には、正解がない。だからこそ技術だけでなく、想像力と情熱が必要になる。クライアントの熱量に触れながら、僕のコードも熱を帯びる。これが、今の僕にとって最高の働き方だ。

朝霞市を歩いていると、なぜかアイデアが湧く。駅から少し離れた住宅街を抜けると、静かな風が流れてくる。信号待ちの間にふとスマホのメモを開いて、コードのロジックを修正したくなる。この街には、なぜか“整理されすぎていない思考”が似合う。都心のように完璧に整ったテンポではなく、ちょっとした間がある。その間に、頭の中で未解決のエラーが整理されていく。ある日、コワーキングスペースの片隅でコーヒーを飲みながら、次のシステム設計を考えていた。周囲は学生やフリーランス、子ども連れの親。誰も急いでいない。そんな環境の中で、思考のスイッチがふっと切り替わる瞬間がある。都心では見失っていた「考える余白」が、ここ朝霞には確かに存在しているのだ。システムエンジニアの仕事は常に正解を探す旅のようなものだが、正解はいつも整然とした環境に転がっているわけではない。むしろ、ほんの少しのノイズやズレがある場所の方が、発見が多い。朝霞の街を歩くと、古い家屋と新しい建物が並び、少し不思議なリズムを刻んでいる。道路の曲がり方ひとつにも、人の生活の工夫が見える。これが、システムの中で言えば“レガシーコード”のようなものだ。削除せずに残されたものが、今の仕組みを支えている。この街の風景を見ていると、システム開発と街づくりが重なって見える。新しいフレームワークを導入しても、過去の構造を完全に捨てることはできない。古いものの上に新しいものを積み重ねながら、少しずつ最適化していく。その過程こそが、創造の本質なのだと思う。朝霞市という空間には、その“積み重ねの美学”があちこちに息づいている。商店街の小さな看板、静かな公園、夕方の子ど

深夜のオフィスで、無数のコードと数字が私を取り囲んでいた。システムエンジニアとして働く日々は、問題解決の連続であり、無限ループに巻き込まれるような感覚に陥ることもある。バグを追いかけ、仕様書と戦い、ユーザーの要望を現実に変換する。目の前の画面は冷たく光り、指先の動きとキーボードの音だけが世界を支配していた。しかしある瞬間、私はふと自分の仕事の意味を違う角度から見つめてみたくなった。翌朝、いつもの通勤路を歩きながら、街の景色を観察してみた。普段は目に入らない建物の隙間や、歩行者の微妙な表情、交差点で信号を待つ人々の間に生まれる小さな動き。コードの世界では見えない微細な情報が、現実には無限に存在していることに気づいた。デバッグの連続で疲れた頭が、街のリズムに触れることで静かにリセットされていく。その日、カフェでノートパソコンを開くと、普段ならただの文字列にしか見えないログやデータが、何か新しいアイデアの種に変わった。人々の行動パターンや季節の変化、空気の匂いをヒントに、システム設計に応用できるインスピレーションが湧いてきたのだ。プログラムの世界は理論やルールで満たされているが、現実世界のランダムさや微妙なズレが、創造性のトリガーになることを知った。私はその日、システムエンジニアとしての仕事を単なる“バグ修正”や“仕様実装”ではなく、現実世界からの情報を取り込み、柔軟に応用するアートのようなものだと考えるようになった。コードと街、人とデータの間に見えないつながりを見つけることが、仕事の楽しさを倍増させる。毎日のルーチンやタスクに追われるだけでなく、意識的に現実の動きに目を向けることで

こんにちは！システムエンジニアの雨河倖生です。今日は「バグを劇的に減らせるコードレビューのコツ」について、実体験を交えてお話しします。従来のコードレビューの問題点大手SIer時代、私は典型的な「粗探しレビュー」をしていました。コードの間違いを見つけることが目的指摘される側は萎縮レビューが形式的になりがち結果、表面的なバグは見つかっても、根本的な問題は見過ごされることが多かったんです。私が実践している3つのポイント1. 「なぜ」を聞く文化を作る「このロジック、どんな理由でこの実装にしたんですか？」批判ではなく、純粋に理由を聞くだけで、書いた本人が「あ、ここ改善できるな」と気づくことが多いです。2. 段階的レビューの導入設計レビュー（実装前）コードレビュー（実装後）テストレビュー（テスト実装後）早い段階でチェックすることで、大きなバグを防げます。3. AIツールとの使い分け最近力を入れているAI技術を活用して：構文エラーや基本的なミス→AIがチェックロジックや設計の妥当性→人間がレビュー実際の効果あるスタートアップでこの方法を導入した結果バグ検出率が30%向上チーム全体のスキルアップが加速レビュー時間は逆に短縮バックエンドからインフラまで対応する理由システム全体を理解しているからこそ、単体のコードだけでなく、システム全体への影響も含めてレビューできます。まとめコードレビューは「人を育てる場」でもあります。バグを減らすだけでなく、チーム全体の技術力向上につながる仕組みを作ることが大切です。システム開発でお困りの企業様、ぜひ一度ご相談ください！

こんにちは、城間勝行です。最近、ふと思うんです。エンジニアとして仕事をしている中で、何かがうまく動いた瞬間や、新しいアイデアが閃いた瞬間、テンションが急上昇することってありませんか？私、まさにそれがあるんです。仕事で「テンション上がる〜！」って思う瞬間って、単なる結果や成果だけじゃなく、実は「コードを駆使して何かが動き出したとき」なんですよ。例えば、あるプロジェクトでAPIの設計を担当していたときのこと。初めてそのAPIが動いた瞬間、思わず声が出ました。「うわっ！動いた！」って。バグもなく、スムーズにリクエストが返ってきた時、なんとも言えない達成感とともに、心の中でガッツポーズ。開発の初期段階で悩んでいたことが、時間をかけて形になった瞬間、もうテンションがMAXになります。エンジニアって、普段は目に見える形ではなく、コードの中で悩んだり、試行錯誤したりしているので、成功したときの感動はその分強烈なんです。特に、難解な仕様を解決したり、以前解決できなかったバグをやっと直した瞬間なんかは、「自分、天才か？」って思っちゃうくらい嬉しくなります（笑）。また、フリーランスで働いていると、自分で計画を立て、スケジュールを管理しながら進めていきます。これ、意外とテンション上がるんですよね。クライアントから「これで進めてほしい」と言われた要件が、最終的にどんどん具現化していく過程。コードを書いている途中で「ここ、こうしたらもっと効率良くなるんじゃないか？」と気づき、そのまま実装してみたときの爽快感。理想通りに進むと、これまたテンションMAX！自分で思いついた改善が反映される瞬間って、エンジニア