達人プログラマーを目指すための素質
http://1yg.net/archives/554という記事がはてブで相当話題になっているみたいです。
そんな感じで、自分の考える「プログラミングの出来る人と出来ない人の決定的な違い」は
文字の羅列に興味を持つ事が出来、理解しようと真剣に取り組めるか否か
だと思う。
この文章を頭ごなしに批判する記事もありますが、「好きこそものの上手なれ」ということで、職業プログラマーを目指す上での必要条件としてプログラミング作業に興味が持てるかどうかという点は間違っていないと思います。超一流の天才クリエーターを目指すのではなく、あくまでも職業プログラマーとしてやっていくという前提において、しかも、過酷な労働や割に合わない報酬といったことが盛んに言われるような環境で、長いこと仕事を続けていくためには「プログラミングが楽しい」と思えなくては始まらないですからね。*1
ただ、私としてはプログラムを無味乾燥な文字の羅列として捉えるよりも、よりビジュアルなクラスの構造を頭でイメージしながらコードを書くことが多いため、その「興味」を示す方向が多少違っているなとは思いますが。つまり、より右脳的発想で考えているなということはあります。私もまだ修行中の身の上で偉そうなことは言えないですが、そういう観点でプログラミングのプロを目指す上での素質のある人というのはどういう人なのかというのを私なりに考えて見ました。
まずは、当然左脳的な論理的思考が得意であるべきということはありますが、それに加えて最近のオブジェクト指向的な発想でアーキテクチャーを考えながらコーディングするというということを考えると、ビジュアル脳的、右脳的思考も重要なように思います。そうすると、たとえば、囲碁、将棋、チェスといった頭脳ゲームが得意な人というのはかなり高い確率でプログラマーの素養があると言えるのではないかと思います。囲碁では相手の次に打つ手を読むという論理思考だけでなく、定石を駆使して臨機応変にパターンを当てはめたり、石の生死の判断を求められたりしますからね。実際、こういったゲームの有段者で達人プログラマーという人もかなりいると思います。それから、ゲームということで言えばRPGやシミュレーションゲームといったある程度時間をかけて攻略するようなタイプのゲームに興味を持って相当やりこむようなタイプの人はプログラマーの素質があると思います。こうしたゲームは決められた大量のルールのある世界で、最適なストラテジーを考えるということですから、プログラミングに共通するものがあります。とにかく大量のルールを覚えるのが嫌いなタイプだとこうしたゲームは受け付けられませんから*2
あと、忘れてはならないのは学校の勉強が得意かどうかという点ですね。一般的に、教科書をいくら暗記して学校の成績が良くても*3仕事ができるかどうかには関係ないと言われます。一般的にはその通りなのですが、プログラマーの場合にはちょっと違っているかなとも思います。第一に国語、数学、英語などの基礎学力（特に高校レベルまでの）はプログラミングを行ったり本で独習する上で非常に大切な基礎となります。また、一部のクリエーターなどと言われる天才的プログラマーを除いて普通の職業プログラマーに求められるのは、要件がある程度決められた範囲で最適な実装手段を考えることになります。この点で、期末試験の範囲が決まっていて、その範囲をしっかり勉強してよい点数を取ることができる秀才タイプの人はPGに非常に向いていると言えると思います。（必ずしもオール5タイプでなくても特定の得意教科を徹底的に勉強するタイプも可）悪い言い方をすれば決まりきったパターンに当てはめることしかできないということですが、それはそれで一つの才能ではないですかね。受験数学の問題をパターンに当てはめて解いていくなどは、デザインパターンを当てはめるという行為にも近いと思います。しかも、ガリ勉君は、本をたくさん読んで勉強する習慣が当然身についていますからね。ですから、本来は学歴の高い人はPGに非常に向いていると思うのですが、残念ながらそういう高学歴の人でPGになるという人は非常に限られているようですね。
http://newslogs.browncat.org/2007/08/toudai_programmer.html
本来は潜在的にプログラミングの才能を持った人はもっとたくさんいるはずなのに、社会的地位の低さゆえかそういう適正を持った人がこの業界でPGになってくれないという事実はあるのかもしれないとちょっと思いました。
結局当たり前の結論になるのですが、論理的思考、視覚化などのセンスがある程度あって、常に勉強をする努力を怠らない人というのがプログラミングのプロとして大成するためには大切なことであると私は考えます。
*1:数年ですぐにやめていく人も多いと思うので、多くの方の指摘されるように全体としてはプログラミングが特に好きでなく仕事としていやいややっている人もたくさんいるかもしれませんが、相当ぬるい環境でない限りそういう人は仕事として長続きしないのでは？
*2:私の嫁さんがそのタイプで、ドラクエなど初心者向けのRPGでもレベル10くらいですぐに飽きてしまいます。いろいろなアイテムやモンスターの特徴を覚えるのが面倒らしいです。対照的に私はいろいろなアイテムを集めたり、ハマルとのめりこむタイプです。いろいろコレクションしたり凝り性な性格はPGとして有利なところがあるでしょう。
*3:一般的には学歴が高くても。ただし、学歴は家庭環境などさまざまな要素にも左右されるものですから、一概に名門校の卒業証書を持っていることが重要というわけではもちろんありません。ここでは勉強する努力をすることという点を強調しています。
プログラマーの才気
今日会社の上司から「読んでみて」ということで、以下の本を渡されました。
ソフトウェア要求と仕様―実践、原理、偏見の辞典 (新紀元社情報工学シリーズ)
- 作者: マイケルジャクソン,Michael Jackson,玉井哲雄,酒匂寛
- 出版社/メーカー: 新紀元社
- 発売日: 2004/04
- メディア: 単行本
- クリック: 5回
- この商品を含むブログ (19件) を見る
この本の中で、「才気」というセクションがあってその中で「フレッド」と「ジェーン」という二人の対照的なプログラマーの話が出てきます。フレッドの方は「5枚の大きな出力用紙に200程の記号、そして無数の結合線」が書かれた極めて複雑なフローチャートを唯一理解できる「才気ある」開発者として管理者から評価されています。一方で、ジェーンの方は
ジェーンの前評判はたいしたものでした。だから私たちは彼女がフレッドと同じくらい才能に満ちた人物であることを期待していたんですけどね。でも彼女、まだ私たちにはその才能を見せてくれないんですよ。私たちは彼女に非常に難しそうな問題をいくつか任せてみせたんですが、彼女が解き終えた答えをみてみると、じつは残念ながらどれもこれもそれほど難しい問題ではなかったんですよ。実際大部分のものはとても単純なものばかりでね。
ということで、その管理者からはいまいちな評価しか与えられていないというお話です。
プログラマーの才気といった場合、いろいろな評価基準があるとは思いますが、少なくともプログラミングをエンジニアリングとして考えた場合はジェーンの方が優秀だということは明白ですね。もちろん中には複雑なパズルを一瞬で解いてしまったり、円周率を何万桁も暗記してしまうといった天才的な能力を持った人もいるかもしれませんし、中にはどのように複雑なスパゲッティーコードもたちどころに一瞬で解読してしまうプログラマーもいるかもしれません。しかし、一般的に工学的と呼ばれるアプローチであれば複雑な問題を簡単な問題の集まりとして分解するとか、スマートなアプローチを考える能力の方が大切なことは明らかです。業務システムの開発のようにある程度の人数のプログラマーを集めて開発するのであれば、一層のこと「誰でも理解できる」簡単なやり方を考えるプログラマーの方が価値が高いですね。
このお話を読んでその上司がこの本を私に渡した意味がなんとなく分かったのですが、そうすると普段のプログラミングに対する私の考え方と「一般的なSIerの上司の考え方」として以前に紹介した「低スキルのPGでも開発できるための仕組みを考える」というのと方向性が完全にずれているわけではないという気もしますね。つまり、「簡単に開発できる生産性の高いプログラミングモデル」を考えるということはフレッドのようなある意味「天才」PGでなくても普通のPGで効率的に開発するということにつながるのですから。だから、ジェーンのような才能を持つ人、物事を単純化して考えられる人がアーキテクトとかチーフプログラマーにはふさわしいのではないかと思いますね。
ただし、誰にでも開発できるようにするという最終目的は同じですが、Excel表からの自動生成とか1クラス1メソッドの規約とかSIer脳の一般的な方法を押し付けるアプローチが、リファクタリングしながら問題に応じて最良のやり方を見つけるというアジャイル脳の考え方と違っているということに過ぎないのかと思いました。
PGとプログラマーは意味が違う？
どうでもよいことかもしれませんが、人によってはPGはSIer用語で、SEと単価を差別化するための用語だから、広い意味でのプログラマーという用語とは意味が違うという主張もあるみたいですね。ただし、SEがシステムエンジニアの省略なのと同じで、PGは単にプログラマーの省略語と考えることもできます。そういう立場だとDave Thomasのような達人PGというのもありだし、高収入の上級PGだって存在してよいわけですね。
プログラマーだと入力が面倒だし、文字数も多くなるので、時々、私のブログやTwitterの発言ではPGとプログラマーを同義語として使っていることが多いです。「私はPGです。」と胸を張っていえる時代にならないかなという希望もあってのことですが。もちろん文脈にもよりますが、PGという言葉には初級とか低単価のニュアンスは通常含めていません。その点ご注意ください。
OSS開発の世界にしかアジャイル脳プログラマーの活躍場所がないのはいかがなものか
アジャイル脳の対立概念はSIer脳でなくてウォーターフォール脳？ - 達人プログラマーを目指してに関連して、ここで書いておくと、オープンソース開発の世界はどう考えてもアジャイル脳のプログラマーが支配している世界だと思います。こんなことはわざわざここで書かなくても自明のことかもしれませんが、実際、OSS開発の領域でExcelの詳細設計書なんてまったく聞いたことがないですね。もちろん、OSSプロジェクトでもある程度大きな規模のものだとビジネス上、マーケティング上の判断による影響力もかなりあると思いますし、まったく自由に開発というわけにはいかないでしょうが、基本的にはコミュニティーのアイデアによって機能を追加していきます。そこでは、いかに低スキルのPGを統制するかというSIer的発想は当然無くて、いかに使いやすいAPIを提供するかなどよいソフトを作るというのが最大の目標になっています。
そういう事情を考えてみると理解しやすいのですが、最近のOSSのフレームワークは非常にアジャイル脳的な考えでできていると思いますね。実際、最近のJavaのフレームワークであれば、アノテーション（ソースコード上の設定データ）を使って、できる限りソースコード上で設計も行えるようになっています。SeamもSpringも最近は皆そういう傾向になっています。ソースと設計をいかに一体化させるか、ソースをいかに簡潔に記述するかということに非常に大きな注意が払われており、そこにはSIer脳的な発想が入り込む余地がほとんどありません。さらに、Rubyなどの世界では、この傾向がもっと顕著だと思います。
ある意味、OSS開発というのはアジャイル脳のプログラマーにとっては天国のような世界に見えます。OSSですから、参加する時間さえ確保できれば誰でも無料で開発に参加できるというのも魅力的です。（私自身も今後何かのOSSに参加してみたいなとは思っていますが、今までは非常にプロジェクトが忙しかったこともあり残念ながら一度も開発に参加した経験がありません。）
それで、OSS開発はスキルの高いプログラマーの受け皿になっていることは非常によいことだと思うのですが、日本だとOSSの成果をビジネスに活かすとかそういう機会がほとんどないのが問題なのではないかと思います。日本の会社でOSS自体でビジネスをして大成功している会社も私の知る限りあまりないと思いますし、プログラマーとしてOSS開発で得た知識やスキルを活用する機会もそれ程ありません。最近はOSSをプロジェクトで利用することはあるのですが、以前も指摘したようにSIer脳の手にかかるともともとのOSSの考え方というのは無視されて、まったく別物のフレームワークにされてしまいますし。
そのように思っていたら、実は3年も前に以下のような記事が書かれていました。
Javaを古くしたやつとRubyを煽っているやつ - yvsu pron. yas
Struts脳の恐怖とRails - Djangoへの片思い日記
ここで書かれている「Struts脳」とか「スーツ」というのが私の言うところの「SIer脳」と非常に近いなと思いますし、基本的に私の考えていることと非常によく似た事を主張しているなと思います。
私としてはOSS開発の世界に逃避するのもよいですが、最終的に実案件に成果がうまく還元されないとあまり面白くないなと思ってしまいます。アジャイル脳プログラマーの活躍場所が業務システム開発案件でもっと与えられるようになるとよいと思うのですが難しいでしょうか。
アジャイル脳の対立概念はSIer脳でなくてウォーターフォール脳？
SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？ - 達人プログラマーを目指してに対して「アジャイル脳」の対立概念は「SIer脳」ではなくて「ウォーターフォール脳」であり、「SIer脳」の対立概念は「ソフトウェアハウス脳」なのではというご指摘をTwitter上でいただきました。正確な用語の意味からはまったくそのとおりなのですが、結局
という様に繋がっているのですね。だから、「アジャイル脳 対 ウォーターフォール脳」より「アジャイル脳 対 SIer脳」*2の方がこの現在の*3業界の仕事に対する姿勢や考え方の違いに関する問題の本質をより鮮明に表現していると思います。
そうすると、基本的にはSIerでは技術力というのは優先順位が低くなり、営業力やマネジメント力が重要ということになります。また、このビジネスモデルだと当然ウォーターフォール脳の人がお金が稼げる能力が高いため、会社からも評価されて出世しやすいのではないかなと思います。
ちなみに、多くの人々のご意見を参考にすると
- SIer脳 ⇒ いかに大量の開発者をうまくまとめるかが最重要。技術力は失敗しない程度で十分。人生経験を積んだ「大人の脳」。
- アジャイル脳 ⇒ ユーザーのためにとにかくよいシステム（プログラム）を作りたいという「純粋な子供の脳」。学者や職人のタイプ。
ということになるのではないかと思います。私として、もう少し何とかならないのかと思うのはこの業界においてSIer脳が過剰に評価されて、逆にアジャイル脳が過小評価され過ぎているのではないかという点ですね。これは一般的に技術軽視とか理系軽視と言ったわが国の全般的な傾向とも関連していると思うのですが、このようなことは今になって私が初めて言い出したものでも何でもなくて、かなり前に以下のような指摘もありますね。
どうせ理系出身者なんていらねえんだよ。
ニッポンIT業界絶望論:Kenn's Clairvoyance - CNET Japan
私としてはこうした事柄について興味関心がなかったこともあり、今までほとんど考えたことがなかったのですが、ブログを付け始めていろいろ調べたり、多くの方々のコメントをいただくことで、上記の問題にやっと気づきました。今までよいプログラムを作ればいつか評価されるようになると信じて疑わなかったですからね。私のような極端なアジャイル脳の人は、SIer脳の人々の考え方を理解するように努めると今まで気づかなかったいろいろなことが見えてくるようになると思いました。
*1:SIerの下請けビジネスしかしていないソフトウェアハウスだと違うかもしれないです。アジャイル脳が活用できるのは独自のサービスを提供しているごく少数の会社にしか当てはまらないかもしれません。
*2:ウォーターフォールが常に工学的でないと主張する気はなく、技術的観点からウォーターフォールが適切なプロジェクトも存在すると思う。しかし、現状多くの場合、業務都合の理由からウォーターフォールが利用されていることが多いのではと考える。
*3:会社の形態と開発プロセスの結びつきは固定というわけではなく、時間軸に依存して変化し得る概念。あくまでも現時点におけるスナップショットとしてこのような関係が成り立つことは明白と言える。
SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？
以前Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してにて
何でもかんでもとにかく自動生成させたがる。特にExcelなどの表から大量のクラスを自動生成させるなど。たいていそのようにして生成されたクラスはゴミで保守も大変なものになりがちです。
ということを書いたことに対して、会社の忘年会で上司や同僚の間で議論が盛り上がって興味深かったので、ここで自分の考えを再度整理させていただきたいと思います。（忘年会で1次会、2次会の間ずっとこういった話題で話が盛り上がるというのはかなり特殊な部署なのかなとは思います。「SIerのやり方はXXだ」一口に言っても、それは全体的な一般傾向を表しているのであって、実際はさまざまな人々がいることを忘れてはなりません。あくまでもそういう意味で捉えてください。）
それで、私の周りにはプログラミング好き、技術好きが多いのですが、それでも自動生成の善悪については意見が分かれるようです。誤解を恐れず一言で言うと、この業界の技術者には「SIer脳」の人と「アジャイル脳」の人がいるように思います。理想的には臨機応変に両者を柔軟に使い分けられるハイブリッド脳がよいのだろうけれども、多くの場合考え方がどちらかに偏っていることが多いのですね。それで、いままでの慣習や教育というのが大きいので、数から言うと前者に偏っている人の数が圧倒的に多くて、「アジャイル脳」の人はごく少数で異端者扱いということが普通のようです。（ちなみに私は完全に「アジャイル脳」に偏っていて、会社員としては問題ありかもしれません。）
私もそうですがアジャイル脳の人は本能的に設計とコーディングが切り離せないものであるという考え方に心底ほれ込んでいるのですね。（プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して）つまり、コーディングを単純な製造工程ではなくて、著作とかデザインといった創造的な作業であると捉えています。この考え方ではコードと設計は一体であり、どちらが先か後かというのは鶏と卵の議論と同様に意味をなしません。一方SIer脳の考え方では、たとえ繰り返し型開発の価値を認める人であっても、やはり設計（書）が先で、コードはそれに付随して半自動的に製造されるものであるという考え方が根強いようです。アジャイル脳の考え方からすると「DNAの連続性を考慮するとどうしても卵が先でなくてはならない」といった議論と同様におかしく思えてしまうのですが、やはり設計書が先行しなくてはならないという考え方に囚われています。そして、ExcelにせよUMLにせよそこから自動的にJavaなどのコードを自動生成することはユーザーの目に触れる設計書とコードとのトレーサビリティーが確保される上での有効な手段であると考えます。
たとえば、Excelのテーブル定義書からエンティティクラスを自動的に生成するツールをSIer脳の人は非常にありがたがります。*1でも、私はどうしてもそういったツールは好きになれないのであって、できることであれば使いたくないと考えてしまいます。好きになれない理由としては以下のようなことがあげられます。*2
- Excel表では継承や値オブジェクトなどオブジェクトモデルを正確に表現できず、多くの場合テーブルとクラスが一対一対応するような設計に帰着する*3
- Excelと生成したソースコードとの間で2重メンテナンスの問題が発生する可能性がある（DRYの法則に反する*4）
- 自動生成ではテストファースト的な開発が困難
- 自動生成ではソースコード上で積極的にリファクタリングしたり、頭を使って設計することが困難
たとえば、以下のようなコードだったら、Excel表と読みやすさはほとんどかわらないはずです。
public class User { @NotNull @Size(min=4, max=8) private String userName; ... }
その上コードは実行可能だから設計の妥当性を簡単に試験できるし、リファクタリングによる設計変更もきわめて簡単にできます。さらに、継承やアノテーションなどプログラミング言語本来の機能をいかんなく発揮することができます。どうしてもSEや顧客がコードを読みたくないのであれば、JavaコードからExcel表を生成することは容易に可能です。このようにアジャイル脳になっているとコードこそが多くの場合設計の最良の手段であり、これを中心にしてその他の文書は必要に応じて補助的に発生する副生成物であると考えます。
まずはコード上でじっくり設計を考えた後で、説明資料として後から必要に応じて要点をUMLで文書化するという流れの方が作業手順としてしっくり来ることが私の経験上ほとんどです。コードこそが設計の本質をもっとも正確かつ簡潔に表現できる手段なのであり、UMLはそのある側面を捉えやすくする方便としての一表現に過ぎないなどと言うと怒られてしまうでしょうか？
同様に、アジャイル脳は一般的にDDLからエンティティクラスをボトムアップで生成する*5ことを好まず、エンティティクラスからDDLを自動生成するトップダウンのO/Rマッピングを好みます。この点でテーブル定義書や画面定義書からクラスを自動生成するのが望ましいと考えているSIer脳の考え方とはまったく正反対です。
なお、Excelからクラスを生成する場合、Excelを唯一のソースコードであると考えるのであれば、アジャイル脳的にもまだ許容できます。（mavenならExcelをsrc/main/excel配下に格納して、生成したJavaコードをtarget配下に生成してSVN上でも共有しない）この場合、ExcelはDSLの一種であると考えていることになります。ただ、バイナリファイルなので共有が難しいし、重いし、通常は不便で良い事無しだと思います。
もちろん、自動生成をすべての分野で否定しているわけではなく帳票作成とかビュー周りとかテストコードとか形式化が可能な分野であればよいと思うのですが、自動生成することによってドメインモデルのような最重要の領域において、コード上できちんと設計する自由を奪ってしまう*6のは私の理想とする世界の基準では悪であると思えてしまいます。
しかしながら、何が善で何が悪かということはさまざまな要素によって決まるものであり、一概に決めつけることはできないでしょう。戦前であれば他国の領土を侵略することが善であったのと同じように多数派の意見が正義であると考えられるものです。そういう意味において、現在の多くのSIでは自動生成は有効なツールであると考えられれているのだと思います。また、アジャイルなどというのは現実の仕事の進め方にマッチしないとんでもなく悪い考え方とされてしまいます。そもそも製造業のメタファーからPGが自発的に設計を考えるということを許容しない文化が非常に深く浸透しています。私としてはこうした状況は残念に思いますが、それが多くの場合、現在の業界の現実なのだと思います。
*1:こうした傾向になるもう一つの理由として会社でFWやツールを作る部署と実際に業務システム開発を担当する部署が明確に分かれているというのも原因のひとつとして考えられます。業務と切り離されていると有能なプログラマーの才能がツールなどに費やされることになります。確かに、そういったツールの開発は楽しいので。
*2:もちろん、アジャイルなRailsだってscaffoldingの自動生成機能などはありますが、それは開発初期の成果物のベースを作るものであって、設計書とコードをずっと同期するというSIer脳的発想とはまったく異なるものです。
*3:もちろんそうした設計がすべて悪と決め付けているわけではありません。ただし、そのような付加価値の低いシステムのスクラッチ開発は今後少なくなると思います。
*4:最近の傾向としてはRooのようにアノテーションなどソースコード中のメタ情報を元にバイトコードに機能を織り込むような考え方が流行かもしれません。これだとDRYの原理が保たれますので。
*5:Hibernate Toolsではこうした方向の生成をリバースエンジニアリングと呼んでいます。Javaコードが設計の中心であるという思想が表れたものと言えると思います。同僚に言ったらテーブル定義書を中心に考えてそれはフォワードエンジニアリングでしょと言われたことがあります。なにが世界の中心か、大きな思想のギャップを感じました。
*6:多くの業務システムではレガシースキーマの存在を考慮しないといけないため、テーブル設計がまず最初にありきという制約がある場合が多いという事実はもちろんあります。
どんなにがんばって教えても伸びないプログラマーの比率
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指してに対して、
センスとやる気があるプログラマの方が20人に一人もいないに一票
というような意見をたくさんの方からいただきました。私の文章力のなさで多くの人に誤解を与えてしまったかもしれません。ここで私が言いたかったことはプログラマーはきちんと指導すればほぼ確実にレベルアップするということであり、どんなに優秀なプログラマーとペアを組ませて指導してもまったく実力が伸びない人はほとんどいないということでした。
類は友を呼ぶということで、私の周りには自然とプログラミング好きが集まってくるということがあるのかもしれませんし、一般的には20人に一人というのはちょっと大げさだったかと思いました。*1ただ、私とペアプロした人は多くの場合きれいなプログラムの価値を理解してくれ、最初は見よう見まねでやっていますが、徐々に自発的にきれいなコードを書くようになっていくということはいままで何度か経験しています。
まあ、好きこそものの上手なれということで、変な規約を強制され、仕事としていやいやプログラミングさせれられる環境ではまさに、20人に一人もやる気を出すプログラマーがいなくなるというのは事実でしょう。また、先のエントリでも書いたようなアーキテクトが不在で、全員烏合の衆で開発していたらもちろん成長しないでしょう。
どんなスキルでも「才能」と「環境」があって初めて活用できるということだと思いますが、多くの場合潜在的な才能があっても、それを活かす環境が与えられず、努力して勉強しようという気にならないという点に注目すべきです。日本人の場合、英語力などは確かに障害となり得ますが、（多くの日本人がオブジェクト指向プログラミングを苦手とするのは英語アレルギーだからか？ - 達人プログラマーを目指して）もともとその人の才能がなくてどんなに努力してもスキルアップしないというケースはレアでは。確かに誰でもプログラマーになれるかというとそれはないと思いますが。
