技術広報の941です。カケハシはPyCon JP 2024にスポンサーをし、ブースにて「カケハシ式、チャートでわかるふりかえりの技法」という冊子を作成し配布しました。普段はデータばかりを取り扱っているので、本というリアル媒体に関わることが少ないためなかなか苦労しました。 実際に配布した冊子 この記事では、イベントで配布するための冊子を印刷するためのデータ(組版といいます)を、Google Docsで作成する際に気をつけるべきポイントについて共有したいと思います。 この記事は秋の技術特集 2024の19記事目です。 組版とは Google Docsで作成するメリット Google Docsで作った組版データでハマりやすいポイント 入稿時に気をつけたいポイント 組版とは 文字や画像や表などの要素を配置して、読みやすく視覚的に効果的なデザインに仕上げる技術やプロセスのことを組版といいます。主に印
走り書き。根拠はない。 まだ小さな開発チームなので社内のプルリクエストを流し読み程度に全て見るようにしている。コードの品質は人によってさまざまあるのは当然だが、仕様の理解度に差があるように感じている。それは人によって異なっていて、常に理解度の高い人と低い人がいる。 仕様を読むためには、主に3つの要素があるのではないかと考えた。 前提知識 環境要因 完成の定義 前提知識 システム開発だと0から作ることは少なく、多くの場合は追加開発になる。要求は何か、既存のシステムがどうなっているか、技術的に何が使われて何を使えばいいのか、がわかっている必要がある。 例えば、「ルービックキューブに黒い面を追加する」という追加開発があったとする。要求は「他の6面と同様な7面目を追加する」ということになり、既存のシステムは「3x3マス、立方体の組み合わせ、回転できる」等である。技術的な部分は「回転機構、各パーツの
R Markdown RではR Markdownでコードを記述することで、データ解析の結果、データ解析に使われたプログラム、解析プロセスの説明等をHTMLやPDFなどのフォーマットでレポート化することできる。他人に解析結果と解析方法を共有する場合に大変便利な機能だが、ここではR Markdownで美しいレポートを作るためのTipsをまとめようと思う。 R Markdownの基本的な記法や使い方は以下のページがわかりやすいです。 kazutan.github.io R Markdownに関する大体の情報は基本的には以下のページに網羅されているので、こちらもご参照ください。 bookdown.org 1. テンプレートを使う rmdformatsやprettydocといったパッケージが美しいデザインのテンプレートを用意しておりオススメ。rmdformatsだけでも>5種類のレイアウトが用意され
はじめに 私は GitHub のリポジトリごとに、そのプロジェクトで得た学びや知見を Markdown で記録しています。README にプロジェクトの概要を書き、docs フォルダに技術的な詳細やトラブルシューティングの記録を残すといった具合です。 しかし、これらのドキュメントが各リポジトリに散在していると、過去の学びを探すのが大変です。「あの実装方法、どのプロジェクトに書いたっけ？」となることもしばしば。 そこで、GitHub に蓄積した Markdown ドキュメントを 同じく GitHub 上で管理しているObsidian のナレッジベースに自動集約する仕組みを作りました。GitHub Actions を使って毎日自動的に全リポジトリから Markdown を収集し、Obsidian で横断的に検索できるようにしました。 構成図 毎日 3:00 (JST) または手動実行により、G
本記事は、#IVRy_AIブログリレー の 9 月 8 日（6 日目）の記事です。昨日は、インサイドセールスののすけさんが「若手3人が語る！成果を加速させるインサイドセールス×AI活用の最前線」という記事を公開しました。 ブログリレーの記事一覧は「IVRy AIブログリレー全記事まとめ」をぜひご覧ください。 1. なぜ今 Design Doc x AI なのか みなさんご存知のように最近の LLM の進化により、エンジニアリングの現場は劇的に変化しています。 Claude Code や Cursor、Codex といったツールの登場により、実際のコーディング作業の多くを AI に移譲できるようになってきました。社内でも「ほとんどコードを書かずに日本語で指示を出すだけ」という声が上がるほど、開発体験は根本的に変わりつつあります。 一方で、この変化は新たな課題を生まれています。AI が生成する
以前の記事で「なんか案件降ってこないかなー」と書いてみたのを知って知らずか、WEBサービスの企画およびシステムの設計を裏表どっちもやるトンデモ案件が降ってきてしまってちょっと更新が止まってしまってました・・・。楽しいから良いのですが、フォトショを起動してる時間よりパワポを起動してる時間の方が圧倒的に長いので、そろそろ自分がWEBデザイナーである事を忘れつつあります・・・。しかし、そんなある日、システム部の方々と共同で企画書作りをしてふと気付いた事があります。ノンデザイナーの方々ってわざとやっているのかというくらい企画書の体裁や見た目には全く頓着しないのだという事です。文字サイズは全部一緒、改行位置も要素の配置もめちゃくちゃ・・・。これは勿体ない。とても勿体ないです。 いくら優れた企画力や専門知識を有していたとしても、それを相手に上手く伝えられなければこんなに勿体ない事はありません。今回はち
前置き できるようになること Julia のパッケージである Documenter.jl を使ってマークダウンからHTMLを生成し，GitHub Pagesを使って公開するまでの流れをまとめます． 私はこれを使って自分のウェブサイトを作成して公開しています．以下のリンクから良ければご覧ください． おことわり きっと，もっと上手なやり方があります．Twitterにて助言いただいている箇所もたくさんありますが，私ができたレベルでご紹介します．私もスキルレベルを上げて進化させていく所存です．私のスキルアップに伴ってこの記事も進化していく予定です． 普段は大学院生をしていて，プログラミングをゴリゴリ使うような研究をしているわけではありません．これは全て独学+Twitterで優しい方々から教えていただいたことを参考にまとめています．記事内の専門用語などに違和感がありましたらコメント等で教えてください
MTECの鈴木です。今回は「スライド資料の自動生成」を試した結果についてご紹介します。 TL;DR Gemini CLIを用いて論文（pdf）の解説資料（ppt）を作成できるかを試みる pdf操作とppt操作はMCPを利用 ppt操作が難しくうまく指示を守ってくれない 4Pほどの論文の解説資料を作成するのにもそれなりにトークンを消費する 良い感じの資料を作るためには、スライド生成サービスを使うor自分で色々と作り込むか モチベーション 今回はGemini CLIを用いて論文（pdf）の内容を解説したパワーポイント（ppt）資料を作成できるかを試してみます。一般に研究においては「サーベイ⇒先行研究の論文精読⇒研究テーマ策定⇒研究」といったフローがあります。現時点においては生成AI（Deep Researchなど）でサーベイを行い、論文（pdf）の内容を精読してくれるようになってきていますが、
こんにちは、UXライターの8chariです。早いものでSmartHRに入社して1年が経ちました！初めてTech Blogを書くのでドキドキしています。 SmartHRでは、フィーチャーチームでプロダクトを開発しており、開発プロセスの改善を日々行なっています。 この記事では、私が所属しているBチーム*1でヘルプページ作成のプロセスを見直し、チームのボトルネックを解消しようとしている話を紹介します。 特定の業務を担当できるメンバーが限られていて、以下のような課題を感じている方の参考になると嬉しいです。 必要なノウハウや知見がほかのメンバーに広まらない プロジェクトのボトルネックになっている 担当できるメンバーの負荷が高くなっている 前提 UXライターがいる開発現場はあまり多くないと思いますので、前提を説明します。 SmartHRのUXライターは「言葉の力でプロダクトを、もっとわかりやすく」する
先日とある発表資料をレビューする機会がありまして、自分はこういうことに気をつけているよ〜というフィードバックをしたんですが、フィードバックをしながら「あ、自分これ、結構大事にしているなぁ」と改めて気づいたので書き留めておきます。 気をつけていること 気をつけていることはこの3点です。 想定するターゲット（聴講者、読者）は誰なのか この発表の前、ターゲットはどういう状態なのか この発表を経て、ターゲットにどのような状態になってほしいのか 気をつけている、というか、この3点を直接的に資料に盛り込んでしまうことが多々あります。 あなたに聴いてほしいんです あなたはいまこういう状態なんじゃないかなぁ？とわたしは想像しています この発表のあと、あなたにこういう状態になってもらいたいなと思ってます といった感じですね。 伝えたかったことがまとまる これを書いておくと、自分自身が「結局だれになにを伝えた
Integrated Data Service 部の中野 (takamoto) です。2021~2022年頃は主に データプラットフォーム統合プロジェクトの紹介 - KADOKAWA Connected Engineering Blog で紹介されていたデータプラットフォーム開発の認証認可の開発に関わっていました。また、ここ2年弱は別チームに移り、データプラットフォーム上のデータパイプラインの開発・運用をメインで担当しています。 今回は、上記のデータプラットフォーム統合プロジェクトの開発チームに導入され、その後移った先のチームでも活用が進んでいる ADR の活用事例を紹介します。既に ADR 自体の紹介記事自体は数多く存在するため、この記事では ADR 自体についての説明は軽く流し、代わりに以下のような観点での事例紹介に重きを置くスタイルを取ります。 どのようなモチベーションで ADR を
お仕事で Design Doc を書く前に色々整理するのだが、その作業をシンプルなフォーマットで効率化してみた。 やることは本当に簡単で、箇条書きに色をつけるだけ。 赤：誰かに質問や相談をしないといけないところ 緑：他の人のボールで待ち状態になっているところ 青：自分で調べるところ 黒：その他 設計を考える時、最初から全てのコードが頭の中に入っているわけではないので基本的には調査から入る。 その際、やるべきこと、分かったこと、分からないこと、気になったこと、不安なこと、全てを片っ端からメモっていく。 そうすると巨大な箇条書きのリストが出来上がるので、そこに上記の要領で色をつけていく。 まず「誰かに質問や相談をしないといけないところ」を赤文字にする。 こういう場合はどういう挙動になるのが正解？ ここはもっと良いデザインがあるんじゃないか 既存仕様がどうなってるのか分からん ここは一人で考えて
はじめに はじめまして！ レバテックでプロダクトデザイナーをしている成田です。 現在は日々のプロダクトデザインの業務に加え、デザインシステム『VoLT』の構築と運用に取り組んでいます。 なんとか社外公開まで漕ぎ着けた『VoLT』ですが、プロジェクトが開始してすぐの頃は「無理だ」と弱音を吐きたくなるほど課題が散見されていました。実際、私は何度も「え〜無理なんだが」と声に出しながら作業を進めていました（笑） 本記事では、Figmaでのコンポーネント管理の話を中心に、抱えていた課題を解決するために生み出した 「インスタンスガイドライン」 というものについてお話しできればと思います。 ちなみに、デザインシステム構築の背景や目的が書かれた記事も公開されているので、気になる方はぜひチェックしてみてください👏 何が難しい？レバテックのデザインシステム デザインシステムは、定義すること自体は難しくありま
本記事は わた推し～AWSアワードエンジニア編～ 2日目の記事です。 💻 1日目 ▶▶ 本記事 ▶▶ 3日目 💻 小西秀和です。 先日、2020、2021年に引き続き、2022年のAWS ALL Certifications Engineer(旧称：APN ALL AWS Certifications Engineer)、AWS Top Engineer(旧称：APN AWS Top Engineer) (Service)に選出されました。 今回はこれらの当社選出者達によるブログ企画「わた推し～AWSアワードエンジニア編～」の記事の一つとして、私が推すAWSサービスを紹介します。 「推し」というテーマということもあり、いつにも増して個人的、主観的な主張および長文となっていますので、その点はご了承ください。 私の推しのAWSサービスは「AWSドキュメント(AWS Documents)」で
Claude Codeを使っていると爆速で実装してくれて、 エラーが発生してもいつの間にか解決してくれています。 （これまでは、AIと二人三脚でエラーの原因を考え、解決していて楽しかったので何か寂しい気持ちに・・・） エンジニアとしては、やはりどうやって解決したのか気になるので、 トラブルシューティングを記事化してもらうようにしました。 記事化してもらったトラブルシューティングの例 エラー解決後に、Markdown形式にて記事にしてもらっています。 発生環境や原因、解決方法だけでなく、試行した失敗パターンも記載するようにしています。 記事のテンプレートを用意する やり方としては単純で、テンプレートを用意して指示出しするだけです。
はじめに 技術プロジェクトにおいて、ドキュメントの作成・更新・メンテナンスは重要な作業ですが、多くの開発者にとって煩雑で時間がかかる作業でもあります。特に、Sphinxのようなドキュメント生成ツールは高機能である反面、設定が複雑で学習コストが高いという課題があります。 本記事では、 Claude Codeのカスタムスラッシュコマンド機能 を活用して、こうした課題を解決し、効率的なドキュメント作成環境を構築する方法を紹介します。 Claude Codeのカスタムスラッシュコマンドとは Claude Codeは、.claude/commands/ディレクトリに配置したMarkdownファイルを自動的に読み込み、カスタムスラッシュコマンドとして利用できる機能を提供しています。 主な利点 プロジェクト固有の操作を標準化: 複雑なコマンドラインや設定手順を単一のコマンドに集約 チーム全体での作業統一
こんにちは。みらい翻訳のtoshと申します。 私は社内でSRE-SWEというチームに所属しており、主に既存システムのアーキテクチャ刷新をミッションとしています。 具体的な業務としてはアーキテクチャ刷新に必要な基盤の整備やガイドラインの制定を実施しています。 その中で、基盤やガイドラインの共有方法や整備の仕方に対してチーム内で課題感を持っていたところ、とあるメンバーからアーキテクチャデシジョンレコード（以下ADR）が提案されました。 軽量なフォーマットで書きやすく、テキストベースであるため差分管理も簡単であるADRはチーム内でもすぐに受け入れられ、ADRを必要に応じて書くこととそのフォーマットが決定しました。 今回はADRの紹介と実際に利用しているフォーマットを紹介します。 アーキテクチャディシジョンレコード(ADR)とは こちらのGithubリポジトリには以下のように記載があります。 An
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
