大阪・新大阪から米原へJRで行く最安手段は？

移動する機会がありましたので検討しました。検討結果は最後にまとめています。

JR大阪駅からJR米原駅へ、また、JR新大阪駅からJR米原駅へ行く場合の価格について比較。彦根・長浜へ行く場合も同様に切符を選択します。 （2015年1月現在：消費税8%含む）

在来線の場合（大阪から米原まで新快速で所要時間は83分）

（1）正規運賃

何も考えずに切符を買うとこの値段になります。 大阪→米原、新大阪→米原はともに片道運賃1940円です。

（2）区間を分割して購入

大阪から京都までは特別運賃が設定されているため、大阪→京都と京都→米原と切符を分割購入することで料金が安くなります。

分割すると合計で1700円となり、片道▲240円の節約になります。 （大阪→京都：560円、京都→米原：1140円）

（3）昼得切符を購入

使用できる時間帯に制約のある回数券です。 大阪から京都までの切符を昼得切符にすると、12回分で3800円なので1枚当たり317円。 合計すると片道一回あたりが1457円相当となり、片道▲483円の節約です。

土曜・日曜・祝日の休日ダイヤの場合は終日、昼得切符が利用できます。 また平日の場合も特定の時間帯（朝10時から夕方17時）であれば、昼得切符が利用できます。 ただし、切符を分割する場合は、乗車するときと降車するときの両方が昼得切符の時間帯である必要があります。

（4）青春18切符を購入

春・夏・冬の期間限定で使用できる1日乗り放題の切符で、5回分で11850円です。 したがって、1回あたりでは2370円です。 日帰りで往復する場合、正規料金は1940円×2=3380円なので、往復で▲1510円の節約です。

乗り放題切符なので、大阪駅や米原駅からさらにJRに乗る場合はさらにお得度が増します。

（5）企画切符を購入

季節によっては関西1dayパスが発売されます。 JR西日本の大阪近郊のほとんどの路線に乗車できます。

指定区間の1日乗り放題で3600円です。 日帰りで往復する場合、正規料金（3380円）に比べて、往復で220円損になります。

大阪駅から神戸・和歌山方面へさらにJRで移動する場合、 米原駅から長浜方面へさらにJRで移動する場合、 なんども乗降する場合には企画切符のメリットもでてきます。 往復するだけであれば、金券ショップの価格を考慮すると利用シーンはないでしょう。

（6）参考：金券ショップでの実売価格

昼得切符の場合、片道1500円程度で販売していることが多いようです。

青春18切符や昼得切符はバラ売りはしていませんので、1往復しかしないのであれば、大抵は金券ショップのほうが安くなってしまいます。

新幹線 自由席の場合（新大阪→大阪の所要時間は36分）

新大阪→米原は所要時間36分（在来線より約45分速い）
大阪駅から米原駅の場合は、在来線(4分)と乗継時間を考慮すると約50分（在来線より約35分速い）です。

（1）正規運賃

新大阪→米原で購入：片道4420円

（2）区間を分割して購入

新幹線は一駅区間だけの乗車の場合、少し運賃が安くなります。あらかじめ分割して購入しておくと安くなります。なお、乗越清算の場合は正規運賃と同じになるため、あらかじめ買っておくところが重要です。

大阪・新大阪→京都、京都→米原で購入：（1420円＋2220円＝）片道3640円。片道▲780円の節約です。

（3）企画切符を購入

「シャトル切符」という企画切符がJR東海から発売されています。 ただし発売は米原の東隣の駅の醒ヶ井駅〜大垣駅までの各駅となります。 また発売駅から新大阪駅までの往復切符で、途中下車ができないということになっています。

醒ヶ井から新大阪までが往復で4940円です。別途新大阪から大阪までの在来線 片道160円を買うとすると、大阪駅から醒ヶ井駅まで往復で5100円になります。

①企画切符の条件として、米原→新大阪、新大阪→米原の順でしか乗車出来ません。そのため、新大阪→米原、米原→新大阪と乗る場合には向きません。切符の有効期間は二日間なので、２日連続で大阪から米原へ向かうのであれば、使うことも出来ますが…。

②途中下車ができないので、本来なら米原→醒ヶ井、醒ヶ井→米原と往復する必要があります。よって、米原〜醒ヶ井の200円の運賃と、往復10分＋乗換待ち時間が必要になります。と、すると、所要時間の短縮効果が薄くなり、所要時間と金額を考えると在来線が優位です。米原から大垣までの東海道線は本数がかなり少ないので、新幹線との乗継を考えるとロスが多くなります。

③米原〜醒ヶ井の200円運賃だけ買って、米原〜醒ヶ井を往復して乗ったことにすると時間的にはメリットが残ります。ただし、私にはこれが合法なのかはわかりません、旅客規則やシャトル切符の条件を確認する必要があります。

④醒ヶ井〜新大阪の往復切符なので、醒ヶ井から米原区間の権利を放棄したことにできないのでしょうか？実際、インターネットを検索すると米原から乗車したり、米原で降りている人がいるようです。これが認められているのかは私にはわかりませんでした。途中下車と違って、残りの米原〜醒ヶ井を乗るわけではないので問題ないのでしょうか？

（4）金券ショップ

この区間は金券ショップでの取扱量は少なく、したがって割引額もほとんどありません。

まとめ

在来線と比較すると、新幹線は往復70分短縮を3000円で買う、というコスト感覚になりそうです。

結局、在来線で昼得切符を活用するのが一番コストパフォーマンスが良さそうです。 大阪駅からなら大抵は座れますからね。

技術英文の書き方〜仕様書を英語にするにはどうしたら良いのか？

エンジニアであれば、英語で技術文書を書く必要に迫られることもある。近頃の会社では「オフショア」だのと言って、海外の会社に英語の仕様書を提示する必要も出てきているのではないだろうか。 さらに悪いことに、技術文書ならではの特有の表現とか、特有の文法があるに違いない。

私は英語が苦手だ。英語を読むくらいならC言語を読むほうがマシだ。中学英語までの平易な英語でなければ書けないし、単語もほとんど分からない。

なので、どうやって技術英文を書けばいいのかを考えてみた。結論からいくと方法は、「専門の本を読む」「多言語対応ソフトウェアを参考にする」となる。

特有の言い回し

コンピュータならではの特有の単語というものがある。 幸いカタカナ語が多いので、「ダイアログ」「スワイプ」など、大抵の用語はそのまま英語にできそうだ。 だけども、「名前をつけて保存」のような変化球には対応がしづらい。

UIに関する言い回しは、特有の専門語となっているけれども、日本語と英語が一対一に対応しやすい。

私のおすすめする、対応関係を調べるため手段は：
(1) 英語版で使ってみる。
(2) OSSなどの言語切替用の翻訳ファイルを参照する。
という二つの手段だ。

(1)は当たり前で、使ってみればどれとどれが対応しているのかがすぐわかるのだ。AndroidやiPhone、LinuxといったOSは設定で簡単に言語を切り替えることができるし、Webサービスでも世界展開しているものを活用すると雰囲気がわかってくる。

(2)は(1)の応用である。他言語化されているオープンソースであれば、①そもそも他言語化されているような有名プロジェクトであれば、翻訳の質も高い、②翻訳されたファイルを比較しやすい、というメリットがある。

ではどうやって翻訳ファイルを検索すれば良いのか。 これにはGoogleの拡張子検索を活用するのが良い。 gettextというライブラリを使って多言語化している場合、 翻訳ファイルは拡張子が「po」となる。したがって、Googleで「filetype:po」をキーワードに付加してやれば良い。

「名前をつけて保存　filetype:po」として検索すれば、すぐに対応する英語が「Save As」となることが分かる。 ⇒(google検索結果を見る)

文章の書き方

仕様書の書き方には特有のルールがある。日本語の仕様書だって、小説や新聞のような文体では記載されないのだから、英語でも同じと考えることに不思議はない。

こういうものは本のお世話になるのが良い。

おすすめできるほど沢山の本を読んだわけではないのだが、私が手にとって役に立ったものを紹介したい。

「技術英文の正しい書き方」佐藤洋一（著）、オーム社、2003年、ISBN4-274-19706-9

良い点は、例文の数が60個もあること（コンピュータ関連に特化したものも含む）。そして、それが今すぐ使える内容で、例文の英語を少し変えればそのまま仕様書に適用できるところだ。例えば、こんな例文が記載されている。

[基本例文(33)]
文字列が長い場合には、それぞれの文字列（CALCULATIONやTRANSFORMATIONなど）にシンボル（＊や＊＊など）を割り当てておくことができるので、例えば、＊という記号を入力してEnterキーを押すと、最初の文字列（CALCULATION）を入力したのと同じになります。

[基本例文(50)]
DELETEコマンドの対象となる画面が存在しません。

→ No screens exist for the DELETE command

この例文に対して、好ましくない英文例と、それぞれの問題点が日本語で指摘される。必要ならば、日本語の文章の曖昧な点を指摘した上で、望ましい英語例文が記載されているところが分かりやすいと思う。

仕様書にありそうな文章に対して、英語例文がある。こういう本を探していた。

C言語で処理系依存なコードを書く

プログラミングにおいては、相当な理由がない限り、わざわざ処理系依存なコードを書くことはありません。仕事なら「このコーディング規約に従うこと」「この静的解析ツールで警告をゼロにしろ」「MISRAガイドラインに従う」だの、厳しく言われるかもしれません。でも趣味の世界ならなんでもあり、やりたい放題できます！

ということで、処理系依存なコードを沢山書いてみましょう。と、突然言われてもなかなか処理系に依存するコードは出てきません。そこで、C言語の規格を参照して、「処理系依存」とされているものを順に書いてみましょう。そして、コンパイラによって動作が本当に違う！って確認していきたいと思います。

処理系依存なコードとは

2015年現在では、C言語の規格としてはC99（ISO/IEC 9899:1999、JIS X 3010:2003）やC11（ISO/IEC 9899:2011、対応するJIS規格は未発行）があります。 C99であればJISから日本語で規格を読むことができます（ただしWindows環境に限る。LinuxやMacでの閲覧は出来ませんでした）。 現在最新のC11ではJIS規格はまだありません。ISO規格の閲覧は有料となるため、C11では最終ドラフトのN1570で代替することにします。

それでは規格の「Annex J (informative) Portability issues .」 （JIS規格の場合は「附属書J.可搬性」）を参照して行きましょう。何ページにも渡って、下記の分類で「べからず集」が記載されています。

• J.1 Unspecified behavior
• J.2 Undefined behavior
• J.3 Implementation-defined behavior
• J.4 Locale-specific behavior
• J.5 Common extensions

今回はこれから幾つかピックアップして実行してみます。使用するコンパイラはgccとclangです。バージョンはgcc 4.9.2とclang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn))で実行しました。

J1: Unspecified behavior

— Whether two string literals result in distinct arrays (6.4.5). ...文字列リテラルが同じポインタになるかどうかは処理系依存

#include 

int main()
{
 const char* str1 = "hello, world";
 const char* str2 = "hello, world";
 printf("%s str1 = %p, str2 = %p\n",
  (str1==str2 ? "[Match]" : "[Different]"),
  str1, str2
  );
 return 0;
}

これを実行すると「Match」と表示されるか「Different」となるかは処理系次第のようです。GCCもClangも、デフォルトのままコンパイルすると「Match」となりました。文字列リテラルを最適化して配置するのがデフォルトなのですね。

— The order in which the function designator, arguments, and subexpressions within the arguments are evaluated in a function call (6.5.2.2). ... 入れ子になった関数の呼び出し順序は処理系依存です。

#include 

int f(int x, int y)
{
 printf("f(%d, %d)\n", x, y);
 return x+y;
}

int g(int n)
{
 printf("g(%d)\n", n);
 return n;
}

int main()
{
 int a = f(f(g(1),g(2)) , f(g(3),g(4)));
 printf("a = %d\n", a);
 return 0;
}

これはGCCとClangで実行順が異なりました。GCCでは一番右側から実行されていきます。 「 g(4) g(3) f(3, 4) g(2) g(1) f(1, 2) f(3, 7) a = 10 」
しかしClangでは、一番左側から実行されていくようです。 「 g(1) g(2) f(1, 2) g(3) g(4) f(3, 4) f(3, 7) a = 10 」 面白いですね。

— Whether or not a size expression is evaluated when it is part of the operand of a sizeof operator and changing the value of the size expression would not affect the result of the operator (6.7.6.2).

#include 

int main()
{
 int a = 1;
 size_t b = sizeof(++a);
 printf("a=%d. \n", a);

 a = 1;
 size_t c = sizeof(int [++a]);
 printf("a=%d. (will be 2)\n", a);

 a = 1;
 size_t d = sizeof(int [++a % 1 + 10]);
 printf("a=%d. (unspecified: 1 or 2)\n", a);
 printf("b=%zd, c=%zd, d=%zd\n", b,c,d);

 return 0;
}

sizeof演算子に式を与えた場合の動作で、可変長配列について規定したものです。++a % 1 + 10は++aを実行してもしなくても結果は変わりません。ちなみにgccもclangもともに1,2,2という結果でした。

J2: Undefined behavior

J3: Implementation-defined behavior

J4: Locale-specific behavior

j5: Common extensions

続きはまた次回。

おわり

分量がおおいので、今回はここまででおしまいです。

（英語力の問題もあり、誤解をしていたらごめんなさい）

追記

追記：下記サイトにて未定義動作や処理系依存のコード例と、その回避方法が記載されていました。 https://www.securecoding.cert.org/confluence/display/seccode/DD.+Unspecified+Behavior;jsessionid=9AFACDECE35236C29B02BC507735CF34 https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+Behavior

TV感想：エンジニアとして生きる根幹

新年から＜エンジニアとして生きるために必要な信念とは何か？＞、＜エンジニアとして根幹を成すものはは何なのか＞を 録画していたNHKの番組をきっかけに考えることになりました。 番組中で凄く良い言葉がありましたので、その内容を引用します。

NHK2015年1月12日放送「プロフェッショナル　仕事の流儀」第251回 ”振り切る先に、未来がある

http://www.nhk.or.jp/professional/2015/0112/index.html

以下は、NHK放送内でのマツダ・常務執行役員　パワートレイン開発担当・人見光夫氏（60）の発言からの引用です。

試すときは大きく振って試してくれ。じわじわと　こつこつとやったら人より新しい発見なんて絶対できないので、大きく振りなさいと。だって誰も行ったことがない世界へ行ったら何が起きるかですよ。

ブレイクスルーできそうな改善をひとつ、部下が見つけた時には、

目標はここまでいけば達成できるという姿をつくって その実現のアイデアを出して欲しいんだけどね。そういうのを見ると「あとここやればいい」と他のところをおやすみするから

いけるのがここと分かって、ここでやめた言う必要はないんでね。遠慮したらいかん。まだ諦めちゃいかん。必ず目標を目指そうよ。

エンジニアとして挑戦する姿勢が大事だということでしょう。壁にぶつかった時にひとつ光明が見えてくると、ついついそのアイデアだけを見てしまいがちですが、トータルとしての目標を達成するためにはひとつの光明だけではなくて、まだまだブレイクスルーが必要になってくるでしょう。そこで甘えてしまうのではなく、さらにさらにと貪欲にアイデアを試すっていうのは、追い込まれれば追い込まれるほど難しいのが現実ではあると思います。でもどうせやるなら”大きく振って”やりきってやろうじゃないか、とそう勇気付けられました。

人見氏はエンジンの技術者でした。私はソフトウェアのエンジニアです。要件定義をしたり、仕様書を書いたり、ソースコードを眺めたり、その試験をしています。そんな環境の中で、「大きく振った」アイデアとはどういう内容になるのでしょうか。とにかく安く短納期で品質を、という業界のなかで、大きく振ったアイデアとは何か？をまず考えていきたいと思います。

（開発は）一斉にやったら大きい会社の方が勝つでしょうけど、その前に何をやるかというところでは大きいも小さいもなくて、そこで考えが勝っていれば　そりゃ勝てることだってあるでしょう

絶対自分が（アイデアを）思いつく。これが一番のプライドです。次は人のものも否定しない。これも技術者としてのプライドがある人間はそうすべきだと思いますがね」

これは本当にその通りでしょう。方向さえあっていれば、あとは突き進めば良いだけ。方向を合わすことが一番難しいです。方向を合わすためには、「あるべき姿は何か」そして「現状はどこにいるのか」が分かっていないといけません。理想の姿も現状の姿も、周囲と相対化して比較しないとなかなか見えてきません。だからこそ、エンジニアなら感度を高くしていくことが大事でしょう。

アイデアは出すのに資本はいりません。考えるだけならタダ。恵まれない環境の小さな小さなやつだって、頭をとにかく使えばきっと勝てるはず！

明日からまた頑張ろう、と思える番組でした。

ブログ、はじめました。

2015年、新たにアウトプットする場として、blogを始めることにしました。

主にコンピュータプログラミングについて書きたいと思っています。

よろしくお願いします。