akiharu国はこれまで運用、維持コストに優れた量産機を作り、共和国の共通機として採用されてきた。
しかし、宇宙用I=Dのマスプロダクトは初めてであり、宇宙戦に適した機体がどんなものか分かっていなかった。
そこでシーキャットは、その開発工程で複数の試作機が作られた。
この中でよく知られているものは二つある。

ひとつは宇宙ステーションAGEHAの搭載機である。
便宜上、この機体をシーキャットアルファと呼称する。
アルファは比較的初期にターキッシュバン2を改修して作られた。
デブリの破壊を目的としており、宇宙で有効な兵装がなにかが調べられた。
アルファには操縦席や推進器はない。
コックピットがないのは、搭乗者の安全を考慮してのことである。
このサイズの機体に、熱や宇宙線などからパイロットを守る性能を持たせられるか、不安があったのだ。
そのため、操縦は宇宙ステーションから行われる形となった。
遠隔操作ということは、必然的に宇宙ステーションの付近でしか動作できない。
無線操作では太陽風や磁気などの外乱が考えられ、有線ならケーブルの長さに限界があるからだ。
そのため、AGEHA外壁に設置されたレール上を移動する形となった。
また、動力は機体に内蔵せず、AGEHAから供給される形式になった。
このアルファの運用によって、多くのデータが得られた。

もうひとつの試作機は、火星探査に使用されたものである。
こちらはシーキャットベータと呼称することにする。
ベータはアルファの設計を流用せず、新規にターキッシュバン2を改修して作られた。
アルファは動力や推進器をオミットされたものである。
これを改修し、エンジンやブースターを搭載するのは、原型機を宇宙仕様にすることと同程度の工数を必要とする。
また、アルファの開発目的はデブリ破壊であるのに対し、ベータのそれは火星探査と資源採掘である。
当然、要求される機能は異なる。
言い換えれば、アルファには火星探査に不要な機能を数多く付与されている。
これをさらに改修すれば、ハードレベルでもソフトレベルでも非常に複雑になる。
そのため、ベータはターキッシュバン2から作られた。
アルファから設計や部品、ソフトの流用は行われていない。
しかし、要求仕様のフィードバックはされている。
アルファの運用によって見つけられた問題点は、ベータで対処が試みられた。
さらにアルファの仕様書で、あいまいであったり、漏れがあった箇所も、ベータの仕様書では明記した。
akiharu国がほぼ単独で作ったアルファと違い、ベータの製造は多くの協力があった。
その中でもFEGの豊潤な資金と鍋の国の技術援助はベータの完成度を飛躍的に高めた。
ベータの運用から得たれた情報もシーキャット開発に活かされている。

シーキャットは老朽化したサイベリアンを補うため、急遽、大量生産されることが決まった。
そのため、予算や納期の面で非常に厳しい制約があった。
そこでシーキャットは活動範囲を高物理域の宇宙に限定し、第五世界での動作を保障しないことで、技術的制約を取り払った。
さらに中距離以遠の射撃戦に特化した機体とし、開発目的を限局した。
これにより開発期間は大幅に短縮された。

シーキャットは開発を効率よく進めるため、いろいろな手法が試された。
たとえば、日程管理があげられる。
日程管理とは計画をすべて完了させるのに必要な最小時間を求める方法である。
この方法で、どの作業が遅れると開発が遅れるか、あるいはどの作業にどれくらいの余裕があるかを算出し、開発に役立てている。

シーキャットの制式量産機開発にあたり、改めて「やるべきこと」を計画段階で細かく洗い出した。
これはなにをすればいいか明確にすることで、作業を進めやすくするためである。
この際、量産計画にリスクをあらかじめ織り込むようにした。
予期しない失敗や急な仕様変更にも対処できるようにするためである。

シーキャットは試作機を何度も作った。
そのため、どこが重要で、どこは手を抜いても大丈夫か、開発工数やコストはどれくらいになるかがだいたい分かっている。
その結果、シーキャットは無理のない開発スケジュールをたてることができた。

仕様書はakiharu国だけでなく、他国の要求も反映している。
akiharu国には整備士はサーラ先生のみ、搭乗者も最近まで基本職業のパイロットや猫妖精しかいなかったからだ。
開発者は、他国の名整備士や名パイロットなどに会い、彼らの意見を仕様に取り入れた。
むろん、すべての要求に答えることはリソース面で無理がある。
そこでどの意見を採用するか、宇宙で動作する他の機体を分析したうえで、仕様書が作られた。
このとき、特に入念に分析したのは、「どのような設計思想でなぜそうしたのか」である。

競合する機体と、設計の優先順位が同じにならないようにしている。
たとえば、人形は、操縦者の食費を含め、運用コストも低くなることを優先して作られている。
技術的には究められているといってよいだろう。
その燃費面で人形と同性能にしようとすれば、必然的に人形と同じような機体になってしまう。
これでは開発する意味がない。
すでにある物を作ってもアイドレス枠の無駄である。
そうではなく、多少燃費が劣っていても、火力やARなど他の面で優れていれば、開発する意味が出てくる。
だから、開発者は競合機の設計思想を入念に分析した。

こうして作られた仕様書には以下のことが明記されている。
・なぜ開発するのか？
・誰のために作るのか？
・どこで使うものか？
・なにを開発するのか？
・どのような技術を採用するか？
・原価はどれくらいか？
・納期はいつか？
この仕様書をもとに設計書が作られ、内容が問題ないか審査された。
このとき、操作手順や整備方法については搭乗者、整備士も協力して審査した。
仕様書作成段階で潜在化していた要求を引き出すためである。
ただし、大幅な仕様変更となる意見は、よほど重要なものを除き、取り入れなかった。
このタイミングでの手戻りは納期が危うくなるからだ。
同様の審査は設計書作成後に何度も行った。
仕様書や設計書が正しくなければ、完成品に致命的な不具合が混入してしまうためである。
早期にバグや問題が発見できれば対処しやすい。
なお、発見された問題は試作機のものを含めデータベース化されており、不具合の未然防止や問題の解決の参考にしている。

シーキャットはこれまでのターキッシュバンシリーズと同様、造船所で量産できるように設計されている。
これは早く大量生産し、老朽化したサイベリアンを速やかに退役させるためである。
誰だって故障しそうな機体には乗りたくないし、乗せたくない。
カマキリが共食いするakiharu国でも、それは同じである。

シーキャットは同サイズの宇宙用I=Dと比較し、装甲に優れる。
これはターキッシュバン2のフレームをそのまま利用しているからである。
ターキッシュバン2は重力下で運用を想定されたため、自重を支えられるように作られている。
また、水中で自壊しないよう、水圧に耐えられる構造になっている。
他の宇宙専用I=Dは、重力や水圧の存在下で動作するように作られていない。
そのため、シーキャットは頑丈である。

シーキャットのコックピットには二つの改良点がある。

ひとつは操作性の改善である。
akiharu国には名パイロットがいない。
そのせいか、ターキッシュバン2は未熟な操縦者を支援する機能が充実していた。
だが、熟練した乗り手がよりうまく使いこなすための工夫は十分ではなかった。
そのため、シーキャットでは搭乗者が操作系を柔軟に変更できるよう、OSが改良されている。
また、宇宙では無重力によって筋力が低下し、操縦桿やレバーが重く感じる。
ゆえにシーキャットは、パワーステアリングなど操作系の制御プログラムに調整が加えられている。
以上の変更で操作しやすくしている。

二つ目の改良は生産性の向上である。
シーキャットの原型機であるターキッシュバン2は水陸両用機である。
そのため、水中でハッチオープンしてもいいようにコックピットは高い防水性を持っている。
しかし、シーキャットは宇宙用のI=Dである。
従来機のような耐水圧性能は必要ない。
そこでシーキャットは生活防水程度に水準を落としている。
また、ターキッシュバン2では物理域制限を想定し、旧式モニターを搭載していた。
だが、宇宙戦が行われる世界はほぼ確実に高物理域である。
ゆえに旧式モニターはオミットされている。

生産性の向上はコックピット以外にも及んでいる。
たとえばセンサ類である。
ターキッシュバン2は水中で地形や敵を走査するためソナーが搭載されていた。
また、ソナーが有効でない状況を想定し、臭紋センサーも装備していた。
だが、上記のセンサは大気も水もない宇宙では無用である。
そのため、不要なセンサ類は削減されている。
それ以外にも、有効性が低い機能や部品は、取り除かれるか、安価な代替品に取り替えられている。
さらに、宇宙適応のため、追加されたものについても、既存の艦船やI=Dから流用している。
これらの工夫により量産性を高めている。
ただし、重要な部分については、従来機と同程度の冗長性を維持している。
そのため、故障が発生しても障害の影響を最小限にとどめ、故障前と同じ運用が可能である。

OSを含む各種プログラムはアルゴリズムの最適化が行われている。
アルゴリズムとは処理の手順のことで、これが悪いと無駄が発生したり、処理をまちがえたりする。
同じ処理結果を出す複数のアルゴリズムがある場合、どれがよいかは以下の項目から判断できる。
・コンピューターにかかる負荷の大きさ
・一部の機器や部品に負荷が偏っていないか？
・処理結果を出す速さ
・時間や電力などのリソースの消費量
開発者は処理の順番を検討し、正しく動作し、効率のいいアルゴリズムを採用した。

こうして作られたシーキャットはバグや不具合がないかテストがされている。
テスト方法にはいろいろな種類があり、シーキャットでは下記の順番で行われた。
1.単体テスト
　ひとつのモジュールが要求された機能どおりに動くか検証するテスト。
2.結合テスト
　単体テストが終わったモジュールを結合させて行うテスト。
　最初は二つ、三つの結合で、徐々に結合の数を増やし、最終的にはすべてのモジュールを結合させる。
3.システムテスト
　システムの要件を満たしているか確認するテスト。
　以下のようにさまざまな観点からチェックされている。
　・要求された機能を満たしているか？
　・処理速度や待ち時間など性能は問題ないか？
　・操作しやすいか？
　・障害が起きてもすぐに回復できるか？
　・想定よりも大きな負荷がかかったときの性能や機能はどうか？
　・長時間の連続稼動に耐えられるか？
4.運用テスト
　実際の運用と同じ条件で行われるテスト。

バグや不具合を見つけることはシステムを作ることより難しい。
そのため、テストには多くの工夫が加えられている。

そのひとつがバグ管理図である。
バグの数の増え方は経験的に知られており、それをグラフにしたものをバグ管理図という。
バグの増え方が多い場合はプログラムの質に問題があると考えられる。
また、逆にバグの増え方が少ない場合はテストの質が悪いと判断できる。

不具合発見のもうひとつの工夫はエラー埋め込み法である。
これはまだ見つかっていないバグの数を推定する方法である。
わざと既知の不具合をシステムに埋め込み、その存在を知らない検査チームにテストを行ってもらう。
発見された埋め込みエラーと本当の不具合の発見率が同じと仮定すれば、見つかっていない不具合が推定できる。