企業における研究が基本的には製品をめざしたものであることは，いうまでもありません． よい製品をうみだす開発 (さらにはビジネス) と，よい研究 (論文) をうみだす研究とを両立させるのが企業における研究者の理想だと私はかんがえています． これらを両立させるにはどうすればよいのか，私にも真のこたえはわかりませんが，この問題について，例をひきながら，かんがえてみたいとおもいます．
日立の 外村 彰 (とのむら あきら) さんはノーベル賞級だが製品にはむすびついていない研究によってフェローという地位をえています． 日立はこういう研究にも価値をみとめる会社です． しかし日立の研究者がみな外村さんのように優秀だったとしても，かれらがみな外村さんのような研究をしていたら，会社はつぶれてしまうでしょう．
製品を開発する技術者は設計・製造に必要な知識を獲得して，実際にそれを設計します． 企業研究者もそれにちかい作業をおこないますが，現在の製品の開発に埋没することなく，より応用のきく技術を開発する必要があります． そのためには，製品開発のなかでぶつかる課題を分析して，より普遍的な問題をみつけだす必要があります． そのためには，ぶつかった課題を数理的にモデル化 (抽象化) することが有効です． 適切なモデルをみつけて，それにあった手法を適用する必要があります． 適切なモデルをみつけるためには，さまざまな数理モデルを知っている必要があります． 重要なモデルは大学で学習しますが，さらに学習をかさねることによって，よりさまざまな状況に対応することができるようになります． 研究にかぎらず企業での仕事の際に問題をモデル化しなさいということを，私も東大在学中に講義をきいたことがある，すでになくなられた米田信夫先生がプログラミング・シンポジウムでおっしゃっていたのをおもいだします．
たとえば，私は入社してまもなくベクトル計算機のための Fortran コンパイラの開発 (ベクトル / 並列計算機のためのプログラミング言語処理) に従事しましたが，ここでプログラムのベクトル化 (並列化) が可能かどうかを判定するアルゴリズムを開発して，実際にコンパイラにくみこみました (Compiling Algorithms and Techniques for the S-810 Vector Processor)． この課題は入社したての私にとって適切なものでした． モデルとしてはコンパイラの本によく書いてあるデータフロー解析のためのプログラムのモデル (基本ブロックを単位とするグラフ) をつかうことができました． 既存のコンパイラにおいてすでに基本ブロックへの分割がなされていて，かつ手順としては通常のデータフロー解析の手順をあてはめればよかったので，私の仕事はほとんど各基本ブロックにわりあてるべき変数をみつけることだけでした． さいわい，データフロー解析の手順を適用することによってベクトル化可否がこたえとしてえられるような変数をみつけることができました．
つぎの Fortran コンパイラの開発 (スカラー計算機のためのプログラミング言語処理) においても，データフロー解析のモデルがやくにたちました (大域配列データフロー解析法) が，詳細はここでは省略します． この開発ではまた，整数論やそれをとくためのディオファンタス方程式をモデルとしてつかいました． これらもまた，まえのコンパイラをてがけていたときにしいれた知識です．
最近ではこれほど数学との関係が明確なモデルがつかえなくなって，やや，みとおしのわるい仕事をするはめにおちいっています． もしかすると，もっとちがったモデルを学習するべきなのかもしれません．
