過去の記事
ロシアOSD（Offshore Software Development）考
OSD（Offshore Software Development）、すなわち「ソフトウェア開発の海外発注」は、国際回線を通じたデータの送受信、 いわゆるインターネットの普及によって可能となった。国際データ転送のためのITインフラが実用レベルに達した時期と、 旧共産圏の崩壊の時期が重なったことは、決して偶然ではなかっただろう。 冷戦時代はココム規制を初めとする情報隠蔽遮断政策が国家的にも経済的にも強い威力をもっていた。冷戦構造が崩れたことにより、 情報のグローバル化が飛躍的に進んだが、逆に、アメリカのCompuServeをはじめとする広域のネットワークが実用段階に達したことが、 冷戦構造崩壊を招いたともいえる。パソコン通信の技術を利用すれば、普通の国際電話回線を通じてデータの送受信が簡単に行えた。 (旧)ソ連の研究者は、その生来の人なつこさから、自作の通信ツールを使って、世界中の研究者、技術者と秘かに熱い交流を続けていたのも事実だ。
１．冷戦時代のIT事情
冷戦当時、軍事目的で開発されるアメリカのスーパーコンピュータの開発費は、今で言えば「宇宙旅行のチケット」と同じぐらいの価値があった。 他の科学技術を凌駕してスパコンの性能競争が国家の威信とされた。同じ頃、 「ソ連の科学者はIntelベースのパソコンでアメリカのスパコンと同程度の性能を引き出した。」というジョーク（？）があった。 ソ連の技術インフラはアメリカに比べて相当に遅れていたが、軍事的な技術力ではアメリカと肩を並べていた。アメリカが金を使うのに対し、 ソ連は人間の頭を使う、と言うのだ。実際、圧倒的に貧弱な技術インフラにもかかわらず、アメリカに対抗する軍事技術を実現するために、 人間の能力が極限まで試されたことであろう。
２．コピーして分解して理解
1990年代初頭、筆者は（旧）ソ連の技術者と仕事で交流する機会を持ったが、彼らがパソコンやMS-DOSの仕組みをよく理解し、 ハードの性能を活かしたソフトウェアの開発に長けていることに気がついた。当時、 ソ連製のソフトウェアとして持ち込まれたプログラムは日本のPCでは動作しなかったが、デモを見る限り、 日本では類を見ないスピードと複雑さを実現しているようであった。
IntelのチップやMS-DOS、Windowsなど、低価格の開発ツールが発表されるたびに、ソ連の技術者は、貧弱なインフラでも性能を最大限に引き出せるよう、 それらのツールの裏の裏まで研究しつくしていた。ロシア人のソフトウェア開発能力は、冷戦時代、 インフラが制限されている中で、バイナリーコードを逆アセンブリしてプログラムの仕組みを理解し、 メモリやレジスタの仕組みなどコンピュータの動作原理を全て理解した上で、実用的なプログラムを開発したところに源を発しているのではないか、 と思われる。
MS-DOS時代のプログラム開発はデバイスの互換性がなく、メーカー毎に調整が必要であり、それを行うプログラマは一癖も二癖もある職人のようであった。 そもそも開発ツールもユーザインタフェースもなかった。Windows時代になっても、開発環境が洗練されたとはいえず、プログラマは癖の強い言語仕様に振り回された。Visual BasicやC言語対応の開発ツールなどが出現した後も、プログラマ（特に日本の）はツールを使いこなすのに四苦八苦し、とても大規模アプリケーション開発どころではなかった（日本では、汎用機やUNIXが業務用として安定供給されていた時代でもある）。
このようなMicrosoftベース技術が試行錯誤を続ける間、（旧）ソ連および、その後のロシア人技術者は、 安価に入手できるMicrosoft製品（のコピーなど）を入手し、説明書を熟読し、試行錯誤を重ねて深く理解するに至った。1990年代、 ソ連崩壊と主要都市における国際間高速通信網の発達により、 蓄積した知識や技術を「オフショアソフトウェア開発」という事業に活用できるようになった。1990年代は、 それまで「パーソナル」であったMicrosoft製品が業務用に活用されはじめた時期でもある。無料の開発ツール（オープンソース）が出回り始め、 UNIXや汎用機などの安定環境を持たなかったソ連では、発展途上のWindowsやオープンソース環境が業務用、科学技術用の開発に使われ、 ロシアのプログラマはそれらに熟練していったものと思われる。 ソ連崩壊にともなってインターネットが国際間通信ツールとして日の目を見たことも追い風となった。
３．英語がOK、だからロシアオフショアはアメリカからはじまった。
もともとアメリカは広大な国で、同国人同士の取引も全てインターネットで済ませようとする国である。 アメリカ人技術者以上にパソコンやソフトウェアを理解し、国際回線を使って日常的に英語で話ができるロシア人は、 アメリカ人にとっては頼もしい「縁の下の力持ち」であった。英語ＯＫ、だからロシアオフショアはアメリカからはじまった。 アメリカがロシアにソフトウェア開発を発注するのは当然だ。アメリカ人にとって、ロシアの英語圏は、地理的には外国でも、 言語的には本国なのだ。ロシア人は「Ｗｉｎ−Ｗｉｎ」の関係にある限り、最強のパートナーでありうるし、しかもその人件費は アメリカの四分の一程度ですむ、ときている。
1990年代はロシアでパソコンや周辺機器を入手することは困難であったから、オフショアの仕事をするために技術者が行き来して、 外国からハードウェアを持ち込んだ。アメリカの顧客をつかんだロシアのプログラマ（グループ）は、夢のような開発環境を手に入れ、 収入も安定し、誇りをもって好きな仕事に専念できる。この状態を維持するために、 顧客満足や納期厳守など、本来ロシア的でない規律を受け入れるぐらいなんであろう。結果的にアメリカは、 低コストで高度技術をもち勤勉で規律正しく信頼できる開発者を確保できるようになり、その発注規模は急速に拡大していった。
４．ロシア人は優秀か？
一般に、ロシア人は「数学、物理が得意」「ソ連時代の軍事、航空開発の経験からシステム開発が得意」「基礎教育が強い」などと言われ、 それがオフショア開発成功の要因だと言われている。先進国では常に、不十分ながらも新しくて便利な開発環境やインフラが入手可能であったから、 OSや開発ツールの性能を極限まで引き出す、という探求は必要なかった。しかし旧ソ連、ロシアではそれが必要だった。 ロシアでオフショア向けの開発現場を５年以上観察した結果、ロシア人の優秀さは、情報への飢餓感から探究心が鍛えられたためではないかと推察される。
将来、ソフトウェア開発環境が整備されて、万国のプログラマが容易にソフトウェア開発ができるようになれば、 ロシア人の強みは意味を失うかもしれない。しかし現在までのところ、ソフトウェア開発環境はますます複雑化し混乱をきわめ、 更に悪いことに、ソフトウェア開発は外注するものだ、という意識が広がって、先進国の技術者が勉強しなくなってきた。 勉強すれば簡単にわかるような技術も「食わず嫌い」で難しいものだと思い込み、 それらを使いこなすロシア人やインド人の技術者を「高度技術をもっている」と持ち上げる。
先進国が白痴化しオフショア開発国が技術を溜め込む、というのは、時代の流れとしては避けられないことかもしれない。 しかし、だからといって、「サルでもわかる・・」式の教科書で勉強する日本人技術者が、 技術と英語を使いこなす外国人技術者に劣等感を感じる必要はない。環境が違うために結果が異なるのであって、 人間の能力には、差はないと考えた方がいい。できれば、彼らと競争するのではなく、彼らをツールとして使いこなす立場にいたいものだ。
５．ロシア人の優秀さ
ここでもう一度「ロシア人の優秀さ」について考察してみたい。
５．１．「ロシアのIT技術者は数学、物理が得意」？
「ロシアのIT技術者は数学、物理が得意」。これはロシアの現場にいても納得できる。大学で数学、物理、 工学を学ぶ学生は、実は小学校からそれらの専門校で教育を受けている。専門分野の知識だけでなくアルゴリズム的思考、理路整然、 几帳面さ（学習における）などは感覚的に身についている。このような人たちに矛盾だらけの日本の開発仕様を与えると、 理解されないばかりか不信感さえ持たれかねない。
私が日ロ間の開発を仲介していて、「TOYOTA車やSonyのAIBOを作った日本人が、こんな変な仕様で仕事をするはずはないから、 仕様が変なのは翻訳や仲介者が悪いのだ」と責められたことが一度ならずあった。日本人同士であれば、仕様の論理性、合理性や要件の必然性を 深く考えもせずにそのまま構築するが、論理的、数学的な美しさを追求するロシア人は、そうする必然性があるかどうか、にこだわる。
ある開発において、「社員情報の中に子供の学校名があるのはどうして？」というロシア人の質問に対し、クライアントの回答は「意味は無い。 手書き時代の前例に従っただけ。」であった。ロシア人は「必要なら入れる、不要なら外す。そもそも個人情報保護の観点からも外した方がいいのでは」 というもっともな意見を主張したが、日本側は「必要かどうか」の判断ができず（実は不要だが、前例にあるから入れておきたいだけ）、 結局相互理解には至らず、仕様未消化のままプログラマに実装を強要したこともあった（プログラマはこのような仕事を繰り返してノイローゼ気味になった）。
数学的、論理的、アルゴリズム的、必然的、ということを極めれば、必要最小限で無駄のないプログラムを作ることができ、 その後の保守でも混乱が少ない。前例や旧システムを忘れて新しいシステムをゼロから立ち上げるのはもちろん困難であるが、 「新しいぶどう酒は新しい皮袋」という西洋のことわざを思い出し、ロシア人から学ぶことも必要ではないだろうか。
５．２．「軍事、航空開発の関連でシステム開発が得意」？
「ソ連時代の軍事、航空開発の経験からシステム開発が得意」。これは背景としてはあるかもしれないが、 実際のソフトウェア開発者は20代から30代前半の若者が多く、彼らがソ連時代の軍事、航空、宇宙開発を経験してきたとは考えられない。 ITの最新技術は文字通り最近現れたものだから、技術者は最近それを習得したばかり、 開発現場ではマニュアルと首っぴきでコードを組み立てているのが実情だ。
もちろん、軍事、航空、宇宙分野のアプリケーション開発であれば専門家も多く、そのレベルも世界のトップを走るものであるから得意に違いない。 ロシア製の航空シミュレータや戦闘ゲームなどは有名だ。
しっかりした開発企業の中には、アドバイザーやコンサルタントとして、ソ連時代の大規模システムの開発経験者が鎮座していることがあり、 それはそれで大きな役割を果たしているのは確かだ。年長者の中には、アメリカなど海外で長年実務経験をもち、 現在ロシアの若者を指導しているものもいる。
５．３．「基礎教育が強い」？
ソ連時代からの遺産で今でも誇りに足るものの一つとして、ロシアの教育制度がある。外国語教育に関して言えば、一般教育、 科学技術系の教育現場では幼児期から第二外国語を体系的に教えている。論理的思考が可能な年齢になれば、原書を読んだり会話能力を磨いたりして、 実用で英語が使えるようになる。外国留学経験が全く無いにもかかわらず、下ネタやスラング、 ビジネス用途を含めてネイティブレベルで英語を運用できるロシア人もいる。
国際間取引を行うロシア企業には、ネイティブ英語で顧客と交渉できる営業担当者がいる。 彼らはロシア人お得意の小話（ロシアには「アネクドート」という笑い話があふれていて、ジョークには事欠かない。）を英語で披露してアメリカ人の心をつかむのが得意だ。
技術やロジカル思考は現場技術者も自由に使える（特にメールやチャットなどで）。IT業界で使われる英語語彙は世界共通で数も少ない。 英語文法を体系的に学んだ非英語圏の技術者が、IT用語を駆使した明確で論理的な英語を運用することはそれほど難しいことではない。 ネイティブがだらだらと説明するところを、非ネイティブは簡潔明確に説明できる。そのため仕様協議になれば、ロシア人が会話をリードすることが多い。
「基礎教育が強い」ことには、前述した「数学や物理」の専門性、教育制度の充実などとあわせて、 「娯楽が少ないので勉強に集中できる」という要因もあるものと考えられる。この理由から私は、 ノボシビルスクの技術者はモスクワやペテルブルグの技術者よりも優秀で勤勉だ、という主張を展開している。 ノボシビルスクの学術都市アカデムガラドクには、とにかく遊ぶところがない。かわりに、白樺と松の森、散歩道、 静かな住宅街、子供たち、そして冬の厳しい寒さがある。それでいて田舎のような不便さがなく、全てが充足している感じがある。 これは「白樺の癒し効果」によるものであろうか、それとも単なる私の主観、隠居生活の満足感によるものであろうか？
藤原正彦氏が「国家の品格（新潮新書）」という本の中で、天才の生まれる風土として「美の存在」「（偉大な自然に）ひざまづく心」 「精神性を尊ぶ風土（金銭や世俗的なものを低く見る）」の三つの条件をあげておられるが、アカデムガラドクの風土は、自然の美しさ、 自然の厳しさ、枠組みの決まった生活など、三つの条件を見事に備えている。そしてノボシビルスクは、 数学や物理の優れた研究者を輩出する町としても知られている。
アカデムガラドクはもともと研究者が住む町で、商業活動は不活発であるが、住民は与えられた枠組みの中で豊かに生きている。 その豊かさとは、例えば子供に上等の教育を与える、ということである。大人になれば世の不正も眼にするであろうが、 大学卒業までの若者は世間知らずの「純粋培養」という感じがするのもおもしろい。
６．ロシアIT市場は優等生か
実は、ソ連時代の実績の有無にかかわらず、市場経済になってIT事業を始めた多くの元ソ連の研究者ベンチャーの中で、 事業に成功しているのは極々わずかだ。大部分は、営業に失敗したり、顧客に嫌われたり、内部分裂を起こしたりして消滅している。 しかし次第に淘汰され、顧客満足、社員満足の両方を満たし、かつ世界市場で通用するオフショア開発事業を展開するIT企業が増えて来たのも確かだ。 その発展プロセスは、日本の戦後となんら変わりは無いかもしれない（日本は「安かろう悪かろう」と言われた時代もあった）。
また、市場経済移行からわずか十数年でロシアのIT産業は大きく成長したが、 それは若者が短期間に大きな成功を収められる市場の仕組みがたまたまあったからではないだろうか。 ロシアの行政システムはいまだ手作業が多く、新興チェーン店以外の一般のショップは、いまだにソ連時代と変わらないチェッカーを使っている。 一般家庭におけるパソコンの普及率も低く、地方都市ではまだ高速インターネット回線が利用できないところが多い。
（補足：2006年8月現在、郵便局や住民登録などは末端までIT化、データベース化されているようだ。POS管理されたスーパー、 郊外型の大型店も増えてきた。状況は劇的に改善されている。ただし大規模なインフラ投資が必要なので、 通信環境（電話回線）の優劣は都市によって差がある。）
オフショア開発など先端分野のソフトウェア開発においてロシアが台頭してくるのを確信する一方、 ロシア全土が先進国並みのインフラを整備するにはまだ10年（20年、30年）かかる、という予想も否定できない。 地球の陸地の１／６を占めるロシアであるから、単純には測れないということであろう。
７．美しき「日本流」
日本では「仕様は未定ながら３ヶ月後のカットオーバー」などと平気でいうが、この場合の「３ヶ月」というのは計画のうちに入らない。 これは無計画というものだ。しかし、日本では発注を決める前に仕様が確定していることは少ない。普通、開発請負会社が要件分析を引き受けるが、 そのやり方は、発注者が口を開かなくても、開発担当者が耳穴を掃除するようにかゆいところをさぐりあてて仕様を起こしてくれる、というものだ。 仕様分析を専門に行うコンサルティング会社やソリューションプロバイダがいて、発注者にとっては至れり尽くせり。 このような過剰サービスは、日本的な習慣かもしれないが、悪いことではないと思う。
しかし、引き受けては見たものの仕様協議に思わぬ時間がかかり、３ヶ月後のカットオーバーは無理、と判明することも多い。 その場合は、「とりあえず何か動くものを」カットオーバーして、そのマイルストーンが済んでから後のことは後で考えよう、 と問題先送りになる。これも無計画というものだ。また「仕様協議」と「とりあえず開発」を並行させるから、途中の仕様変更や作り直し、 後戻りが多い。こうして理路整然とするべきプログラムのコードが、からみあったスパゲッティとなってきて、完成後の保守の首を絞める。
インドやロシアのオフショア開発企業で採用されている「反復型プロセス」では、仕様が明確な部分についてのみ見積りをし、 絶対できる、という確信をもって開発に着手する。開発と並行して、不明確な要件を再調査し、仕様が明確化した部分から順に後続の開発フェーズを立ち上げ、 その中で「分析・設計・構築・移行」というプロセスをまわす。全ての開発フェーズで、計画や見積り精度が高く、 曖昧さやリスクを先送りしない方法である。
開発の初期段階に全体工数や期間が見えない、という欠点があるが、結果から見れば、この反復型プロセスが最も効率よく、短期、 低コストで高品質のシステム開発を実現できる、ということがわかってくる。無から有を作り出すソフトウェア開発で、 初期段階にコストを正確に予想することはもともと「不可能」なのだ。 とはいえ、結果を信じてじっと待つことができるか・・・、初めてこの手法を採用するときには忍耐を必要とするだろう。
ロシアのプログラマは原則、8時間／日、５日／週労働で、週末や休暇、誕生日休みなども習慣化している。
職場は知的労働に集中できるように配慮された、個室に近い快適な作業環境を備えている。日本のプログラマの職場環境と比べると、
これで同じ仕事をしている、とは信じがたいほどだ。
もし「反復型プロセス」とロシア並の労働条件が日本人開発者に与えられるならば、
日本のスパゲッティだってフルコースのフランス料理に変えられるはずだ。この背景の違いを無視して、日本のソフトウェアは品質が悪く、
ロシアのは良い、と断定することはできない。
しかし、私は日本を擁護しロシアを非難するためにこれを書いているのではない。それどころか、日本はロシアを見習うべきだ、 と思っている。企業にとってITリソースが単なるツールとしてではなく戦略として用いられる時代になってきている。 時間やコストなど近視眼的な価値観で適当に作るのではなく、じっくり本腰を入れて作るべきだ。 開発におけるその差は１ヶ月から数ヶ月の違いしかないかもしれないが、システムの保守にかかるコストでは何倍も差がでるかもしれない。
反復型開発、高品質プログラミングを実現しているロシアに開発部分だけを外注する、というのでもいいだろう。 共同開発を通じてロシアから身をもって学ぶことも多いはずだ。
８．日本の問題
短納期、無計画、”とりあえず開発”による開発プロジェクトの失敗は、長年多くの企業が経験し、 そればかりか日本のIT業界で常態化している（そのため、それが失敗とは考えられていない）。 低品質、長期化、コスト増を問題視する意見もあるが、対策は一向に進まない。
それというのも、「それが問題かもしれない」という意識はあるものの、現場の開発者はその状態を受け入れ、変化を望まない。 開発現場において、時間に追われ、日々発生する緊急課題に立ち向かい、チームが一丸となって解決を図るのは、 戦略ゲームに似ていて、そのプロセスが楽しいのだ。
毎日12時間働き、月に1日しか休みを取らないような生活ではあるが、開発というのは無から有を作り出すものであり、 毎日新発見があり、努力のしがいがある。チームの中で自分のアイデアが活かされる、というのはとても嬉しいものだ。 私自身がそんな生活をしていた頃、疲れた、健康に悪い、時間が欲しい、と思ったことはあるが、仕事がいやだ、 と思ったことはなかった。簡単に摂取できる栄養（サプリメントやビタミンクッキー）に頼ったり、１日が36時間なら・・、 睡眠時間が４時間で済めば・・、などと夢想したりはしたが、もし時間に余裕があれば、「もっと仕事したい、もっと考えたい」、 という欲求が消しがたくあった。
そんな経験を長年続けた百戦錬磨の戦士が、企業のIT事業部長のような立場に収まるのだから、今までの方法を変えられるわけがない。 条件が厳しくても「何とかなる」、と思ってしまうし、特に新規開発で背景や条件が分からない場合は、 「なんとなく全てがうまくいくようなバラ色の人生（プロジェクト）」を思い浮かべてしまうものだ。
企業経営者は自らITの技術や現場を知らないので、経験豊富な（どんな経験か！）事業部長を奉り、そのいいなりになっている。 遅延や変更、保守にかかる費用も、それが必要だと説得されれば、そんなものかと思ってしまう。そのようにして開発されたシステムで、 どれほどの余剰価値を生み出し得たかは不明だが、とにかく日本の経済はそれで回っていた。
ここで、働きすぎる開発者を責めることはできない。オープンソースの動向を見ても分かるとおり、開発は楽しいもの、 熱中してしまうものなのだ。
しかし、無計画な短納期、仕様あいまいなままのとりあえず開発は、今後なんとか変えられないものか。 合理的な裏づけのあるプロジェクト計画、あいまい仕様を明確に定義するプロセスを含む開発手法、 これを実現するための理論やツールが、世界を見渡せば既に実用化段階にあり、インド、 ロシアなどのソフトウェア開発請負企業はこれを使いこなして成功事例を重ねている。
９．オフショア・アウトソーシングは世界規模か？
オフショアソフトウェア開発が世界規模で拡大し、日本も負けじとその波に乗り、もっともっと、という風潮があるが、 はたしてオフショアソフトウェア開発は世界に普及しているのであろうか。事実は、世界ではなく、英語圏でだけ広がっているのである。 日本の場合は、日本語圏だけで広がっている。
国際通信回線の発達と普及により、コミュニケーションやデータ送受信における時差がなくなった。母国語が通じるならば、 相手が隣のビルにいようが、隣の国にいようが、はたまた地球の裏側にいようが、ほとんど差がなくなってきた。ただし、 母国語が通じるならば、である。特にアメリカは、英語が通じるならば世界中どこに発注しても変わりは無い。 IT技術はアメリカ製だから自分の土俵で仕事ができる。それならば安いところに発注しよう、何の問題があろうか、である。
日本も、海外発注といいながら、英語や他の外国語で海外と取引しているところはほとんどなく、 大抵は日本語によるコミュニケーションを前提としている。多くは、アジアから日本のIT企業に研修にきた技術者を本国に帰して開発を指揮させたり、 日本人が海外の開発現場に行って日本語で管理を行ったりしている。海外発注といいながら、それは真の国際交流や国際化に貢献しているとはいえない。 日本の場合、アメリカのように「自分の土俵」で仕事ができないから、海外の開発者との摩擦が大きく、海外発注は常に問題を抱えてしまう。
世界を見渡した場合、自国語を相手に押し付けて開発させているのは、アメリカと日本ぐらいではなかろうか。 ノボシビルスクのオフショア開発企業を見ても、英語以外の言語に対応した開発をしているところはほとんどない。 インドの場合も、英語での取引が基本だ。ヨーロッパ企業と取引する場合も、コミュニケーションは英語、という場合が多い。 ヨーロッパ人が英語を無理なく使えるからそうしている、というのならば問題はないが、ヨーロッパといえでも、 やはり母国語でやりとりする方がいいし、それしかできないケースも多い。伝統を重んじる国では、アメリカナイズされた考えや手法を嫌い、 あくまでも自国の伝統や習慣にこだわる人も多く、そのような国と「英語圏」のオフショア開発企業が共同開発するには、まだ無理があるであろう。
単に開発するソフトウェアのインタフェースをマルチリンガルにするだけならば大きな問題はない。そのような仕組みは、 最新のWindowsのOSや開発ツールに最初から組み込まれている。しかし海外発注の問題は、単なる翻訳や言葉の置き換えにあるのではなく、 メンタリティの違いや文化、習慣の違いをどう克服するか、ということにある。説明しても通じない、通訳自身が理解できない、 問題の所在がわからない状況というものがある。
１０．ヨーロッパでOSDが進展しなかった理由
一部の例外（ハンザのインド調達、ＣａｐｉｔａとMastekなど）を除いて、大多数のヨーロッパの地元密着型サービス企業は、 オフショア戦略をもたない。
日本でもおなじみの「オフショアの壁」- 「地元にいる」「建物内にいる（常駐）」ことが必須
- 長期的（保守的）協力（寄生）関係
- 文化障壁、言語障壁
上記の他、ヨーロッパには下記のような、オフショア開発阻害要因がある。
- 地元労働者の雇用機会損失を避ける（高い失業率が労働者市場を保護している）
- 冷戦時代を引きずった、ロシア人に対する不信感
- ロシア人の労働態度に対する偏見（時間にルーズ、無責任など）
にもかかわらず、2000年以降の世界不況が長期化する中で、海外からのITサービスを受け入れようとするヨーロッパ企業が現れ始めた。 オフショアに依頼するソフトウェアサービスはまだ「初めの一歩」のレベルであるが、コールセンターやサービス処理の分野で興味が拡大している。
オフショアの促進と阻害要因
2006年6月記