ブログ

  • 情報整理ツールObsidianの紹介

    情報整理ツールObsidianの紹介

    IT業界に限らず、普段PCを使って作業している方はメモを取ったり、情報をまとめるためのツールを何かしら使っている方が多いかと思います。
    私の場合、2年ほど前からObsidianというツールを愛用しています。今回はObsidianの魅力について紹介します。

    https://obsidian.md

    Obsidianとは

    詳細な情報は公式サイトやWikipediaなどを参照ください。

    ざっくり言うと、Markdown専用のエディタ、及び情報整理用ツールです。ファイル単位で簡単に相互リンクを付けたりタグを付けたりすることができます。

    Notionとの使い分け

    Obsidianに出会う前は、情報を蓄積・整理するツールとして主にNotionを使用していました。

    https://www.notion.com/ja

    Notionは使いやすい上にできることが多く、汎用性も高くで非常に便利です。そのため、今でも目的によってはNotionを使うことも多いです。私の場合、チーム間で情報共有したいときや、複数人で共同編集したい資料作成ではNotionを使うことが多いです。また、複数のデバイスで情報を共有したい場合(PCとスマホでの情報共有、WindowsとMacでの情報共有など)にもNotionを使います。

    一方で、他人には共有しない、自分用のメモや資料の作成が目的で、かつローカルのPCだけに情報が閉じられていても問題ないような情報の整理は主にObsidianを使っています。

    Obsidianの魅力

    Markdownの書き心地が抜群

    私がObsidianを使う一番の理由は、Markdownの書き心地が他のツールに比べてダントツで良いと感じるからです。

    ソフトウェアの開発に関わる方であれば、資料を作ったりメモ取る際にMarkdown記法を使う人も多いことかと思います。Markdown記法は今では様々なツールやサービスでサポートされており、VS Codeのような開発用エディタやNotionなどのツールもMarkdownで書くことは可能です。

    ただ、ObsidianはMarkdownに特化したエディタというだけあって、他の開発用エディタやNotionと比較しても非常にMarkdownの書きやすいです。
    「書き心地」というのは言葉ではなかなか表現がしにくく、使ってみれば分かる、という感じです。
    あくまでも個人の感覚なので、人によっては他のツールの方が書きやすいと感じる方もいるかと思いますが、日ごろからMarkdownを書く機会が多いけれど、Obsidianを使ったことがないという方は、ぜひ一度使ってみることをお勧めします。

    カレンダー機能が便利

    1日のほとんどをPCで作業している方は、日単位でメモを分ける人も多いかと思います。私自身、メモを取ったり情報を整理する際は日単位で区切って整理することが多いです。

    • 1日やること(やりたいこと)のTODOリスト
    • その日作業の中での学びや作業ログ
    • 打ち合わせのメモや議事録
    • 報告書類系の下書き

    私の場合、上記にあるような情報を日単位でファイルを作成して整理していくことが多いです。

    メモ帳やVS Codeなどのエディタを使ってメモを作成する場合は、日ごとに新しいファイルを作成するし、日付でファイルを入力する必要があります。
    Notionの場合はカレンダービューを使うことで日単位での情報整理やしやすくなりますが、毎日新しくページを作成する必要があり、それが個人的に若干手間に感じたりします。

    Obsidianは、ツールを起動するとサイドメニューの一番上にカレンダーマークがあり、このマークをクリックすることでその日の日付がファイル名になるメモが自動的に作成されます。
    この機能があることで、日単位で情報を整理することのハードルがかなり低くなります。
    人によってはそれほど重要な機能には感じないかもしれないですが、日ごとにメモを作成する習慣がある人にとっては、地味に便利な機能で、私はこの機能を重宝しています。

    タグをつけるという発想

    Obsidianでは、メモはファイル単位になります。
    そして、ファイルに対して好きなだけタグをつけることができます。タグをつけると以下のようになります。

    情報(ファイル)に対してタグ付けしておくことで、タグによる検索やタグの数を集計したりすることが可能になります。

    このタグを付けるという発想が、個人的には画期的な発想だと思いました。
    タグという概念自体は、自体はSNSなどで情報発信する際に付けるものとして一般的になっており、特に目新しいものではありませんが、自分自身の整理用のメモに対してこのタグをつけられると非常に便利だと感じています。

    なぜタグが便利かというと、タグがあることによってフォルダ構成を意識する必要がなくなるからです。

    階層構造の問題点

    一般的にファイルで情報を管理する場合、カテゴリ単位でフォルダを作り、ファイルをフォルダに振り分けることで情報を整理します。例えば、Windowsの場合デフォルトでビデオ、ミュージック、ピクチャ、ドキュメント、のようにファイルの種類単位でのフォルダが用意されていたりします。

    そして、1つのフォルダに対してファイル量が多くなった場合、フォルダを入れ子にして階層構造にすることで情報を整理していきます。入れ子構造にできるフォルダの概念は便利ですが、内容によってはどのカテゴリに分類すべきか判断が難しい場合があります。そして、どこに格納すべきか迷う情報が増えると、結果として求めているファイルを探すのが困難になってしまいます。
    Notionはファイルという単位を意識しなくても良いのが強みですが、階層構造でページを作成するので、情報を整理する際はカテゴリ分けを意識する必要がある点はフォルダによる整理と同じ問題を抱えます。

    一方で情報に対してタグをつけて整理しておけば、後から情報を探したいときにタグで探すことができるので、フォルダ構成を気にする必要がありません。
    (一応Obsidianでもフォルダを分けて整理することはできますが、タグがあるおかげでカテゴリ分けをきっちり行う必要性があまりないと感じています。)

    親クラスの継承か、インターフェースの実装か

    この部分は、この記事を書きながらふと思ったこと。(少し話が逸れます。)
    階層構造で分けるか、タグをつけるか、という違いは、オブジェクト指向でいうところの親クラスの継承かインターフェースの実装かの違いに似ている気がします。

    言語にもよりますが、基本的に多くのオブジェクト指向言語では多重継承は禁止されており、1つの親から継承することしかできません。一方、インターフェースであれば複数の実装が可能です。継承は1つの親からしかできないという制約があるため、実際の開発ではインターフェースの方が便利に使えることが多いです。
    ファイルも、基本的に1つのフォルダにしか格納することができない(リンクを作れば別ですが)です。この制約はオブジェクト指向における継承と似ています。

    その他の機能

    Obsidianは他にも色々な機能があります。
    ファイルごとに相互リンクを簡単に作ることができ、相互リンクのグラフを見れる機能があります。

    また、拡張機能をインストールすることでカスタマイズしていくことも可能です。

    ただ、この辺りは私自身便利に使いこなせている自信がないので、詳細は割愛します。気になる方は使いながら色々調べて試してみてください。

    AIとの相性

    生成AIを使用する際、テキストデータはAIとの相性良いです。また、生成AIに対する指示(プロンプト)はMarkdownで書くことが多いです。

    Obsidianで作成される情報は実態がすべてテキストデータ(拡張子.mdのMarkdownファイル)なので、その点で生成AIとの相性が良いです。AIエディタであるCursorとの連携や、最近だとGemini CLIとの連携についてまとめられた記事をよく見かけます。

    Obsidianで情報を整理することに慣れておくと、結果的にAIと連携したい場合に有利に働くこともあるかもしれません。

    バックアップと同期に関する補足

    Obsidianは基本的にローカルで閉じた環境での情報整理として使うのに適していますが、バックアップを取ったり、複数のデバイスで共有したい場合もあるかと思います。そこで簡単に補足しておきます。

    有料ライセンス

    まず、Obsidianは基本的に無料で使うことができますが、有料のライセンスもあります。有料のライセンスがあれば、複数のデバイスで同期するための機能が使用可能になり、PCとスマホ間で同期することもできるようになります。

    スマホでも入力して、異なるデバイス間で同期を取りたいという方は検討してみても良いかと思います。

    フォルダのバックアップ

    Obsidianのツール上から見える情報の実態は全てMarkdownファイルとしてローカルに保存されています。そのため、単にバックアップを取っておきたいだけあれば、Obsidianのデータが格納されているフォルダごとコピーすればバックアップが取れます。

    GitHubとの連携

    Obsidianは、情報が全てテキストファイルとして管理されているため、Gitとも相性が良いです。Obsidianのデータが格納されているフォルダにGitリポジトリを作成し、GitHubなどのリモートリポジトリと連携することで、バージョン管理しながらクラウドにバックアップしておくことも可能です。
    Gitの拡張機能もあり、定期的に自動コミット・プッシュしてくれるように設定しすることも可能です。GitHubのリポジトリにデータをプッシュしておくことで、間接的に複数の端末で情報を共有することも可能になります。

    まとめ

    • ObsidianはMarkdownエディタ
    • Markdownの書き心地が非常に良い
    • 日単位の情報整理がしやすい
    • タグによる情報整理ができる
    • 他にも機能多数
    • GitやGitHubの設定をしておくとより便利

  • Pagefindを使って静的Webサイトの検索を実現する

    Pagefindを使って静的Webサイトの検索を実現する

    このブログサイトでは、ヘッダー部の右側に検索窓があり、ブログ記事の内容をキーワード検索(あいまい検索)することができます。この検索はPagefindというライブラリを使って実現しています。今回はこの検索ライブラリPagefingについて紹介します。

    ブログの戦略

    この自社ブログ(オウンドメディア)では、今後も技術的な内容の記事を多数投稿していく予定です。技術的な内容の記事を投稿していると、どうしてもキーワード検索の機能を付けたくなります。

    一般にキーワード検索というと、入力されたキーワードをもとにDBなどから対象のコンテンツを検索し、検索結果の一覧を表示するような、動的なWebアプリケーションを想像します。

    一方、このブログサイトはWordPress + Astroという技術構成で開発しており、サイト自体はAstroによる完全な静的Webサイトとしてデプロイされています。

    なぜこのような構成にしたかというと、

    • 使ったことのない技術(ここではAstro)を学びたい
    • パフォーマンスの最適化を考えて静的Webサイトでデプロイしたい
    • 今後のSEO対策も考慮し、静的Webサイトにしたい

    というのが主な理由です。

    Pagefindとの出会い

    静的Webサイトとしてデプロイしているブログに対して、検索結果のページだけ動的なサイトにするのはちょっと避けたい(技術的できない訳ではないですが)。

    ということで、静的Webサイトでありながら、サイト内の検索ができる方法がないかを探っていたところ、開発メンバーの一人がPagefindというライブラリを見つけてくれました。

    https://pagefind.app

    そして、別のメンバーが早速そのライブラリを組み込んで検索機能を実装してくれました。(つまり私は実質なにもしていない。。)

    その結果実現したのが、ヘッダー部にある検索窓での検索です。

    導入方法と仕組みの概要

    詳細な仕組みや導入方法などは公式サイトをご覧ください。

    ざっくりの導入手順は以下。

    1. プロジェクトにPagefindをインストール
    2. ライブラリで提供されるPagefindUIを組み込んでWebページに検索窓を追加
    3. 検索用のindexを作成するコマンドを実行

    Astroと組み合わせる場合は、`astro build`を実行してWebページを生成した後に、Pagefindのindex作成コマンドを実行することで、検索が可能になります。

    PagefindのindexはHTMLファイルに対してしか作成されないため、一般的な動的Webアプリケーションや、SPAでは使用できません。

    実装の所感

    (他のメンバーがかなり実装してくれましたが、、)思ったよりも簡単に実装できた印象です。

    導入時、何も設定をしていない状態だと、全てのページが検索対象になってしまったので記事の一覧が並んでいるトップページも検索対象となっていましたが、検索対象外にしたい要素にも特定の属性を付けることで簡単に検索対象から外すことができました。

    UIに関してはライブラリが用意されたものを使用する形になりますが、`PagefindUI`に多数のプロパティが用意されており、ある程度カスタマイズすることは可能です。

    CSSに関しては上書きで適用するのに多少苦労しましたが、ディベロッパーツールで要素を解析しながら調整することでデザインも調整可能でした。

    個人的には全体的にハードルが低くて扱いやすい印象でした。

    余談

    個人的な話になりますが、私は以前プログラミング講師をしていた時期があります。その時に、教材となるテキストをマークダウンファイルで作成し、スクリプトでHTMLに変換してWebサイトとして教材を展開していた時期があります。

    この時も、テキストの量が多くなって検索機能を付けたくなりました。ただ、そのころは静的Webサイトとしてコンテンツを検索する良い方法が分からず、結局RDBにコンテンツを全て格納してSQLであいまい検索する方法を取りました。

    この時はまだPagefindのライブラリはリリースされていなかったと思いますが、あの時期にPagefindに出会っていれば検索の実現が格段に楽だったのになーと思わずにはいられませんでした。

    まとめ

    • Pagefindは静的Webサイト内でコンテンツをあいまい検索できるライブラリ
    • Astroのような静的Webサイトを生成するフレームワークと相性が良い
    • レンダリングのパフォーマンスやSEO対策などの関係で静的Webサイトにしたいが、サイト内での柔軟な検索を実現したい場合におすすめ

  • OGPを使ってリンクを良い感じに表示する

    OGPを使ってリンクを良い感じに表示する

    リンクを良い感じに表示したい

    SNSやブログ、チャットツールなどでリンク(URL)を張り付けると、リンク先のページを開かなくても概要が良い感じに見えるようなサービスやツールが多々あります。

    例えば、SlackではチャットにURLを張り付けて投稿すると以下のようなプレビューが表示されます。

    このブログはWordPress + Astroという技術を使って自社で開発・運用しているブログサービスになりますが、技術ブログをメインに執筆するにあたって、リンクを共有したくなるケースが多くなることが予想されます。

    しかし、Wordpressの標準機能だけで記事投稿をすると、リンクを張り付けてもAstro側ではただのリンクとしてしか扱われず、上記のようなリッチなプレビュー画面は表示されません。

    そこで、自分たちのブログでもこのようなプレビューが見れる仕組みを作ることにしました。開発する中で個人的に色々と学びもあったため、この記事で共有していきたいと思います。

    OGPとは

    そもそもどうやってあのようなプレビューを実現しているのか、私自身に全く知識がなかったのですが、調べているとどうやらOGPという技術(仕組み)を使っているらしいことが分かりました。

    OGPはAIの解説によると

    OGP(Open Graph Protocol)とは、Webサイトの情報をSNSでシェアする際に、表示されるタイトル、説明文、画像などを制御するための仕組みです。

    とのこと。

    具体的には、HTMLのmetaタグを使って以下のように設定します。

    <meta property="og:title" content="記事のタイトル">
    <meta property="og:description" content="記事の説明文">
    <meta property="og:image" content="記事のサムネイル画像のURL">
    <meta property="og:url" content="記事のURL">

    どうやってプレビューを表示するか

    リンクを共有される側のWebページとしては、OGPのための設定はmetaタグにOGP情報を設定するだけです。

    SNSやチャットツールがどうやってプレビューを表示しているのかというと、リンクのURLからWebページ情報(OGP情報)を取得し、その情報をもとにプレビュー用の要素を作成して表示しているだけのみたいです。

    仕組みを知る前は一体どういう仕組みなのかと疑問でしたが、知ってしまうと案外シンプルな仕組みで実現しているのだなと思いました。

    実装してみた

    仕組みが分かれば、後は実装するのみ。実装前、リンクを張り付けた場合の見た目は以下のようなものでした。



    そして、OGPに対応したプレビューを実装したのが以下。



    かなりいい感じになりました。

    OGPによるプレビュー表示の課題

    OGPの仕組みによってリンクをいい感じに表示できるようになりましたが、課題を感じた点もありました。

    ビルド時間の増大

    このブログサービスは、WordPressで記事を作成した後、Astroのビルドによって静的Webサイトを生成し、デプロイします。

    ビルド時にWebページ情報を生成する仕組み上、OGP情報を取得する処理もビルド時に実行されることになります。今はまだ記事数が少ないこともあり、ビルドにそこまで時間はかかりませんが、記事数が多くなり、リンクの数も増えていくとその分だけビルド時間が増えていくことが予想されます。

    いずれ、何らかのタイミングでビルドの仕組みを再検討する必要が出てくるかもしれません。

    Amazonのリンク対応

    OGPによるプレビューを実装したのちに、Amazonから商品のリンクを張るとどう見えるか確認してみると、求めている情報がうまく表示されませんでした。

    実際にAmazonのWebページを見てみると、OGP情報が設定されたmetaタグは存在しています。不思議に思ってもう少し調べてみると、どうやらAmazonではWebページを表示後にJavaScriptによってOGP情報を後から生成しているらしいとのこと。

    そのようなWebページの場合、ページがレンダリングされてOGP情報が生成された後に情報を取得しにいくか、Amazonが提供するAPIを使って取得する、などの対応が必要らしいとのこと。どちらもそれなりの手間がかかることもあり、現状は未対応ですが、このようなWebページもあると知れたのは、一つ勉強になりました。

    まとめ

    今回はOGPという仕組みについてでした。日ごろから何気なく見ていた、SNSやチャットツール上でもリンクのプレビューがどのような仕組みで実現されているのか知ることができ、勉強になりました。

  • UIライブラリを導入する際の注意点

    UIライブラリを導入する際の注意点

    WebアプリケーションのUIを実装する際、UIライブラリを使用すると、す来ない開発コストでリッチなデザインを作成することができます。

    UIライブラリはフロントエンドのフレームワーク毎に用意されていることが多く、Vue.jsの場合はVuetifyやElement Plusなどがあります。React.jsの場合はMaterial UIなどがあります。
    これらのUIライブラリは非常に便利な反面、いくつかのデメリットもあり、導入には注意が必要です。UIライブラリの導入を検討に参考になるよう、UIライブラリのデメリットについて解説します。

    デメリット1:E2Eテストのハードルが上がる

    E2Eテストとは、End to Endテストの事で、エンドユーザーが使用することを想定したテストのことです。Webアプリケーションの場合、ブラウザを使って各ユースケース毎の操作を確認することがE2Eテストになります。

    E2Eテストのためのフレームワークは色々とあり、有名なものだとSeleniumやCypress、Playwrightなどがあります。
    ブラウザを自動操作するテストでは、Webページの要素を取得して入力やクリックなどの操作をプログラムで制御することになります。
    ブラウザを自動操作するフレームワークでは、多くの場合CSSセレクターの要領でWebページの要素を取得します。

    例えば、以下のようなHTML要素があったとします。

    <input type="text" name="email" id="email" class="email">

    Cypressの場合は以下の書き方で要素の取得ができます。

    cy.get('#email')  // idによる取得
    cy.get('.email')  // class属性による取得
    cy.get('input[name="email"]') // name属性による取得

    HTML標準のタグを使って実装する場合は、CSSセレクターの知識があれば比較的簡単に要素を取得してWebページを操作することができます。

    しかし、UIライブラリを使用すると、この要素の取得が格段に難しくなります。

    分かりやすい例だと、セレクトボックス(プルダウン)があります。
    HTML標準のタグで実装する場合は、selectタグを使うことが一般的かと思います。

    Vuetifyの場合だと、v-selectコンポーネントがあります。

    https://vuetifyjs.com/ja/components/selects

    以下は公式サイトのサンプルコード。
    これだけのコードで見た目がかなりリッチなデザインになるので、とても便利に感じます。

    <v-select
      label="Select"
      :items="['California', 'Colorado', 'Florida', 'Georgia', 'Texas', 'Wyoming']"
    ></v-select>

    しかし、実際にレンダリングされた要素をブラウザのディベロッパーツールなどで見てみると分かりますが、div要素が深く入れ子になっており、かつselect要素は使われていません。(実態としてはinput要素が使われています)
    このような要素をプログラムで取得して操作しようと思うと、実際にレンダリングされた要素の構造を調べたりする必要があり、時間がかかる上、テストコードの可読性や保守性も低くなってしまいます。

    デメリット2:スタイルの自由度が下がる

    開発のスピードを速める代わりに自由度が下がるというトレードオフは、UIライブラリに限らず、ほぼ全てのフレームワークやライブラリの特徴と言えます。

    UIライブラリの場合、最初から多くのスタイル(CSS)が適用された状態になっており、スタイルを変更しよう思ってもうまく適用されなかったり、どのクラスに対してスタイルを適用すべきかが分かりにくいケースが多々あります。
    また、強制的にスタイルを変更しようと思うとUIライブラリによって自動的に付与されているクラス属性に対してスタイルを適用しなければけないケースもあり、コードの認知コストが高くなってしまいます。

    UIライブラリを組み合わせることで求めていたUIデザインが作れるのであれば問題ありませんが、デザインに対して多くのカスタマイズをしようと思うと、それなりに大変です。

    デメリット3:バージョンアップやライブラリ切り替え時のコストが大きい

    UIライブラリもライブラリである以上、バージョンが古くなったりサポートが切れてしまう事があります。その場合はバージョンアップをしたり別のUIライブラリに切り替える必要がありますが、バージョンアップで仕様が大幅に変わった場合や、別のライブラリに移行する場合、元のデザインが大きく崩れてしまう可能性が高いです。
    そうなってしまうとバージョンアップやライブラリの移行に想定外の開発コストがかかる可能性があります。

    まとめ

    UIライブラリのデメリットばかりをピックアップしてしまいましたが、デザインやCSSに対して高度な知識がなくても短期間でリッチなUIデザインを作れるのは大きなメリットです。

    メリットとデメリットを認識したうえで、プロジェクトの特性、プロダクトの特性などを踏まえてUIライブラリの導入を検討するのが良いのかなと思います。
    Webサイト・Webアプリ全体の統一感をうまくコントロールできるのであれば、部分的にUIデザインを導入するという選択肢もありかもしれません。

    終わりに

    以前、個人的にReactを使ったWebアプリを開発していたことがあり、その時にMaterial UIを使って実装していました。実装中は非常に楽で便利だと感じていたのですが、後になってE2Eテストを作りたくなって実装を始めてみると、UIライブラリがテスト実装の大きなハードルになることに気づきました。それ移行、Webアプリを開発する際、UIライブラリ導入に対して慎重に考えるようになりました。

    また、自社内にVue.jsのバージョンアップ(Vue2 → Vue3)の案件に関わっているメンバーがいるのですが、そのメンバーもUIライブラリに苦しめられています。Vueのバージョンアップに伴ってUIライブラリのバージョンも上げる必要があるそうなのですが、その影響範囲が思いのほか大きくVueバージョンアップの障壁になっているとのことでした。E2Eテストを作成しておけばバージョンアップ時のデグレは検知しやすくなりますが、UIライブラリ自体がE2Eテストのハードルも上げてしまうため、結局のところUIライブラリがバージョンアップ全体に関して大きな障壁となっているようです。
    (この辺りの詳細はいずれ当事者のメンバーが別の記事で書いてくれることを期待)

    以上、UIライブラリを導入する際の注意点についてでした。
    Webアプリケーションのプロジェクト立ち上げ時などの参考になれば幸いです。

  • 沖縄事業所について紹介します

    沖縄事業所について紹介します

    どうも、テクノコアの岸本です。
    今回の記事内容は、沖縄事業所についてです。

    弊社は東京都神田に事務所を構える東京の企業なのですが、2024年7月から開発センターとして沖縄事業所が設立されました。私は現在、沖縄事業所のメンバーとして働いています。

    実は、私がテクノコアに転職したのが2024年の7月で、元々私が沖縄に住んでいたこともあり、転職のタイミングで沖縄事業所が設立されました。

    8月からは事務所も構え、現在は宜野湾市に事務所があります。現在のメンバーは私を含む2名体制です。メンバーが2名ということもあり、事務所自体はそれほど大きくありません。

    仕事内容や雰囲気

    沖縄事業所メンバーは2人ともエンジニアとして開発の仕事をしています。ただ、今現在はお互い別々の案件(どちらも東京の案件)に関わっており、それぞれが案件メンバーや顧客とリモートでコミュニケーションをしながら作業しています。

    案件が別々ということもあり、同じ仕事を一緒に進めることはありませんが、開発の仕事で悩み事や課題があればお互いに共有して相談することも多いです。
    案件は別ですが事務所は小さくて物理的な距離も近いので、仕事の内容以外でもしょっちゅう時々雑談も交えながら、お互い気ままに開発の仕事をしています。

    悩み

    沖縄事業所で今一番の悩みは、近くにご飯屋さんが少ないこと。
    歩いていける距離だと食堂が1件、ラーメン屋が1件、後はコンビニかスーパーか弁当屋さんくらい。(意外とある?)
    昼休憩は2人で一緒にランチに行くことも多いですが、徒歩圏内だとバリエーションが少ないので、車でどこかへ出かけることもしばしば。

    今後徒歩圏内でいい感じのカフェなどができてくれると嬉しいです。

    本棚の紹介

    沖縄事業所メンバーは2人とも読書が好きです。仕事に関係する技術書から、仕事とは直接関係のない本まで、様々な本を読んでいます。

    2人とも自分で買った本を事務所に持ってきて、空き時間に読んでいることも多く、気づけば事務所にそれなりの量の本があります。

    以下は実際の沖縄事業所の本棚の写真。

    (正直、読み終えた本よりも読みかけの本の方が多かったりするのですが。。)きっとこれからも本が増えていくのではないかと思います。

    沖縄事業所で盛り上がった本

    読んだ本の内容や感想はお互いアウトプットして議論したりしながら、日々お互い学びを深めています。同じ本を読んで、お互いの意見を共有しながら学びを深める輪読会をすることもあります。

    2人とも読んで特に感想が盛り上がった本をいくつか紹介。

    #100日チャレンジ

    大学生がChatGPTを使って100日連続でアプリを作り続ける中で、プログラミングスキルを身に付け成長していく実話ベースの物語。

    AIは開発の仕事をする中で日々活用していますが、この本を読んでAIの活用法やAIを使った学習法という観点で、すごく刺激を受けました。

    自分とか、ないから

    この本は元々書店で見かけて少し気になってはいたのですが、以前とあるカンファレンスの動画を観ていた際に登壇者の方がおすすめされていたので、それをきっかけに購入して読みました。

    内容はすごい読みやすい(普通に読みながら笑えるくらい面白い)ですが、普通に学びになることも多く、ちょっとだけ悩みが減るような気もする、そんな感じの本。

    もう一人のメンバーにおすすめしたらすぐに読んでくれました。その後しばらくの間、沖縄事業所は東洋哲学がブームになりました。

    おわりに

    今回はテクノコアの沖縄事業所について紹介しました。少しでも雰囲気が伝われば幸いです。

    今はまだ2名体制の沖縄事業所ですが、一緒に働いてみたい方がいれば大歓迎です。少しでも興味がある方はHPのリクルートからお気軽にご応募くださいませ。

    https://www.techno-core.jp/recruit

  • テックブログをはじめました

    テックブログをはじめました

    テクノコアの岸本です。
    この度、自社でオウンドメディア(ブログ)を作成しました。ここでは一発目の記事として、自社ブログを作成するまでに至った経緯と、技術選定、リリースに至るまでの経緯について書いていきます。

    テックブログ作成の経緯

    ブログを始めた経緯としては、主に自社ブランディングと技術力向上の2つです。

    自社ブランディング

    ブログを作成した一番の目的は、自社のブランディングです。
    我々の企業では大きく2つの事業があります。1つが、IT企業向けの新人研修など、教育に関する事業を展開している教育事業部。もう1つが、システム開発に携わるシステム事業部。

    システム事業部は主にSESを中心とした開発部隊となっていますが、昨年度から本格的に受託案件の開発も行っています。私自身、現在は受託案件の開発に携わっています。今後、受託案件の件数を増やし、開発メンバーも受託に関われるメンバーの比率を上げていきたいと考えていますが、そのためには会社の知名度を上げていくことも必要になるので、その手段の1つとして自社ブログを作成することにしました。また、会社の知名度を上げることで、開発案件以外でも研修事業や採用の活性化もにつなげたいと考えています。

    技術力向上

    今後、受託開発を増やしていきたいという思いはあるものの、現在社内でインフラ技術に詳しい人の数が限られています。そこで、今後に向けた技術力強化の側面も兼ねた取り組みをしたいという思いもあり、インフラを含めた形で、自前でブログサービスを構築することにしました。

    技術選定

    以下は、ブログ開発で使用した主な技術・サービスの一覧です。

    • AWS(Amazon Web Services)
      • EC2
      • CodeBuild
      • S3
      • CloudFront
    • WordPress
    • Astro

    WordPress + Astro

    まず、ブログサービスを完全に一から作成するのは開発コストがかかりすぎるので、既存のCMS(Contents Management System)も活用することにしました。CMSとしては、日本で最もメジャーで情報量も多いという理由から、無難にWordPressを選択しました。

    ぶっちゃけ、WordPressを導入してしまえばそれだけで完結するブログサービスを構築することは可能です。ただ、そうしてしまうと、インフラ環境はほぼEC2だけで完結してしうので、インフラの学習機会が減ってしまいます。また、開発に関してもWordPressに特化した開発スキルしか身につかず、限定的な技術力向上にしかなりません。

    そこで、WordPressは記事の投稿・管理の機能だけを使用し、外部のユーザー向けのフロント画面は別のフロントエンド技術で開発することにしました。
    このブログは自社ブランディングも兼ねているため、今後はSEO対策も進めていく必要があります。SEO対策という観点では、静的なWebサイトの方が有利に働くことが多く、かつレンダリングのスピードも速い方が良い。
    そう考えた時に、Astroが最適なのでは?という話になりました。個人的に気になっていた技術でもあったので、開発の学習も兼ねてAstroを選択することにしました。

    https://astro.build

    インフラ環境

    まず、WordPressはEC2に環境を構築しました。EC2でWordPressを構築する手順は、AWSの公式ドキュメントにもチュートリアルが載っているため、ドキュメントに従って構築すればそこまで苦労せずに構築することができました。

    https://docs.aws.amazon.com/ja_jp/linux/al2023/ug/hosting-wordpress-aml-2023.html

    記事を投稿する際には、WordPressの記事投稿画面から記事を投稿します。
    その後、CodeBuildでビルドを実行すると、Astroプロジェクトがビルドされます。この時、AstroはWordPressのAPI経由で記事を取得し、静的Webサイトを生成します。生成されたWebサイトはS3に配置し、CloudFront経由でアクセスできるようになります。

    デプロイのフローは以下のようになっています。

    開発の進め方

    環境構築、及び開発は私を含む3人チームで進めました。
    週に1回、2時間程度リモートで集まる時間を作り、Discord上で会話しながら画面共有ベースで作業していきました。タスク管理や仕様の整理にはNotionやFigJamを使用し、開発時はVS CodeのLive Shareや、WebStorm(JetBrains製品)のCode With meを使ってモブプロ形式で進めました。

    開発メンバーの中にインフラに強いメンバーと、フロントエンドの開発に強いメンバーが1人ずついたため、作業を進めるときにはそれぞれの得意分野が活かされて比較的スムーズに開発を進めることができました。また、画面共有ベースで作業を進めたため、それぞれが苦手分野についてもすぐに解説を得ることができ、学びを得ながら進めることができました。

    まとめ

    ブログ環境の構築、開発について経緯や概要をまとめました。
    ブログの開発に関してはここで紹介した以外にも細かい技術を色々と利用した箇所もありますし、まだまだやりたいこともあったりします。
    この辺りは機会があれば別の記事でご紹介できればと思います。

    システム開発、新人研修、採用に関して気になることがあればお気軽にご連絡ください。