はじめに こんにちは。2026年4月に新卒で入社したエンジニアの尾形です。 入社してからの半年間は、新卒研修の一環として、最初の3か月と次の3か月でそれぞれ別のチームに入って開発をしてきました。9月末でその研修期間が終わり、ひと区切りついたこのタイミングで半年を振り返ってみることにしました。 この半年でやってきたこと 大学院を修了して入社し、介護/障害福祉事業者向け経営支援サービス「カイポケ」の開発組織に所属しています。カイポケは、長く提供してきたカイポケクラウドから、新しく作り直したカイポケコネクトへの移行を進めています（リニューアルの背景は こちらの記事 にまとめられています）。私はこの半年で、その両方のチームを経験しました。 4〜6月はカイポケコネクトのチームで、小さな修正から始めてモブプログラミングで少しずつ機能開発に入り、帳票の一覧・出力機能をバックエンドからフロントエンドまで通して実装しました。7〜9月はカイポケクラウドのチームに移り、長く運用されてきたコードベースで、不具合修正の施策や画面のパフォーマンス改善を担当しました。9月は次の制度改正への対応準備に加えて、カイポケコネクトのチームの開発にも一部関わり、9月末からは本配属先としてカイポケコネクトのチームで活動しています。 この半年で印象に残ったこと 現場やユーザーに触れた 最初のカイポケコネクトのチームでは、入社1か月目からユーザーインタビューに参加し、現場の声を直接聞きました。入社直後の研修で介護業界の全体像を学んでいたので、業務の大まかな流れは追いながら聞くことができ、研修で学んだ制度が実際の業務で使われているのを感じました。 7月には、デイサービスでの事業所体験にも参加しています。その日は送迎に同行し、レクリエーションの補助をしながら、主に記録業務を手伝いました。印象に残ったのは、利用者さん一人ひとりの状況に合わせた運用があることです。たとえば送迎では、耳の不自由な方の場合はインターホンを鳴らさず、決まった時刻より前から玄関前で待っていました。まだ準備をしていないだろうと予想できる方へは先に声だけかけておき、ほかの方を迎えている間に支度をしてもらうといった工夫も見られました。 記録は、ご家族に渡す連絡帳のもとにもなり、ご家族とのコミュニケーションに欠かせないものです。ただ、ケアに追われると記録は後回しになり、数字では表しづらいけれど連絡帳に書きたい、利用者さんのちょっとした様子ほど残すのが難しいというお話も職員の方から聞きました。 一方で、ドメインの理解には今も苦戦しています。入社直後は、帳票の種類も、それに絡む制度も、ほとんどわかっていませんでした。リファインメントで何の話をしているのかわからず、「何を聞けばわかる状態になるのか」すらわからない時期もありました。カイポケクラウドのチームに移ってからも、次の制度改正に向けた勉強会で介護報酬の単位数計算に初めて取り組み、その複雑さを痛感しました。 ただ、研修や事業所体験など学ぶ機会は多く、知っていることは少しずつ増えています。9月に受けた業界団体の介護請求システムの入門講座では、すでに聞いたことのある内容も多く、ゆっくりではありますが学んできた知識が定着してきたと実感しました。 わからないことをチームに頼った カイポケコネクトのチームでは、入社直後から夕会でタスクと関係ない雑談や相談ができたので、チームに声をかけやすかったです。モブにも気軽に誘ってもらえ、はじめは質問すること自体にハードルを感じていた私も、回数を重ねるうちに慣れていきました。担当した機能は、ほぼモブで実装するところから始めて詰まったときだけ相談する形に移り、最後は1人で実装するという段階を踏ませてもらえたので、自分の手で作りきれました。 カイポケクラウドのチームでは、自分から方針を出して見てもらう、という頼り方へ変わりました。最初の施策はデータ取り込みの不具合の修正です。局所的なバグに見えていたものが、実は仕様上の考慮漏れでした。そこで一通り調べたうえで、根拠を添えて「この方針で直します」とチームに伝え、方針を見てもらってから実装を始めました。先に見てもらえていたので、その後は安心して手を動かせたと感じています。 8月に担当したのは、利用者さんの介護サービスの予定を事業所へ送るときの、送信対象を一覧で表示する画面が重いという問題の改善です。SQLを書き換えると別の箇所で全件を読みにいってしまうなど、すんなりとは進みませんでした。手元で再現しながら原因を詰め、変更が複雑だったので、最後はチームでモブレビューをして一緒に確認してもらいました。5分以上かかってタイムアウトしていた画面は、今は8秒ほどで表示されます。 社内のいろんな人と話した 入社してから、チーム外の人とも1on1を重ねてきました。最初に申し込むときは「何を話そう」「勝手に予定を入れていいのか」と緊張していましたが、話してみるとどの方も快く時間をくださいました。半年で話した相手は20人以上で、職種もさまざまです。 カスタマーサポートの方からはサポートの仕事の様子を、事業部側の方からは事業としての判断の考え方を聞きました。開発チームの中だけでは聞く機会の少ない話で、カイポケという組織やプロダクトを別の角度から見るきっかけになりました。 入社前に心配していたのは、フルリモートの環境では一緒に働く人の顔が見えにくく、コミュニケーションを取りにくいのではないかということです。5月の社外カンファレンスでのブース運営やオフラインのイベント、1on1などで言葉を交わすうちに、Slackのアイコンを見て顔が浮かぶ人も増えてきました。今はリモートでも特に苦労することなく働けていて、心配は杞憂でした。 自分の動き方を自分で決めた 7月にカイポケクラウドのチームに着任したときは、着任から4週目までの過ごし方や、施策担当に期待することを言葉にして共有してもらえました。期待されていることがわかっていたので、自分から動き方を提案しやすかったです。 実際に8月末には、9月の動き方を提案しました。示されていた選択肢は、8月末でカイポケコネクトのチームに移るか、9月までカイポケクラウドのチームに残るかの2つでした。ただ、制度改正は数年に一度しかなく、改正の中身が固まる前の段階から関われる時期は限られています。研修期間中のこのタイミングだからこそ、どのような改正になりうるかを見立てる経験ができると考えました。一方で、カイポケコネクトのチームでは新しい案件が始まるところで、そちらにも早くから関わりたいと思っていました。 そこで、カイポケクラウドのチームで制度改正への対応準備を主に担当しつつ、カイポケコネクトのチームの開発にもサブとして関わる案を、3つ目の選択肢として伝えました。提案は受け入れられ、9月は両方のチームで動く形になりました。 カイポケクラウドのチームで9月に取り組んだのは、次の制度改正に向けて、何に備える必要があるのかを洗い出すことです。その時点でわかっていた厚生労働省の発表や過去の似た制度改正を調べました。そのうえで小さいチームに分かれて、ユーザーの業務やカイポケにどのような影響があるのかを検討し、関係するメンバーに発表しました。並行して、カイポケコネクトのチームでは、開発に向けた業務の流れの整理や調査を担当しました。 2つのチームのことを同時に考えるのは大変でしたが、制度改正への備えを通じて、ドメインのもっと深いところまで学ぶことができました。何より、自分で提案して納得感のある状態で動けたことが良かったと感じています。 2つのチームの違い 同じカイポケの開発でも、2つのチームが向き合っている課題はかなり違いました。 カイポケコネクトのチームは、モダンな技術スタックで新しいプロダクトを作っていて、課題の探索から実装・提供までをチームで一貫して行っています。私が関わったのはデリバリーの側で、ドメイン知識をキャッチアップしながらスクラムで開発を進めました。 一方のカイポケクラウドのチームは、すでに多くのユーザーに使われているサービスを運用しています。制度改正への対応、長く運用されてきたシステムの制約、お客様からの問い合わせなど、チームの内外から課題が次々と持ち込まれます。それらを事業としての優先度と見比べながら、何にどこまで対応するかを決めていきます。私が担当したデータ取り込みの不具合修正や一覧画面の改善も、すでに使われているサービスだからこそ出てきた課題でした。 2つのチームを経験したことで、プロダクトがどう作られ、どう使われ続けているのかを、少し立体的に捉えられるようになったと感じています。 これから 今はカイポケコネクトのチームで、新しい案件に本格的に取り組んでいます。 カイポケクラウドのチームで学んだ、資料を読み解いて調べる力や、チームで不確実なものを形にしていく進め方を、今のチームでも使えると考えています。 半年の研修では、任された範囲の中では自分で考えて動けていたものの、その範囲は1つの機能や施策といった小さな単位で、チームとして動くというよりは個として動く場面のほうが多くありました。これからは本配属となったチームで、周りの人を巻き込みながらプロジェクトを牽引できるようになることが目標です。 おわりに 半年を振り返ると、リファインメントで何の話をしているのかもわからなかったところから、制度改正の資料を読んで議論に加われるところまでは来ました。 入社前に制度やドメインに詳しくなっておく必要はないと思います。私も、研修や事業所体験、チームでのモブを通して、入社してから学んできました。半年経った今、自らの成長を実感しながら働くことができています。 この記事が、エス・エム・エスに入ろうと思っている方の参考になれば幸いです。

はじめに こんにちは！丹羽と申します。 初めてのブログ投稿です。よろしくお願いします。 今回は私がサイオステクノロジーに入社して1年間で読んだ書籍をご紹介します。 こんな方へおすすめ 入社1年目の新入社員・新人エンジニアの方 IT業界への就職が決まった大学4年生の方 「仕事の進め方」や「文章力」に課題を感じている方 ビジネス書籍 入社1年目の教科書 ワークブック その名の通り、入社1年目の新入社員に向けたビジネス書です。 「優秀な新人」や「モチベーションの高い新人」を目指すものではなく、ビジネスパーソンとして最も重要な「信頼」を得ることを目指します。 抽象的なことではなく、仕事をする上での具体的な仕事術が書いてあります。 この本を「読む」「読まない」では仕事に適応する速度が変わると思います。 ITエンジニア1年目の教科書 新人エンジニアが仕事で成功体験を積み重ね、自分で自信を育てられるように、「優秀な若手エンジニアが自然とやっていること」を言語化した本です。 構成は、テクニカルスキル(第1部)、ヒューマンスキル(第2部)、自己投資スキル(第3部)となっており、スキルごとにまとまっているので読みやすいです。 何回も読み直している本の1つです。 コンサル一年目が学ぶこと テーマが「コンサル一年目が学ぶこと」ですが、職業や業界を問わず、15年、20年とずっと役立つ普遍的なスキルを、基礎的なレベルから学べる本です。 4章構成で、それぞれ、話す技術(第1章)、思考術(第2章)、デスクワーク術(第3章)、ビジネスマインド(第4章)となっています。 特に第1章の、「相手の期待値を把握する」「上司の期待値を超える」という節は、社会人1年目からずっと心がけることの1つだと思いました。 会社では教えてもらえない 上に行く人の報連相のキホン 「報連相」に焦点を当て、「きちんと仕事をこなしているのに評価されない」「仕事が思うように進まない」と悩んでいる新入社員含め若手のビジネスパーソン向けの本です。 基本的に仕事は一人でするものではなく、自分に対して業務の指示と管理をする上司が、仕事の成果の主な評価者です。その上司に対して「報連相」をするタイミング、対応の優先順位を上げてもらう方法など、すぐにでも実践できる具体的なハウツーが書いてあります。 「報連相」は社会人において必須スキルなので、今回紹介するビジネス書籍の中でも最もおすすめしたい書籍の1つです。 ToDoリストですら使えなかった僕が見つけたすごい仕事術 「ToDoリストでタスクを管理せよ」「朝活で時間を有効活用せよ」「やり抜く力を身に付けよ」など、ビジネス書に書かれているような「仕事術」ができなかった、または難しい方向けの本です。 何十人もの部下を見てきた上司に「今までで一番仕事ができない」と言われた筆者が、外注したら2000万円かかると言われていた作業を1人でやり、「仕事ができる」と認められるようになるまでに編み出した仕事術が書かれています。その仕事術とは、「自分の意志」や「頑張り」に頼らず、意志力ゼロでも動く「仕組み」をつくるものです。 「頑張ろうとしても頑張れない」「頑張っているのにミスをしてしまう」といった方におすすめです。 超訳 カーネギー 人を動かす エッセンシャル版 本書は『超訳 カーネギー 人を動かす』を文庫エッセンシャル版として加筆訂正を加えて再編集したもので、職場、学校、家庭で円満な人間関係を築き、大きな成果を出すための、人間関係の原則が書かれた本です。全部で項目が181個ありますが、全て1ページ～2ページで書かれたものなのでサクサク読めます。 「181個も覚えることがあるのか」と思われるかもしれませんが、テーマを変えただけで趣旨が重複しているものが多いので、読むうちに筆者が伝えたいことがわかると思います。 体力がない人の仕事の戦略 体力がない人が根性論に頼らず、限られたエネルギーで成果を出す「燃費の良い働き方」が書かれている本です。仕事をやる上で「今よりラクな方法を探す」重要性を説いています。 特に真面目でいつも全力で頑張ってしまう方、頑張りすぎてガス欠を起こしたことがある方におすすめです。 伝わる文章が「速く」「思い通り」に書ける87の法則 分かりやすい言葉で「伝わる文章」の書き方が87項目にわたって書かれた本です。 本書のノウハウは、企画書・報告書・日報の作成から、論文やレポート、プライベートのチャットのやりとり、ブログやSNSの投稿記事まであらゆる文章に応用できます。 私は仕事上使用するチャットツールの文章が上手く伝わらず悩んでいましたが、この本がとても参考になりました。 エンジニアのための文章術再入門講座 新版 ITエンジニアが業務で必要な文書・文章を書くために「最低限必要な知識、ノウハウ、コツ」を整理した本です。 文章の書き方の基礎技術から、社内への報告や社外への依頼の書き方、相手に配慮した円滑な社内コミュニケーションの方法などが書かれています。 色々な方法が書かれていますが、社内での書き方もあると思うので、この本と併せて普段のチャットやメールから、先輩の書き方を勉強することも大切だと思いました。 IT仕事図鑑 本書は、そもそもIT業界とは何かから始まり、IT業界での働き方、IT仕事の基礎知識、IT職種の説明が書かれた本です。掲載されている職種は64種類と広範囲をカバーしており、この本に載っていないIT職種はほぼ無いと思います。 ITについて網羅的に書かれているので、余裕があれば手元に置いておいてもよいと思います。 技術書籍 リーダブルコード とても有名な、「理解しやすい」＝「優れた」プログラムコードを書くための本です。 最初に悪い例が出され、その後改善例が出されるので理解しやすいです。 個人的に特に印象に残ったのが「条件式には基本的にif/elseを使い、三項演算子を使わない」という項です。 AIにコードを書いてもらうと、1行で書ける条件式は三項演算子になることが多いです。簡潔な条件式なら理解しやすいのですが、複雑な条件式だと途端に理解に時間がかかります。 以前SNSで「三項演算子を使えるようになったら上級者」「三項演算子を使うのがスマートな書き方である」という文言を見かけて、「三項演算子に慣れたら読みやすくなるだろう」「コードの行数は少なければ少ないほどいいのだろう」と思っていました。 なので、上記の項は目から鱗でしたし、SNSの投稿とは違い実例も載っていたので、説得力がありました。SNSの情報を信じるよりも、技術書に載っている情報を信じた方がいい、という教訓にもなりました。 プログラムの基本的な文法を一通り覚えた方におすすめです。 プログラマー脳 本書は、コードリーディングやコーディング時の脳の働きを理解することで、プログラマーとしてのスキルや習慣を向上させる本です。 コードリーディングやコーディング時は、脳のどの機能と関連しているか、その脳の機能をどう補うかについて書かれています。 コードリーディングやコーディングの効率を上げたい方におすすめです。 Webを支える技術 本書は、HTTP、URI、HTMLなど、Webを支える根本的な技術を学べる本です。 「はじめに」の部分で対象読者は「Web技術を使ったシステム開発の経験がある人」と記載がありますが、理解に特別知識や経験が要るものではないです。 また巻末に付録としてステータスコード(404 Not Foundなど)の一覧があります。 この本を読む前は、出てきたステータスコードの意味をその都度調べていたのですが、この本で学んだ後は調べることはほぼ無くなりました。 IT業界に就職予定の方や、新人エンジニアの方におすすめです。 ソフトウェアテストの教科書 本書は、ソフトウェアテストを「実践的で」「わかりやすく」解説した本です。 実際にテストでバグが見つかりやすい箇所から、テストドキュメントの書き方まで幅広く書かれています。 テスト業務を１回でもやったことがあるエンジニアの方におすすめです。 Python ゼロからはじめるプログラミング 本書は、Pythonを学習して使えるようになることに加えて、プログラミングの基礎を習得することにも重点を置いた本です。 Pythonの基礎だけでなく、「プログラムとは何か」ということまで解説してくれます。 ページ数も少なく、簡潔にわかりやすく書かれているので読みやすいです。 ただ、今後色んな言語を学習していくとすると、初めて学ぶプログラミング言語はPython以外が個人的にはおすすめです。 なので、他のプログラミング言語を学習済で、Pythonの基礎を学びたい方におすすめです。 まとめ 今回は、私がサイオステクノロジーに入社して1年間で読んだ書籍をビジネス書・技術書問わずご紹介しました。 何か1冊でも参考になれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post エンジニア1年目に読んだ書籍をまとめてみた first appeared on SIOS Tech Lab .

こんにちは！SHIFT社内広報チームです。 今回も、従業員のお子さんをお預かりして毎年開催している「 シフトモKidsサマースクール 」についてご紹介していきます。 この記事では、メルカリ様にご協力いただき実施した講座についてお伝えしていきます。