--/--/--(--)


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コメント(-) | トラックバック(-) | --:--:--

2012/12/28(金)


コラムについてですが、編集部の方から連絡があり、相談の結果コメント欄を凍結することにいたしました。
コメントくださった方、迷惑を被った方、ご迷惑おかけして本当に申し訳ありませんでした。

色々悩みましたが、同じようなことが起こる可能性も考えて、コラムの続きを書くのはやめようと思います。
もし書くとしてもこっちでやろうと思います。
楽しみにしてると言って下さった方、数少ない読者の方々、これもごめんなさい。

何かありましたらこちらのブログの方へコメントいただければと思います。
ただ、ここのコメントは承認制となっており、公開については私の独断で行っておりますのであらかじめご了承ください。

スポンサーサイト
コメント(8) | トラックバック(0) | 01:36:31

2012/12/21(金)


先日、知り合いとの雑談の中でTPPの話がでた。
彼とは仕事仲間として十年以上のつきあいがある。
非常に優秀で信頼のできるプログラマだ。
彼曰く「TPPは日本にとってデメリットが多すぎるので交渉に参加すべきではない」と主張する。

いつになく熱く語っていた彼の意見を聞きながら、私は「プログラマらしい物の考え方なのかなぁ」とぼんやりと考えていた。
いわゆる俗語でいうところの「政治」をやる者とそうでない者との考え方の差異とでも言うのだろうか。
彼の言葉からは、はなから政治で物事を変えていこうとする考えを拒絶しているように感じとれた。

彼の頭の中ではTPPには厳然たるルールがあり、TPPに参加するためには絶対にこれらを守らなければならないという縛りができてしまっている。
しかしTPPはこれから始めようとしている新しい協定だ。
野田首相がやろうとしていたのはTPP参加への「交渉」であり、交渉と言うからには日本にとってデメリットとなるものについてははねのけたり、妥協点を論じることもできるはずだ。
そこに交渉の余地がまるでないなんてことはありえない。
TPPにおける取り決めやルールは、政治力・外交力を駆使して捻じ曲げてしまえばいいのだ。

もちろんそれだけの外交能力が日本にあるのかという不安もある。
しかし少なくとも交渉の場に出向くことすらやらないというのは、最初からケンカに負けているようなものだろう。
外交とは、ざっくり言ってしまえばケンカだと私は思っている。
ケンカに負ければ不利になるが、ケンカから逃げていれば後々もっとひどいことになる。

少なくとも中長期的に見れば、TPPのような国際的な枠組みは日本にとって必要不可欠だ。
十分な内需があるから大丈夫だという人は、携帯端末、音楽業界、出版業界のように外国からの黒船に駆逐されつつある状況をどう説明するのだろうか。
TPPがこれらの防御策となるわけではないが、少なくとも常に海外との競争にさらされることで特定業界が既得権益にまみれ、ガラパゴス化する要因を排除することはできるだろう。
国内向けであろうがなんであろうが、もはや経済は国際的な視野がなければ成り立たない。
ギリシャが風邪を引けば、それが日本経済にも影響を及ぼす時代だ。
経済においては、世界各国はまさに運命共同体である。
国際化の波に遅れないようTPPのような枠組みを確立していくことが急務であることに間違いはない。

仕事にだってケンカ(=政治)はある。
経営者や上層部辺りの業務と言えば、大半がこれだと言っても過言ではない。
彼らはいわゆる「政治」をやる者だ。
ケンカから逃げ回る社長がいる会社の従業員は多くの苦労を強いられる。
理不尽な話に巻き込まれたり、くだらない仕事をやらされたり、正しいことができなかったりと苦労が絶えない。
従業員(国民)なら社長(国政)に対して、まずは「ケンカに勝って来い」と交渉の場に送り出すことの方が本来あるべき姿なのではないかと私は思う。
なぜなら社長(国政)はケンカに勝たなければならない責任を負っている者だからだ。
コメント(0) | トラックバック(0) | 12:30:18

2012/12/14(金)


@IT様に投稿させてもらっているコラムに対してコメントをいただいているのですが、

優れたプログラムとは (2)

うーん、さすがにこれはどうなんだろうというような内容で、どう返答すべきか色々と悩んでしまいます。

前にもブログ内で書いたと思うんですが、ソフトウェアを工学的見地からあれこれ議論する場合においてそれが対象とするものは、主に中~大規模のプログラム開発における技術論であったり方法論であったりするわけです。
なぜなら小規模なものはどう作っても意外となんとかなるからで、あまり本質的な問題は出てこないんですね。
例えば使い捨てのテストプログラムやフレームワーク上に薄皮をひくような小さなプログラムなんかは、なんの設計もなくゴリゴリと書いちゃっていいと思いますし、むしろその方が工数が少なくてすむケースも多々あります。
もちろん小規模なプログラムの場合においても、それを利用する人が何人もいたり、長期に渡って保守・拡張する必要があれば徐々に問題が生じ始めるので、ある程度はきちんと作る必要は当然あります。

正しい知識を習得した上でこのような雑なコードを書く分には一向に構わないのですが、プログラマは自分のコードに多くの改善点があることを知らない場合が多いんですね。というのもプログラマの教育はそのほとんどが個々人の独学に委ねられており、また自分のコードについてあれこれ議論できる場もほとんどないからです。

ソフトウェアの開発技術は進化を続け、そのおかげで複雑なソフトウェアも簡単に作れる時代になりました。ただこのような恩恵の裏で下流工程の質が極端に凸凹になっているという懸念を私は持っています。こういった状況は保守工程において担当者が変わった途端に大きな問題が発生する危険性を孕んでおり、できることなら保守作業に苦労している人達をなんとかしたいと常日頃から考えています。

もはや今のソフトウェア業界においては、そのすべてを知見することなど不可能なほどに巨大な世界となっています。あれも勉強しこれも勉強しとやっていては頭がパンクしてしまうでしょう。もちろん日々学習に励むことも大事ですが、とにかく、

・疎に結合すること
・可読性を考慮すること

この二つを常に意識することがプログラム開発においては非常に重要な点であると私は考えます。
コメント(0) | トラックバック(0) | 01:39:42

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。