コードレビュー前に、きちんとテストしよう - GoQSystem Tech Blog
こんにちは。GoQSystemで技術顧問をしております、@hiro_yです。この記事は「GoQSystem Advent Calendar 2025」、20日目の記事です。 Webエンジニアの皆さん、テストをしていますか。 「テスト」と聞いたとき、最初に思い浮かべたものは何だったでしょうか。テストコードを書くことだったりしませんか。テストコードは、関数やメソッドといった処理の単位でユニットテスト（単体テスト）の自動化を進めるためのものです。あくまで「テスト」の一部を構成するものでしかありません。 最近、開発プロセスの一つとしてコードレビューが行われることが当たり前になってきました。コードレビューの責務についてはそれぞれのシチュエーションがあるかと思いますが、単体のコードとして問題がないかを確認するのが第一義です。処理の手順やパフォーマンスの観点から問題がないかどうか、それに対して適切なテス
輪読会に大切なこと - GoQSystem Tech Blog
こんにちは。GoQSystemで技術顧問をしております、@hiro_yです。 GoQSystemでは毎週Tech meetupと称して技術系勉強会を開催しています。ここしばらくは輪読会を実施していたのですが、取り組みとして気を付けておかないとせっかくの時間がもったいないな…と感じたので、いくつかポイントを示します。 ちなみに今読んでいる書籍は、改訂新版『良いコード／悪いコードで学ぶ設計入門』です。 意見や感想を持つこと、表明すること 今回の輪読会では、事前に書籍を参加者がそれぞれ読んでくること、毎回章ごとに担当者を決めるので、その担当者がサマリーを用意して発表すること、というルールでやっています。（皆の前で情報をまとめて発表する練習も兼ねています。） サマリーを作るとなると、よくも悪くも、書籍の内容をそのまままとめたものになってしまいがちです。しかしそれは読めばわかる内容なので、実際に読ん
モデリングは誰の仕事か？ - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiroy.kotori.styleまたは@hiro_y）です。 2024年2月11日、PHPカンファレンス関西2024が開催されました。なんと430人以上の方が参加されたとのことで、大盛況。私も東京から日帰りで参加しましたが、とても楽しい、有意義なイベントでした。 当社からはエンジニアの荻島さんが登壇しました。当日の様子は別記事になっているので、そちらをご覧ください。 tech.innovator.jp.net さて、私が当日参加したセッションに、菱田裕美さん（@77web）の「モデルとは何か」があります。Webシステム開発で使われるところの「モデル1」ではなく、「模型」（「プラモデル」とかの）を示す言葉としての「モデル」に着目して、モデルにすると何がうれしいのか、Webシステム開発におけるモデルとは何なのかについてわかりやすく語られていました。 システムは現
クライアントワークに大切なこと - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡です。 イノベーター・ジャパンのメイン事業はいわゆるクライアントワークです。単に制作を受託するのではなく、お客さまのビジネスの成功に寄与できるよう、そもそもそのシステム（Webメディア等）が必要なのか、他にもっとよいアプローチはないかの部分からお付き合いをさせていただくケースが多くなっています。 そうした各プロジェクトの中で、お客さまと主にお話しするのはWebコンサルタントやWebアナリスト（いわゆる「ディレクター」職に近いところ）となります。しかし例えば、その人たち「だけ」がお客さまと接点を持っている状態で要件と仕様をまとめ、社内のエンジニアやデザイナーに決定事項として制作を指示・依頼するような進め方でうまくいくでしょうか。 もちろん、制作という観点からは、作るものが決まっていればものは作れます。しかしその背景にある、お客さまがどういう企業や団体であるか、担当の方
自分の専門領域の外側の「のりしろ」を増やしていくこと - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiroy.kotori.styleもしくは@hiro_y）です。 先日、当社湘南オフィス（茅ヶ崎にあります）にてGitやGitHubに関する勉強会を行いました。今さら？と思われるかもしれませんが、対象はエンジニアではなく、エンジニアと一緒に仕事をするWebコンサルタントや運用メンバーたち（&donutsプロジェクトメンバー中心）。少しでもエンジニアの話す言葉をわかるようになりたい、円滑にコミュニケーションできるようにしたいとのことでした。 自分が話した内容は、バージョン管理システム、Git、GitHub、CI/CD、ブランチ戦略について等。どこまでわかっておいた方がよいですか、という質問があったので、概要は理解しておいてほしい部分もあるけど、基本的にはエンジニアに聞いてください、コミュニケーションを取るようにしてくださいとお願いしました。 ひょっとしたら、全部
Webエンジニアはクリエイティブな仕事か？ - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiroy.kotori.styleもしくは@hiro_y）です。 先日、PHPカンファレンス20231が開催され、来年前半に開催される東京以外（北海道、関西、小田原、香川）のカンファレンスが案内されました。東京ではPHPerKaigiが来年も開催予定。PHPコミュニティの盛り上がりを感じます。 そうした催しに参加する私たちは「Webエンジニア」なわけですが、よく語られる言説として「エンジニアはクリエイティブな仕事である」というものがあります。クリエイティブ、つまり創造的な仕事というわけです。でも、本当にそうでしょうか。 例えば、ディレクターやSEの作った指示書・設計書に従い、ただそれを実現するためのコードを書くお仕事があるとします。あまりクリエイティブとは思えませんよね。 もちろん、実装の仕方で工夫できるところはたくさんあります。しかし、本当にそのやり方でビジ
処理完了後のリダイレクトのHTTPのステータスコードに「302」と「303」どちらを使うべきかという話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiroy.kotori.styleもしくは@hiro_y）です。 Webアプリケーションを作成する際、最近だとJavaScriptでAPIにアクセス、その結果を受け取って画面の表示を変えたり、場合によっては別のURLに移動するように作ることが多いかもしれません。Next.jsやRemix、SvelteKit等のフロントエンド由来のフレームワークを用いれば簡単に実装もできてしまいます。 しかし全てのWebアプリケーションがそうした実装を必要としているわけではありませんし、以前から運用されているWebアプリケーションはもっと素朴な作りをしているのではないでしょうか。サーバーサイドでHTMLをレンダリングし、フォームから値がPOSTで送信され、サーバーサイドで処理を行う、というような。 そうしたAPIを返すのではないサーバーサイド実装において、POSTで値を受け取り
「正しさ」をめぐるコミュニケーションについて - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_yもしくは@hiroy.kotori.style）です。 自分も含め、エンジニアは「正しいこと」にこだわりがちです。設計の「正しさ」だったり、プログラミングコードの「正しさ」だったり、「正しいこと」について考える機会が多いのが理由でしょうか。 その結果として、「正しくないこと」に過剰に反応してしまいがちです。つい強い言葉を使ってしまったり、細かい部分に都度意見を言ってしまったり。そうしたきっかけで、他の人と衝突してしまったことはないでしょうか。自分はあります。 しかしよくよく考えると、エンジニアが考える「正しさ」も最初から確立していたわけではありません。チームのエンジニア同士、あるいはもっと大きなエンジニアコミュニティの中で何度も議論され、話し合われて、その結果得られた現在地点としての「正しさ」なのではないでしょうか。だからこそ皆が納得感を抱いている。
テキストコミュニケーションでつまずかないようにするために - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 イノベーター・ジャパンでは、リモートでのコミュニケーションが日常です。オフィスが東京、福岡、柏、湘南と分かれており、フルリモートで働くメンバーもいるからです。また現在、出社を最低週3日としているので、週2日はリモートで仕事する可能性があります。 そうしたリモートワークを支えているのがSlackです。全社用、プロジェクト用、部活動用、個人用（分報）など数多くのチャンネルが乱立（よい意味で）しています。もちろん、ビデオ会議（Zoomを使っています）やSlackのハドルミーティングも活用していますが、多くのコミュニケーションはテキストを用いて行われます。 テキストコミュニケーションですが、誰もが最初からうまくできるわけではありません。どういうわけか、人はテキストだと強い調子で物事を書きがちです。人を傷つけてしまったり、人に不安や疑念を起こさせるよ
業務を一人でやらずに楽しく進める工夫 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 イノベーター・ジャパンでは、大切にしている価値観として四つのVALUEを決めています。「LOVE」「CHAOS」「GROOVE」「ENJOY」です。普段特別に意識することはあまりありませんが、ふりかえると大切だよね、と思うことが多いかもしれません。 ちなみに二つ目の「CHAOS」は、別に混沌とした状態を是とするわけではなく、新しいことを始めるときは勇気を持って道なき道を進んでいこうぜ、というチャレンジ精神を大切にする心がけです。やっていくぞ（最近だとGenerative AIあたり進行中です）！ さて、今回はそのうちの「ENJOY」にまつわる話。 開発だけでなく、業務で一人でやるのがつらかったり、一人でやると悩んでしまったりすることってありますよね。あるいは一人でやると捗らない作業も。例えば見積もりを考えるとか、仕様について整理するとか。そ
オフラインのカンファレンスでテンションを上げる話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 2023年3月23日から25日にかけて、PHPerKaigi 2023が開催されました。オフライン・オンライン合わせて過去最多の参加人数だったとのことで、少しずつオフラインイベントに人が戻っている気配を感じます。6月にはPHPカンファレンス福岡2023も開催されますね。 PHPerKaigi 2023には当社もスポンサーとして協賛し、エンジニアのメンバーがオフライン・オンラインで参加しました。参加記事も書かれているので、よろしければご覧ください。 tech.innovator.jp.net tech.innovator.jp.net オフライン参加の意味と効用 さて、数年前に私は「リアルの勉強会やカンファレンスに参加する意味」という記事を書きました。また「それでもオフラインのカンファレンスに行く理由」という記事も書いています。 言いたいこと
情報カードを使って登壇資料のスライドを作る話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 今月（2023年3月）、PHPerKaigi 2023がいよいよ開催されますね。イノベーター・ジャパンはシルバースポンサーとして協賛しています！ そして私は2日目に登壇予定なので、登壇資料のスライドを作って調整しているところです。 fortee.jp 登壇資料はKeynoteで作ることが多いです。スライドは要するに紙芝居。過不足なく一連のストーリーが伝わる必要があります。私の場合、いきなりKeynoteで作り始めるのではなく、最初は紙に流れを考えながら「あらすじ」を書き出すという方法をとっています。 そこで便利に使っているのが「情報カード」です。いろいろな種類や大きさのものが売られていますが、最近愛用しているのはダイソーで購入できる無地で名刺サイズの小さなものです。何と言っても100円なので気軽に買えるし、どんどん書いていけます。 1枚をス
心理的安全性の育て方 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。ここ数年「心理的安全性」という言葉を目にすることが増えました。Web上の記事でも、書店に並ぶ書籍でも。 自分も何度か「心理的安全性」って大事だよね〜と話した記憶があるのですが、実際のところ「心理的安全性」とは何でしょう。大切なのは誰もが同意するでしょうが、皆が思い描く「心理的安全性」が達成された状態は少しずつ違っていたりしないでしょうか。 ちなみに似たような感じで扱われる言葉に「コミュニケーション」があると思っていて、大切なことは否定できないけど具体的に何を指しているかは人それぞれ、という…。最近はなるべく「コミュニケーション」という言葉を使わないようにしてみています。 さて、話を戻します。「心理的安全性」とはそもそも何なのでしょうか。自分なりに考えた結果としては、「状態を指す言葉ではあるけれど直接は作れないもの」です。どのような状態かという
システムの保守には修繕計画が必要という話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 ソフトウェア開発（特にWebアプリケーション開発）に携わっていると「レガシー」という表現をよく聞きます。でもよくよく考えてみると、ソフトウェアは放っておいても腐りませんし、錆びてしまうこともありません。しかし現実問題として、ソフトウェアは放っておくと否応なく「レガシー化」します。どうしてそうなってしまうのでしょうか。 （「レガシー」それ自体は悪い意味の言葉ではないはずですが、不思議とソフトウェア開発の文脈だとよくない意味合いの方が強くなってしまいますね…。） レガシー化する理由とその対策 動いているソフトウェア自体が変化しなくても、周りの環境が変化します。OSのバージョンが上がったり、その上で動いているミドルウェアが変わります。また、最近だとクラウド環境を利用することが多いので意識することが減りましたが、ハードウェアも新しいものがどんどん出
zassouを続けている話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 以前、当社のコーポレートブログ「OMOSAN」に「zassouを始めた話」を書きました。当時はコロナ禍が始まり、リモートワーク導入も緒についたばかり。肩肘を張らずに1on1を続けていく仕組みとして「雑談と相談」を月に一度行うようにしたのでした。当時どのような経緯で始め、何を考えていたかはあちらの記事をご覧ください。 それから二年が経ちましたが、今でもzassouを続けています。形式はオンラインだけでなく、オフライン（対面）で行うことも増えてきました（当社の勤務形態は基本、出社とリモートのハイブリッド形式です）。どのように続けて現在に至っているか、簡単にふりかえります。 月に一度のペースで行う 原則として、月に一回実施しています。評価面談のある月など、予定が立て込んでいたり他で話す機会がある場合はスキップする場合も。 月初にスケジュールを確認
オンライン会議（Web会議）のスッキリした終わらせ方 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 イノベーター・ジャパンではオフィスが複数拠点（東京、福岡、柏、湘南）に分かれているため、コロナ禍以前からオンライン会議（Web会議）を活用してきました。最近ではリモートワークも導入され、一層その頻度が増えています。サービスとしてはZoomやGoogle Meetを使っており、音声だけで済ませる場合はSlackのハドルミーティング（Huddle）を使うこともあります。 距離が離れていても気軽に顔を見て話すことができるオンライン会議はとても便利なのですが、終わらせ方が難しいと感じることがあります。何となく会議や話がスッキリ終わらないな…という体験、されたことがあるのではないでしょうか。もうお互いに話が終わったか、探り合いのようになってしまうこともありますね。 対策として自分がやっているのは、終わりにする、解散する際の決まり文句を決めておくことで
ビデオ会議で明るい表情と声で話すこと - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 コロナ禍でリモートワーク（テレワーク）が促進され、オフィスに出向かず自宅等でお仕事する方も増えたのではないでしょうか。特にIT業界では顕著だと思います。 そういった状況の中で、あっという間にポピュラーな存在になったのがビデオ会議（オンライン会議、Web会議）ではないでしょうか。ZoomやGoogle Meet、Microsoft Teams等を用いた打ち合わせ・会議はもはや当たり前の光景になっています。 当社ではコロナ禍以前より複数拠点間（東京・福岡・&donutsの各オフィス）で連携しての業務を行っていましたが、当時はPolycomの会議システムを利用して、拠点同士をつないでやり取りをする程度でした。しかし今や、それぞれのPC同士で接続できるようになったのです。本当に便利な世の中になりました。 ビデオ会議で必要になるのは、高速な回線とカメ
ねばり強く問題に向き合えるかという資質 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 先日、ISUCON12のオンライン予選に三人のチームで参加しました。本戦には進出できませんでしたが、目標の「スコアをゼロでなく、きちんと出せる形で終わること」「楽しむこと」の二つは達成することができました。 久しぶりに一日アプリケーション開発のことだけ考える時間を持てた気がします。自分の場合、普段はどうしても会議やいろいろやらなければならないことが多く、なかなかまとまった時間を取ることができていませんでした。定期的にそうした時間を取れるようにしてみようかな、と思ったりしています。 さて、ISUCON12オンライン予選への参加を通じて、エンジニアの資質としてあらためて「ねばり強さ」というものがあるなと感じました。何か問題が起こったとき、あるいはわからないことに遭遇したときに、一歩一歩解決に向けて考えたり、調べたりしながら手を動かし続けられる能
採用面談（カジュアル面談）をするときに考えていること - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 採用活動において、「採用面談」（あるいは「カジュアル面談」）を行うのが当たり前になってきました。いわゆる「採用面接」とは別の、選考過程ではない、その前段階という立て付けです。今回は、自分が採用面談をやる側として考えていること、心がけていることについて書いてみようと思います。 ちなみに、当社では私がエンジニアとデザイナーの採用面談を担当しています。自分一人で行うことも、誰かエンジニアやデザイナーと一緒に行うこともあります。 採用面談の目的としては、イノベーター・ジャパンという会社のことを知ってもらうことと、もし何か知りたいこと、聞きたいことがある場合にそれに対して答えることです。基本的には会社紹介を行っていくのですが、話を始める前に、知りたいこと、聞きたいことがないか伺って、あるようならその話題を中心に紹介をしていきます。 昨今の情勢によって
Git diffのタブ幅を設定する方法 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 （諸事情あって）インデントにタブとスペースが入り交じったPHPファイルを編集していて、git diffのデフォルトのタブ幅が8であることに気付きました。タブ幅は4として表示したいところ。 public function foo() // ここもタブインデント { // ここもタブインデント - echo "ここはタブでインデントされているところ\n"; + echo "ここはスペース4文字分でインデントされているところ\n"; ファイル内、もしくはプロジェクト全体のインデントのルールを統一して適用すればよいだけなのですが、一旦とりあえずdiffを見やすくしたかったので、Gitのcore.pagerの設定を変えて見やすいようにしました。 $ git config --global core.pager 'less -x1,5,9,13,17'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
