春の入門連載は2020年から始めた連載で、以下のテーマで行う技術ブログリレーです。

• 新年度、新たなことをチャレンジする機会として、「入門」がテーマ
• 今まで触って無かった技術の体験記
• 先輩・同期・後輩宛に、知っておいて欲しい技術記事
• 好きな技術の布教活動をする記事

上記の前提であるため、具体的に取り上げる技術領域は自由ということが特徴です。人によってテーマである入門の解釈も自由自在で、お気に入りの記事に思いがけず出会うキッカケとしても機能するでしょう。

他の連載に比べて、ジャンルを問わずに応募していることもあり、毎年初の寄稿となる社員も多く参加しています。参加者の中にはブログを書いてみたい、とブログ運営に直接連絡をくれたやる気に溢れた社員もいるほどです。

参加者一覧&投稿タイトル

今年はインデックス記事を含めて10名が参加します！ 間にゴールデンウィークを挟みつつ、5月中旬にかけて平日ほぼ毎日更新していく予定です。

技術ブログにはお馴染みの顔から、今回の連載で初寄稿の社員まで幅広いメンバーで投稿していきます。テーマがまだ決まっていないところや変わる場合がありますが、運営チャットでは各メンバーの気合が漲っております。

※ 各記事が公開され次第、順次リンクをアップデートしていきます。

さいごに

良いと思った記事などはシェアなどのリアクションをいただければと思います！

• 2025年の連載記事
• 2024年の連載記事
• 2023年の連載記事
• 2022年の連載記事
• 2021年の連載記事
• 2020年の連載記事

こんにちは、新卒採用チームの家永です。

フューチャーでは、ITコンサルティングの最前線において、「技術でビジネスをどうリードするか」を体験できるインターンシップ「Engineer Camp」を今年、2026年も開催します。

昨年、2025年開催のEngineer Campに参加した内定者4名（前川さん、大杉さん、木幡さん、酒井さん）にインタビューを実施しました！ 「自分のスキルで通用するのか？」「具体的にどんな経験ができるのか？」と応募を迷っている学生のみなさん、ぜひ彼らのリアルな声をご覧ください。

実社会のデータと最先端技術に触れた、挑戦の日々

前川さん（自然言語処理技術の研究開発に挑戦）

前川さんは、新聞記事の見出しを自動生成するタスクにおいて、既存の大規模モデルを小規模モデルに置き換える技術検証を担当しました。 「普段の研究とは異なり、限られた時間内で計画を立てて実装まで進める『時間管理』が一番の壁でした」と語る前川さん。しかし、毎日のメンターミーティングや週1回のチームミーティング、日々のSlackでの進捗報告をつうじて、トップレベルのエンジニアたちから的確なアドバイスを即座にもらえたことに感銘を受けたそうです。

さらに、前川さんが特に熱を込めて語ってくれたのが「開発環境の豊かさ」です。 「AIの学習には高性能な計算機（GPU）が不可欠ですが、 フューチャーにはそれがめちゃくちゃいっぱいあるんです。これほど充実したリソースを存分に使わせてもらえる環境は、自然言語処理を学ぶ学生にとって大きな魅力です！」 と、開発に没頭できる恵まれた環境についても教えてくれました。

大杉さん（AIエージェント開発に挑戦）

大杉さんは、LangChainやLangGraphといった未知の技術をキャッチアップしながら、AIを組み込んだ新機能のプロトタイプ開発を一から担当しました。

インプットとアウトプットのバランスに苦戦した大杉さんですが、印象的だったのは「社員とのフラットな関係性」だと言います。メンターの森さんは「社内で誰よりもAIエージェントに詳しい」トップレベルの技術者でした。 「そんなすごい方が、多忙を極める中でもインターン生である私の拙い説明にしっかりと耳を傾けてくれたんです。開発アプローチで意見が分かれた際も、頭ごなしに否定するのではなく『どちらが良いか調べてみよう』と検証の時間を割いてくださり、結果的に『大杉くんのやり方の方がいいね』と認めてくれました。対等どころか、想像以上の手厚さでした」

この出来事を通じて「一番いいものをみんなで作り上げる」というフューチャーのカルチャーを肌で感じた大杉さん。「この環境で多くを学ぶには、受け身ではなく、自らタスクを分解して進捗を共有する『自走力（オーナーシップ）』が何よりも大切です」と熱く語ってくれました。

木幡さん（音声AIエージェント作成に挑戦）

木幡さんは、テキストベースのAIエージェントを音声ベースに拡張し、さらにSQL検索を組み込むという難易度の高いタスクに挑みました。 機能をさらに拡張しようと試みた際、「実現したいことはあるが、どの技術を使えばいいか分からない」という壁に直面しました。 「学校の授業なら教科書があり、短期インターンならやるべき作業が決められています。しかし今回は、『何を学ぶべきか』をゼロから自分で見つけ出し、英語のドキュメントを読み込んで未知の技術を習得するプロセスが最大の挑戦 でした」と振り返ります。

その壁を乗り越える助けになったのは、メンターの幅広い知識と、社内の「オープンなコミュニケーション」でした。メンターが的確な技術候補を提示してくれたほか、インターン生向けのSlackで公開されている他プロジェクトのやり取りからも多くのヒントを得たそうです。「言われたものを作るだけでなく、顧客の要望から自分で設計していく仕事の面白さに気づけました」と、Engineer Campならではの実践的な経験を語ってくれました。

酒井さん（知財戦略AIエージェント開発に挑戦）

酒井さんは、知財・特許業界において、生成AIを活用した特許分析機能などの開発を担当しました。

未知の技術や環境構築からのスタートでしたが、大学での研究成果を発展させるような内容だったこともあり、スムーズに進められたそうです。酒井さんが「特に印象的だった」と振り返るのは、社内の風通しの良さです。メンターからの「デイリーでスレッドを立てて、困っていることもそこに書いてね」という声がけにより、「質問や相談にためらいがなくなり、活発な意見交換ができた」といいます。

さらに期間中、プロジェクトが出展する外部展示会（知財フェア）に同席するチャンスにも恵まれました。

「そこで、ロケーションフリー制度を活用して地方で暮らす社員の方々ともお会いできました。普段離れて働く社員同士がフラットに会話している姿を見て、人間関係の良好さを肌で感じました。想像以上に親しみやすい雰囲気で、自分にフィットする環境だなと心から安心できました」と、フューチャーのカルチャーについて語ってくれました。

迷っているなら飛び込んでほしい！ 参加を検討するみなさんへ

インターンを経験し、技術が実社会でどう実装されるのかを具体的にイメージできるようになったと語る参加者たち。彼らからのメッセージです。

• 前川さん: 「社会実装に興味がある人や、高い技術力を持つ同世代・社員と関わりたい人は絶対に参加するべきです！」
• 木幡さん: 「実際のプロジェクトでビジネスに直結する経験ができるのは、他では味わえない貴重な機会です。応募要件への不安よりも、新しい技術を求めるモチベーションを大切に、ぜひチャレンジしてください！」
• 大杉さん: 「技術的もちろん、社会で不可欠な『自走力（オーナーシップ）』を大きく伸ばせるのが魅力です。自信がある人はもちろん、これからその力を鍛えたいという人も、必ず多くの学びが得られるはずです！」
• 酒井さん: 「夏休みの大部分をインターンに費やすことに迷いがある人もいるかもしれませんが、私の場合は『4週間』という期間があったからこそプロジェクトに深く入り込めました。社員の方々との関係構築や展示会への同席など、この期間ならではの価値が必ずあります。夏休みを費やす価値がある環境ですので、ぜひ一歩踏み出してみてください！」

2026年の「Engineer Camp」で、あなたの挑戦をお待ちしています！

今回インタビューに答えてくれた4名は皆、このEngineer Campでの経験を経て選考に進み、入社を承諾しています。 2026年のEngineer Campでも、参加者限定の選考特典をご用意する予定です。

Engineer Camp最大の魅力は、実際のプロジェクトに深く入り込めることです。期間中、最前線で活躍する「技術に尖ったトップレベルの社員たち」と直接関わることで、彼らの圧倒的なスキルや思考プロセスを間近で体感できます。

2026年も最先端技術に触れられる魅力的なコースを多数ご用意しています！

募集コースの詳細やエントリーについてはこちら

フューチャーのEngineer Campは、技術を学ぶだけでなく、プロフェッショナルの思考プロセスを間近で体感できる場所です。 圧倒的な成長を求めるみなさんのご応募を、心よりお待ちしています！

• https://www.future.co.jp/recruit/summer_intern/2026/

はじめに

2026年に計画しているフューチャー技術ブログにおける、ブログリレーの企画スケジュールを紹介します。

スケジュールを発表する背景

ブログリレーの年間計画をあらかじめ公開する背景には、例年通り以下の意図があります。

• 会社のカラーを伝える: どういったブログリレーを行おうとしているかによって、会社の特色が出るため、興味がある方にアクセスしていただけるようにしたいと考えています
• 執筆準備の期間確保: ブログリレーは寄稿者募集のリードタイムが発生するため、あらかじめスケジュールを周知することで準備をしやすくします
• 運営の効率化: 日々の業務をしながらだと企画内容を忘れがちになるため、最初に大枠を固めておくことで運営をスムーズにします。運営を透明化するということで、親しみを持ってもらうという意図もあります

2026年のスケジュール

2026年のラインナップは以下の通りです。今年は「テスト」など、時代の変化に合わせた新しいテーマも取り入れています。

🔰は今年初めて実施する連載です。

ブログリレー企画の概観

2021年に年間計画の公開を始めてから5年が経過しました。これまでの変遷を振り返ると、いくつかの傾向が見えてきます。

• 連載総量の適正化
  当初の2021年は、月に複数の連載を並行して走らせるなど非常に多作な年でした（例：5月にDart/FlutterとServerlessを同時開催など）。しかし、寄稿者の募集や運営負荷の観点から、近年は「1ヶ月に1テーマ」＋「Goのリリース連載」というペースに落ち着き、無理なく継続できる体制へとシフトしています
• 技術要素の変遷：トレンドと実需のバランス
  その年ごとの技術トレンドや社内の関心事が色濃く反映されています
  • 2021年〜2022年: GCP、Serverless、Flutter、IoT（電子工作）といった特定の技術領域への挑戦が多く見られました。一方で、寄稿者が集まりにくいテーマは翌年以降見直されるなど、柔軟に入れ替えが行われています
  • 2024年以降: JavaやVue.jsといった、当社での利用頻度が高い「実需」に基づく技術がテーマとして定着し始めました
  • Go言語: 2021年から変わらず、年2回のリリース記念連載が継続されており、当ブログの技術的なバックボーンの1つとなっています（社内利用率はJavaの方が高いため、Go利用者の外部発信精神が強いことによる差だと思われます）
• 定着した人気の「季節企画」
  技術テーマは変遷していますが、次の季節イベントは定番化しており、ブログリレーの骨格を成しています
  • 4月：春の入門祭り（初心者歓迎の入門記事）
  • 8月：夏休み自由研究（業務外の趣味や深掘り）
  • 10月：秋のブログ週間（読み物エッセイ中心）
  • 12月：アドベントカレンダー（年末のお祭り）

ブログリレー企画を継続的に行うメリットは様々多く、こちらの記事に書いたときから大きな差分はありません。

2026年も、これらの「定番」と「新しい技術的挑戦」のバランスを大切にしながら企画しています。

さいごに

これまでの経緯を踏まえテーマをブラッシュアップしています。2026年も皆様にとって有益な情報発信を活発にしていきますので、応援よろしくお願いいたします！

はじめに

TIG（Technology Innovation Group）の真野です。

フューチャーの有志で取り組んでいる「アーキテクチャ設計ガイドライン」の活動について、2026年の作成スケジュールを公開します。

アーキテクチャガイドラインとは？

アーキテクチャガイドライン」とは、一言で言えば、システム開発の現場で頻出する「よくある設計論点」とその「推奨される解決策」を汎化し、体系的にまとめたドキュメント群です。現在、WebフロントエンドやWeb API、PostgreSQLといった技術領域から、Gitブランチフローやコードレビューといった開発プロセスに至るまで、幅広いテーマをGitHub上で公開しています。

いくつかの強いこだわりがあります。

• 「ルールブック」ではなく「考えるためのツール」
  「これに従えば思考停止でOK」というマニュアルではなく、「何が論点になりやすいか」「なぜその選択肢を推奨するのか」とい背景と理由の記述に重きを置いています。プロジェクト固有の事情で推奨と異なる判断をする際の、「議論の出発点（土台）」として使われることを意図しています。
• 読み物としての「熱量」
  単なる箇条書きの規約集ではありません。PDF換算で40ページから多いものでは140ページにも及ぶため、初見ではおそらく重厚さを感じます。これはアーキテクト以外のメンバーにも理解を深めてもらえるよう、コラムなども交えながら「なぜその設計が必要なのか」を説明するためです。とは言え、より筋肉質に密度を高める打ち手の話もしています。
• 技術 × コミュニケーション
  純粋な技術スタックだけでなく、アーキテクチャ決定に不可欠な合意形成や、チーム開発を円滑にするための「コミュニケーション系」ガイドライン（コードレビュー、Slack利用など）もラインナップしています。純粋な技術だけで、良いアーキテクチャ作れますかというと否ですよね。技術の枠にこだわらないことを思い切って決めました。

ガイドライン タグで、作成報告のブログがまとまっていますので、良ければ参照ください。

なぜスケジュールを公開するのか

事前にスケジュールを公開することで、次のメリットが（微小ながらある）と考えています。

1. 活動の透明性を上げることで、興味を持ってもらう
   ガイドライン作成はそれなりに思いやスキルがある有志メンバーで行っており、中身は常連的なメンバーと新規メンバーが組み合わさっています。それ自体は悪くないですが、新規メンバーの数をもう少し増やしても良いかなと思っています。そのため興味を持った方が、ガイドライン作成がどういう活動なのかを知るための判断材料を、なるべく手に入りやすくしたいと思っています
2. 自分たちへのコミットメント
   ガイドライン作成は有志によるボトムアップ活動です。あらかじめスケジュールを公表することで、計画的に推進するための良い規律になると思います。もちろん、自らを追い込む意図もあります
3. 事前準備のためのジャブ打ち
   スケジュールが分かれば、このタイミングに合わせて、関連したネタを事前に収集・整理するといったアンテナを貼ることができます。ガイドライン作成はキックオフ1~2週間前にメンバー募集をするのですが、書籍や動画などで体系的に学ぼうとすると、さすがに少し時間は足りないと感じます。準備時間の確保のためのジャブは重要です

2026年の公開スケジュール

2026年は、これまでの「設計ガイドライン」の拡充に加え、そしてジュニア/ミドル向けに実務を支援する新シリーズ「初めての○○○○」 を柱に、計15本程度の公開を目指しています。

現時点での計画は以下の通りです。

gantt
    dateFormat  YYYY-MM-DD
    axisFormat  %m月

    section 設計ガイド
    帳票（2025継続）           :active, a1, 2025-12-01, 2026-02-15
    データガバナンス           :a2, 2026-02-01, 2026-03-31
    認証認可                 :a3, 2026-03-15, 2026-04-30
    DFD                      :a4, 2026-03-15, 2026-04-30
    BI                       :a5, 2026-05-01, 2026-06-30
    ETL           :a6, 2026-08-01, 2026-09-15
    ELT               :a7, 2026-10-01, 2026-11-30

    section 基礎/ソフトスキル
    アーキテクチャ原則         :b1, 2026-02-01, 2026-03-31
    テクニカルライティング     :b2, 2026-02-15, 2026-03-30
    ファシリテーション         :b3, 2026-07-01, 2026-08-31

    section 初めての○○
    初めての非機能要件定義     :c1, 2026-03-15, 2026-04-30
    初めての性能検証           :c2, 2026-05-01, 2026-06-30
    初めての開発立ち上げ       :c3, 2026-06-01, 2026-07-31
    初めての障害試験           :c4, 2026-07-15, 2026-08-31
    初めての技術選定           :c5, 2026-09-01, 2026-10-15
    初めての全体テスト計画     :c6, 2026-10-01, 2026-11-30
    初めての処理方式設計       :c7, 2026-11-15, 2026-12-31

春先（3月〜4月）にかけて、「認証認可」「DFD」「テクニカルライティング」などの作成が重なっており、ここが活動の山場となる予定です。

なお、上記はDFDを除き私が企画を主導するコンテンツに絞っています。他のもスター選手がナレッジ作成に勤しむといった話も進んでいますので、実際に公開されるコンテンツ量はこれより多くなる見込みです（凄い量になりそうですね）。

2026年の注目ポイント

• データ領域の強化
  2025年はアプリケーション開発の主要技術をカバーしましたが、2026年はデータ領域を強化します。「データガバナンス」「BI」「ETL/ELT」など、データ利活用の基盤となるテーマに取り組みます。また、業務システムで避けて通れない「帳票」や、設計難易度の高い「認証認可」についても形式知化を進めます。
• アーキテクトの「ソフトスキル」の言語化
  技術力だけでなく、合意形成やドキュメンテーション能力もアーキテクトの重要な資質です。先日公開した「ソフトスキルガイドライン」に続き、「アーキテクチャ原則」「テクニカルライティング」「ファシリテーション」といったテーマで、思考の型や伝える技術をドキュメント化します。
• 新シリーズ「初めての○○」
  アーキテクトを目指す層に向けた実践的な入門シリーズです。「非機能要件定義」や「技術選定」など、教科書的な知識だけでなく、実際のプロジェクト現場で「具体的にどう動けばいいのか」という勘所をガイドすることを目指しています。社内の若手～中堅メンバーが、迷わずに次のステップへ進めるような指南書となることを意図しています。

さいごに

ガイドラインは「これに従えば考えなくて済む」というルールブックではなく、どうすべきかを考えるためのツール（議論の出発点） を意図して作成しています。

2026年もこのコンセプトを大切にしつつ、より多くの領域でナレッジを共有し、本質的な価値創造に集中できる環境作りを推進していきます。

本記事で紹介したスケジュールは現時点での計画であり変更の可能性がありますが、温かく見守っていただければ幸いです。公開されたガイドラインへのフィードバックがあれば、ぜひIssueの起票や、X（旧Twitter）などでコメントをお寄せください。

https://github.com/future-architect/future-architect.github.io/issues

はじめに

TIG（Technology Innovation Group）の真野です。

フューチャーの有志メンバーで取り組んでいる「アーキテクチャ設計ガイドライン」のタスクフォース活動について、2025年の活動実績報告と振り返りの記事です。

アーキテクチャガイドラインとは

https://future-architect.github.io/arch-guidelines/

フューチャーでは、システム開発の現場で頻出する設計論点とその対応策を体系化したドキュメントをガイドラインとして整備し、GitHub Pagesおよび技術ブログで公開しています。

コンセプトは、単なる手順書や絶対的なルールブックではなくどうすべきかを考えるための議論の土台である点です。プロジェクト固有の事情を削ぎ落とし、汎用的な設計論点と推奨される解決策を提示することで、設計者が最適な判断を下すための補助線となることを意図しています。

これまでの歩み（2023年～2024年）

2025年に本格化したガイドライン作成の取り組みですが、活動自体は2022年頃から細々と始まっていました。簡単に経緯を紹介します。

2022年: 活動の萌芽（年1ペース）
もともとは、社内の別チーム（コアテクノロジーチーム）が公開していたJavaやSQLのコーディング規約に触発され、AWSインフラ命名規約 を作成したのが始まりです。各プロジェクトで何かしら命名ルールはすでにあるはずなので、持ち寄って最大公約数的な規約を作れば良いじゃないというどちらかというと緩い連帯的なスタンスでした。それゆえ拘束力は弱く作り上げるまでにかなり時間がかかった記憶です。

2023年: ゆるく継続（年1ペース）
OpenAPI Specification規約のv2版を公開しました。このころから現在に繋がるコアメンバーが自然と集まりました。しかし、未だ議論は散発的で統率が取れず、会議は開催したものの進捗は全員がないといったことも何回か発生したレベルでした。そのため、1つ仕上げるのに1年ほどかかりました。今振り返るとまだまだ牧歌的に活動していました。

2024年: 試行錯誤と転換点（年3ペース）
OpenAPI Specification規約のv3版、GitブランチフローやMarkdown設計ドキュメントなどを作成しました。1つのガイドライン作成に8～10ヶ月を要するなど、決してハイペースではありませんでした。転機となったのは2024年8～9月頃です。このくらいからWeb API・PostgreSQLの2ガイドラインを作り始め、全12回と期限を明確に区切って作成するポリシーとしました。エンドを決めることで個人的にパリッとした運営になり、個人的に運営方針の要だと感じるルールと認識しています。

2025年の活動実績

2025年は、アプリケーション、データ、インフラ、開発プロセスなど多岐にわたる領域で、合計 15本 のガイドラインを公開しました。それまでに比べると大分ペースアップできました。

公開ガイドライン一覧

• アプリケーション領域: Web API、Webフロントエンド、バッチ、I/F、メール、ログ、非同期
• データ領域: PostgreSQL、DynamoDB、データマネジメント
• インフラ領域: AWS、Terraform
• 開発プロセス: コードレビュー、Slack利用
• その他: ソフトスキル

活動データ

活動の規模を示す定量データは以下の通りです。

• 公開本数: 15本
• ドキュメント総量: PDF換算で合計1055ページ（1本あたり平均70ページ）
• 関与人数: 延べ 136名（作成者105名、レビュアー31名）。ユニーク59名（作成者43名、レビュアー25名、重複9名）。コアメンバー（3回以上参加）12名
• GitHub活動: Pull Request 数 242件、Issue 対応数 30件以上（Issueはほぼ公開コンテンツに対する改善対応）

業務の合間を縫う有志活動として、約1.5ヶ月に1本のペースで公開を継続しました。

作成プロセスと運営体制

短期間で一定量のドキュメントを作成・維持するために、以下の体制とプロセスを採用しています。

• AI活用:
  • GeminiやChatGPT等の生成AIを、構成案の作成から誤字脱字チェック、レビューの補助として活用しています。AIが生成したテキストをそのまま採用するのではなく、人間の知見で取捨選択・リライトするプロセスを経て、品質を担保しています（感覚的には1割くらいは元の文が生きるかな？という印象です）
• 短期集中型のチーム組成
  • 1つのガイドラインにつき2～3ヶ月という期限を設定し、4～8名程度のチームで集中的に執筆・レビューするスタイルをとっています
  • 最初に何を議論すべきかブレストを行い、担当者までキックオフで決定。その後、2ヶ月枠であれば残りの7回の定例を週次で行い、各自アウトプットを全員でレビューする形式です
  • 社内作業時は、社員的に最速で作業ができるGoogleドキュメントで管理しています
• GitHubによる版管理
  • GoogleドキュメントやWordの校閲機能、textlint, markdownlint, GeminiのGemなどで確認してから公開します
  • 公開後のドキュメントはGitHub上で管理し、公開後もPull Requestベースで継続的な修正・改善を行える運用としています

活用事例とフィードバック

公開されたガイドラインは、社内外のプロジェクトにおいて、設計のベースラインや議論の叩き台として利用されています。

実プロジェクトでの活用（匿名かつ抜粋）

具体的な活用シーンとして、以下のような事例が報告されています。

• 金融系などのプロジェクト
  データマネジメントガイドラインで、AI-Readyなデータ基盤設計のヒントとして活用
• 製造系などのプロジェクト
  Web API設計ガイドラインの内容がプロジェクトの標準規約として採用や、それに近い形で展開。APIゲートウェイ構築時の設計考慮点として活用
• インフラ系のプロジェクト
  AWSのサービス選定で利活用

当初の想定通り、議論のベースラインとしての利用ができていることは確認できています。比較ができないため予測ですが、おそらく設計の手戻りなどを減らすことに微力ながら効果はあったと思います。

MCISオープンセミナーでの登壇と大きな反響

2025年10月、ITシステム可視化協議会（MCIS）さんが主催するオープンセミナーにて、本ガイドラインの取り組みについて講演しました。

ITシステム可視化協議会（MCIS）とは
1994年に日本ファンクションポイントユーザ会（JFPUG）として設立され、2024年に現在の名称に改称された協議会です。「ITシステム測定・可視化の推進」をミッションに掲げ、ITシステムに関する課題解決や社会発展に貢献するための活動を展開されています。

セミナーでは、私たちが作成しているガイドラインを解説しましたが、アンケート速報では 満足度約93% という極めて高い評価をいただくことができました。

特に、可視化や測定のプロフェッショナルが集まるMCISの皆様から、以下のようなポイントで共感をいただけたことは大きな自信となりました。

社外からの反応

SNS等において、エンジニアの方々より「実用的である」「設計の参考になる」といったフィードバックをいただいています。主観で一番多かったのは「長い」って反応だったと思います。これについてはもっと筋肉質にダイエットする打ち手を内部で考えています。

また、ガイドラインの公開がきっかけで技術的なお問い合わせにつながるケースもありました。

2025年の振り返り（KPT）

活動を通して得られた知見と課題を整理します。

• 成果（Keep）
  • 年始に立てた目標数以上のアウトプットができ、主要な技術スタックを網羅できたこと
  • 「ソフトスキル」など、形式知化が難しい領域についてもドキュメント化できたこと
• 課題（Problem）
  • コンテンツ量の増加に伴い、過去記事のメンテナンス（棚卸し）工数が増加していること
  • また、ガイドラインの提供だけでは、若手エンジニアの実践スキル向上に対して十分な効果を発揮しきれていない面があること。浸透については伸びしろあり
  • 文量が長い
  • 発信がXや技術ブログ程度。勉強会やカンファレンス登壇などでは発信できなかった
• 今後（Try）
  • 実務における具体的な判断プロセスを補完するため、より実践的なシナリオ（例：「初めての〇〇」シリーズ）の拡充や、設計品質の底上げを図る「アーキテクチャ原則」の策定などを検討中
  • 横断的に登場する「テスト」「ドキュメント」「セキュリティ」などの観点は、別紙に切り出して集約することで、個別パートからはリンクを貼るような関係で再構築する。それにより見かけの文量は減らす
  • 各勉強会、カンファレンスで発信（お勧めや指名をお待ちしています）を実施し、認知度を高めつつフィードバックを貰う

おわりに

2026年も引き続き、データ領域（データガバナンス、BI、ETL等）の強化や、人材育成に資するコンテンツの拡充を進める計画です。

私たちのガイドラインは、フィードバックを受けて改善していくものです。
お気づきの点や、「自社ではこうしている」といった技術的な知見などがあれば、ぜひGitHubのIssueやXなどのSNS等でお寄せください。

参考

• Future Enterprise Arch Guidelines (GitHub)

こんにちは。技術ブログ運営の伊藤です。

今回は、社内の取り組みであるBest Blogger of the Yearの紹介と、2025年の受賞者を中心に発表します。

Best Blogger of the Year（べすぶろ）とは

Best Blogger of the Year（べすぶろ）は、社外に影響を与えた記事を執筆した人を表彰する仕組みとして2020年より開催しています。べすぶろは技術ブログ部門と未来報（フューチャーの人を紹介するオウンドメディア）との共催で開催します。いずれのブログについても社内の稼働の一部として認められており、プロジェクト以外の会社のプレゼンス向上などに寄与したことを評価する仕組みでもあります。
記事の選定基準は、

• 品質：読者が望む内容を適切に文章に落とし込んで価値ある記事である
• ユニーク：記事の固有性がある。唯一無二の記事になっている
• 記事数：発信に積極的に取り組んでいる。数多くの記事を出している
• 影響度：記事によって何らかの影響が可視化される（多く閲覧された（PV）、行動変容があった（内定承諾に影響した、ビジネス展開に影響した）等）

の4つを基準とし、毎年3名ほど選出しています。

選出された方は全社メールであったり、月に1度の全社会に相当する会でアナウンスをして、表彰しています。

2025年受賞者の発表

さて、2025年のべすぶろ受賞者を発表します。

2025年はこの3記事を選出しました。いずれもはてブのランク入りを果たしたり、Twitterで話題になった記事なので、皆さんも1度は読んだ記事も上がっているのではないでしょうか？

2022〜2024年の受賞者について

以前、記事を公開した2021年分以降も毎年表彰自体はしていたものの、記事として公開されていなかったため本記事で合わせて紹介します。久しぶりに見る記事もあるかと思いますのでぜひご一読ください。

2024年

2023年

2022年

さいごに

フューチャー技術ブログは社員の有志という形で寄稿されて成り立っているので、今後もこういった称える仕組みを継続していければと思います。
また、皆さんが気になった記事はコメントやシェアをしていただくと、励みにもなりますので、今後ともよろしくお願いいたします！

秋のブログ週間2本目です。

はじめに

初めまして、2024年新卒入社の内堀航輝です。

本日は、秋の夜長にブログリレーの2日目です。テーマは、「手元にあった新卒1年目に勉強していた時のメモ（感想）を振り返って」です。

IT業界に来た人にはあるあるだと思うのですが、プロジェクトに入ると知らないことの連続で、手当たり次第に耳に入った情報をとりあえず勉強しがちですよね。例にもれず僕もそのタイプだったので、1年目はさまざまな技術に触れてきました。

その時々に「なるほど」と思ったことや、素直に感じたことを書き留めた雑メモ（というか感想）が手元に残っていたので、今回はそれを抜粋して、1年目の新人としての当時の気づきを共有できればと思います。「あー、自分も初めはそんなこと思ったな」と思いながら読んでいただけると幸いです。

インターフェースってなんやねんって思ってたけどめっちゃ便利やん

これはJavaのオブジェクト指向を学んでいた時、「インターフェース」の使い方を初めて理解した時のメモです。

新人研修で初めてオブジェクト指向に触れたとき、クラスや継承は、「モノ」の具体例がイメージしやすかったので、割とすんなり理解できました。

その一方で、インターフェースだけは概念が抽象的すぎて、何のために存在するのか全くピンと来ませんでした。「仕様だけを定義して、実装を隠蔽する」と説明されても、「回りくどいことはせずに、普通に具象クラスで定義すればいいんじゃないの？」と思っていました。

しかしその後、DI（依存性の注入）という概念を知り、そこでのインターフェースの活用法を見ました。インターフェースの価値は、単に実装を隠すことだけでなく、「交換可能性」にあるってことに気づいたとき、その考えはガラリと変わりました。

特定の具象クラスを直接呼び出すのではなく、インターフェースを挟んで処理を呼び出すことで、システムを疎結合にできます。このおかげで、呼び出し元は「どんなクラスが動いているか」を気にしなくて良くなり、実装者も定義されたルール（インターフェース）さえ守ればよくなります。急に実装クラスを丸ごと交換したくなっても、呼び出し元のコードには一切手を入れなくて済むようになりますし、用途によって具象クラスを切り替えるといったことも簡単にできます。

具体的な実装から分離することで、システムの柔軟性と保守性を高める。それこそがインターフェースの重要な役割なのだと腑に落ちました。

個人的には、この気づきでオブジェクト指向への理解が一気に深まったと感じており、その時の感動を鮮明に記したメモでした。

パスを繋ぐってなんやねん

環境構築していて、実行ファイルあんのになんで動かないんだ！ってキレていたときのメモです。

「パスを設定する」、「パスを繋ぐ」、環境構築をしていると、呪文のように出てくるこの言葉。当時の僕は意味が分からず、ただ手順書のコマンドを打ち込むだけでした。動かなかったらエラーメッセージで調べ、出てきた別のコマンドを打ち込む、そして動くか動かないかに一喜一憂する。完全に祈祷師でした。

ある日どうしても環境構築が進まず、その怒りをGeminiにぶつけていたのですが、優しいGeminiさんは、僕が理解するまで何度も、手を変え品を変え説明してくれました。

そこでようやく理解できたのが、コマンドが実行されるまでのターミナルの動きです。ターミナルは、コマンドが入力されると、環境変数「PATH」に設定された「コマンド検索先一覧」を頭から順番に見ていき、最初にヒットした実行ファイルを実行し、もし何もヒットしなければ、「Command Not Found」を返しているだけでした。

この仕組みを理解したことで、環境構築に対する苦手意識がかなりなくなりました。結局、環境構築は、①ソフトをダウンロードすること、②開発で使うコマンドを使える状態にすること（つまりパスを通すこと）、の2点におおよそ集約されることに気づいたからです。

この「パスがわかるだけで、環境構築が怖くなくなる」という気づきは、当時の僕にはかなり鮮烈でした。意外と共感してくれる方がいるのかなと、個人的には思っています。ただ、Pythonの環境構築はいまだに苦手です。pipとかpyenvとか管理ルール何種類あんねん、、、、（最近はuvってやつが流行ってるみたいですね。）

Linux勉強してると思ってたけど、これLinuxコマンドを勉強してるやん

「エンジニアたるものLinuxを知らねば」と、「初心者向け！Linux入門！」のような教材で勉強した気になっていました。これは、その後に「ふつうのLinuxプログラミング」という本を読んだときにしたメモです。

あくまで僕調べなのですが、Linux入門のような教材は、コマンドライン操作の説明が中心のものが多い印象です。そのため、僕は初め、「Linux ＝ ls や cd といったコマンド群のこと」だと勘違いしていました。

しかし、そこには大きな認識のずれがありました。
普段使っているLinuxコマンドは、あくまでLinuxというOS（カーネル）の上で動く「アプリケーション」の1つに過ぎず、Linuxそのものではなかったんです。

「ふつうのLinuxプログラミング」は個人的にとても良かったので、おすすめしたい一冊です。この本は、Linuxの世界を構成する概念の解説から始まり、システムコールを使ってプログラムとOSがどうやり取りしているのかを、丁寧な解説と平易なサンプルコードで説明してくれます。おかげで、OSの役割がとてもクリアに理解できました。

余談ですが、現代のLinuxはなんやかんや4000万行ほどあるようですが、Linux 0.01（Linuxの一番最初のバージョン）はわずか1万行だったみたいですね。
いつか挑戦してみたいですね～

SQLが集合を記述してるってまじか

「達人に学ぶSQL徹底指南書」を読んでいた時の感想です。

初めてSQLに触れたとき、SQLは本当に異質な存在でした。これまでやってきたPythonやJavaといった、いわゆる「手続き型」の言語と異なり、forループやif分岐といったフローを制御する文法がなかったからです。ただ当時は、あまりそのことを深く考えていませんでした。「癖の強いプログラミング言語だなー」といった程度の認識で、基本的な記述はできるものの、正直苦手意識を持っていました。

PJに入り、ある日先輩との雑談で、「フューチャーで共通のスキルがあるとしたら、それはSQLだと思う」という話を聞きました。

それならば、もっとちゃんと勉強しようと思い手に取ったのが、「達人に学ぶSQL徹底指南書」でした。この本で、「SQLが集合を記述してる」ということを知りました。他の「手続き型」の言語が、「どのように処理をするか」というフローを記述するのに対して、SQLは「宣言型」で、「この条件を満たす部分集合が欲しい」と部分集合の定義を記述するだけです。

この「何がしたいか（How）」ではなく、「何が欲しいか（What）」を記述するというのが、個人的にはかなり衝撃的でした。それまでは単に癖のある文法を持った苦手な言語でしかなかったSQLが、集合論という数学に裏打ちされた力を持つ面白い言語へと、見方が一気に変わりました。

ちなみに、集合論が面白いと感じたのは、ちょうどその時「数学ガール/フェルマーの最終定理」を読んでいたのが大きかったです。話は面白いし、疲れた頭で数式を眺めてるとよく眠れるんですよね、、、

クラウドってくそでかオンプレやん。サーバーレスは全然サーバーあるし。

1つ目のプロジェクトでAWSを勉強していた時のメモです。

クラウドについてちゃんと勉強するまで、Cloud（雲）という言葉に騙されていました。「サーバーがどこにもないのに、計算とかどうしてるんだろー。何かすごい技術を使ってるのかなー」なんて、本気で思っていました。

でもいざ調べてみたら、クラウドの正体は、どこかの巨大な建物に設置された、超大規模なオンプレミスサーバ郡でした。僕たちユーザは、その広大なリソースの一部を、インターネット経由で、必要な分だけ借りて使っているだけ。なんとなく、小さな雲の集合体が大きな入道雲に見えるのを連想して、「確かにこれはCloud（雲）だな」と、妙に納得したのを覚えています。

サーバーレスもやっぱりサーバーはあって、あくまで「サーバーの管理をしなくていい」という話でした。僕たちのアプリケーション（AWS Lambdaなど）は、裏側で誰かのサーバ上で動いていますが、ただそのサーバのメンテナンスはクラウドベンダーが肩代わりしてくれる、というわけです。まあ、そもそも「サーバ」の定義を考えれば、仮に何か革新的な技術で、コンピュータが今と全然違う姿になっても、処理を行う存在がいる以上、それは結局サーバの一種と呼べるわけです。そう考えると、真の意味で「サーバーレス」になることはないのでしょうね。

全然話は変わりますが、皆さんの好きなクラウドサービスは何ですか？（クラウドベンダー問わず）

僕はS3（Amazon Simple Storage Service）です。ストレージにオブジェクトを保存するというシンプルな機能です。しかしその裏側には、データの一貫性、分散処理、そしてイレブンナイン（99.999999999%）という驚異的な耐久性を支える技術があります。これだけの技術にたくさんの知性が凝縮されていると思うと、とてもロマンを感じます。

AWS最古参のサービスの1つとして、S3が単体で進化してきた歴史もさることながら、他のあらゆるサービスがS3を土台としてどう発展してきたか、その関係性の歴史を追うのもまた、面白いんです。

ちなみに、イレブンナイン（99.999999999%）の耐久性を持つストレージのデータが壊れる確率って、橋本環奈さんが誕生する確率（1000年に1人）と同じらしいですね。

まとめ

ITの世界は、最初はブラックボックスだらけで、「よくわかんないけどこれが正しい、間違ってる」の連続でした。（少なくとも僕にはそう見えていました。）

でも、一歩踏み込んで仕組みを覗いてみると、そこには先人たちの知恵が詰まっており、霧が晴れるみたいに少しずつ色んなものが見えるようになっていきます。今回の記事で触れた「気づき」は、この霧が晴れた瞬間の記録です。

1年目を振り返ってみて、この霧が晴れる感覚が楽しくて夢中で勉強していたのだなと、改めて感じます。2年目も霧晴れドリブンで勉強したメモが手元に溜まっているので、機会があれば2年目編も書けたらと思います。

長くなりましたが、最後まで僕の雑メモにお付き合いいただき、ありがとうございました。

秋のブログ週間とは

2020年から始まったブログリレーの企画です。元ネタは、秋の読書週間（文化の日を中心とした10/27〜11/9の2週間）です。これに合わせて、平日にブログ記事を投稿していこうというブログリレーなイベントです。

「春の入門祭り」「夏の自由研究」「秋のブログ週間」「冬のアドベントカレンダー」と四季の名を冠に持つ、フューチャー技術ブログ4大ブログリレーの1つと言われています。

テーマは秋の読書週間のイメージで、普段のソースコードがでてくる技術記事ではなく、ソファーでゆっくり読めるような、読み物（エッセー）よりの記事を書いていこう、としています。元ネタが読書週間ですし、積読消化を進めるための書評記事もOKとしています。気になるタイトルの記事を読んで読書欲を刺激していきましょう。

12月にはお馴染みQiitaさんのアドベントカレンダーにも参加したいと思いますので、秋のブログ週間はちょうどその中間のまったりとした、秋の夜長を楽しむためにも読み物成分を中心として楽しんでいただければです。

2025年はハロウィンの本日から開始することになりました。

いつもはコードが本文に書かれていることも多いフューチャー技術ブログですが、この連載はスマホ片手で読めるような記事成分を高めたいと思います。約2週間、どうぞお付き合いください。

夏の自由研究2025ブログ連載の7日目です。

フューチャー技術ブログの「関連記事」の表示ロジックの変遷と今後についてまとめます。

背景

フューチャー技術ブログは開設以来、Hexoという静的サイトジェネレータを利用しています。そのため、サイトの構造や記事のレイアウトは完全にフルスクラッチで自由度が効く反面、全てを自分たちで（できれば、手間と時間をかけずに）行う必要があります。

創設が2016年、9年半が経過し現在1300ほどの記事が投稿されています。中にはバズって数万PVに届く記事もあります。せっかく、ある記事を見てもらったのであれば、他の記事をついでに見てもらうことで回遊率を上げたいという気持ちがあります。また、社内のナレッジ管理の側面では「know who」が重要なので、似たような記事を書いた人を辿れるようにしておくことは、ポリシー的に大事にしたいポイントです。

1300記事もあるとユーザー自身で探すことは難しいので、それっぽい記事を表示することが求められます。そこで、「関連記事」の上手い表示が求められます。現在では、記事のSNSボタン領域の次に関連記事を表示するようにしています。

この記事では、なるべくローコストかつシンプルな関連記事の導出しようとした軌跡を紹介します。

黎明期（2016年～） 原始的な運用

投稿推移のページを見ると一目瞭然ですが、ブログ開設した2016年から2019年の間は、チームごとの持ち回り制で運営していたこともあり、投稿数は伸び悩んでいました。

この時期は、正直「関連記事」を出すほど関連性のある記事が存在しませんでした。また、著者数も少なく、記事本文に直接、過去の類似の投稿をテキストリンクで貼る寄稿者が多くそれで満足していた時代です。今の関連記事の領域は「人気の記事」を表示する仕組みにしていました。

「人気の記事」の表示ロジックですが、PVからの判定ではありません。Hexoのテーマが持つYAMLで個別に記事を指定するというモデルです。何か人気の記事があれば手動で切り替えていました。控えめに言って辛さしかありませんでした。そのため、すぐに運用が追いつかず陳腐化した上で、早々に表示ごと削除しました。

勃興期（2019年～） ナイーブな実装

ブログが軌道に乗ってきたのは2019年ごろです。フューチャー技術ブログの運営で心がけていることとかフューチャー技術ブログで行っている連載企画が良いよって話 で書いたように、色々と運営手法が洗練されると記事数が増えてきました。

このころから、毎月10～20記事がコンスタントに公開されてきており、2021年初めには400-500記事に到達したため、「関連記事」を表示するようにしました。

実装は、記事同士の「タグ」と「著者」の重複数から関連度を計算するというロジック（）です。これの上位数件を表示していました。

例えば、以下の2記事があるとします。

• タグが[AWS, Go]。著者が 「未来太郎」
• タグが[AWS, Lambda, Python]。著者が「未来太郎」

この場合、1（AWSタグが同じ）+1（著者が同じ）=2が関連度です。

非常にシンプルなロジックですが、想像より100倍くらいいい感じに機能しました。とにかく軽く、事前の学習時間もゼロで、非力なラップトップマシンでも容易に動き、タグがそこそこちゃんとついていれば、数百オーダーまでスケールもできます。小規模ならこれで十分だと思います。

中興期（2022年～） ベクトル化？

コロナ禍でリモートブームになり2020年～2021年は非常に投稿数が伸びました。分析データとしてそれなりに面白いということでembeddingを用いた分析・検索・推薦の技術 にあるように、記事のメタデータをベクトル化し、コサイン類似度で関連記事を出してはどうかというトライも行われていました。当時は本文を見るより、以下のような原稿のMarkdownの先頭にくっついている、Front Matterと呼ばれるYAML形式のメタデータを用いる方が、精度が上がるという話でした。

---
title: "技術ブログの関連記事の表示～できる限り低コストに関連度を計算～"
date: 2025/09/03 00:00:00
postid: a
tag:
  - 運営
  - TechBlog
  - NLP
category:
  - Culture
thumbnail: /images/2025/20250903a/thumbnail.png
author: 真野隼記
lede: "フューチャー技術ブログの「関連記事」の表示ロジックの変遷と今後についてまとめます。"
mathjax: true
---

embeddingの記事にあるように、記事のクラスタリングや、記事に追加するタグ自体の推薦など様々な試みがありましたが、当時の記事数は500-600ほどで自動化する程ではない。また、タグ自体の運用が試行錯誤だったということもあり、本格導入には至らずでした。

最近（2025年～） 逆文書頻度を取り入れてみる

記事数が1000を大きく上回るようになってきた2024年ごろから、「関連記事」への不満が少しずつ出てくるようになりました。

例えば、以下のようなケースです。

• [Go]のタグを持つ記事が100個
• [AWS]タグが200個
• [テックリード]タグが5個

この状態で、[Go, AWS, テックリード]の3つのタグを持つ記事は、[Go, AWS]のタグを持つ記事Aか、[テックリード]のタグを持つ記事Bを比較すると、記事Aが優先されます。これはこれで正しい気もしますが、[Go]や[AWS]は付けられる記事数が突出して多いため、より希少性がある[テックリード]のタグを優先させたいなと思っていました。しかし、[Go]のタグ数を直接除算するのはペナルティが大きすぎます。

そこで、逆文書頻度（IDF: Inverse Document Frequency）を利用することにしました。IDFは で計算できます。シンプルで簡単に計算できる点が良いです。

タグの総数が1000とし、先程の例でIDFを計算すると、記事Bの関連度が高くなり、目的に合致できます。

• 記事A:
• 記事B:

この関連度を見たい人は少ないと思いますが、デバック用にマウスオーバーでツールチップに表示しています。もし、気になる方は確認してください。

関連度の計算ですが、同一著者かどうかも引き続き計算に入っています。タグがIDFでマイルドになるため、著者側もIDFに入れています。

その他の主要なロジックとしては以下があります。

• もし、タグや著者に紐づく関連記事が、規定件数未満の場合に「同一カテゴリ」のSNS人気記事から補填する
• もし、関連度が同一値だった場合は、最新の記事から選択する

これらのロジックで、概ね運営として関連記事に表示したい内容は実現できていると感じており、完璧では無いけれど、効果とコードベースのシンプルさのバランスが優秀だという点で、満足しています。

現状の課題感

基本的には、「タグ」ベースであるため、「タグ」を適切に設置する必要があります。現状ですと、運営が公開時に（GeminiのGemsなどを用いたり記事をレビューついでに読んで）手動で付与しています。しかし、いくつか課題が出ています。

1つ目はタグの設定の煩わしさと難しさに尽きます。

• 「タグ」の設定漏れがある
  • 公開時点では不要だと思って設定しなかったタグも、後々類似の記事が出たタイミングで、過去記事にも追加すべきです。しかし、どうしても業務が忙しいなどでチェックが雑になり、漏れてしまいます
• そもそも、あるべきタグを付けられていない
  • [Terraform]に加えて、[Pulumi]や[CloudFormation]タグが追加になったタイミングで、[IaC]といったタグを付与したくなります。これは設定漏れの一種ですが、[IaC]タグが既存に存在しない場合があります。その場合、新しい抽象化した概念でグルーピングして設定すべきですが、漏れてしまいます
• タグの表記揺れ
  • [GCP]が[Google Cloud]にリブランドされたように、表記が揺れているものを修正する必要があります
  • 対応が分かれば、便利スクリプトで置換しますが、気が付かない場合もあります。タイポの場合もありますし、例えば[オブザーバビリティ] [Observability] [可観測性]など全て正しいけど揺れていた場合もあります
• 意味のないタグがある
  • 1記事しか紐づかない、現時点では意味のないタグが存在します。例えば[PyCon JP 2024]などは1記事でもタグとしては理解できますが、[ログ] [ログ設計]のうち、ログ設計が1記事にしか紐づかない場合、削除した方がユーザーとSEO観点で重複コンテンツが減り嬉しいでしょう。
  • すべて同じ記事に紐づくタグのセットがある。意味論的に別の概念のタグがたまたま紐づくのであれば良いですが、タグ同士の意味が近しい場合、これはオーバーなタグ付けだと考えられます。必ず関連付けしたい記事同士を紐付ける裏技のようですが、タグ検索時のノイズなので可能であれば統合した方が健全でしょう

このあたりは、タグ一覧のページから、Geminiなどで定期的に怪しいタグを抽出してもらって棚卸ししていますが、本来はCI時点で検知したい内容です。ただし、「LLM」と「生成AI」のように本来は同じ意味と言えるが、「LLM」はLLMやRAGを開発管理する文脈、「生成AI」は業務に活用する文脈で使い分けていることも観測しており、自動化までのハードルは少し高いように思えます。

2つ目はカテゴリの適切な設定です。執筆時点のカテゴリと紐づく記事数は以下です。実は、最近[Frontend] [Mobile] [DataEngineering] のカテゴリを分離独立させました。

• Programming (305)
• DevOps (184)
• Infrastructure (134)
• Frontend (122)
• Culture (115)
• DataScience (102)
• DB (56)
• Mobile (56)
• IoT (51)
• Business (40)
• DataEngineering (37)
• Management (33)
• Security (32)
• 認証認可 (24)
• VR (18)

適切なカテゴリを作ることで、後述する親子関係のタグにより生じる問題を緩和できると思っています。しかし、どのような粒度でカテゴリを作るべきかは、読み手の関心事ごとに分離すべきでもあるので、それらのバランスに苦慮しています。[Programming]は突出して多いですが、その中の大多数を占める[Go]をスピンアウトさせるべきでしょうか？ また、[Programming]から[Backend]をスピンアウトさせるべきでしょうか。まだ判断がついていません。また、意味論的にも、iOSのCI/CD記事は、[Mobile]なのか[DevOps]のどちらに振り分けるか迷いも生じます（現状は、迷ったら数が少ないカテゴリに側を優先して振り分けています）。

今後（2028～）

おそらく、現在のナイーブなIDFベースのロジックでいくと、数年以内に問題が出てくると思います。例えば以下です。

• タグの意味的な親子関係により、精度低下
  • [フロントエンド] [JavaScript] [TypeScript] [React]など、タグ同士で（親子）関係を持つ場合があります。[React]の記事が増えてくると、[RSC]のような、細分化したタグを追加すると考えられるため、全体的にタグ数はインフレ傾向にあります
  • この場合、よりルートに近いタグ（フロントエンド、JavaScript、TypeScript）による評価は下げるといったペナルティによる調整が必要になってくると予測できます
  • また、[React] [Hooks]などの具体度が高いタグのみ紐づけられ、[フロントエンド]のような抽象度の高いタグは設定されない場合も問題です。[React]の記事数が十分であればこれでも良いですが、数が少ない場合は関連記事ゼロと見なされる懸念があります
• タグをたくさん持つ記事が有利という事実は変わらない
  • 多くのタグを持つ記事ほど、他の記事とタグの重複する確率が上がるため、関連記事に表示されやすくなってしまいます。逆に、タグが少ない良質な記事は不当に低く評価されてしまいます

---
title: タグの親子関係の例
---
graph TD
    A[フロントエンド] --> B[JavaScript]
    A --> C[CSS]
    B --> D[React]
    B --> E[Vue]
    D --> F[Next.js]

対策の1つ目として以下が考えられます。

• タグ同士の距離を計算し、近いほどスコアを上げる
  • 例えば、タグの親子関係を以下のように定義し、完全一致は1点、親子関係は0.5点、兄弟関係は0.4点、祖父母関係は0.25点などと調整する

{
  "フロントエンド": ["JavaScript", "CSS", "HTML"],
  "JavaScript": ["TypeScript", "React", "Vue", "Node.js"],
  "CSS": ["Sass", "Tailwind CSS"],
  "React": ["Next.js", "Remix"],
  "バックエンド": ["Node.js", "Python", "Go"],
  "インフラ": ["AWS", "Docker"],
  "AWS": ["EC2", "S3"]
}

親子関係は、共起関係分析（ある記事でタグAが使われているとき、タグBも一緒に使われている）を元に、たたき台を作れると良いかなと思っています。先ほど紹介した、embedding記事のBERTやWord2Vecを利用するのも一手でしょう。とはいえ、まずはタグの共起分析で十分精度が出るのでは？と推測しています。

2つ目の対策は以下が考えられます。

• たくさんのタグを持つ記事の評価を下げるため、タグ数の和や積の平方根などで調整する

例として以下の記事があり、現状のロジックにおける課題を説明します。

• 記事A (シンプル): [React] (1タグ)
• 記事B (近い分野): [React, Next.js] (2タグ)
• 記事C (詳細タグ): [フロントエンド, JavaScript, React] (3タグ)

この場合、記事Aの関連記事は記事Cが優先されて表示されてしまいます。先に上げた親子関係でのルール（親子で0.5点など）で計算した結果です。

• AとBの関連度 1.5（React1点、Next.jsが0.5点）
• AとCの関連度 1.75（Reactが1点、JavaScriptが0.5点、フロントエンドが0.25点）

今回は、フロントエンドやJavaScriptからReactを解説していると推測できる記事Aより、より専門的だと考えられる記事Bを優先させたいとします。

これには、記事が持つタグ数での調整が考えられます。以下はシンプルに総和で使っています。

• （新）AとBの関連度 1.5 / 3 = 0.5
• （新）AとCの関連度 1.75 / 4 = 0.4375

この例では、より専門的な記事であるBの関連度が高くなり、それなりに上手く行きそうだと思われます。実運用時は、和で割るのか、積で割るのか、積の平方根で割るといった、実データを見ながら調整する作業が入ると思います。また、気になるのは1記事にしか紐づかないけど、キーワード的に入れているタグ（例えば、書評記事の書籍名など）は運営側の意思で追加しているため、上記の計算から除外しても良いのではという気もしています。とはいえ、寄稿者側の意思で他に紐づきがないタグとの区別がつかないので、方針を考える必要があります。

他にも、極端にタグ数が少ない記事にタグを足すことや、タグ数の上限を設ける（現在は無限）などで調整しても良いかもしれません。ただ、本質的に必要十分なタグを付けていくことは守りたいので、ルールは慎重に考える必要があります。

注意として、どちらの対応策もそれなりに工数が必要そうな案です。現状、引き継ぎは考えていませんが、なるべく荷物は軽い状態をできる限り維持したい気持ちがあります。

将来（2032年くらい～）

このまま技術ブログ運営が続けば、このようなルールベースでの調整が崩壊すると考えられます。おそらく、3000~4000記事くらいでしょうか。社員数も増えてきており、1日1本の投稿ペースが2本以上になることも十分考えられます。そのため、タグや本文をベクトル化して、コサイン類似度などで判定することで運用負荷を下げる方法が求められるでしょう。

今すぐにコサイン類似度判定をやっても良いのですが、現状は以下の理由でストップしています。

• ルールベース、結果が分かりやすい（慣れてしまった）
  • ルールベースのロジックが高度に複雑化しない限り、関連度が上手くいった・いかないの理由は凄くシンプルに判明します。この結果を元に、タグ付けを改善しようというモチベーションが生まれやすいです
• どういったモデルが良いか、結果検証が難しい
  • 現状のルールベースでほぼ希望の結果ができてしまっているので、ベクトル化とコサイン類似度などの手法を取り入れて、どう良くなかったか確認する手段がない

そのため、ルールベースの複雑度が限界に達した場合や、いかにも面倒そうな親子関係定義などのタグ運用が業務の合間に行うレベルを超過して求められる場合に、導入しようと考えています。

ただし、「この記事にはこのタグを紐づけるべきではないか」という論点での利用は現時点でも積極的に考えたいと思います。

まとめ

技術ブログの関連記事を表示するロジックについてまとめました。

大学は電気電子工学で、うっすらIDFなどを学んだ記憶がありますが、業務ではバックエンド開発が主体で、テキスト処理を集中して行ったことが無いので新鮮に取り組めています。

プロからの意見をお待ちしております。できればJS（Hexo）で簡単に運用できる技術を求めています。

夏の自由研究2025のブログリレーのインデックス記事です。

夏の自由研究連載とは

皆さんも一度は通ったことのある小学生の自由研究。時にはやってみたいことをテーマにして前のめりにやり続けていたり、反対に面倒なことを題材にしてしまったこともあったり、楽しかったり苦かったりする思い出のひとつかもしれません。

夏の自由研究連載とは、そんな気持ちを思い出しつつ、寄稿者の普段の興味をベースとして、

• 普段手をつけられなかったけど、連載を機に何か手をつけてみる
• 童心を思い出して、何かをじっくり研究、工作してみる

などなど、「あの頃の無邪気なココロ」をブログにする連載です。

投稿スケジュール

さいごに

今年もバリエーションに富んだ記事の内容になっています。ぜひそれぞれの記事を読んでいただいて、よければシェアをお願いします！

過去の連載（2024、2023、2022、2021、- 2020）もぜひ読んでください。

ブログ運営の立場として、この生成AIブームな時代に「◯◯について技術ブログを書いてください！」と依頼し続けて良いのか？そんな疑問が湧きました。

情報収集はAIに聞けばいいし、書くこと自体もAIが手伝ってくれます。それでもなお、個人として技術ブログを書き、そして人に勧めるの理由を言語化しておきたい。

今回は、なぜ今あえて技術ブログを書いた方が良いのか、会社Slackのブログ寄稿者チャンネルで太田さん、澁川さん、枇榔さん、山本さん、橋本さん、村田さん、村瀬さん、柏木さんと相談した結果をまとめました。

自分のため

結局のところ、一番大きいのは自分のため。

• スキルアップ
  • 書く過程で、曖昧だった知識が整理される。疑問を調べて解消することで、より深く理解できる
  • アウトプットすることで、社内外からフィードバックをもらえて、さらに詳しくなれる
  • 地味に文章力も上がる。どんな仕事でも役立つ
• セルフブランディング
  • 自分のスキルや考えを示す、分かりやすい成果物になる。基本コンサルは守秘義務のため成果がクローズドになりがちなので、貴重。差がつく
  • 「〇〇の技術に詳しい人」と認識され、面白い仕事の相談が来たりする。実際アサインを決める立場からも、情報発信ができる人を優先したくなる心情も
  • 市場価値も自然と上がる。たまにクライアントが記事を読んでくれて、会う前から好感度MAXなんてことも
• ナレッジ共有
  • 未来の自分や後輩への最高の引き継ぎ資料になる。「これ読んどいて」で済むのは楽
  • だれかがググって自分の記事が出てきて助かったよ報告、ちょっと嬉しいし効率的
• 評価
  • フューチャーだと「その他の貢献」として外部発信がアピールポイントになる

生成AI時代だからこその価値

生成AIの登場で、ブログの価値はむしろ上がった部分もある。

• 情報の鮮度と正確性
  • AIの知識は少し古いことが多い。新しいライブラリやバージョン、ニッチな領域の情報は、結局人が書かないとネットの海に存在しない
  • 「AIが出してくるコードが古い」「このエラー、AIに聞いても解決しない」みたいなことは、まだ頻繁に起こる。誰かが書いてくれるのは本当にありがたい
• 「AIに出せない解決法」という価値
  • 「Copilotに勝つことを目標にしよう」という言葉が印象的だった。AIが生成するありきたりなコードではなく、もっとスマートな、あるいはもっと泥臭い、現場ならではの解決策にこそ価値がある
  • そういう独自解を共有する場として、ブログは最適
• 今後のAI学習のインプットに使われる可能性
  • モダンな記事を世の中に公開することで、将来のAIがさらに賢くなり、広範囲に良い影響を与えることができるという貢献

情報鮮度については、Dockerfileは生成AIが出してくるコードが古臭い、Tailwindは3系ばかり書いてくれて4系が全然書いてくれなくて割と困るという具体的な意見もありました。Goなら (*testing.T).Context() を補完してくれる確率はめちゃくちゃ低い体感があります。

結局、「検索して出てこないから書く」が「AIに聞いても出てこないから書く」に変わっただけなんじゃない？という声もあり、たしかに！と思いました。

コミュニティと文化

ブログを書くことは、文化やコミュニティへの参加でもある。

• プレゼンスの向上
  • 特にリモートワークが増えた今、自分の存在感を示すのは難しい。ブログは、好きな時間に書けて、自分という人間やスキルを知ってもらう良いツールになる
• 繋がり
  • ブログを書いていると、同じような課題意識を持つ人と繋がれる。連載企画なんかに参加すると、普段のプロジェクトでは関われないような面白い人との出会いがある
    • 「執筆者」というコミュニティに参加すること自体が、学習意欲を高めてくれる。一種の福利厚生みたいなもの
• 世の中がちょっとでも良くなれば嬉しい
  • 今までインターネットに助けられた分、自分の知見を出して “恩返し” する。この心情はある程度、経験を積んでから達する境地かも

まとめ

「エンジニアを名乗るなら、インプット/アウトプットを継続しないとゆるやかに陳腐化していく」という危機感はみんな、少しは抱く。ブログを書くことは、単なる情報発信じゃない。自分の思考を深め、キャリアを築き、コミュニティと繋がるための強力な手段。

「書かない理由、ある？」とまでは言いませんが、これだけのメリットがあるなら、書いてみない手はないですよね。ブログ執筆に興味がある人のちょっとでも後押しになれば幸いです！

春の入門祭りとは

春の入門連載は2020年から始めた連載で、以下のテーマで行う技術ブログリレーです。

• 新年度、新たなことをチャレンジする機会として、「入門」がテーマ
• 今まで触って無かった技術の体験記
• 先輩・同期・後輩宛に、知っておいて欲しい技術記事
• 好きな技術の布教活動をする記事

上記の前提であるため、具体的に取り上げる技術領域は自由ということが特徴です。人によってテーマである入門の解釈も自由自在で、お気に入りの記事に思いがけず出会うキッカケとしても機能するでしょう。

他の連載に比べて、ジャンルを問わずに応募していることもあり、毎年初の寄稿となる社員も多く参加しています。参加者の中にはブログを書いてみたい、とブログ運営に直接連絡をくれたやる気に溢れた社員もいるほどです。

参加者一覧&投稿タイトル

今年の参加はインデックス記事を含めて24名が参加します。過去最多の参加人数です..!! 間にゴールディンウィークを挟むため、5月の大半が埋まっています。

技術ブログにはお馴染みの顔から、今回の連載で初寄稿の社員まで幅広いメンバーで投稿していきます。テーマがまだ決まっていないところや変わる場合がありますが、運営チャットでは各メンバーの気合が漲っております。

さいごに

良いと思った記事などはシェアなどのリアクションをいただければと思います！

• 2024年の連載記事
• 2023年の連載記事
• 2022年の連載記事
• 2021年の連載記事
• 2020年の連載記事

2025年に計画しているブログリレーのスケジュールを紹介します。

連載計画を発表する背景

• どういったブログリレーを行おうとしているか、会社のカラーが出ると思うので、興味がある人に対してアクセスできるようにしたい
• ブログリレーは寄稿者募集のリードタイムが発生するため、予めのスケジュールを周知したい
• 日々の業務をしながらだと、どういった企画を考えたか忘れがちなので、最初に大枠を固めて置けると運営的に楽

2025年のスケジュール

2025年にはじめて開催する連載は初心者マーク（🔰）を付けてみました。いくつかの連載は、毎年実施しているわけではないため、Linkの過去年度は連続していない場合があります。ご了承ください。

さいごに

これまでの経緯を踏まえテーマをブラッシュアップしています。2025年も皆様にとって有益な情報発信を活発にしていきますので、応援よろしくおねがいします！

10/28より、秋のブログ週間というブログリレーを始めます。

秋のブログ週間とは

2020年から始まったブログリレーの企画です。元ネタは、秋の読書週間（文化の日を中心とした10/27〜11/9の2週間）です。これに合わせて、平日にブログ記事を投稿していこうというブログリレーなイベントです。

「春の入門祭り」「夏の自由研究」「秋のブログ週間」「冬のアドベントカレンダー」と四季の名を冠に持つ、フューチャー技術ブログ4大ブログリレーの1つと言われています。

テーマは秋の読書週間のイメージで、普段のソースコードがでてくる技術記事ではなく、ソファーでゆっくり読めるような、読み物（エッセー）よりの記事を書いていこう、としています。元ネタが読書週間ですし、積読消化を進めるための書評記事もOKとしています。気になるタイトルの記事を読んで読書欲を刺激していきましょう。

12月にはお馴染みQiitaさんのアドベントカレンダーにも参加したいと思いますので、秋のブログ週間はちょうどその中間のまったりとした、秋の夜長を楽しむためにも読み物成分を中心として楽しんでいただければです。

過去のインデックスのリンクです。

2024年に追加されたルール

2023年以前は書評の選定は自由でしたが、縛りがないとリーダブルコードなどの不朽の名著が選ばれがちでした。これはレビュアーの気持ちがイマイチ盛り上がらない…というわけで、書評タグにすでに存在する書籍はNGという縛りを追加しました。先勝ちになってしまいますが、これは秋のブログ週間だけのルールですのであり、その他の期間に入稿すれば引き続き受け付けるため、特に厳しくなった訳では無いためご安心（？）ください。

スケジュール

2024年は曜日の区切り的に、10/28（月）から開始することになりました。

見どころとして、2週目にアーキテクチャ設計系の書評が続きます。最近、ソフトウェアアーキテクト周りの書籍が増えてきたこともあり、有志で読み込もうというサブ企画のためです。当社は社名に”アーキテクト”がついていることもあり、アーキテクチャにはこだわっていきます！

さいごに

いつもはコードが本文に書かれていることも多いフューチャー技術ブログですが、この連載はスマホ片手で読めるような記事成分を高めたいと思います。約3週間ですがどうぞお付き合いください。

アイキャッチ画像は、Image Creator in Bingを利用させていただきました。

技育祭はサポーターズが実施している未来の「技」術者を「育」てる活動としている学生向けの「技育プロジェクト」の一大イベントです。

2024年9月21日-22日に開催された「技育祭2024秋」で登壇してきました。発表資料はこちらになります。

前回の登壇資料はこちらです。

僕自身はだいぶ年齢が視聴者の学生の皆さんと比べると2倍ぐらいと離れてしまっていますが、タイトルにあるような活動を通して若い人と一緒に活動しています。今回は、そちらの内容のPRをさせていただきました。聞いていただいている学生の方々と比較的年齢の近い清水さんにも参加していただきました。

コロナの前後で勉強会のあり方というのは大きく変わりました。オフライン主体だったものが、この技育祭のようにオンラインのイベントだったり、オンライン・オフラインハイブリッドになったり、形態も大きく変わりました。また、僕自身も子供たちと過ごす時間確保のために自分が発表する場以外にはほとんどいかなくなりました。

そんな中感じであっても、全然寂しくなく活動していて、それがこの社内のサークル活動です。

勉強というと、学校の授業の延長のイメージで、偉い人がしゃべっているのを聞いて覚える、みたいなイメージがありますが、僕は学生時代から実験とか発表とかそういうのが好きでした。で、情報収集はネットで集めることができます。ただ収集するだけではAIの方が賢いわけで、学んだことを元に何か動くソフトウェアを書いたり、内容をまとめてブログにしたり、というのを最近は活動のメインとしています。

そんでもって一人で活動するのではなく会社のメンバーと一緒にアウトプットを作っていこうという活動をしている点が、勉強会に行かなくても良い、むしろこっちの方が有意義だし、業務時間内なので家族の時間も犠牲にならないし一石二鳥、と感じている理由であります。そのような気持ちが少しでも伝われば、という感じで発表させていただきました。

サークルというワードを選んだりしたのは、学生の人たちに少しでも共感してもらえたら、という感じの目論見であったのですが、アンケートの結果を見る限り、結構よい感じにボールを受け止めてもらえた気がします。それ以外にも、フューチャーがこのイベントに出る目的でもある「コードが書けるコンサルタント最強説」の話も、びっくり、とかかっこいい、みたいな反応をいただけてうれしいです。また、こういう「会社をこうしたい」という思いがあれば自分自身をコンサルして変えていける雰囲気も伝わったのではないかと思います。

イベントを続けるうえでの工夫

質疑応答では、4件ほど質問がありました。その中の2本が、イベント開催で気を付けていること、イベントの集客についてです。勉強会の準備の負担を減らすこと、というのを回答しました。これは、どうしても本業ではないタスクではあるので、優先度が下げられてしまう可能性があるため、輪読会の発表者が事前に準備して資料を用意するスタイルだと、その負担が大きくて参加自体がおっくうになってしまう、というのがあります。

今回発表したものは事前の準備はしてくるのですが、勉強会としてやっている読書会では、事前準備はゼロでその時間の中で読み、コメントをしあうというスタイルをしています。以前技術ブログにも書きました。コストvs効果で、コストが小さくなれば同じ効果でもメリットが出てくるよ、というお話です。

https://future-architect.github.io/articles/20220125a/

あとは、「渋川さんがこういった活動をしているモチベーションの源泉はなんですか？」という質問がありました。確かこれは時間がなくて回答できなかったと思いますが、やはり会社の中への貢献だけではなく、社会全体への貢献をしたいという思いがあります。また、中と外の技術スタック・考え方などの差を小さくしていくことで、社内でのスキルアップ＝社外でもスーパーパワー発揮、みたいな感じの雰囲気は作っていきたいな、とも思っています。社内だけで通じるスキル、というのはやはり閉塞感の元ですし、「この中で仕事し続けていたら」という若手の迷いの元になってしまうので、そういうのはなくして、いきたいな、と。アウトプットし続けるのはそのための手段であると考えています。

こんにちは。技術ブログ運営の伊藤です。

夏の自由研究連載 2024のインデックス記事です。

夏の自由研究連載とは

皆さんも一度は通ったことのある小学生の自由研究。時にはやってみたいことをテーマにして前のめりにやり続けていたり、反対に面倒なことを題材にしてしまったこともあったり、楽しかったり苦かったりする思い出のひとつかもしれません。
夏の自由研究連載とは、そんな気持ちを思い出しつつ、寄稿者の普段の興味をベースとして…

• 普段手をつけられなかったけど、連載を機に何か手をつけてみる
• 童心を思い出して、何かをじっくり研究、工作してみる

などなど、「あの頃の無邪気なココロ」をブログにする連載です。

投稿スケジュール

今年の投稿スケジュールです。

今年は、夏ならではのネタよりは個人の研究に近い記事の方が多くなりました。

投稿順は前後したり、内容ば変わる可能性がございますがご了承ください。

さいごに

今年もバリエーションに富んだ記事の内容になっています。ぜひそれぞれの記事を読んでいただいて、よければシェアをお願いします！

過去の連載もぜひ読んでください。

• 2023
• 2022
• 2021
• 2020

はじめに

過去に公開したフューチャーアドベントカレンダーの記事の中から、評判が高かった or 社内投票があった珠玉の記事を再公開（リバイバル）するブログリレーを始めます。

背景

フューチャーでは2015年から2023年末までで合計9回に渡り、Qiitaさん主催のアドベントカレンダーに参加しました。

アドベントカレンダーはQiitaさん主催ということもあり、ブログ記事をQiitaさんのプラットフォーム上で公開するようにしていました。そのためこのフューチャー技術ブログ側と公開先と揺れているため、「あれ、あの記事どこだったけな..？」→「あ、Qiita側に公開されていたのか」といったやり取りが何度もありました。当然、新しくフューチャーに参画してくれたメンバーがイチから探すのは難易度が高いです。

だったら、技術ブログ側に再収録したら良いんじゃない？ とUroboroSQLなどのコミッターである星さんにアドバイスをもらったことがキッカケです。

アドベントカレンダーの記事をGoのスクレイピングライブラリであるgoqueryを用いて、Google SpreadSheetに一覧化し、投票＆著者に再公開してもよいか確認し、このたび第一弾として8記事+α を逐次公開します。

スケジュール

※星さん、柳原さんの記事は、時代に合わせてかなりアップデートしないと厳しいということで、間にあえば公開する予定です。

さいごに

構想から半年以上でやっと実現した、Qiitaアドベントカレンダーリバイバル企画。新しいことをすると取りまとめは大変ですが、その過程で学ぶことも多いですし、これを通して少しでもみなさまのお役に立てればなと思っています。

こんにちは。技術ブログ運営の伊藤です。

春の入門連載2024のインデックス記事です。

春の入門連載とは

春の入門連載は2020年から始めた連載で、アドベントカレンダーを除いて技術ブログの中ではご長寿な連載となっていて、2024年で5年目です。

この連載は以下のテーマで社員向けには募集をかけています。

• 今まで触って無かった技術のやってみた記事
• 先輩・同期・後輩宛に、知っておいて欲しい技術記事
• 好きな技術の布教活動をする記事

他の連載に比べて、ジャンルを問わずに応募していることもあり、毎年初の寄稿となる社員も多く参加しています。参加者の中にはブログを書いてみたい、とブログ運営に直接連絡をくれたやる気に溢れた社員もいるほどです。

さて、フューチャーには100名を超える新卒が4月に入社しました。社内外問わず、新人はもちろん、新しいことに取り組むきっかけとしても是非この連載を読んでいただければと思います。

参加者一覧&投稿タイトル

今年の参加はインデックス記事を含めて15記事14名が参加します。
技術ブログにはお馴染みの顔から、今回の連載で初寄稿の社員まで幅広いメンバーで4月いっぱい投稿していきます。テーマがまだ決まっていないところや変わる場合がありますが、是非色々な記事をお楽しみにしていただければと思います。

さいごに

是非、良いと思った記事などはシェアなどのリアクションをいただければと思います！

• 2023年の連載記事
• 2022年の連載記事
• 2021年の連載記事
• 2020年の連載記事

技育祭はサポーターズが実施している未来の「技」術者を「育」てる活動としている学生向けの「技育プロジェクト」の一大イベントです。僕自身も何度かかかわっているイベントで、先日開催された2024年3月17日に開催された「技育祭2024春」で登壇してきました。発表資料はこちらになります。

タイトルの2064年というのは、技育祭で一番ボリュームゾーンだと思われる20歳ぐらいの学部2年、3年の若者が60歳定年まで働くとしたら、という年ですね。AIでIT技術者がいらなくなる、みたいな話がよくされていますが、AI以前に優秀すぎる若者が周りにいっぱい増えてきて、ずっと前から危機感を感じていた40代のおっさんのキャリアプランをテーマに今回は講演しました。

私は今後AIの革新的発展によってプログラマーの人数が半分になるとしても、上から半分に入っていれば生き残れるだろうという打算のもと、技術力の向上や、プログラマーとしての市場価値を向上させていく、そしてそれを見える化する、というのが基本戦略としてやっています。今回の発表では時間もなかったので割愛しましたが書籍執筆もそのための一手です。本を書く、というのをここしばらくは年に2冊ぐらい継続しています。これに関する説明を一枠しゃべったときの、2021年の技育祭の資料も張っておきますね。

今回のイベントでは自分と聴講者層の大学生の年齢差が大きくなってきたということで、まさに技育祭でフューチャーを知って入ってくれた若手の大岩さんにもアシスタントとして参加してもらいました。親子といっても嘘じゃないぐらい年齢差があっても仲良く仕事しているというのも伝わればいいな、というのもちょっぴり思っていましたがいかがでしたでしょうか？ 大岩さんとは、技術広報として、会社の魅力を外に伝えていくにはどうすればよいのか？ という課外活動を一緒にやっています。

質疑応答

Q: IT職は人気なのに人手不足なのはどうしてでしょうか？

みんなIT力を高めてビジネスを強くしたいと思って、たくさん人が欲しいので、需要がすごく増えています。

Q: 早く一人前にならなければという危機感があるが一人前になるというのはどういうことか？

言われたことができる→自発的にできる→自分より若手をリードしつつできる→自分から道を切り開ける。

というのが思っていることで、実際にフューチャーのランクアップ要件もこんな感じ。フューチャーは年功序列ではないので、これができている若者は年齢関係なくじゃんじゃんランクアップしていますね。

Q: ITコンサルは, 要件定義など人と関わる部分がメインで開発に携わることが少ないと考えているのですが, いかがですか?

会社にもよると思いますが、フューチャーは一次受けで、お客さんとグラウンドデザイン策定から要件定義、実装、運用まで一気通貫でやる会社なので、実装とかもよくやっています。

Q: 現状未経験の人がこれから勉強を始める場合まず何から始めるべきでしょうか？

フューチャーは大学時代にITをやっていなかった学生も新卒で入っています。新入社員研修をきちんと行ってその後エンジニアとして活躍している社員も多いです。キャリアパスは自分で選べるので、学んだ上でお客さんと話をするのをメインとして選ぶ人もいますが。

そういうきちんと鍛えてくれる会社に入るのが良いと思います。でも、どうすれば入れるか、各社がどのような人材を求めているかは各社ばらばらなので「こうすれば大丈夫！」という正解はちょっとわからないですね。

Q: 他の方が「泥臭くても、コツコツ、貪欲にやる」が良いという旨の話をよくしているのですが、渋川さんもそう思いますか？

そう思います。といっても、同じ仕事を10年やり続けるとかそういうのはいらないと思います。学生のうちは「こんなことしたい」とキラキラした仕事をやりたいと思うかもしれないですが、自分が想像もしていない仕事が上から降ってきたりします。でもそういう未知だったものこそ、自分が知らないものがたくさんあって実力を伸ばすチャンスにつながるかもしれない。あらかじめ見えていた目線というのは実はそこまで広くなかった、ということは十分にある。目の前に来た仕事にまずは全力で取り組んでみるというのは大切。

質疑応答の残りや拾ったコメント

ドメイン知識も若い人はすぐ追いつくと思う

ドメイン知識って教科書的に資料としてまとまっていたりはしないんですよね。お客さんもたくさんの部署に分かれていて、それぞれの領域で仕事をしている。それぞれの領域の中の「常識」をつなげていくと知識体系が現れる。あとは既存のシステムの中にソースコードとして書かれた知識もある。利用者はボタンを押す方法だけ知っているがコアの知識はコード解析しないとわからなかったり。今後はこういうシステム考古学がますます重要になってくるかと思います。

こういうたくさんの情報を引っ張って集める社会学的な活動を毎回やって初めて知識として取り出せるのですが、その知識の取り出し方、実際に取り出した知識（業界ごとではなく会社ごと、部署ごとに違ったりする）もあるので、学ぶのはだれがやっても大変かと思います。

自分の得た知識は自分のもの！ 誰にも公開しない！ でも他の人からは情報はもらう！ って感じのエンジニアを学生の中に時々みるのですが、自分が長い時間を掛けて得た知識を本で共有するにあたってそのような考えにはならないのでしょうか？

それで知識を持っていても、外からはどれだけの情報を持っていることが分からないので、結果として本人の魅力アップにはなっていないと思います。あと、自分が手を動かして作業者として仕事するのよりも、回りを導いて組織として成功できる方が社会としては必要とされます。ICよりもマネージャー採用しにくい問題。

基幹システムって具体的にはどのようなものですか？ イメージ湧かなくて・・・

その会社のビジネスの根幹をささえるシステムですね。小売りなら商品を管理して売り上げを集計するなど。

早いうちに一人前になるような人は外向性の高さやフットワークの軽さなどどのような特性がありますか？

どちらかというと、求められていることをきちんと把握してやりきるための段取り力ですかねぇ。もちろん、ステージやその時のプロジェクトの状況によって必要な能力とかあるとうれしい能力は変わってくると思いますが。

支援士のような資格がある人とCTF経験が豊富な人とではどちらの方が需要ありますか

セキュリティ系ですかね？ セキュリティ系はかなりタレント性が強い仕事もあったりするので一般化はしにくいですね。元フューチャーで海外からオファーが来て転職していった若者もいましたし。フューチャーにもセキュリティ特化のグループ会社DITとかフューチャー社内のセキュリティ部門のCSIGがあるので、興味がある方はカジュアル面談を申し込んでいただけると、中の人が事例とかどのようなスキルが必要とされているかとかお話できるかと思います。

失礼なことを聞くようで申し訳ないのですが、フューチャー株式会社は年収どこまで伸ばせますか？

おっと、それ聞いちゃいます？ 転職のときにもがっと上がったけど、入ったあともがっがっと上がっています。技育イベントは公開イベントですので、そのあたりはもうちょっとクローズドなフューチャーのイベントで社員の人にぶつけてもらえればと思います。

年収は能力というか入った会社次第なところがありますが、一般的な傾向としてはきちんと利益を上げていく、業績を伸ばし続けていたり安定している会社が延ばしやすいと思います。

就活対策で会社が公開しているプレスリリースはきちんと目を通した方が良いですよ、というお話はしましたが、決算資料の数値も見ておくと良いかと思います。

2024年に計画している、ブログリレーの企画スケジュールを取り上げます。

連載計画を発表する背景

• どういったブログリレーを行おうとしているか、会社のカラーが出ると思うので、興味がある人に対してアクセスできるようにしたい
• ブログリレーは寄稿者募集のリードタイムが発生するため、予めのスケジュールを周知したい
• 日々の業務をしながらだと、どういった企画を考えたか忘れがちなので、最初に大枠を固めて置けると運営的に楽

2024年のスケジュール

2024年にはじめて開催する連載は初心者マーク（🔰）を付けてみました。

フューチャーで最も利用頻度が高い重要技術要素である、JavaやVue.jsを今回始めてテーマに加えたことが変わったポイントです。実はフューチャーはJavaやVue.jsの会社でもあります。

アドカレリバイバルは、QiitaアドベントカレンダーでQiita側に書かれているか、フューチャー技術ブログ側で書かれているかたまに混乱することがあるという意見を某メンバーからもらい、せっかくだからリバイバルと称してアップデートしてこちらのブログに転記してもらったらどうか？ ということで企画しました。

新しい風を入れつつ、春・夏・秋などの定番企画は引き続き開催しようと思っています。

さいごに

これまでの経緯を踏まえテーマをブラッシュアップしています。2024年も皆様にとって有益な情報発信を活発にしていきますので、応援よろしくおねがいします！

はじめに

こんにちは。技術ブログ運営の伊藤です。

11月も終わりに差し掛かり、毎年後１ヶ月あるにも関わらず年末に急かされている気持ちになります。そんな12月ですが、エンジニアとしてはもはや風物詩となっているQiita Advent Calendarにフューチャーは今年も参加します。本記事ではこれまでの振り返りと今年の記事内容について触れます。

アドベントカレンダーとは

アドベントカレンダーは以下のようにWikipediaには書かれています。

アドベントカレンダー (Advent calendar) は、クリスマスまでの期間に日数を数えるために使用されるカレンダーである。待降節の期間（アドベント、イエス・キリストの降誕を待ち望む期間）に窓を毎日ひとつずつ開けていくカレンダーである。すべての窓を開け終わると迎えたことになる。

このように、クリスマス(25日)を迎えるまでに1日1日数えるカレンダーですが、エンジニアの業界では毎年これになぞらえて、リレー形式で記事を公開していくイベントとなっています。
このうちQiita Advent Calendarについては2015年からフューチャーが参加しているイベントであり、今年も社内で参加者を募りました。

2023年のカレンダー

2023年は以下の参加状況になっています。

参加者については全社から以下のような方々が集まりました。

• 数年来毎年参加し続けている方
• アドベントカレンダーを機にブログを投稿する方
• 今回は現在新人研修を終えてOJT期間に入ったフレッシュな新卒
• 他薦によって記事を執筆する方

例年のアドベントカレンダーから比べると、これまで技術ブログに投稿したことのない方も多くいます。そのため、普段技術ブログでは見られないような内容も見ることができるかもしれません。

また、シリーズ1が無事全て埋まったので、シリーズ2も開けております。こちらはシリーズ1で投稿したけどまだまだ書き足りない、シリーズ1の参加を逃してしまったけど投稿したい、といった方が参加しております。シリーズ１から含めると３本投稿する予定の方もいたり、こちらもぜひご覧になってください。
どちらのシリーズについても本記事投稿時点ではネタが定まっていない方がいますが、当日に向けて鋭意執筆中ですので、公開当日をお待ちください。

発表テーマについて

例年の記事で掲載している内容を改めて引用します。

例年と同じく、IT技術であること以外はフリーテーマです。

ポリシーとしては基本的にはQiitaそのものに投稿していただくスタイルですが（順位も少し気にしています）、Qiitaの投稿規約に沿わない記事（エッセー過ぎるもの、プログラミングに関係ないもの）は技術ブログ側に投稿することもあります。このあたりの決めは各人にお願いしています。
その他、個人ブログへのリンクは非推奨で基本的にはNGとアナウンスしています。

記事投稿については個人が気になる場合は内部で確認するなどしますが、基本はガイドラインや倫理的に反しない内容で投稿していただくようお願いしております。また、個人ブログへのリンクは原則として当社のアドベントカレンダーではNGとしているので、参加される方は注意してください。

さいごに

エンジニア業界、年末の大きなイベントになっており、当社に関わらず様々なところで外部発信が溢れて色々な記事を読むことが楽しい時期でもあるのがこのアドベントカレンダーです。
参加者一丸で盛り上げるので、ぜひご一読いただければと思います！

中山心太氏の最新作、高校生だけじゃもったいない　仕事に役立つ新・必修科目「情報Ⅰ」のレビューに参加し、お礼に献本をいただきました。ありがとうございました。読んだ感想としては発表されたタイミングでツイートしたのがそれにあたります。結構レビューではがんばってコメントを入れました。レイアウトの都合で入りません、と言われたものもいくつかあったのですが、その反映されなかったコメントも交えて本書の紹介をしようと思います。

レビューに参加しました！単に教科書をなぞるだけじゃなくて、ところてん節がところどころにあって、社会人であっても、ITの専門家でなくても、リテラシーとしてITが何をできるのかというのを身につける大切さが書かれています。面白かったです。 https://t.co/tOUBpGiPtN

— 渋川よしき (@shibu_jp) October 19, 2023

コンピュータが基礎教養になるというのはどういうことか、というのは最初のP19で紹介されている問題の解法の解説で明らかになります。大学で学ぶような理論であっても、プリミティブな手でも解けるシンプルな計算や数のカウントといった簡単な手順に落とし、それをCPUのパワーで繰り返すことで高速かつ大量のデータに対して解決できるようにするのがコンピュータを使った問題解決です。この例では1つ1つはとてもシンプルな事象なので、それを手でシミュレートしています。これを繰り返すことでかなり複雑な予測でもコンピュータでできそうだという気持ちにさせてくれる本です。

そのように導入部から説得力のある形で始まるのですが、作者はChatGPT本も数ヶ月前に出しており、そちらも精通しています。最後にはそちら方面の情報のキャッチアップも行えるような構成になっております。情報Iの教科書を読み進めていく上ではガイドとして道を示してくれる本だと思いますし（僕は実際は読んではないですがITパスポートなどの学習にも使えそうという感想）、他の本を読まなかったとしても、単体で「自分の仕事にどのような影響があるのか？」というのを考える大きなきっかけを与えてくれる本かと思います。それだけではなく、P200のような神Excelがなぜダメなのか、なぜこれがDXではないのか、というのが理解できるようになってくるでしょう。

神Excelの方は説明はあっさりしたものですが、おろらく、後続の事務処理にはまったく手を入れる意思がなく（もしくは権限がない）、紙の申請書を回すフローをそのまま使うために「印刷したら過去の方法と互換性が生まれる」という方式になっており、仕事の流れ自体は全く変わっていない（もしくは増える）ため、本来のDXで得られるはずのメリットが享受できないということを説明しようとしていたのでは、と思います。

「ITは基礎教養」とか「これからはインターネット」とかふわっとしたものではなく、学ぶことによって何がどう変わるのか、というのをきちんと伝えてくれる良い本かと思います。システム開発をするにあたって、予算の都合で機能（スコープ）を削っていくというのはよくある話ですが、やはりどこを新しくすることでどのようなビジネス上のメリットを得るのか、どこが費用対効果が大きいのかというのをきちんと考え抜くスキルはITにかかわるけど本業がIT出ない人にもとても大切になり、かなり大きな金額のITプロジェクトの成否を決めるポイントになります。

なお、著者のところてん氏は本に入りきらなかった内容をブログ公開しているのですが、これらも面白いです。

情報I本の未収録原稿をブログで公開しました。これでまだ半分くらい

「豚と符号化」が割とお気に入りだったんだけど、紙面の都合でカットされて辛かったので供養https://t.co/kCsYyfvOcS

— ところてん (@tokoroten) November 5, 2023

情報I本の未収録原稿その２（ChatGPT関連、機械学習回り）ですhttps://t.co/1hqlQodDPF

— ところてん (@tokoroten) November 6, 2023

ITを仕事にしている人にも読み物として面白く、そうじゃない人には今後のビジネスを大きく飛躍させるのか、逆に時代遅れにしてしまうのかの分水嶺となる考えを学べる良い本だと思いますので多くの人に手に取ってもらえると良いのではないかと思います。実際、かなり売れているようです。

AmazonでIT関連で1位になってた pic.twitter.com/evVLLInyGd

— ところてん (@tokoroten) November 4, 2023

著者のところてん氏にはこのブログ原稿を見てもっと本文を引用してもいいのよ、と言われたのですが、本文を読む楽しみを最大化して欲しいのでこのままにしておきます。

秋のブログ週間2023、本日から3週目に突入です。

はじめに

こんにちは、TIG所属の大野です。

秋をすっ飛ばしてめっきり寒くなってきた今日このごろですが、読書の秋ということで、以前から気になっていた『インターネットの起源』（原題『Where Wizards Stay Up Late: The Origins Of The Internet』）を読んでみたいと思います。

感想

本書は、1960年代から1980年代にかけてのインターネット黎明期のアメリカを、数多の書籍や記事、論文、そして関係者へのインタビューを元に描いた、いわばインターネットの歴史書です。

歴史書といっても、重要な出来事を時系列に沿って整理したような堅い読み口ではなく、インターネットの生みの親たちのリアルな会話を中心に構成されたドキュメンタリーのような趣で、読み物としても大変面白かったです。

本書の構成としては、インターネットの前身であるARPANETの誕生から各種プロトコルの作成、他ネットワークとの連携によるインターネットへの成長、そしてARPANETの終焉までを、全8章に分けて記述しています。

各章の概要と印象に残った箇所を紹介します。

第1章 即断即決で100万ドル

第1章では、ARPANETの生みの親たるアメリカ国防総省ARPA（国防高等研究計画局）およびIPTO（情報処理技術研究室）の創設経緯、そしてIPTO初代部長であるJ・C・R・リックライダーによるコンピュータ・ネットワークの構想について語られています。

元々音響心理学者であったリックは、当時もっぱら計算機としての利用が主流であったコンピュータについて、その対話的利用が人間にもたらす計り知れない恩恵を予見していました。

本章では、リックが政治プロセスを例にコンピュータおよびコンピュータ・ネットワークの有用性を説いた話が紹介されています。

（前略）リックは、将来コンピュータに手が届くようになれば、多くの市民が「政府の政策決定過程に関する情報を得て、興味をもち、そこにかかわるようになる」と考えていた。（中略）
「政治は基本的に大規模な電話会議を通じておこなわれ、選挙運動は候補者と広報担当者、評論家、政治行動グループそして有権者のあいだの数ヶ月におよぶ一連のコミュニケーションになるであろう。そのカギを握るのは自発的な積極性であり、それには良質のコンソール、良質のネットワーク、良質のコンピュータを通じて得た情報を真に対話的に扱える環境が必要である」

誰もがスマートフォンを持ち歩き、ソーシャルメディアで世界中と瞬時につながる現在の世界をリックは正しく予言していました。

彼が「真のインターネットの父」と言われる所以がよく分かる内容でした。

第2章 大聖堂を建てたのは誰か

第2章では、ARPAのラリー・ロバーツによるARPANETプロジェクトの発足、そしてポール・バランおよびドナルド・デイヴィスにより、偶然にも同時期に全く別の場所でそれぞれに発明された「パケット交換」の概念について語られています。

よく「インターネット（の前身であるARPANET）は軍事目的で開発された」という風説を耳にします。本章を読む限り、ARPAが国防総省の機関であること、そしてARPANET構想の技術的概念を形作ったバランが核攻撃時も可用性を失わない通信システムの必要性を強く意識していたことがこの風説の形成に影響しているのではないかと思いました。

実際のところ、ARPANETプロジェクトは研究者間の資源共有による経費削減というARPAの思惑に端を発していたとわかり、その現実的な理由にクスリとしてしまいました。

第3章 第3の大学

第3章では、「第3の大学」と呼ばれたBBN社の歴史、この小さな会社がARPAとのIMP開発の契約を勝ち取るに至った経緯が語られています。

IMPとは「Interface Message Processor」の略で、現在でいうルータにあたるような装置です。もちろんこの時代にそのような機器の前例はないため、IMP開発は難易度も不確定性も極めて高いものでした。そんなシビアなプロジェクトの管理者であったBBN社のフランク・ハートは、効率的なエンジニアリング・チームを編成するため、以下のような方針を取ったといいます。

彼が求めたのは、個人的な課題よりも共通の目標の達成に力を注ぐような人材だった。誰もがつねにほかのメンバーたちと話し合えるようにチームを少人数に抑え、自分のしごとを個人的な責務として引き受けられる人びとを選んだ。特異な面は大目にみてはいたが、どれほど頭がよくても自己中心的な”変人”は退けた。

現在でも通じる価値観であり、思わずチームメンバーとしての我が身を省みた部分です。

第4章 プログラムと格闘する日々

第4章では、BBN社によるIMP初号機作成の苦難について語られています。

初期のIMPはハネウェル社のDDP-516というミニコンピュータ（といっても冷蔵庫くらいの大きさ）をベースに作成されました。ところが、ハネウェル社から納品された516は発注内容とまるで違っていて……といったように、トラブル続きの現場の雰囲気が感じられてとても臨場感がある内容です。

IMP初号機納入の期日が刻々と迫る中、オシロスコープと配線ツールを手に、数ナノ秒ほどのごく一瞬の同期システムの異常パターンを探すシーンは、想像するだけで胃が痛くなります。

第5章 トゥルート宛必着

第5章では、初めてのARPANETの実地試験、そしてスティーブ・クロッカーとヴィント・サーフらによるホスト間通信のためのプロトコル設計の取り組みについて語られています。

本章では、研究者や大学院生などのARPANET関係者らが、対等な開かれた議論の場の中でプロトコルについての合意を形成していったそのプロセスが印象的でした。その最たる例として紹介されているのが、クロッカーの考案した意見表明の手段である「RFC（Request For Comments）」です。

クロッカーがRFC1をバスルームにこもって徹夜で書き上げたときのエピソードが紹介されていました。

彼は思慮深く、周囲に気を遣う青年だった。「僕らの書いたものが”公式の”プロトコルを設計する人たちの気分を害するんじゃないかって、ものすごく心配した」。（中略）彼は、自分の言わんとすることそのものよりも、その口調を間違えないように気遣った。「基本的な大原則は、誰もが自由に発言でき、”これが公式見解だ”というものはないってことだ」

RFCによる技術仕様の共有は今日まで続くシステムではありますが、今日のRFCが「ひと通りの議論を終えた標準仕様を公開するための文書」といった色を持つのに対し、初期のRFCは字義通り「議論のための叩き台」であったことがうかがえます。

第6章 ハッキングと喧騒と

第6章では、ARPANETの拡大や端末IMP（TIP）の作成、TelnetとFTPの作成、そして第1回ICCC（コンピュータ通信国際会議）でのARPANETのお披露目会について語られています。

ARPANETのお披露目は、ワシントンのヒルトンホテルに設置された多種多様な端末機器をARPANETのTIPと接続し、アメリカ各地に散らばったARPANETサイトのホスト・コンピュータとリアルタイムに通信するデモンストレーションの形で行われました。

特に参加者の目を引いたデモとして、対話式の英会話プログラムPARRYとDoctorが紹介されていました。PARRYはパラノイア患者の思い込みを、Doctorは精神科医の行動を模倣するプログラムです。

サーフらがおもしろ半分にこの2つのプログラムをARPANETを介して「対話」させた記録がRFC439として公開されています。全体的にとんちんかんではありますが、部分的には患者と医師としての会話が成立しているようにも見えて面白いです。

第7章 電子メール

第7章では、ARPANETにおける電子メール利用の急速な拡大、そして電子メールがARPANETの主要な用途へなっていく流れが語られています。

特に印象的だったのは、Dungeons and Dragonsという最古のTRPGを元にウィル・クラウザーが作成し、のちにドン・ウッズにより改良された、Adventureというコンピュータ・ゲームに関するエピソードです。改良版のAdventureはスタンフォードAI研究所のコンピュータ上で誰にでも自由に公開され、また作者たちも海賊版の作成を推奨していたため、多くのARPANETユーザは寝不足になりながら夢中でこのゲームを遊びました。

この時点では政府の持ち物であるはずのARPANET上では、しかしながら国防とは何ら関係のない私的で自由な利用が実質的に認められていたことが分かります。

実際、ARPANETにおいて電子メールがここまで広く普及・成功した要因として、ビジネス用途以上にプライベートなコミュニケーションツールとしての魅力が大きかっただろうことは想像に難くありません。用途や目的を制限しない、自由で開放的なネットワーク文化が、ネットワーク技術の成長を加速させたのだと感じました。

第8章 手にしたロケット

第8章では、ロバート・カーンとヴィント・サーフによるTCP/IPの作成、ロバート・メトカーフによるイーサネットの発明、DNSの開発、そしてインターネットの成長が語られています。

ネットワーク接続の標準仕様を巡る、ISO（国際標準化機構）擁するOSI参照モデルとTCP/IPとの競争はとても興味深かったです。

OSI参照モデルは、アメリカにおいてもヨーロッパ諸国においてもネットワーク接続の公式標準として採用されました。しかし、開放的なネットワーク文化に親しんだインターネット・コミュニティの参加者たちは、クローズドな机上の理論であるOSIモデルに反対し、ある種の非合法活動のようなかたちでTCP/IPを採用する動きが広がりました。

当時人気のオペレーティング・システムであったBSD UNIXがTCP/IPを組み込んだこと、そしてイーサネットの発明とLANの爆発的な普及に助けられ、ARPANETおよびARPANETの通信プロトコルであるTCP/IPは、公式標準であるOSIモデルを凌駕する巨大なネットワーク基盤を構成するに至りました。

あるTCP/IP推進派のコンピュータ科学者の印象的なセリフを引用します。

「標準とは合意によって形成されるもので、命令で作られるものではない」

おわりに

インターネット黎明期のおおらかでオープンな空気感が伝わってきて、当時を追体験しているかのような感覚でワクワクしながら読み進めることができました。
また、プロジェクト運営の哲学や技術開発に対する態度など、ITコンサルタントとして備えておきたいマインドセットという観点でも学ぶところが多くありました。

惜しむらくは、本書は現在ほとんど流通していないことです……。原著であればまだ入手できますので、英語が得意な方はぜひ読んでみてください！
（私のように英語を見ると蕁麻疹が出そうになる方は、図書館を探してみると翻訳書が見つかるかもしれません）

最後に、本書の中で最もお気に入りのフレーズを紹介して終わりたいと思います。

技術における進歩は、往々にしてありふれた営為から生まれる。研究者たちは、新たな技術を用いてふだんどおりのことができることを示し、新たな技術への信頼を醸成する。信頼が生まれると人間はさらに大きな可能性を考え、そして次の段階へと進んでいく。変化を受け止めていくうちに、人びとのなかでは次の世代の構想がはぐくまれていくのである。

明日は、工藤さんの「TEAM GEEK」を読んでメンバー視点で良いチームについて考えるです。

導入

小学校を卒業して云十年。

この年になって100マス計算のドリルを毎日1問解いているTIGの原木です。

念のため、100マス計算を知らない方に説明すると、
100マス計算とは、下記のように縦横にランダムに数字を並べて、
四則演算(足し算、引き算、掛け算、割り算)のどれか1つにしたがって、
縦と横の数字を計算した答えを(一般的には)左上から順番に空白へ埋めていくものだ。

100マス計算をするために必要なのは、以下の3つ。

100マス計算の白紙、シャーペン、そしてストップウォッチ。

100マス計算をやるのにストップウォッチは欠かせない。
時間という制限に追われて初めて真価を発揮するからだ。

スマホの時計アプリで開始ボタンを押した瞬間、自分は小学二年生だったころの自分と接続する。教室の片隅でクラスメイトと教室の時計を見つめながら呪文のように九九を唱えていたあの頃に。

何代目かもう忘れてしまったグラフギア500が走る音だけがこだまする。7,8あたりが来た時にかすかに脳裏から訴える不調音に耳をそばだてる時間などない。

考える間もなく次の問題へ移る。書き損じに消しゴムを使う余裕などない。とっさに6を伸ばして4に書き換える。0と1が左にあればそれはもうボーナスステージだ。計算すらやめて必死に書き写す。あと、3行。あと、2行。ラスト!

…そして、スプラトゥーンの鮭狩り1ゲームにも満たない時間が終わりを告げる。

調子がいい時で1分20秒、悪い時で1分30秒、そこから上がる気配はない。

情けないがそれが今の自分だ。

右手の外側を鉛筆カスで真っ黒にしながら中学受験の勉強をしていた当時の自分ならもっと早かっただろう。栄光学園だけに過去の栄光だけどね、HAHAHA¹

計算ドリルの魅力

私はドリルに飢えていた。いや、正確にいえば、何も考えずに一心不乱に書きこむという経験に飢えていた。

そのことに気づかされたのは、とある若手社員に質問を受けたことがきっかけだった。会社のチームメンバーに質問されたことから流れで「ソフトウェアテスト技法練習帳」をやることになり、はっと思ったのだ。

https://gihyo.jp/book/2020/978-4-297-11061-1

昭和生まれのアラサーでも公文式はやるのは楽しい、と。²

公文式の要領は、ちょっと引っかかりを感じるが、深く考え込むまでもない問題を、パターンを変えて何回も何回も繰り返すことだ。

この体験に当てはまる仕事は残念ながらインフラエンジニアには少ない。

ソフトウェアを書く機会はそれなりにあるが、ちょっとでも似た作業が続けば怠惰の登場だ。それどころか、最近では社内用のAzure OpenAI Serviceを利用して、ちょっとでも楽をすることが増えてしまった。

そもそも、仕事で解答を問われる仕事は大体次の3パターンに分かれる。

• 今までやったことがない新規性が非常に問われる問題
• 深く考えぬき、悩んでも、正解がはっきりしないが回答は求められる問題
• 過去にどこかで解決した問題、その解答の繰り返し

そのどれでもない体験が計算ドリルには秘められている。

正解はあらかじめ与えられている。そこにブレはない。

人の顔をした新規の案件が反転して正解がない泥沼案件へと変わる恐れ、そこから必死に脱出しようとするストレス地獄もここにはないのだ。

ちょっと考えられれば解ける問題というのも重要だ。1分ですら長すぎる。深入りも不要だ。AIじゃないし、思考の連鎖は1回でいい。

もちろん、後から振り返ればいくらでも課題は見えてくる。1+1=2であることにすら考察が求められる世界もあることはある。だが、少なくともここでは深く考えなくていいのだ。ちいかわである。

そしてゴールが明確なのもいい。

短い時間の中で、思考の100m走に追われる中でいつの間にか後味よく終わる。計算ドリルたーのしーという後味とともに、忘れていた四十肩が返却されてくる。

それらすべてが、自分が長く続けられる理由だろう。

この計算ドリルの体験を横展できないか？

計算ドリルの魅力を踏まえると次のように分析できるだろう。

• 解答とそこに至るまでの道筋が明快であること³
• 圧倒的な物量を時間に追われながら消化することによる、適度な認知負荷がかかること⁴
• 正解率を下げるのはケアレスミスと老化だけという大人げない自信⁵

これらの美点を抑えたうえで、IT業界の仕事に役立つ書籍や問題集はないかと探してみた。

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

「同値分割法と境界値分析」「デシジョンテーブル」「状態遷移テスト」「組み合わせテスト」の4観点による、ソフトウェアテスト技法の練習問題集。

計算ドリルの魅力に嵌まるきっかけとなった書籍。

構成が非常にわかりやすく工夫されており、左のページに設問、右のページにジャポニカ学習帳のようなメモ欄、そしてページをめくると答えという風になっているので、実本を購入した方が良い。

100マス計算と同じで、とりあえずシャーペンを動かしてる間に思考がまとまるという懐かしい追体験もできる。

Python初学者のためのPandas100本ノック

Pandasの基本的な使い方について100ケースの問題をjupyter notebookでひたすらコーディングしながら学べる。

去年、BIサービスのシステム構築に関するプロジェクトにいた時に、上物のアプリケーションで何をしているのか知りたいなと思って初めてPandasに手を出した時に、一番最初にお世話になった。ありがたい。

10ケースぐらいに分割して、写経->解答というパターンでかならず2回踏むことで、考える前に入力できるようになったら、圧倒的に徳を積み重ねることができた。

応用情報技術者試験ドットコム

応用情報技術者試験の試験問題をひたすら解くことができる。

お勧めの使い方は「過去問道場」-> 「分野を指定して出題」-> 「出題ジャンルを一点に絞り込み/計算問題を出題しない」を選択して、計100問ぐらいをわからなくていいので毎日解くことだ。

もちろん、これは最初から計算ドリルという使い方はできない。スルメ化により計算ドリルと化すまでには相応の時間がかかる。だが、中身の把握より先に「問題」と「解答」が分かった状態に至るころには、無味乾燥な解説に理解も追いつくはずだ。

さいごに

以上が計算ドリルの魅力と、それを体験できる書籍の紹介である。
もし他に計算ドリルのような体験ができる書籍があれば、教えていただきたい。

次は高瀬さんの土地勘に頼らずに地の利がある場所をみつける方法です。

秋のブログ週間2023の1日目です。

はじめに

※この記事やこの本を読んだからと言って自身で診断せず、まずは整形外科などの医療機関にて診断を受けて、医師の方と治療方針を決定しましょう。また既に治療中の方は、取り組む前に一度医師や理学療法士の方と相談しましょう。

腰が痛くて仕事にならない、プログラマーこそが天職なのにこの痛みと一生付き合っていかないといけないのか…と思っている方は結構多いのではないでしょうか？
かく言う自分も腰痛持ちで、20代前半で椎間板ヘルニアと診断されました。当時はヘルニアが神経を圧迫し歩くのもつらい時期もありましたが、通院によってなんとか回復しました。
しかし完全にはよくならず、残りの人生全てを腰を気にしながら生きないといけないのか、、、と絶望しておりました。

そんなこんなで腰痛人生を送ってきたわけですが、ケリー・スターレット式　「座りすぎ」ケア完全マニュアルは自分の人生を変える一冊となりました。
本記事では読書の秋・スポーツの秋にぜひ読んで頂きたい本書を紹介していきたいと思います。

本書の構成

本書は全7セクションに分かれていて、順序立てて姿勢を改善していく方法を紹介していきます。
また、本書は腰痛のみならずデスクワークが引き起こす全ての痛み（肩、首、腰）に対応しております。

• 姿勢の改善
  • Section1: 悪い姿勢がもたらすもの
  • Section2: アライメントが整い、安定した脊柱の重要性
• 運動の改善
  • Section3: 上手に動く～歩行、ヒンジ、スクワット、安定した肩～
• 習慣の改善
  • Section4: 立位ワークステーションのガイドライン
  • Section5: 座位のバイオメカニクスを最適化する
• セルフケア
  • Section6: 基本的な身体のメンテナンス
  • Section7: 全身の可動性改善の処方箋

Section1～3では、論文の引用も挟みつつ主に科学的な視点で悪い姿勢による身体への影響や、なぜこの姿勢・運動が良いのかを説明していきます。
Section4～5は、姿勢が悪くならないようにどうやって習慣を改善していくかについて説明していきます。スタンディングデスクを始めたい方は、Section4を読んでから環境構築すると効果を最大化できます。
Section6～7は、自分の現在地を知るための柔軟性テストに始まり、凝り硬まった身体に対してアプローチするためのストレッチ方法が紹介されています。もし、スタンディングデスクをやる気がない人でもこのセクションで紹介されている可動性改善メソッドは十分に読む・実践する価値がある内容です。

本書を新冊で買うと「”Know how”ではなく”Know why”が書かれた本」と記載された帯がついてくるのですが、まさにその通りの内容となっております。問題に対して「なぜ（Why）」が先に説明された後に「どのように（How）」アプローチしていくかが紹介されているため、理解を深めやすいです。

感想

丸くなった背中

ケリー氏は言います。

「食事の度にチョコレートドーナツを食べて、食後にタバコを1箱吸うことが長期的に健康に有益な影響をもたらさないことは直観的にわかるだろう。一方、姿勢に対しても同じレベルで直観が働かないことが問題なのである。」

姿勢の悪さを気にしている人って案外少ないと思います。というよりも多分気づかないんですよね。
これは恐らく、自分自身の姿勢が目に見えないからなんだろうなーと思っています。例え鏡を使ったとしても、正面から見た状態では自分の姿勢がどうなっているかなんてほとんどわからないですよね。
かく言う自分も人に言われるまでは、日常的に猫背でストレートネックな状態であることに気づきませんでした。

ケリー氏は姿勢の悪い状態を、この木と同じ状態であると表現します。

「この木は支えられていない。大雪は簡単にこの木を半分に折るか、川へと倒すだろう。」

本来、人体には重量に対して均一に吸収できるような分散システムが備わっています。しかし、姿勢が悪いことによって一部の箇所に重量を集中させてしまうことで酷使され、破綻を招いてしまうわけです。
エンジニアはシステムを設計するうえで、一部の箇所が過負荷に陥らないように負荷分散をさせることが重要だと認識していると思います。それと同じように身体の負荷分散にも目を向ける必要があります。

椅子に座るな、立て

この本で主張したいことはこういうことだろ？ と想像すると思いますが、まさにその通りです。
しかし、ただ立てばいいということではありません。姿勢良く立つ必要があります。
また環境によっては立って仕事ができない場合もあります。ケリー氏はこう言っています。

「結局は座る方法が重要なのだ。」

この本で一貫して主張していることは姿勢が良い状態を保ちましょうになります。
Section5に「座位のバイオメカニクスを最適化する」を設けているようにケリー氏は「椅子に座ること」に対して切り捨てているわけではありません。
また、スタンディングデスクを導入するだけでは姿勢の問題は解決に至りません。

姿勢を整える

ケリー氏はブレーシングシーケンスと呼ばれる以下の3つの要素によって構成された姿勢の整え方を紹介します。

• 腹式呼吸
• 殿筋（お尻の筋肉）の収縮
• 肩の外旋

スタンディングデスクを導入したうえで、ブレーシングシーケンスによって姿勢を整えることで問題の改善に兆しが見えてきます。
しかし、ケリー氏は厳しく言い放ちます。

（ブレーシングシーケンスは）少しの練習で習得可能である。問題は、習慣化できるかどうかである。何においても同じだが、実直な実践こそが習慣につながる。

私たちは正しい姿勢がDNAにプログラミングされており、一時的に取り戻すことは可能ですが、コンピュータのように初期化して取り戻すことはできません。
デスクバウンド（机に張り付いている）な社会において、長年積み重なった悪い姿勢を改善するには時間がかかります。常に姿勢のチェックを繰り返し、自然に染み込ませることで習慣化する必要があります。

立って仕事をするという選択

立って仕事をすることは、座って仕事をするよりもずっとよい選択である。なぜなら、立つことが運動への入り口となるからだ。

多くの人々は人生の大半を仕事に費やすこととなりますが、その時間のほぼ全てを立つことによって姿勢に良い影響をもたらすことが可能となります。またケリー氏が言うように、立つことが運動への入り口となり、日常に運動を取り入れることが更なる身体への好影響となります。

しかし、一日中同じ姿勢で立っていると非常に疲れますし、結局座位と同じで筋肉が同じ長さで凝り硬まってしまいます。そこでケリー氏は姿勢のルーティンを紹介します。ルーティンを取り入れることによって、筋肉を作用させ続け、身体の血流を保ち、一日中立っていることを可能とします。

セルフケア

より重要なこととして、そもそも組織が適応的に硬直して、機能不全となって最初に痛みを感じる前に、予防のために基本的なメンテナンスを行う方法を理解しなければならない。言い換えれば、腰部が痛んだり、股関節が硬くなったりするのを待つ必要はない。

痛みのあるなしに関わらず、予防としてのセルフケアストレッチは非常に有用なもとのなります。また、長時間のセルフケア時間を取る必要はなく、就寝前に10～15分程度行えばよいともケリー氏は述べております。
自分も就寝前に行っており、一日で硬まりきった身体をほぐした状態で睡眠に入れるため非常におススメです。

痛みがない生活を送り、間接と軟部組織が最適な状態になるように、戦略的かつ体系的なアプローチをとらなければならない。たとえば、腰部が痛む場合、その部位の軟部組織でフォームローラーを転がすだけでは、症状は回復しない。本当にこの問題を取り除くためには、計画的に、日常生活で脊柱のバイオメカニクスを改善して、（胸椎と股関節のような）腰部の上部・下部の部位にある軟部組織と間接制限も対象にすることを入れなければならない。

つまり、「痛みのある部位ばかりが問題ではない」¹ということを理解する必要があります。
最近フォームローラーがやたらと流行っていますが、痛みのある個所でコロコロやりがちです。結局、なぜその動きをするのか、なぜその姿勢をとるのかを理解していないと、自己満足コロコロで終わってしまいます。セルフケアを取り入れるには、まずHowよりもWhyを理解することが非常に重要です。

Section6では自身の可動性を確認するための、以下8つのテストを紹介しています。

• ディープスクワットテスト
• ピストルテスト
• ヒップヒンジテスト
• ソファーストレッチテスト
• オーバーヘッドテスト
• 肩の内旋テスト
• 足趾・足部テスト
• 手関節テスト

そしてSection7では上記のテスト結果に対する処方箋として、ストレッチ方法が紹介されております。どこが悪いかが分かったあとにちゃんと処方箋も用意されているため、すぐに改善へとつなげることができます。

バイオメカニクス、ライフスタイル、可動性

セルフメンテナンスを1日10分～15分費やすことは、潜在的な問題が本格的な炎症になるのを防ぐのに役立つ。しかし、セルフメンテナンスは痛みの解消と可動域の改善における一部分にすぎないことも同時に理解してほしい。可動性を高めることによる変化を持続させ、真の利点を得るために、さらに2つの要素－バイオメカニクスとライフスタイル－を扱う必要がある

しかしストレッチこそが銀の弾丸になるわけではないとケリー氏は釘を刺します。
ストレッチはあくまで硬くなった身体をほぐす役割であって、正しく動けない状態（バイオメカニクスが悪い状態）で、かつ座りすぎ（ライフスタイルが悪い状態）ではその効果が十分に発揮されないとケリー氏は述べています。また、そのような状態を穴の空いたタイヤに空気を入れ続けていると表現しております。まずは穴を埋めなければタイヤに空気は入りません。

硬いせいで、うまく動けないのか、うまく動かないから硬まるのか？

卵が先か、鶏が先かといった話に陥りますが、ケリー氏にとって答えは両方であると述べております。色々な複合要因から痛みが生じるのであって、1つ1つ紐解いていく必要があり、痛みを改善するには長い目で問題の根本を潰していく必要があります。週に1回マッサージに行ったからと言って痛みの問題は解決しないのです。

問題に対して論理立てながらアプローチしていくことが好きなエンジニアにとって、実は身体機能を理解して科学的に腰痛を改善するためのアプローチをとることは実は非常に相性がいいのではないかと思っています。

まとめ

硬まりきった身体を元の状態へ戻していくのは中々骨の折れるプロセスではありますが、地道にコツコツと続けていけば確実に成果が表れます。
自分も痛みが取れるまで2年くらいかかりましたが、今では趣味の筋トレにてBIG3²で腰を酷使しても問題ない状態にまで戻りました。
ぜひデスクワーク中の痛みを感じている方は一読してみてください。

Appendix

実際に立って仕事をしてみた

ここまで読んでスタンディングデスクをAmazonの買い物カゴに入れた方は一旦立ち止まりましょう。まずはスタンディングでの仕事を試してみて、買うかどうかを決めた方が良いと思います。

※手作りスタンディングデスクの恒久的な利用は事故の元となるため、一時的な利用のみに留めて下さい。ある程度利用の目途が立ったら専用デスクを買いましょう。

テーブルにこたつ机を設置することでスタンディングデスクを作ってみました。こたつ机の足には滑り止めがついており、ちょっとした揺れでは机がずれないようになっています。
実際1か月ほど、立って仕事をしてみたところ、

• 疲れる
  • めっちゃ疲れます。カロリー消費してる感。
  • かかとが痛い。
    • スリッパを履く or 抗疲労マット買うなど足裏を労わること大切
• 眠くならない
  • 同じ姿勢でいられないので、自然と体が動いて眠くならないです。
• 頭が冴える
  • 考え事をするとき歩き回れるので頭が働いている感あります。
• 姿勢を気にしやすい
  • 座っているときよりも姿勢が悪い状態に気づきやすい気がします。
  • 姿勢が悪くなったらブレーシングシーケンス

というのが実感です。
自分は初日から業務時間フルで立ってしまったために、ものすごく疲れて太ももパンパンでした。そのため、いきなり業務時間フルで立つ必要はなく、休み休みで身体を慣らしていく形がよさそうです。
また、昇降式デスクを買うかどうかは難しいところになります。ケリー氏も以下のように言っております。

座位・立位のワークスステーションに関するコーネル大学の研究によれば、（昇降式デスクを）導入して最初の数か月は立つが（おそらく、珍しいため）、次第に机を低くして、座ることに戻ってしまい、再び立たなくなってしまう傾向があることが示されている³

強制力がなくなると強い意志を持っていない限り、楽な状態をとってしまうのが人間です。こうなると値段の高い机だけが残ってしまいます。
これらを考えると、下げることのできないスタンディングデスクと座面の高い椅子を用意したほうが安く済んで、なおかつ立って仕事をする習慣が続くのではないかなーと思います。

秋のブログ週間2023の1日目でした。次は山本さんの時を駆けるモバイルアプリUI設計です。

また、本記事のイラストはすべてDALL-E 3によって生成したものとなります。