【マイレース開発記録(4)】
Swiss Ephemeris導入で詰まる
Yoko次の課題は「本物の天体の位置」を計算すること
前回までの開発で、マイレースの基本的な仕組みが少しずつ形になってきました。次に必要になったのは、実際の天体の位置を計算する機能です。
そこで導入したのが、天体計算用のライブラリ「Swiss Ephemeris(pyswisseph)」でした。
「ライブラリ」とは、プログラムを作るときに使える、便利な機能をまとめた部品のようなものです。すべての計算を自分でゼロから作るのではなく、既存の技術を活用しながら、アプリに必要な機能を組み立てていきます。
インストールできても、すぐには動かなかった
Swiss Ephemerisのインストール自体は、問題なくできました。ところが実際にプログラムから天体の位置を計算してみると、思ったような結果になりません。
最初は「自分が書いたプログラムが間違っているのかな」と考え、設定を変更したり、天体データを読み込む場所を指定し直したりしてみましたが、かえって動かなくなることもありました。
ここで一つ学んだことがあります。
分からない部分を、想像だけで直さない。
これは今回の開発で、とても大切だったことの一つです。
本当の原因は「時間」の扱いだった
さらに調べていくと、大きな問題が見つかりました。
マイレースでは、日本に住む人が入力することを想定しているため、時刻を日本時間(JST)で受け取ります。一方、天体計算はUTC(協定世界時)を基準に行う必要があります。つまり、
日本時間 → UTC → 天体計算用の時刻
という変換が必要だったのです。ところが最初のプログラムでは日本時間をそのまま計算に使っていたため、計算する時刻が約9時間ずれていました。計算式そのものではなく、計算する前の「条件」が間違っていたのです。
AIと一緒に原因を一つずつ確認した
問題が起きたとき、最初はどこが原因なのか分かりませんでした。そこでAIと対話しながら、可能性を一つずつ確認していきました。
- タイムゾーンは正しいか
- 日本時間をUTCへ変換しているか
- 計算に渡している時刻は正しいか
- 入力するデータの形式は合っているか
こうして問題を細かく分けて確認していくうちに、原因を見つけることができました。
以前の私は、エラーが続くと「全部分からない」と感じてしまうことがありました。今回は、
大きな問題を、小さな確認項目に分ける
という方法で、一つずつ進めることができました。
高性能な道具ほど「使う前の確認」が大切
今回の経験から、高精度な技術を使えば自動的に正しい結果が出るわけではないことも学びました。たとえば、
- どんな単位を使うのか
- どの時刻を基準にするのか
- 入力データの形式は正しいか
- ライブラリが想定している条件は何か
といった前提条件を、事前に確認する必要があります。
これはプログラミングに限らず、仕事にも共通する考え方だと思います。作業を始める前に条件を確認する。分からないことは推測せずに調べる。問題が起きたら、一つずつ切り分ける。今回の開発を通して、そんな仕事の進め方も学ぶことができました。
苦手な「環境構築」にも向き合えた
私は発達特性の影響もあり、以前はパソコンの環境設定でトラブルが起きると、
- 何が原因なのか分からなくなる
- 情報が増えると混乱する
- 焦っていろいろな場所を変更してしまう
- 途中で諦めたくなる
ということがよくありました。
今回も、すぐに解決できたわけではありません。それでもAIとの対話を使いながら「今、何を確認するのか」を一つずつ整理し、確認した結果を見てから次の作業へ進むようにしました。これは、今回の開発を通して身につけたいと思っていた進め方でもあります。
「詰まらないこと」より「詰まったときに戻れること」
プログラミングをしていると、分からないことやエラーはどうしても発生します。だから今は、
一度も失敗しないことより、失敗したときに原因を整理して戻れることの方が大切
だと考えるようになりました。
今回のSwiss Ephemeris導入でも、何度か行き詰まりました。それでも、
問題を分解する → 一つ確認する → 結果を見る → 次へ進む
という流れを繰り返すことで、最終的には正常に計算できるところまで進めました。
詰まったけれど、そこで終わらなかった。それが今回の開発で得られた、一番大きな経験だったと思います。
次回予告
Swiss Ephemeris導入は、単なるライブラリ追加ではありませんでした。
それは、
- 時間とは何か
- 計算基準とは何か
- データの前提とは何か
を考えるプロセスでした。
そして私は次に、
「ユリウス日そのもの」と本格的に格闘することになります。
次の記事では、
を書いていきます。
