今の自分につながる現役時代の集大成的な話

自分にとっての集大成的な開発の話。60手前の元エンジニアの昔話、長いです笑。

一期目

シャープ時代、最初に配属された部署が流通機器事業で、私はお店にあるレジスタの海外向け機種の開発を担当していました。

私たちが担当している海外向けの機種は7セグメントディスプレイ（古い電卓などで使われているあれ）とドットディスプレイ（液晶の粗いやつみたいなのわかるかな笑）しかついていないものがメインだったのですが、一期目の終わり頃に液晶画面搭載モデルの開発があり、以下のような分担で担当させてもらいました。

• ウインドウ制御：先輩
• メニュー表示用ミドルウェア：私
• アプリケーション：他メンバー＋外部委託＋私

いわゆる組み込み開発で言語はC。ポリモーフィズムみたいなオブジェクト指向的な機能は言語レベルでサポートされていないので、これをミドルウェアレベルで実現することに。 といっても、その当時私はオブジェクト指向とかまったくわかってなかったので「オブジェクト指向言語的な考え方を取り入れよう」というよりも、どんな設計にしたらアプリケーションが開発しやすくなるかを考えたらオブジェクト指向言語の機能を取り入れた形になったというだけ。

しかも、基本的な考え方はウインドウ制御を担当した先輩が示してくれたので、後はそれを具体的にするだけだったけど。

（Visual C++とかもやってたけどまったく理解できなかった。後から思えばあれはMSの独自ルールが多すぎたせいだと思う）

構造体を作ってその構造体を参照する関数を呼び出すとメニューが生成されるという方式で、アプリケーション側は構造体と自分が管理するメモリだけ管理しておけば良いという形を実現した。ポリモーフィズム的な実装については構造体にコールバック関数を登録するという方式で実現しました。言語のような汎用的なもの作るわけじゃなく、自分ところの製品開発ができればよかったのでそれで十分でした。

二期目

この製品がリリースされ私は異動することになり（この異動先の話もまた大変なんだけど、また別の機会に）そして数年後にまた戻ってきました。 その頃には全面液晶パネルでタッチ操作のモデルの企画があり、またユーザーインターフェース周りの開発を担当することになりました。

前回のモデルは液晶は表示のみで操作はハードウェアキーだったのに対して、今回のモデルはすべて液晶パネルのタッチ操作。画面も大きくなり表示できる情報量も増え、表現力も増した。といってもやはりグラフィックは使えずテキストでの表現のみ（グラフィックが使えない8bitパソコンのアプリのレベル）。

一期目で開発した設計をそのまま適用したのではショボい製品が出来上がるのは目に見えていたので、この製品向けに設計をやり直すことに。

今回はウインドウ制御とメニュー制御を基本的な考え方から私が担当。ウインドウ制御といってもつまりはメモリ管理です。限られたメモリで表示を制御しなければならないので、メモリの管理まで自前でやらないといけない。

さらに操作仕様も再設計。

冒頭にも書いたように、私たちの製品の多くは表示機能が乏しい。操作は基本的に数字キーといくつかの機能キーの組み合わせで「ジョブコード」と呼ばれる機能ごとの番号を入力して行う方式でした。

この方式の場合ジョブコードをあらかじめ知っていないと操作できないので、画面上に表示されるメニューを操作する方式よりも圧倒的につかいにくい、はずなんですがこの仕様ははずせない。

それはこの方式に精通した人たちが代理店やサービスにたくさんいるからなんです。この人たちにとっては新しくて使いやすい操作よりも暗唱できるぐらいに覚えたジョブコードを使った方が圧倒的に速い。

新しい便利な操作があるなら古いのはもういいじゃん、開発もその方が楽だし。って話なんですが、もし私たちがそれを切り捨ててしまったら、代理店は扱いにくくなりサービスのメンテナンス性も下がってしまう。toBの世界で代理店に嫌われるということはこの世に存在しないのと同じ。

to Bではレガシーとっても大事。レガシーとひとことで片付けるなかれ、そこには歴史があるのです。

というわけでこの二つを両立させる操作仕様を考え、それを実現するミドルウェアを設計し実装していきます。

開発経験がある方ならわかると思いますが、ミドルウェアを作るということは当然アプリケーション開発者向けにドキュメントをきちんと整備しないといけない。ドキュメントだけでは学習コストが高いのでリファレンス実装を示す必要がある。

アプリケーションの作り方も考えた上で、リファレンス実装を示します。

ここまでで

• 操作仕様
• ウインドウ制御
• メニュー制御
• アプリケーションにかかる設計とリファレンス実装

と結構広範囲にやってたことわかっていただけるでしょうか？（号泣）

もちろん、それらは綺麗に進むわけもなく、開発途中に設計の見直しも発生します。ミドルウェアの設計の難しさは「どこまでをアプリケーションがやって、どこからをミドルウェアがやるのか」の線引き。

ミドルウェアが大部分を引き取ってしまうとアプリケーションの開発が楽になる一方、自由度が下がってしまうので特殊なケースが発生すると個別の対応が必要になってしまう。

それらが最初に見通せていればいいのですが、開発途中で発覚することがあるので、その時点で見直しを行う。ミドルウェアの見直しを行なって設計仕様を変更すると当然アプリケーションの実装に影響がでる場合がある（でない場合もあります）。

アプリケーションの実装に影響が出るとしても、将来的なことを考慮して設計変更を行うべきと判断した場合には仕様変更を行います。仕様変更（主にはアプリケーションインターフェースですが）が発生した部分はアプリケーション側もコードの書き換えが必要になります。

当時の私たちの開発ではアプリケーションは外部委託先がメインだったので、そこに影響がでるというのは嫌がられる。追加工数が発生するのはもちろん、不具合が発生した場合の責任問題もあります。

ミドルウェアの変更に伴うコードの書き換え作業、ならびにそこに起因する（と考えられる）不具合の発生に対する責任は取るという条件でアプリケーションのコードの書き換えもやりました。もしかすると今時だと考えられないのかもしれませんが、その判断をさせてもらえたのはよかったです。

開発は大変だったけれど…

そんなこんなで開発は難航し、日程は遅れ、委託先にも散々文句を言われましたが、完成した製品には超満足しています。操作性、アプリケーションのメンテナンス性、拡張性をバランスよくできた開発だったと自負しています。

その製品が発売になり、現地（ドイツだったと記憶しています）の代理店向けお披露目会でも好評で特に使い勝手の部分での評価が高かったと現地の担当者から連絡をもらいました。

事実、デモ機の操作で戸惑う人はほとんどなく、戸惑った人も他の代理店の人（シャープの担当者ではなく！）が教えあっている様子があったと聞いた時には最高に嬉しかったです。

振り返って

この開発、それまでの自分の経験が全て生きた＋さらに新しいことを学んだ開発で今の自分につながるすべてのことが詰まっていたと振り返って思います。

さらにこの数年後にデザインとかブランドということに関する自分なりの考え方ができるプロジェクトに参加することになるのですが、それはまた別の機会に。