最初のページに戻ります。

総合の目次があるページに戻ります。

よく使うマニュアルです

Wiki

updated on 2004.06.23

17.29.コモンセンス

[ Previous ] [ HOME ] [ Upper ] [ Next ]


コモンセンス

common senseとは; (経験から身に付いた)常識的な判断力、良識、分別(大修館書店ジーニアス英和辞典より)という意味です。ここでは、プログラマーのコモンセンスを書いてみたいです。結構難しいです。プログラマーを1年以上やれば、誰に教わらなくても、分かることです。

「どうあるべきか」があって、「どうすべきか」があると思います。「目的」があって、それを達成する「技術」なり、「方法論」が付いてくるのです。この「どうあるべきか」を、一言で述べる能力を私は持っていません。そこで、いろいろな例を挙げて考えていきたいと思います。

オフコンは、大抵、会社の財産である

あなたは、会社のオフコンを自分のもののように使っているかもしれませんが、それは、会社の固定資産です。もしくは、リース会社と契約を結び、借りているものです。

リース

あなたがコンピュータをリース会社から、手に入れたとすると、コンピュータを販売した会社は、あなたの会社にコンピュータを導入して、リース会社がそのコンピュータ会社にコンピュータの代金を支払います(この時点で、コンピュータの所有権はリース会社に移ります)。そしてあなたの会社は、リース会社に、月々リース料金を支払います。三角形の各頂点に、あなた、コンピュータ販社、リース会社が居る関係になります。

リースの場合、大抵、4年契約が多いです。リース物件のコンピュータの所有権はリース側にあります。したがって、借りている会社では、そのコンピュータは固定資産になりません(所有権はリース会社にあるので)。つまり棚卸し資産になりませんし、減価償却計算も勿論しませんし、税金もかかりません。また、4年たって、リース契約が終わる(リースが切れる、といいます)と後は、「再リース」と言って、大抵、1月分払っていた金額を、年額に(よって、12分の1)して、リースを続行します。

コンピュータの販売会社は、それを狙って、導入してから4年を迎える会社に、セールスをするのが一般的です。導入がいつなのかを知っていれば、それを元に、来年リース切れになる会社の一覧を、テレソン(テレホンマラソン)の女性に回したりする事が可能です。

ここで、コンピュータを商品としない、商社を考えてみましょう。あなたは、その会社の専任プログラマーとします。すると、あなたは、そのコンピュータで、ユーザーにサービスをする事で、お給金を貰っていることになります。直接、間接に、ユーザーサポートをすることがあなたの仕事になるのです。コスト(給料)しか発生しません。あなたは、外からお金を稼ぐことはしていません。売上はないのです。

あなたの立場

普通の会社は、純粋に利益を追求する法人です。営業マンが商品を売り、利益をあげ、その営業マンに、給料を出します。その給料計算をしたり、仕入れの買い掛け管理や、経費を計算するスタッフが居ます。利益からそれら経費をひいて、純粋な利益が求まります。会社が追求しているのはこの利益です。

そして、その中では、プログラマーは、経費にしかなりません。コンピュータを運用しても、直接お金は儲かりません。しかし、「支援」や「無駄な経費」を避けることは可能です。営業マンサポートの「システム作成」や、「合理的な新しいシステム」を導入したり、「欠陥だらけのパッケージ」を排除したり、が、あなたの会社への貢献方法となります。これで、売上を伸ばすようなビジネスチャンスを作ったり、下手に業務改悪をして余計な人件費をかける事無く、経費を減らしたりします。そして、その差額の「利益」を伸ばすことに貢献できるのです。システムの改善とか、BPRとか言っても、結局同じです。それがそのまま、売上にはなりません(コンサルタント会社は、売上になるでしょうけど)。

また、社内開発が完全に終わると、動きが無くなります。「運用と保守」だけになります。サービスが、コンピュータやシステムそのものにだけに向けられます。経費の比率が俄然高くなります。そこで、開発チームがそのノウハウで、別の会社のシステムを作って、その対価を貰う事(つまりは営業をすること)もあります。これは、純粋に「売上」そのものになります。自分の業務がそのまま商品(システムとかプログラム)として売れたのですから、当然、「直接」売上になるのです。これは、上記の話しとは、又別の事になります。「コストセンター」のみから「コストセンター+プロフィットセンター」になります。これは重要なことです。外資系の場合、本社が他の国のシステムを作るのも、同じ理由です。部門間の売上が考えれれるケースですね。これも、この業界では良くある話しです。良く耳にする「アウトソーシング」は(この定義は難しくて、というより、どんどん変わってしまって、捕らえどころがないのですが)、別会社に運用やシステム開発を任せる事をさすようです。アウトソーシング側は、上記の、「開発部門スピンアウト」集団も多く、それを利用する側は、「コンピュータ要員=経費」でしかない現状を何とかしようとしているようです。一人の社員が入社する、というリクルート費用だけで100万かかるそうです。これにその人の年収が、初年度かかるそうです。このことから、社員を雇うより、アウトソーシングという考えが出てきても不思議はありません。

コンピュータがユーザーの為に有るのは分かりましたよね。そして、あなたが作るプログラム全ては、最終的にそのユーザーの為に帰するのです。自分の為だけのプログラムは、あり得ません。また、プログラマーがプログラマーの支援をすることもあり得ます。ユーザー支援をするプログラマーの、サポートをするプログラマーは、間接的に「ユーザーサポート」をしたことになります。もし、あなたがソフトハウスのプログラマーだったら、話しは単純です。あなたは売れる商品を作る、工場の1ラインです。サービスがどうのこうの、は有りません。直接会社に貢献しています。

さて、今、まず、自分がどういう立場なのか、よく考えましょう。誰も、教えてはくれません。自分で考えるのです。会社の仕組み(何を売り、どんな経費があり、そのように資金が巡るのか)を知るべきです。それを知った上で、自分がすべき事(たとえば、売上に重要なセクションへのサービスを向上する、とか)を考えるべきなのです。よその会社を参考にしても良いでしょう。

プログラミング・センス

コモンセンスのセンスは、「感覚」と訳します。プログラマーとしてのセンスって、どんなものがあるでしょうか?ミクロな視点とマクロな視点が有ります。マクロな視点は、どちらかと言えば、社会人として情報を絶えず吸収する(最近は新聞よりも、インターネットで配信されるニュースの方が速くて、リンクを辿ると、深い情報が得られますね。広く浅くの雑学なら新聞や雑誌でしょう。)なんていうho-humなあくびの出る教訓話ですけど、このページの本来の趣旨は、「ミクロ的な」センスです。広義と狭義なら、狭義のほうですね。

システムは統一美を持っているべき

うまくは言えないのですが、全体が一環して、「同じ」、でなければなりません。いろいろな部分で言えます。簡単なところで言えば、ユーザーインターフェイス(画面、帳票、エラー)もそうでしょう。また、ファイルレイアウトもそうです。プログラムそのもののコーディングもそうです。さらに、ジョブ環境とか、業務の流れ、もう、考え出したら、きりがないです。みな、似ていなければならないのです。同じコンセプトを持っていなければいけません。ある時、F3で終了して、ある時はF1で終了して、ある時はF7で終了したら、ユーザーは、怒りますよね。そのバラバラな仕様に、美しさは感じません。

「統一」するためには「マンネリ」をうち破ろうなんて考えないことです。「マンネリ」で良いのです。いつも似たような画面、いつも似たような帳票、いつも似たような動き、同じ用語、同じメニュー構成、同じ、似ている...この繰り返しが「統一」です。分かっていますか?なにも、すばらしいものではなく、逆に、とても、シンプルで、単純で、つまらないものです。OS400を見てみてください。とてもいい、お手本です。いつか、そこに、美しさを感じるはずです。ほれぼれする、ほどではありません。でも、ぎらぎら、ごてごてしていない、シンプルな、統一された様式を持った「美」があります。プログラマーならそのプログラムの中に、システムデザイナーならそのシステムの中に、それを具体化していきましょう。

無駄は省く

似たような画面、と言いましたが、「冗長」は入れてはいけません。同じ事を繰り返してはいけないのです。

  1. エレガントに、無駄を無くすのです。

  2. 様々な具体的数字や式が、一個の公式にまとめられた時の、洗練さ、を思い出して下さい。

  3. 一つ定義が有るのなら、再び、同じ定義をしないのです。共有するのです。

  4. 同じロジックを、何度も使うのなら、何度もロジックを定義しないで、1つ準備して、それを使い回すのです。

  5. 有効で効果的なアルゴリズム、学者の考えた関数・公式は、プログラマーにとって、どん欲に知らなければなりません。それが、無駄を省く可能性があるのです。

  6. 事前に準備したものがあるのなら、その労力を無駄にせず、流用して、引き継ぐのです。新たに定義し直しては、無駄になります。

  7. データの正規化の、目的を学んで下さい。http://www2s.biglobe.ne.jp/~coach/onepoint/database/db_seiki.html を参考にしてみて下さい。

  8. 無駄か、必要かの判断は、時に難しいです。商品マスターの単価、と売上ファイルの単価は、重複した無駄なデータでしょうか?これは無駄ではないのです。商品の単価が、値下げなどで変わるから、マスターの単価は「最新の単価」、売上ファイルの単価は、「売上時点の単価」で冗長していません。省いてはいけないのです。

変更しやすくしよう

柔軟なプログラムやシステムを作りましょう。

「情けは、人のためならず」ということわざをご存知ですか?情けを人にかけておけば、めぐりめぐって、自分に良い報いが来る、という事です。これは、プログラムでもそうです。ある日、3万ステップのプログラムの修正を依頼されたら、どんな気持ちになりますか?まあ、一般的に言って、ステップ数の多いプログラムは修正しにくいものです。勿論、短ければ良い、のではないです。適当なステップで、誰しもが考えるロジックで、無理なく、地味に、押さえるべきところは押さえてある、プログラム。まあ、できれば、将来の修正に備えて、わざと修正箇所を、コメントで指示して於いたり、ドキュメントを残したり、そう言った全てが、やがて、あなたを救うのです。

それから、無駄を省き、共有出来るところは共有する姿勢で生まれてくるシステムは、一つの変更が、きれいに、システムの隅々までを変更してくれたりします。まあ、動的に共有されたプログラムがあるのなら、それを修正するだけで、システムが変わります。でも、だからと言って、何でもかんでも、独立したプログラムで、それを共有するのは考え物です。今度は「柔軟性」と「資源」のトレードオフが発生します。

バランス感覚

「トレードオフ」という事が、よく出てきます。「同時に成立しない、二律背反の関係」のことです。

たとえば、外部サブルーチンは、プログラムが独立していて、何度も呼び出せるので、ルーチンの共有化にもってこいに見えます。しかし、500本のプログラムが、一時に、1000個の別々の外部サブルーチンを、間断なく呼び出したら、AS/400への負荷は、きわめて高くなります。「外部サブルーチン」ではなく、「内部サブルーチン」に出き無かったのでしょうか?外部サブルーチンが「柔軟性」を担保しても、「資源」に圧迫をかけてしまうのです。他には、たとえば、予め論理ファイルを作っておけば、処理が早いかもしれません。でも、その分、資源(ディスクスペースやCPU処理)を使うのです。「処理時間」と「資源」もトレードオフの関係になりやすいです。

でも、どちらかに決めなくてはいけません。この場合、もっと柔軟に考えなくてはいけません。後者の例では、たとえば、「これは月に1回しか使わない論理ファイルなので、メンテをリビルドにして、CPUの負荷を下げよう」とか「この論理ファイルのソート処理を待つことで、何もの人が、自分の仕事に取りかかれず、論理ファイルを普段から使いたいので、CPUを犠牲にしよう」とか、必ず「根拠」「解決の着眼点」が、どこかに有るはずです。そのことから、二律背反の両者のうち、どちらをとり、どちらを犠牲にするのかを天秤にかけることになります。

この先、必ず、「どっちにしよう」と考える局面が出てきます。先輩に相談するとか、ユーザーにそれとなく、情報を聞き出すとか(どれほど重要なのかとか..)、「どっちでもいいよ」というのは、止めましょう。

以上

2000-2-6


[ Previous ] [ HOME ] [ Upper ] [ Next ]

You are at K's tips-n-kicks of AS/400

 

SEO [PR] 爆速!無料ブログ 無料ホームページ開設 無料ライブ放送