r_shibataの備忘録

大学院で研究したり,コーヒー入れたり,マジック勉強したり,ITの勉強したり...

フットサルの駆け引き

2024/02/04の練習

 

メニュー

6vs3

ピッチを二分割にして、攻撃側が分割されたエリアに3人ずつ配置。ボールサイドに守備が2人、ボールのないサイドに1人。攻撃側が三本パスを通すと反対のサイドにパスできる。

ポイント

攻撃の意図は3vs 2の攻略。中央のフィクソが守備の圧縮を崩しパスコースを増やせるか。エイトでファーの守備を惑わせることも効果的。

守備の意図は攻撃のパスが三本通るまでに同サイドのパスコースを消しパックできるか。

感想

攻撃は早めに三本パスを通せると、駆け引きなく反対サイドに返せた。今回はサイドのフィクソが高い位置を取ることが多く、サイドからサイドへ守備の間を狙うパスが多かった。

 

2人組のシュート練習

 パラ、ワンツー

 ダイヤゴナルからの落としでシュート、ワンツー意識からのカットイン

中央とサイドの2枚でのコンビネーション攻撃の練習。中央のフィクソとサイドのアラが平行位置でスタート。フィクソがサイドのアラにパスを出し、その間にフィクソが目の前の守備に近づく形で駆け引きをして背中にスペースを作る。アラは中央のフィクソに返すと、上記のいずれかの抜け出し、ボールを受けて最後はシュート。

ポイント

中央のフィクソが駆け引きをして、対応してくる守備を外し起点をつくる。

サイドのアラはパラやワンツーするときに、フィクソのタイミングを見ながら抜け出す。

感想

フィクソが駆け引きをするときにサイドの状況が見えておらず、準備ができてない状況で受けてアラに返すことが多かった。

アイコンタクトで、お互いのタイミングを図ると良さそう。

守備がいると駆け引きで守備を外すイメージがつきそう

 

3vs3 キーパーあり

ゲーム形式。相手陣でボールを取るとそのまま攻撃できる。自陣でボールを取ると一度キーパーに戻してからスタート。1セット2分。

ポイント

今日の2枚でのシュート練習を実践する。フィクソは目の前の守備との駆け引きと、サイドのアラとの関係で崩すこと。サイドのアラもワンツーやカットインを使って裏を取ったり、展開をする。

感想

最初はお互いがどの動きをしたいかが見えなかったが、次第にワンツーやパラができる様になった。縦関係が多くパスコースが無くなることで詰まりがちなことが多かった。一度サイドに開いた配置にすることで、守備のスライドを遅らせたりやスキマを使えるようになりそう。

 

振り返り

攻撃の2枚の関係ではプレーの選択を合わせるためのリズムが大事。そのためには、味方とアイコンタクトをしながら、タイミングを合わせる練習が必要。顔を上げて駆け引きを感じてみる。

また、今日のシュート練習は「守備との1vs1駆け引き」と「パラ、ワンツーなどの2vs1」の状況を組み合わせていた。1vs1の駆け引きができるタイミングのイメージを作ること、2vs1の関係で味方とアイコンタクトをすることで、成功確率を上げていきたい。

特に1vs1の駆け引きは、駆け引きができる状態を作るところから練習してみても良いかも。試合中に自分たちで意図的に配置を作れると、プレーの再現性も上がりそう。

焙煎によるディベロップメントが難しい

はじめに

焙煎がうまくいくように感じていた自分ですが、お世話になっている焙煎師さんと同じ豆を焼きあって、ブラインドカッピングをしたところ。 まったく、焙煎師さんの豆はすごく浅く焼いてるのにディフェクトもなくて、優しい酸が高温から低温まで続きました。 私の焼いた豆は結構深入りで、甘さや酸もありましたが、低温になると滑らかさがないラフな感じがでました。またスモーキーでもあった気がします。 焙煎師さんと自分の豆は1個と2個で用意しましたが、カップをとったお客さんは2つで悩んでくれましたが、残りの1つは水みたいな感じと言われてしまいました。もちろん焙煎師さんのカップが一番いいという結論になりましたが、とてもいい経験でした。 今の課題を言葉に残しておこうと思います。

ディベロップメント

そのあと、私はプロファイルをあまり変えず、余熱を高めに早めに焼いてみました。 八分半くらいで焼き上げ、50秒くらいをディベロップメントに使いました。 カップをとってみると、明らかにナッティーな感じになって、酸も全然ないぐらいに芯まで焼いてしまいました。。 焙煎師さんも同じくらいの時間で焼き上げてるようだったので、ハゼ前からのディベロップメントが足りないように感じました。

まとめ

今から検証するぞー

「人が増えても早くならない」と著者の倉貫さんから得た気づきをブログに残す

概要

先日、12月1日に富山県立大学DX教育研究センターで行われた「企業のシステム開発 なぜ上手くいかない? ~対話で解き明かす、開発の課題と解決策~」と2日に金沢で行われた「Agile Japan 2023 北陸サテライト」の両イベントに裏方として運営と参加してきました。 両イベントにゲストとしてソニックガーデンの倉貫さんに来ていただきました。倉貫さんと直接話すことで感じたことがたくさんあったため、ブログという形で残してみました。

きっかけ

はじめに倉貫さんのイベントを富山で開催してみたいと思ったきっかけは、弊社CLでどこよりも早く、倉貫さんの著書である「人が増えても速くならない」のABD読書会を行っていたからでした。私はYoutubeと社内Slackからイベントの様子を見ており、富山の企業さんにもこの話をしてもらってアジャイルについての理解を深めてもらいたいなと考えていました。また、何気なくTwitter(X)でイベントできたらいいよねーとツイートしたところ、Aglie Japan北陸サテライトのGのヤナギさんも似たような話をしていて、盛り上がりました。

その後、CL富山事業所と富山県立大学DX教育研究センターが共催した富山のイベントでGのヤナギさんに会う機会がありました。そこで、GのヤナギさんにAglie Japan北陸サテライトで倉貫さんが金沢に来るついでに、富山にも来てもらえるよう話をつけていただいた、という流れでイベントが実現しました。

経営についての話

富山県立大学DX教育研究センターとアジャイルジャパン北陸サテライトの両日とも、裏方に近い形で参加したこともあり、移動の時間や懇親会で雑談をする機会がありました。

もちろん、イベントに参加して感じたことはありますが、倉貫さんを送迎している最中や懇親会での話がとても面白かったため、雑談をメインに振り返ってみようと思います。

アジャイルという言葉を使わずに説明する

倉貫さんは具体的な事例やソニックガーデンの話をするときにアジャイルという言葉をあまり使わないところが印象的でした。

富山県立大学のイベントでは、非エンジニアの参加者にソニックガーデンを説明するときにアジャイルな開発をしている、とは言わずに「顧問料をいただきながらITに関わる仕事を全て受け持ちますよ」という説明をされていました。私は気になったのでイベント後に倉貫さんを送迎している車内で、なぜアジャイルという言葉を使わずに説明しているのかという質問をしてみました。すると、倉貫さんは「お客さんがほしいのはアジャイルではないんだよ」と回答してくれました。お客さんはアジャイルで得られるメリットをほしがっていて、メリットとデメリットを説明してあげれば、納得して取り入れてくれるよと解説してくれました。

私はそれを聞いて、ウォーターフォールで炎上している友人に、アジャイルの良さを伝えたときのことを思い出しました。友人はアジャイルというカタカナ語は覚えてくれた様子でしたが、意味を伝えてもあまり響いてない感じでした。今考えてみれば、アジャイルの意味を知っても、適用方法が分からなければ本当の意味で良さは分かりません。本当に必要だったのは、アジャイルという言葉ではなくて、困っていることの改善案を一緒に話し合うということだったなと思います。

社長、部長の視座になって言葉を考える

2日間のイベント参加をしてみて、私が一番気になったことがありました。それは倉貫さんのコピーライターのようなシンプルかつ、耳に残る言葉づかいでした。どうしても気になったので、懇親会の席で倉貫さんに尋ねたところ、会社勤めをしていたときに企画書や提案書などをたくさん書いたからだと言っていました。

昔、AWSが始まったばかりのときに、AWSを使った企画書を上司に持っていくと、なぜオンプレではなくAWSが必要なのか分からないと言われたそうです。社長に持っていっても同様のことを言われたことで、確かに社長はAWSのことは知らないよなと納得したそうです。 倉貫さんが振り返りをして考えたのは、社長や部長の視座になって企画書を考えられていなかったということでした。それからは、誰の視座で見てもぶれない言葉を使うように心掛けていると言っていました。

また、大企業じゃないと経験出来ないことだったと語っていました。

果物屋さんの看板を掲げておくと、お客さんは果物を買いに来る

私はイベントでソニックガーデンのプロジェクトのほとんどがうまく行っているという話を聞いて、いいお客さんに恵まれているなという印象を持ちました。私はそのことが気になり、倉貫さんに「なぜいいお客さんに恵まれるのか」と、また質問をしてみました。 倉貫さんの回答は「果物屋さんの看板を掲げておくと、お客さんは果物を買いに来るのと一緒だよ」でした。私は当たり前のことすぎて、はじめはピンときませんでした。続けて解説を聞くと、商売をするときには売上を伸ばしたくてスーパーのように品揃えを増やしがちだけど、逆にお客さんは何でもそろうと思って来てしまうことで目的の商品がなかった時のすれ違いも増えてしまう。もし美味しいメロンが欲しくなったら、スーパーじゃなくて果物屋さんに行くでしょ、と言っていて納得してしまいました。

また、企業の上場についても同様の話をしていました。

倉貫さんが取締役をしているクラシコムは上場企業ですが、スタートアップなどによく見られる、株主からの急激な成長を求めるヤジや圧力がなく、株主総会はいつも平和だそうです。理由は、IRに急激な成長を目指さないと書いてあり、配当金の計算式についても明示しているからです。IRを読めば、急激な成長を期待する投資家はつかずに、純粋にクラシコムに愛着を持ち応援したいという投資家だけに投資してもらえるとのことでした。

倉貫さんがお客さんと企業の両方が幸せになるためにビジネスを設計していることがわかりました。私個人としてもサービスを提供する側として、お客さんと楽しく仕事をするためにすれ違いをなくす努力や、そもそも仕事をしない提案をしなければならないと感じました。 ※この話には、よいサービスを持っていることが前提にあるとは思います。

既にある構造を適切に理解し、取り入れる

倉貫さんがソニックガーデンを説明するときには、聞きなじみのある言葉が出てきます。

例えば、会計士や委員会、親方のような言葉です。会計士がどのような場面で出てきたかというと、ビジネスの形態を説明するときです。ソニックガーデンはお客さんに会計士のように顧問料をもらいながら、必要に応じて追加で仕事を行い、成果に対しても報酬をもらいます。という説明をしていました。また、委員会であれば会社の決まりなどを話し合うときを指し、役職関係無く定期的に選ばれた人が参加します。

私は、倉貫さんが言葉として枯れていて、概念が揺らぎづらい仕組みを、ビジネスの要素として配置することがとても得意なんだなと感じました。ただし、仕組みを完全に理解した上でないと混乱を生むこともあるから、慎重に取り入れる必要があるよとアドバイスをもらいました。

ビジネスの幅を段階的に広げる

懇親会の席でビジネスに関する話をしていると、ビジネスは幅を段階的に広げることが必要だよという話をしてくれました。

ソニックガーデンがどのように大きくなっていったかという説明はとても興味深かったです。ソニックガーデンは5人ほどの会社で始めて、まずは「納品のない受託開発」をビジネスとして確立させることをしたということでした。次に、「納品のない受託開発」をやりたいエンジニアのための会社をアピールすることで正社員のエンジニア採用の施策を進めたということでした。

ビジネスが確実に成長していくためには1つ目の施策がうまく行くという土台を作ってから、1つ目の施策を元にした2つ目の施策を打つ必要があり、それぞれを同時に進めることは難しいことだという話でした。

似たような内容は、「ストーリーとしての競争戦略」という楠木さんの著書でも読んだことがありましたが、倉貫さんに直接お話を聴いたときの納得感は計り知れないモノがありました。

なぜかというと、ソニックガーデンの信念となるであろうエンジニアとお客さんが両方幸せになることであったり、プログラマが活躍できるということを大切にし、長期的に視点を持った施策を行っているように感じたからです。

「ストーリーとしての競争戦略」という本にも書かれていますが、単純に誰もが良いと思う施策を全てストーリーのように順番に行っても、すぐにみんなが真似をするので差がなくなります。そのため、差を作るためには他の会社が必ずしも良いとは思わない施策をする必要があります。この話の中では「納品のない受託開発」や正社員のみの雇用などがそれにあたるでしょうか。どちらも、明確に狙いがないとできない施策だと思います。

そのため、より強くソニックガーデンの信念を感じさせられました。

ソニックガーデンとメルカリの違い

私の中での成功しているIT企業イメージは、上場して株価や売上を5、10年で10、100倍に増やしているような企業です。

私は、ソニックガーデンの経営がとてもうまく行っているのに、なぜそのように急激なスケールする会社運営をしないかということも気になって倉貫さんに聞いてみました。

そのような疑問にまず、ビジネスの構造的な違いから答えてくれました。メルカリはサービスを売り物とした業態を取っているのに対して、ソニックガーデンのような受託開発を行う会社はプロフェッショナルサービスと呼ばれる業態をとっています。大まかに説明すると、人が専門的な知識や技術を使って仕事を行う業態です。つまり、プロフェッショナルサービスは人と売り上げが比例する関係にあります。線形にしか売り上げを増やすことが出来ないという構造的な理由から、目指す方向性が違うということでした。

ただし、SIerにもT○SやN○TDataのような大きな会社があるので、会社を大きくすること自体は不可能ではないという考えでした。先ほど述べた通り、会社の規模を大きくするためには一緒に働いてくれる人が必要です。倉貫さんは一つの要因として、昔はベビーブームで人が多かったため、売り上げを伸ばしやすかったのではないかと考察していました。

ソニックガーデンでは、「ビジネスの幅を段階的に広げる」の節でも書きましたが、「納品のない受託開発」をやりたいエンジニアのための会社という考えをエンジニアに伝えることでエンジニアに共感してもらい、会社の規模を大きくしていると考えられます。

私がこの話で感じたことは、無理やり残業をして売り上げを伸ばそうとか、とりあえず自社サービスをやりたいとかは、私のような一社員のミクロな視点で良い取り組みに見えても、会社全体では構造的に無理のある行動になっているかも、ということでした。

起きたことに向き合う経営をしている

私はここまでの話を聞いて、倉貫さんの話のロジカルさに感銘を受けました。なんだか、倉貫さんの計画通りに物事が進んでいるように感じました。私は、倉貫さんが計画通りに行くように不確実性を排除することを好んでいるのではないかと思い、経営で意識している観点について聞きました。

答えは全く違いました。ビジネスに不確実な要素は必ずあるので、起きたことに向き合うことは大切にしている。新型コロナのような予想のつかないことがあっても、起きたことに向き合うことで変化に適応することができる。逆にそれ以上できることはないということでした。

私はすぐに「人が増えても早くならない」のサブタイトルが浮かび、「ここでタイトル回収か!!!」と心の中で唸りました。本を買った人ならわかると思いますが、サブタイトルは「変化を抱擁せよ」です。

著者本人から自然と聞けたことで、本に書いてある言葉以上に「変化を抱擁せよ」が、私の心に深く刺さりました。また、アジャイルを体現する倉貫さんとお話をすることで、私の中でアジャイルという概念が芽生えてきた気がしました。

「人が増えても早くならない」を読んで

「人が増えても早くならない」を読んで感じたことも、振り返りたいと思います。

私がイベント前に本を買って読んでみたときは、あまり特別なことは書いていないという感想を持ちました。また、非エンジニアに向けた本と導入部分にも書いてあるため、非エンジニアの方に読んでもらえればいい本なんだなというくらいに思っていました。

しかし、富山で開催したイベントでイメージはだいぶ変わりました。

富山で行われたイベントには、発注者としてシステム開発に関わっている方が多く参加されていました。

発注者の視点での話を聞くと、本に書いてあるような話がたくさん出てきました。例えば、リリースには間に合ってない上に、仕様通りできていないソフトが納品されたり、仕様通りなのに思っていたものと違うという具合です。私から見た発注者の方々は怒っているというよりも、困っているという様子でした。

しかし、倉貫さんと参加者が話をしていく様子を眺めてわかったことがあります。発注者と受注者はどちらも業界の慣習となっている契約方法や仕事の進め方をそのままプロジェクトに当てはめているということでした。その結果、契約通りにシステムができたかに焦点が当たり、お客さんが本来欲しかった価値から関心が外れてしまうということが分かりました。

私はこのイベントを通して、システム開発は開発者が考える良い製品を作れば良いわけではなく、お客さんとの関係性を含めて作っていく必要があることを学びました。

富山のイベント後に改めて「人が増えても早くならない」を読み返すと、お客さんと話す上で価値観や言葉の意味を合わせておきたいトークテーマがずらっと並んでいるように見えました。また、お客さんから良かれと思って本書の原則から外れるような提案をされたときは、その提案の結末を一緒に考えてみるといいのかもしれないと思いました。

また一度、価値観や言葉の意味が揃ってしまえば、本当に求めていることについて集中して考えることもできます。

本書に書かれている内容や言葉はとても簡潔に書かれていますが、とても選び抜かれた言葉選びをされていると思います。筆者の倉貫さんと直接話してみたから感じることですが、本書で書かれている言葉の一つ一つが誰にとっても意味や意図が変わらないように丁寧に磨かれています。より深く本書の価値を感じるためにも、今使っているカタカナ語や専門用語を一般の人がわかる形で定義し直してみると良いのかもしれません。

焙煎時のマンダリンオレンジについて

きっかけ

焙煎をしているときに、よくマンダリンオレンジのフレーバーを感じることがある。 全くもって根拠のある話ではないが、現在のところの考察を書きたい。

マンダリンオレンジと焙煎

マンダリンオレンジのフレーバーを感じるときは1ハゼ近くまではカロリー過不足もなく、適度な焙煎ができている状態が多い気がする。 その後の1ハゼ前後になってからの火力が適正より1.2倍くらい高く、ファンが中程度の状態で起きる気がする。 ベイク傾向であり、イメージとしてはフレーバーの発言が火力が少し高くなったことで、少ししか進まなかったのではないか。 シトリックなAcidityとベイクが混じってマンダリンオレンジに感じるのではないか。

また、個人的にはフレーバーはクリーンな感じが好きなので、Fanを強めに設定するなどしてベイクとカロリーを弱める方向に対策をしている。

コーヒー焙煎のディフェクトについて

概要

ディフェクトはコーヒーを焙煎したり、抽出したりする時に発生し、飲んだ時に美味しくないと感じる味覚の要素です。(柴田の定義)

焙煎を美味しくするためには、ディフェクトを減らすことが重要

ディフェクトを減らすためには、減らしたいディフェクトの味と出現理由を知る必要がある。

消したいディフェクトの種類

ディフェクト自体はいくつかあるが、私が焙煎するときに感じやすいディフェクトを書いていく。

アストリンジェント

Googleなどで検索すると、収斂みをもつ渋みという説明があるように、 柿の皮やたねを食べた時に感じる渋さのことをアストリンジェントという。 口の歯や歯茎、口の裏(硬口蓋)、舌などでキュッとしたが萎むような味覚がすると思います。 英語でAstringentは収斂という意味があるらしい。渋いではないのね!

私の焙煎では特に表面の付近で熱が足りずに起きるのではないかと感じることが多い。(未検証) なので、表面に十分に熱を加える必要があると感じている。 焙煎の操作でいうと1ハゼ前にRoRが上がりすぎて、急に中に熱がかかりすぎた場合に起きるのではないか(未検証)

12/12更新 初めはイエローになるまでファンを一番弱くしていたが、Astringentがひどかった。 たまたま、プロファイルを間違えて、ファンを少し開けた状態で焙煎したところかなり改善された。 いわゆるい水抜きができていなかったことで最後まで水分が残ってAstringentを生じさせていたと考える

ドライ

ドライはそのままではありますが、喉が渇いたような感覚になる状態を言います。 コーヒーが喉を通った後の後味が喉風邪になったような喉のイガイガ感が感じられたら、ドライだと思います。

私の焙煎では、本当に中まで熱が通っていない時に起きやすい気がします。 なので、熱を十分にかけて、中まで熱を通す必要があると考えています。 焙煎の操作でいうと1ハゼ前後でファンを開きすぎて、表面だけに熱がかかったり、単純に火が弱すぎて起きてしまうことが多い気がしています。

ハーシュ(harsh)

ハーシュは英語で調べるとトゲトゲしいという意味があるように、攻撃的な味です。 自分はピリピリするという表現をよくします。お店でたまに深煎りで焙煎されたコーヒーを飲むとピリピリを感じる時があります。

私の焙煎では、1ハゼ前後で急に熱を加えすぎた時におきやすいかなと思います。 焦げてはいないけど、ピリピリするなという時はハーシュだと思ってます。 焙煎の操作でいうとアストリンジェントと同様に、1ハゼ前にRoRが上がりすぎて、急に中に熱がかかりすぎた場合があるのではないか(未検証)

まとめ

なぜディフェクトが出るのかという観点で、理解できていない部分が多いと感じた。 検証が必要。

言語化について

経緯

先日、ソニックガーデンの倉貫さんのイベントに参加して、言語化とはなんぞや。ということに気づいた気がするので、メモとして吐き出してみたくなった。

現象

ソニックガーデンの倉貫さんは、難しい言葉や新しい言葉を使わずに、真に言い表したいことを話しているなと感じる場面があった。 代表例が「納品のない受託開発」である。受託開発や納品は少し専門用語には寄っているが、言葉は複数の意味を持っていない。 さらに簡単な言葉を使ったとしても、お客さんに商品を納めることがないシステム開発。といった具合かと思う。

言語化とどう紐づくか

私のよくある言葉の扱い方に多いのが、流行り言葉や「やばい」といった、意味のまだ固まっていない言葉を使って会話をしている風を装うことだ。 なぜよく使うかを考えると、言葉の意味がその場所の状況や流行によって決まることで、その場では意味を他人に説明したり考えたりすることをしなくてよいからだと感じている。逆に考えると、流行り言葉や「やばい」という言葉は後から文章で見返しても意味が通じなくなるということでもある。 つまり、言語化という作業を真に行うためには、時代やその場の状況によらない言葉を使う必要があるということに私は気がついた。 倉貫さんは事業を言い表すのに、言語化を正確に行なっていると気づいた。

今の自分が考える言語化とは

早速、今の気づきを実践してみる。 自分にとっての言語化とは、物事や概念を、時代や状況に左右されない形で言い表す作業である。 言い表す言葉として使用できるのは一般的に通じる言葉だけである。 もし仮に新しい言葉を使って一言で言い表すとしたら、時代や状況に左右されない言葉で丁寧に定義して、常に人々に意味が通じるまでに行動で示し続けることをしないといけない。

その他の気づき

私が人に話をする時は主語をつけずに述語だけを使うことが多かった。 次に同じ状況が起きたら、一度時間をかけて主語の言語化を行ってみたいと思う。

PencilKitとSwiftUIでApplePencilの筆跡の情報(CGPoint)を取得管理する.

はじめに

最近iPadを買ってアプリ開発したいなと思って簡単なアプリを作ってみました.

検索してみたら,ApplePencilから情報を取得するプログラムや,ApplePencilKitを使ったプログラムは見つかったのですが, ApplePencilKitからswiftの一般的な座標情報であるCGPointを取得するプログラムがなかったのでいろいろ探してみました.

iOS: Apple Pencilから情報を取得する|TechRacho by BPS株式会社

たった3行のコードで PencilKit を導入して Apple Pencil 対応 - Qiita

PencilKitでApplePencilの筆跡情報を取得する

コードはGithubに挙げてあります.

github.com

PencilKitの筆跡情報は PKCanvasViewで管理されており, PKCanvasViewで作成したインスタンスのPKCanvasView.drawing.strokesにPKStrokeとしてストロークの配列が格納されています.

また,PKStrokeはPKStroke.pathプロパティを持っており,PKStrokePointとして1ストローク分の筆跡情報が格納されています.

そして,PKStrokePoint.locationが筆跡の1点を示すCGPointです.

これをコード(PKStroke2CGPoint.swift)ではfor in でパースしています.


func PKStroke2CGPoint (strokes: [PKStroke])->[[CGPoint]]{
    var cgpoints: [CGPoint] = []
    var cgpointList: [[CGPoint]] = []
    cgpoints = []

    for stroke in strokes {
        for strokePoint in stroke.path {
            cgpoints.append(strokePoint.location)
        }
        cgpointList.append(cgpoints)
        cgpoints = []
    }
    return cgpointList
}

動かしながら試してみてください.

CGPointで線を引く

これは,xy座標さえあれば線が引けるので,他の端末で描いたイラストなどを移すときに便利だと思います.

プログラムを作るにあたって,以下のサイトが参考になりました.

Convert UIBezierPath to PKStrokePath swift - Stack Overflow

詳しいことはあまり理解していませんが,ApplePencilの筆跡座標はBスプラインで保持されているらしく, CGPointをそのままpathとして渡してもうまく行かないらしいです.

func CGPint2PKStroke(canvasView: PKCanvasView, pointArrays: [[CGPoint]])->[PKStroke] {
    let ink = PKInk(.pen, color: .blue)
    var strokes: [PKStroke] = []
    for points in pointArrays where points.count > 1 {
        let strokePoints = points.enumerated().map { index, point in
            PKStrokePoint(location: point, timeOffset: 0.1 * TimeInterval(index), size: CGSize(width: 3, height: 3), opacity: 2, force: 1, azimuth: 0, altitude: 0)
        }

        var startStrokePoint = strokePoints.first!

        for strokePoint in strokePoints {
            let path = PKStrokePath(controlPoints: [startStrokePoint, strokePoint], creationDate: Date())
            strokes.append(PKStroke(ink: ink, path: path))
            startStrokePoint = strokePoint
        }
    }
    return strokes
}

なので変換するためのプログラムを挟んであります.

まとめ

簡単なプログラムですが,初めてswiftを書いたので少し手こずりました.個人的にSwiftUIは好きな書き方だなと思いました.

本当は筆跡情報をDeepLearingなどで加工するために,Pythonを使用することも検討していました. APIではなくSwiftにPythonスクリプトを埋め込む,KivyやBeewareが良いかなと思っていますが,なかなかうまく行かないです.

PythonとApplePencilの情報をうまく連携させる方法があればぜひコメントで書いてもらえれば幸いです.

また,コメントやいいねがいただけるとモチベになります.