こまぶろ

技術のこととか仕事のこととか。

アーキテクチャデシジョンレコード(ADR)を組織構造の変更にも適用する

ソフトウェアアーキテクチャに関するプラクティスとして、アーキテクチャデシジョンレコード(Architecture Decision Records, ADR)というものがあります。この記事は、それを組織構造に適用してみるとどうなるだろうと考えてみるものです。100%妄想ですので、予めご了承ください。

(↓妄想が湧いたときのツイート)

2021/11/30 追記: 数日前に、同じくADRを組織の領域に適用する話が出ていました。

dev.classmethod.jp

ADRとは?

今回の題材である(本家の)ADRとは、以下のようなものです。

テキストベースの軽量なテンプレートを使用して、アーキテクチャ上の設計判断を記録する。(中略)設計判断を記録していくことで、それらを共有し分析することが容易になる。意思決定の履歴を残すことで、現在のアーキテクチャについてのコンテキストを、その過程と結びつけて提供できる。

(『Design It! ―プログラマーのためのアーキテクティング入門』p.302)

ADR - iki-iki

アーキテクチャに関する設計判断は、プロジェクトの最初に一回だけなされるというものではありません。設計判断(およびそれに基づくアーキテクチャの変更)は、コンテキストの変化にも対応しながら、継続的に行われていくものです。ADRは、これらの判断を毎回簡潔に記録していくことで、将来の開発者のアーキテクチャに対する理解や判断を助けてくれます。

なぜADRを組織に適用しようと思ったのか?

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』は、チーム編成は継続的に設計していくべきものであると主張しています。

探索や実行といった、プロダクトや技術のライフサイクルにおける各フェーズをサポートするには、チーム同士のやりとりは時間を追うごとに進化する必要がある。

(『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』p.xi)

※『チームトポロジー』については以下の記事をご覧ください

ky-yk-d.hatenablog.com

この書籍では、組織内のコミュニケーション(チーム同士のやりとり)の構造がソフトウェアの開発にとって極めて重要であり、開発の中で実現したい事柄に応じてこれを変更していくことが必要であると指摘されています。この言説に従うならば、チーム編成の変更は、偶発的なものではなく、継続的に行われていくものということになります。

また、この主張の背景には、組織のコミュニケーション構造とそれが生み出すシステムの設計との相関を指摘した「コンウェイの法則」(および、その応用としての「逆コンウェイ作戦」)があります。

以上のことから、継続的に行われるソフトウェアの設計に関する判断を記録していくプラクティスが有効なのだとすれば、ソフトウェアの設計と密接に関わっている組織構造(チーム編成)に関する判断(これも継続的に行われる)を記録していくことにも意味があるかもしれない、というのが今回の着想です。

記録するとよさそうなこと

Michael Nygard による本家ADRのテンプレートは、以下の通りです。同じものをベースにして、補足をしてみます。

  • タイトル(Title)
  • コンテキスト(Context)
  • 内容(Decision)
  • ステータス(Status)
  • 影響(Consequences)

※各項目の訳語は『Design It!』に準拠しました

「コンテキスト」の項目では、本家ADRでは、技術やスキルといったソフトウェアに「近い」内容に限らず、ビジネスの状況などのアーキテクチャに影響を与える要因を記述することが推奨されています。組織構造についての判断についても、ほぼ同様の内容を記述することができるはずです。システムに対する変更の判断が技術以外の要因の影響を受けるのと同様に、組織に対する変更の判断も技術やビジネスなどの要因の影響を当然に受けるからです。

「影響」の項目では、本家ADRでは、判断がシステム、ステークホルダー、チームの状況をどう変えるか(そして変えたか)を記述することが推奨されています。ここも同様の内容を書くことができるでしょう。特に、ネガティブな変化についても記述せよという本家の指摘は、組織に対してこのプラクティスを適用にするときにも重要になると思われます。組織の変更はポジティブな結果を期待して行われるものですが、そこにトレードオフやリスクがあることを(判断する側はもちろん、その他のメンバーも)知っていることは大切です。

何が嬉しい(嬉しそう)なのか?

実践してみたわけではないのですが、本家ADRについて挙げられているメリットや、過去の自身の経験などを踏まえて想像(妄想)してみます。

  • 組織構造に対して変更を加えるというのは、一定のポジションにならないと経験しづらいものですが、判断を記録の形式に落とし込むことで、マネージャー以外のメンバーもその判断について理解することができます。
  • メンバーは、自身が所属するチームの役割だけでなく、他のチームの役割や、それとの関わり方についての「設計思想」も知ることができます。
  • 現時点での組織構造についての歴史的経緯がわかるようになります。歴史的経緯がわかると、今後の方向性について共通認識を持ったり、過去の過ちから学んだりできます。

注意(したほうがよさそうな)点

  • 本家ADRに比べて、GitHubなどのコードに近いところで保存しておくメリットは乏しいように思われます
  • 本家ADRでは、ADRを(GitHubなどを使って)ピアレビューできることもメリットに挙げられていますが、組織の変更について同様の民主化が完全に可能なのかは不明です
  • 最も粒度の小さい変更としての個人の異動については、理由を全て公表することができない場合もありうるでしょうから、そもそも残さないほうが良いようにも思われます

おわりに

以上、組織構造版ADRというプラクティスを考えてみたよというお話でした。

もし、「実践してみたよ!」という方や、「既に似たようなプラクティスをやっているよ!」という方、あるいは「それにはそもそも名前がついていてだな・・・」という方がいらっしゃったら、記事へのコメントないし @koma_koma_dまでぜひご連絡ください(興味本位)。

「ちいとぽ」こと『Team Topologies』の翻訳(12月1日発売)を読んだ

邦訳が待望されていた『Team Topologies』(邦題は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』。以下、「ちいとぽ」)ですが、発売日(12月1日)を前にして翻訳レビュワーを務められた角谷さんからご恵投いただいた(ありがとうございますありがとうございます)ので、とりあえず一気に読みました。

Kindle版も出る予定とのことです。

内容については、すでにiki-ikiTwitterで色々話を角谷さんから聞いていて、ある程度前提があったのですが、実際に読んでみて印象に残ったことや感じたことを2点ほど記します。

一読した感想を先に記しておくと、この本は、自分一人で読んで、自分の組織について「あのチームは『ちいとぽ』でいうとこういう風に再定義できて、そうなると・・・」と考えてみるのも面白いですし、同僚と一緒に読んで「現状だとうまくいっていないところがあるだろうか?」と話してみるのも有意義だろうなと思いました。フルカラーで、視覚的にも楽しいです。そして、翻訳もとても読みやすかったです!

詳しい紹介が欲しい人は原書を読んで書かれた以下の記事がおすすめです。

deeeet.com

訳者の一人である吉羽さんの記事もご覧ください。

www.ryuzee.com

翻訳書籍とは別ルートで「ちいとぽ」に興味を持った方によるよいまとめ記事も公開されていました。

zenn.dev

「内容を三行で・・・」という人は以下もご活用ください。

scrapbox.io

組織・チームの「継続的な設計」

「ちいとぽ」といえば「4つのチームタイプと3つのインタラクションモード」です。こういうのをみると、「はいはい、またSpotifyモデルみたいな話でしょ?」となってしまいがちで、実際にこの書籍の中でもSpotifyモデルの話は何度か登場するのですが、「ちいとぽ」の優れているところは、これらを動的なものとして、書籍中の表現を使えば「継続的な設計」をするものとして位置付けているところだと思います。

できる限り効果的なチームにするには、ただ偶発的もしくは行きあたりばったりでチームを編成するのではなく、継続的にチームを設計する必要がある。このように継続的な設計によるチーム構造のことをチームトポロジーと呼ぶ。これは、それぞれのチームの責任範囲を明確にしながら、組織内にチームを意図的に「配置」することを意味する。(p.72-73)

「ちいとぽ」による組織改編の結果のスナップショットは(まさにSpotifyモデルがそうであったように)常に動的な過程の中の一断面に過ぎないと考える必要があります。

書籍では、スナップショットを説明するための静的な概念の紹介は一部のみで、重点は組織構造をどのように変化に対して適応させていくか、という方面にあります。第1章のタイトルは「組織図の問題」ですし、冒頭で既に以下のようにインタラクションモードは状況に応じて変化させていくものであるという言明があります。

技術やプロダクトの探索段階では、成功のために、チームの境界がオーバーラップしたコラボレーションの多い環境が必要だ。だが、探索が終わって技術やプロダクトができあがったあとも同じ構造を維持すると、無駄な労力と誤解を生んでしまう。(p.10)

あらゆる状態に適した組織構造というものはあり得ず、状況の変化に応じて形を変えていく必要があるというのは当たり前といえば当たり前なのですが、この書籍がその適応のさせ方に明快なガイドラインを与えてくれていることの価値は大きいように感じました。

豊富な参考文献と納得度の高い経験に基づいた議論

「ちいとぽ」を一読して印象に残るのは、豊富な参考文献を用いた議論の整理や裏付けと、時折挿入される経験にもどついた議論の納得度の高さです。

巻末に参考文献表が掲載されているのですが、細かい字で丸々12ページに渡って文献が列挙されています。これらの文献が文中のいいところで引用・紹介されていて、理解の助けになったり、「そういえば積んでるなその本・・・」となったりします。書籍の本筋とは別のところでも得るものが多いというのは、個人的には読む甲斐のある書籍の1つの特徴だなと思っています。

一方で、著者のこれまでの経験に基づいた記述も納得度の高いものです。たとえば、51ページではチームに割り当てるドメインの複雑度と数についての経験則が紹介されています。ここでいう複雑度は「シンプル」「煩雑」「複雑」の3つに分類されていて、「第2の経験則」として「1つのチームに、シンプルなドメイン2~3つ」がちょうどいい、という話がされています。これ自体もなるほどと思わされる記述ですし、最後に付け加えられている「しかし、仕事がルーティン化することで、チームメンバーのモチベーションが下がるリスクもある」という但し書きも、「お、そうだな……」と思わされます。

全体を通して、理論的根拠と経験の裏付けの両方に支えられた優れたガイドラインになっていると感じました。

おわりに & おまけ

というわけで、「ちいとぽ」を読んだよ、面白かったよ!というお話でした。

「ちいとぽ」を読んで、チームをトポっていきましょう!

おまけ:関連資料

IDDDの著者のバーノンのポッドキャストに著者2人がゲストで出てました。

open.spotify.com

「DDDとTeam Topologiesでプロダクト・レッド・オーガニゼーションですよ」だそうです。


www.youtube.com

プロダクト・レッド・オーガニゼーションについては、横道さんが訳された以下の書籍をご覧ください(僕は積んでます)。

公式のGitHub Orgもあります。

github.com

国内の事例も。

engineering.mercari.com

第4章でも言及されている「DevOpsトポロジー」について。

kakakakakku.hatenablog.com

おまけ:印象に残った参考書籍

前述のように「ちいとぽ」の中では様々な文献が紹介されているのですが、印象に残ったいくつかについて少しコメントをしておきます。

『LeanとDevOpsの科学』はしばしば引用されていました。ちょうど3年前にざっと読んだままなので、改めて読み直してみようかなと思いました。

ky-yk-d.hatenablog.com

『モチベーション3.0』も引用されていました(13ページや104ページ)。「ちいとぽ」13ページで言及されている「8人の精鋭からなるチーム」の話は読んでいるだけで辛いものがありますね。こちらもだいぶ前から積んでいるのでこれを機に読んでみようかと思います。

最後に、ナオミ・スタンフォード『Guide to Organisation Design: Creating high-performing and adaptable enterprises』です。9ページなど何度か言及されているこの書籍ですが、おもしろそうでした。Amazonだと2つページがあるのですが、Kindle版のある方のページのリンクを貼っておきます。

Janet Gregory さんの Agile Testing for the Whole Team 研修 に参加した

※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。

Agile Testing for the Whole Team 研修

3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。

www.jp.agilergo.com

講師は Janet Gregory(@janetgregoryca) さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している(こちらについても既にブロッコリーさん(id:nihonbuson) による邦訳がある)。

leanpub.com

また、Janet Gregory さんは先日開催された RSGT2021 でも基調講演の1つを務められていた。動画を以下に貼っておく。


RSGT2021 - Janet Gregory - What’s Testing Got to do with Quality?

研修の概要については、冒頭のアギレルゴコンサルティングのWebサイトの他、Agile Testing Fellow のWebサイトで研修概要のPDFファイルがダウンロードできる。

前置き

なぜ開発者である自分がこの研修に参加したか

会社がお金を出してくれ(ry

自分は、開発者の立場でアジャイルに関心を持って勉強してきて、前職時代から自分の仕事に学んだことを活かそうとしてきた。前職では自分の力不足もあってアジャイルのプラクティスを実践に投入できる機会は多くなかったが、現職のチームではイテレーション開発を採用し、ペアプロやCI、その他のアジャイルプラクティスを適用しながら仕事をしている。

しかし、テストという部分を見てみると、開発チームとQAチームとの関係は(決して険悪ではないが)密接とはいえず、「開発チームが作ったものをQAチームに回す」という流れになっている。バグによる手戻りが多くて困るということはそんなにないものの、仕様の把握とシステムが仕様通りに動いていることの確認という2点において、開発チームとQAチームが重複して仕事をしてしまっているなど、改善の余地があると感じていた。そういった背景もあり、冒頭で言及した書籍『Agile Testing Condensed』も、邦訳が出たときにすぐに買って読んでいた*1

また、別の観点からは、TDDやDDDの方面からATDD・BDDにも関心があり、つい最近は きょんさん(id:kyon_mm)と東口さん(@hgsgtk)による雑談を聴いたりしていた。


ATDD再考 2021

そういうわけで、この研修の存在をTwitter経由で知って「面白そうだな、参加してみたいな」と思っていた(会社Slackのtimesチャンネルにも投げていた)ところ、ありがたいことに会社で声をかけてもらい、同僚の開発者・QAメンバー数名と一緒に参加することになった。

研修のフォーマットなど

このご時世なので、当然オンライン開催で、3日間8:00~12:00の合計12時間の研修だった。これとは別に、事前に資料と動画(研修後にみることを想定したおさらい編も含めて全部で5時間ほど)が配布されていて、座学になる部分は極力事前予習で済ませ、当日の研修の時間ではさまざまなグループワークを行うことに時間が割かれた。

講師は英語話者だが、日本語の通訳者がついており、Zoomの同時通訳機能を使って、参加者の方で聴きたい言語(英語 or 日本語)を選んで聴くことができるようになっていた。この通訳の方がすばらしく、通訳を待って話のスピードが遅くなるという体験はほぼしないで済んだ。また、アギレルゴコンサルティングの川口さん(id:wayaguchi)が共同トレーナーとして臨席されており、参加者からの質問に対して補足説明を加えるなどしてくださって理解の助けになった。

研修の内容について

「チーム全体」で品質を考える

タイトルに「Agile Testing for the Whole Team」にあるように、研修のコアメッセージは「品質のことをチーム全体で考えよう」というものだったと思う。ここでいうチームとは「デリバリーチーム」であり、役割としてはテスター、開発者に加え、プロダクトオーナーのようなビジネスサイドのメンバーも含まれている。このメッセージは研修を通じて一貫したもので、当日に行ったワークショップでもPO、開発者、テスターというそれぞれの観点に立って意見を出してみるとしばしば促された。

研修の主な受講者として想定されていたのはテスターであったと思われるが、テスターに対してもマインドセットの転換を要請していた。開発プロセスの最後にバグを見つけることにテスターの役割を限定せずに、「そもそもバグを作らないで済むようにする」ことなどを通じて、「ソフトウェアを成功裡にデリバリーする」ための行動をテスターに取るように求めていた。

当然、その裏返しとして、開発者に対しては、品質を作り込むことを強く求めていた。研修中に出た印象深い発言として、「テストをする気がなく、品質について考えようとしないプログラマーがいたら、『コーディングを止めろ!("Stop coding!")』と言ってやりなさい」というものがあった。これを含め、テスターをエンパワーするような発言が随所にあり、(自分はテスターではないが)参加していたテスターの人たちには非常に心強かったのではないだろうか。

ワークショップから

先述の通り、研修当日(3日間)の時間は多くがワークショップに割かれた。かなりたくさんのワークショップを行ったので、いちいち内容に言及することは避けるが、ワークショップを通じて印象に残っているのは、「仕様について勝手に自分で判断せずに質問する、質問することで共通理解を形成する」ことの重要性である。自分はかなり「理解力」的なものを尊んでいて、「一を聞いて十を知る」的なあり方に憧れてしまうのだが、チームでものづくりをしているときには自分の頭で勝手に補うことが非常に危険であると実感することができた。

また、今回の研修のワークショップの多くは、ストーリーにイテレーションで取り組む前の段階にフォーカスしたものだった。講師の言い方では「ストーリー準備ワークショップ(story readiness workshop)」、スクラム的な言い方をすればバックログリファインメントで有効活用できそうなプラクティスを多く学ぶことができた。研修の趣旨からすると、この段階でチーム全体での共通認識の形成が、(バグの混入など)ソフトウェアのデリバリーを妨げる事象の発生の防止に重要ということなのだが、個人的にはストーリーを小さくスライスする具体的な方法が今まで良くわかっていなかったので大きな学びだった*2

ATDD, BDD, SBE

個人的には一番関心があった部分。『実践テスト駆動開発』(通称GOOS)は読んだが、実務ではATDDは取り入れておらず、BDD(Behavior Driven Development)やSBE(Specification by Example)は概要を知っている程度で本は未読だった。

講師はATDD(Acceptance Test Driven Development)が最も包括的な用語だとして説明していた。ATDDといえばGOOSで、GOOSは技術的な側面にフォーカスした本なので、自分の理解も(『テスト駆動開発』付録Cの表現を借りると)「外側のループ」をTDDに足したものという捉え方をしていたのだが、この研修では自動化の前段階で、チーム全体で共通認識を作り、ストーリーのスコープを把握するためのものとしての側面を重視していた。

イテレーションで実際にストーリーの実装(テスト&コード)に取り組む前に、ATをチーム全体で考える。ATを記述するフォーマットとしては、BDDスタイル(Given/When/Then)や、表形式(Tabular)など複数の書き方があるが、Given/When/Thenは自然言語で記述するのでわかりやすく、表形式では具体的な値を使って考えるのでより踏み込んだ議論を促してくれるということだった。これは実際にワークショップで体験したが、確かに表形式で記述しようとすると具体的な入出力をイメージしやすく疑問が出やすかった。

その他、研修で言及のあったもの

上記のトピックの他に、一部を挙げると以下のようなトピックが取り上げられた。

  • テスト自動化ピラミッド
    • なるべく下にテストを押し込んでいく
    • それぞれのテストがどのレイヤでできそうかを考え、マッピングしてみる(もちろんチーム全体で!)
    • 真ん中のレイヤ(API・サービス層)のテストはビジネスサイドの人も読めるようにする(Living Documentation!)
  • アジャイルテストの四象限
    • 第四象限おそろかにしがち問題
    • 上半分のテストはビジネスサイドの人も読める
  • バグトラッキングシステムの必要性
    • 新規フィーチャーの実装では、ゼロトレランス方式*3を採用するため不要
    • レガシーシステムの場合、本番環境で発生する不具合などの傾向を分析することが更なるバグの防止のために重要なのでしっかりとバグは管理するべき
  • テスト計画

まとめ的な感想

今回の研修を通じた最も大きな学びは「ストーリーをいかにReadyな状態にするか」に関わる具体的なプラクティスだった。ストーリーを十分に小さくしてReadyな状態にすることは、短いタイムボックスでインクリメンタルにソフトウェアを開発してフィードバックを早く得ることを旨とするアジャイルにとって極めて重要な営みであるはずだが、自分はあまりその部分を勉強してこられていなかったので、今回の研修を通じてようやく「ああ、こうやるのか!」と得心がいった部分が多かった。ただ、うまくやらないとストーリーをReadyにする営みにかなり多くの時間をかけてしまいそうで、そこは難しいところだと感じた。

他の感想としては、研修の語り口からすると、テスターを主な参加者層として想定しているようだったが、プロダクトオーナーや開発者にも役立つことの多い研修だったと感じる。「エラーをみつけるつもりでプログラムを実行する過程」としてのテストの技法についてはあまり言及がなかった分、自分のような開発者ロールで働いていて、テストに関する知識がそこまでない人間にもとっつきやすかった(裏を返せばその部分に関する学びは少なかった)。ただ、アジャイルという考え方についての説明や、TDDやCI/CDといった技術的プラクティスについての説明は少なかった(ある程度わかっている前提だった)ので、一定以上のアジャイルについての前提知識は持っていた方が理解しやすい研修だったのではないだろうか。

今回、同僚の開発者やQAメンバーと一緒に参加していたので、研修が終わった後、今後の実務にどうやって生かしていこうかという対話を始めている。研修で教わった内容をそのまま適用するのは難しいが、目指す一つの方向としてモデルを持てたこと、組織の課題を語るための共通言語を得られたことは価値があると思っている。この記事を読んで、「次回開催されたら参加したいな」と思っている人がいれば、ぜひチームのメンバーみんな(できればプロダクトオーナーも!)で参加すると良いと思う。

おまけ

Agile Testing Fellowshipについて

なお、この研修の副賞的なものとして、Agile Testing Fellowship のメンバーになることができるというものがある。研修受講後にオンラインでのアセスメントを受験して、合格すれば会員として迎え入れられるというシステムだ。自分も研修が終了したその日に受験し、無事に合格した。合格すると、PDFの会員証がもらえるほか、会員で構成されている Slack workspace に参加することができる(名称からして「認定なんちゃらer」ではないし、むしろこちらのコミュニティでの交流・相互支援に重きがあるようだ)。

なお、この Agile Testing Fellowship への入会は、研修を受けなくても可能で、120ドルを支払うことでアセスメントを受験し、入会することができる。『Agile Testing Condensed』の邦訳を手掛けられたブロッコリーさんはこちらの方式で昨年の時点で入会されている。

nihonbuson.hatenadiary.jp

参考:研修に関連する書籍

Janet Gregory & Lisa Crispin

その他

leanpub.com

*1:なお、研修を終えてみて改めて読んでみたところ、研修前に読んで全く頭に入っていなかった内容がワークショップでの経験によって理解できるようになったことを感じた。書籍には掲載されていないが研修で扱われているトピックも多くあったことも確認できた。

*2:「スチールスレッドコンセプト」というもので、フローチャートを使ってコアを特定していくワークショップを行った。

*3:既知の不具合が混入した状態でイテレーションをストーリーが通過することを許さないということ。

Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対処法

※以下の問題が発生しない場合もある。おそらく使用するフォントによると思われる。

Speakerdeckの既知の問題

登壇するエンジニア御用達のスライド共有サービス Speaker Deck だが、いくつか既知の問題がある。

たとえば、以下のようなものだ。

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

今回、別の問題に直面したので、対処方法をメモしておく(結論から先に言えば、 Speaker Deck の問題ではなかった)。

Transcriptが文字化けする問題

Speaker Deck には、「Transcript」という項目があり、スライドの各ページの記載内容をテキストで自動的に補ってくれる。

Keynote で作成したスライドを Speaker Deck にアップロードすると、以下のようになってしまう。

文字化けしている様子
文字化けしている様子

この問題は、企業が運営しているアカウントのスライド資料で発生している例もあり、様々な人がぶつかっている問題だと思われる。

対処方法

当初、 Keynote の問題だとわからなかったため、「Speakerdeck 文字化け」などで検索してもなかなか見つからなかったのだが、知人からCMAPの問題ではないかとの指摘をもらい、以下の記事にたどり着いた。

fu7mu4.hatenablog.com

結果としては、上の記事で記載されている通りの作業を実施することで、 Transcript の文字化けも回避することができた。

手順1: Keynote から「PostScriptとして保存」

PDFが必要な場合、Keynote から「PDFとして保存」するのが定番だが、問題を回避するために一度 PostScript を経由する。「プリント」から「PostScriptとして保存」を選択する。

「PostScriptとして保存」を選択
「PostScriptとして保存」を選択

手順2: PostScript をプレビューで開き、PDFとして書き出し

PostScfript を「プレビュー」で開いて、PDFとして書き出す。

PostScriptから「PDFとして書き出す」
PostScriptから「PDFとして書き出す」

※2024.3.9 追記

Macの新しいバージョンではPostScriptのビルトインサポートがなくなっているため、上記の工程を代わりにGhostscriptなどのツールで行う必要がある。

ky-yk-d.hatenablog.com

対応後

綺麗に Transcript が文字化けせずに表示されるようになった 🎉

綺麗に表示されている様子
綺麗に表示されている様子

補足

16:9 のスライドを上記の方法でPostScriptに書き出すとサイズの関係で余白ができてしまうので、以下のようにサイズを調整してアップロードするとよい。

  • keynoteで「プリント」
    • ページ設定でカスタムサイズ設定
    • サイズを横254mm*142.9mm
    • PostScriptとして保存
  • プレビューで開いて、PDFに書き出し

ソフトウェア開発者としての4年目を新しい会社で始めた

今年の4月から新しい会社で開発者として働いています。

2017年4月に新卒で前職に入社したのがソフトウェア開発者としてのキャリアのスタートでもあったので、この4月で4年目に突入していたこととなります。早いものです。

大学院(修士)卒で就職したので、25歳になる年に就職したわけですが、あっという間に28歳になる年です。あと2年で30歳になる年です。以前(当時は26歳)、id:nitt_san さんに投げかけられた「30歳のときにどうしていたい?」という問いに改めて向き合おうと思う今日この頃です。転職できたことに満足して一息ついていたら30歳になってしまっていたということがないように。。


色々書こうかなと思うことはあったのですが、まとまらないのでやめました。Amazonの欲しいものリストだけぶら下げておいてもよかったのですが、なんか気が乗らなかったのでそれもやめました。それなら転職エントリ自体書かないという手もあったのですが、まぁ一つの区切りとして書いておくとすっきりしそうだなと思ったので書きました。ふー。

このブログもだいぶご無沙汰になってしまっているのですが、また思い出したように何かを書き始めることもあるかと思います。乞うご期待。またTwitterの方は(アイコンもIDも何もかも変わってしまっていますが)相変わらず元気にやっていますので引き続きご愛顧ください(?)。