2012年9月20日木曜日

JALの高収益はゲタ履いたものなのか？

HBRの記事を読んでいて、ちょっと気になって調べたことがあるので、メモ。
（Google+に投稿してましたが、長くて読みにくいかとも思ったので、コピペですが）

JAL H.24.3 短信 http://www.jal.com/ja/investor/library/information/pdf/h24_4q.pdf
ANA H.24.3 短信https://www.ana.co.jp/ir/kessan_info/kessan_tan/pdf/tan_120427.pdf

＞「やればできるじゃないの！」という話だ。それにしても、「だったら、なぜもっと前からできなかったのか……」という素直な疑問が出てくる。華々しいV字回復は、破綻以前の日本航空の経営がいかにユルユルだったかを改めて浮き彫りにしている。
こういうのって、実態を知っている人が軽々しくいうことじゃないと思うんです。ましてやHBRで。
経営破綻したから、あれだけの人員削減を実施することができた。（というか破綻してても合理性の評価で揉めた）
あれだけ大量の人員削減は、「業績が悪いから」というだけではできないでしょうね。

本文の流れとは逆になりますが、
＞破たんを経験している日本航空の場合、繰越欠損金の優遇策の恩恵で、2018年度までにおよそ4000億円の法人税が免除される。
とありますが、税引き前当期純利益で見ると（以降、いずれも単位は百万円）
JAL：168,583
ANA：55,940


＞所得税の手前で、債権放棄によって金利負担も軽減されている（だから経常利益と営業利益の差が小さくなっている）。
期末の数字だけではなんとも言えませんが参考値として（JALは期中にかなり返済している）
     短期借入金 ｜｜ 長期借入金 ｜｜ 合計
JAL 79,088 ｜｜ 20,811 ｜｜ 99,899
ANA 57,705 ｜｜ 715,409 ｜｜ 773,114

に対して、支払利息
JAL：10,962
ANA：19,721

確かにこれだけ見ると金利は低い「かも」しれませんね。

＞航空会社の減価償却費として大きいのは、言うまでもなく高額な航空機への投資だ。航空機の簿価を比較すると、～
これを比較できる情報が十分に取れませんでした。。残念。

＞無視できないのは、破綻に伴う資産評価損計上によって、減価償却費が大幅に抑制されたということだ。これが日本航空の増益に大きく貢献している（新聞報道によると約500億円のコスト削減効果があるという）。
キャッシュ・フロー計算書から見ると
JAL：81,222
ANA：119,268

う～ん、元々の減価償却費を見てないのでなんとも言えませんが、500億円くらい圧縮されたかもしれませんが、保有していた機体の売却や、オペレーティング・リースに切り替えオフバランスしてしまえば、現時点の航空機で369,502もの資産額なので、償却期間って20年ですかね？として、例えば3割の機体を売却、オフバランスしてしまえば、ひねり出せませんかね。
まあ、他の方法も組み合わせれば、500億円はデカいとしても相当額の減価償却費の圧縮は可能だったんじゃないかと想像しています。
（繰り返しいいますが、あくまで破綻した企業であればできるという意味です）

ということから、確かにゲタを履かされているという部分に対して想定される部分もあるとは思いますし、短期的に出ている高収益とも見えるのは事実ですが、通常の企業再生として行った成果も十分見て取れるのではないかと思っています。

余談ですが、見ていてびっくりしたのが現預金の多さなんですよ。
JAL：272,475
ANA：41,867
なんと5倍以上持っている！！

営業未払金は
JAL：125,185
ANA：180,804
なので、そんなに差は無いですし、他に見ても瞬間風速的に持っているだけには見えないんです。
なんに使うんでしょうね。もっとお金返せますね。
投稿者 時刻: 0 件のコメント:

2012年9月11日火曜日

Java EE 仕様策定における問題点について（妄想）


食後の眠気を堪えられず、集中力が切れる時間帯にGoogle+を徘徊していたら、Kazunori Satoさんの次のようなポストがありました。自らの理解を確かめるように、文章に起こしてみたいと思います。
"分散システムはそれでなくても複雑で、ましてクラウドのような大規模分散システムは常軌を逸した世界。それが実現できているのは開発と運用を一体化しているから" 私もそう思います！
そのポストにあるリンク先を見ると、（続き）とあったので原点ポストを見てみると

以下のニュースが引用されていました。
Oracle が Java EE 7 計画からクラウドサポートを削除


次のポストが、
とありました。疑問が生じたので、以降のツイートも参照してみました。


その疑問を解消するために、まず、こういう解釈で間違いでなければ、同意できるというものを挙げてみます。

解釈１：クラウドサービスの開発と運用は一体でなければ難しい

これは、完全に同意できる解釈なのですが、おそらく違うと思われます。
サービスの開発と、技術開発というのは別物という理解の下、伊藤教授はツイートされているように見受けられます。

ちなみに上記での言葉について意味合いを示しておきます。
サービスの開発：例えばGmailやGoogle Calendarといったサービス自体の開発
技術開発：サービスを実装するために必要となる技術要素の開発、例えばフレームワークなどの開発。

解釈２：クラウドサービスの提供に必要となる技術開発は、運用を行う母体（一般的には企業）は同一でなければ技術開発のスピードは促進されない

これも、完全に同意できる解釈です。
伊藤教授は、これを仰りたいのではないかと、当初も、今現在も感じております。

しかし、そうだとすると、その技術開発とJava EE 7の仕様策定計画から、ある仕様が外れたこととのリンクが難しく思いました。

これも想像ですが、

現時点ベンダーに依存したクラウドサポート仕様が、Java EEの仕様に組み込まれることで標準仕様となることが望ましいという前提があるとします。その上で伊藤教授の主張が、
「Java EE 7の仕様策定が計画から遅れ、結果的にクラウドサポート仕様が落ちてしまいそうな状況に陥っている原因が、運用を知らない（運用を担っていない）人が仕様策定を行なっているからだ。」

というものだと想定すると、この主張には疑問が残ります。
その疑問というのは、

『「ある機能を担う人と、リンクする別の機能を担う人は、一体であるべき」という主張が正しいとして、はたしてどれだけのケースにおいてその人が同一人物なのでしょうか。』

というものです。

一般的にこの【一体】と言われた時、人は個人ではなく法人を指していると思われます。組織として一体となれという主張です。

Java EE 7の仕様策定のチーム運営に対する理解が間違っていれば別ですが、基本的には外部からの仕様化に対するリクエストをベースに仕様策定に望んでいると思っています。
オープンなチームとして機能しているはずで、Javaの技術者コミュニティーとして一体となっているのではないのでしょうか。

もし、上記の理解が正しければ問題点は次のいずれか、もしくは複数要因となると思います。

  1. サービスの開発や運用に従事しているJava技術者のコミュニティーに対するコミットメントが足りない
  2. Java EEの仕様策定チームが、コミュニティーとしての機能を十分に果たしていない
  3. Java EEの仕様策定チームが、最新の実装に対する理解が拙い


個人的な想像でしかないですが、上記１の要因が強いのではないかと懸念しています。
Javaはもう枯れた言語と言っていいレベルに達していると思います。すると、技術者もコミュニティーへのコミットメントが下がり、利用する側の立場が強い、もしくはその立場しか持たない人が多数になることは仕方のないことだと思います。

これはコミュニティーを盛り上げるしか、対策が思いつかないのですが、今後も暫くの間、Javaは重要な言語で在り続けると思っているので、なんとか頑張ってもらいたいものです。
投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)