FC2ブログ

2010/12/02(木)


地方からの戯言
ソースコードの可読性や保守性

保守性には細かく言うと、機能拡張性や性能・規模拡張性、デバッグやチューニングの容易性などが挙げられると思うのですが、私がこれまで経験した現場においては、これらの項目はシステム設計やモジュール・階層設計、データ構造設計、基底・抽象クラス設計、デバッグ機構やシステムパラメタ設計等々といった設計フェーズ、いわゆる上流工程で主に議論・吟味され、「ソースコード以外」のドキュメント上にて完結されることがほとんどでした。

コードそのものに向けられる観点といえばせいぜいコーディング規約やコメントくらいで、上流工程のそれに比べてあまりにも貧弱であり、そういう意味では保守性を考える際に、
”ソースコードだけに目がいきやすい”
というのは実際の現場においてはあまりないのではないか、というのが私の認識です。少なくとも保守性が「属人的な指標」であるというのは言い過ぎではないかと思います。なぜならデバッグロギング機構の有無のようなところでソフトウェアの保守性を語ることができるからです。

可読性を議論する際に注意が必要なのは、その論点がコーディングスタイルだけに限定されがちで、これをもって「属人的な指標」と言われてしまうことです。これは可読性のメリットの多くが拡張性や保守性とセットになることが原因で、例えばMVCモデルのようなアーキテクチャはコードの可読性向上に大きく貢献しましたが、拡張性のメリットの影に隠れてあまり語られることがないように思えます。

またリファクタリングの目的の大半が可読性向上による保守性の維持であり、例えば冗長なロジックの最適化やクラス・関数構造の見直し、共通モジュール化といった修正がほどこされますが、このような修正がはたして「属人的な指標」と言えるのでしょうか。

プログラマの教育は多くの現場で可読性の領域までなされることはなく、個々人の独学に委ねられています。プログラミングスキルが水準に達していないプログラマは、グローバル変数の乱用や複雑な条件分岐など一般的に見て悪いコードと評価できるくらい可読性の低いコードを量産します。一番の問題はこうしたコードが現場において公に問題視され議論されないことで、これを引き継いだ担当者は修正の複雑さやリファクタリングにかかるコストを一人で背負わされている現状があると思います。また可読性の低いコードを作った本人のスキルがいつまで経っても向上しないというのも問題で、基礎教育の観点においても議論が必要なのではと感じています。
コメント(0) | トラックバック(0) | 23:52:09

2011/01/05(水)


ソースコードの可読性を議論する際に注意すべきことは、そもそも可読性とは一体なんなのか、なんのために議論するのか、それがどういう効果をもたらすのかを明確にしなければならないということです。プログラムにおける「可読性」という単語は非常に曖昧で明確な定義を持っておらず、個々人がそれぞれの我流解釈で論理展開するため、しばしば議論が発散したり、そもそも議論ができるのか? といった意見が必ず噴出するという、かなりナイーブな題材です。

ところが保守フェーズを経験したことのある多くのプログラマは、可読性の低いコードがソフトウェアの保守性を恐ろしいほどに下げてしまうことを身を持って経験しており、非常に深刻な問題だと認識しているにもかかわらず、いまだにたいした解決策も進展もないまま今日に至っている現状があります。一番やっかいなのは、問題意識のない上司や上流工程に携わる人達にこのことを理解してもらえず、保守にかかる工数や複雑さを担当者が一人で抱え込えこんでしまっている状況です。プログラミングの知識のない人にとっては理解のしづらい部分であり、上流と下流の担当が分かれている日本の組織構造においては、特に顕著にあらわれる問題ですね。

以前のエントリでも書きましたが、今後は保守フェーズが長期化する時代が来ると予想されます。IT業界に携わる技術者は、まず可読性に関する問題をしっかりと認識し、周りに認知してもらうよう努力する必要があると思います。そうしないといつまで経っても事態が改善されず、自分の首がどんどん絞まっていくだけですので……。
コメント(1) | トラックバック(0) | 12:47:14

2011/01/07(金)


達人プログラマーを目指して:
高い品質のプログラムを作らなくてはならないと考えている職人PGの考えは間違っていた?

SI業界の分野ではその事業内容の特性上、ソフトウェア品質に対する理想を追うことが非常に困難な現状があります。SIerの分野に限らず、主に受託でまかなっている企業は、短い工数でより多くのプログラムを絶えず生産していかなければ経営が成り立たないというところがほとんどではないでしょうか。

ところがこうした企業こそソフトウェアの保守性・生産性を強く意識していかないと、今後生き残っていくことは難しくなると思います。なぜならハードウェアの性能向上などによりソフトウェアの寿命が延び、繰り返しリビジョンアップを行う必要が出てくるであろうことと、般化された他社製のクラウドシステムと競合していかなければならなくなっていくであろうと予測されるからです。*1

クラウドを分散コンピューティング技術と見たとき、分類化された業務を複数のシステムが担当するという構図が生まれ、結果としてシステムの置き換えが容易に行われるようになることで競争が激化する可能性が出てきます。いつまで経っても似たようなシステムを作るのに同じ工数・同じ人件費がかかっていては、機能に特化した安価で優れたクラウドシステムに徐々に侵食され、いずれは完全に置き換えられていってしまうでしょう。保守性・生産性が向上することは納期や金額の面で営業力の向上にも繋がりますし、競争力をつけるという意味でもこれらの施策をどう打てるかがカギとなってくると思います。

ただソフトウェアの保守性や生産性はプログラマだけが担っているものではなく、事業戦略やシステム構成設計・機能仕様設計などの上流工程においても多くの部分が盛り込まれます。あくまで推測ですが、恐らくSIerの方が本当に言いたいのは、(SI業界においては)下流工程の品質担保に対する優先順位は、上流のそれに比べて低くなる傾向にある、ということではないかなと思いました。そもそも上流設計は顧客に見せる必要があり、受託の成否や受託金額に関わる重要な業務ですので、どうやってもしっかりとやらざるをえないんですね。限られた工数でプロジェクトをまわして行くにはおのずと下流工程にしわ寄せがいくという構図です。

またプログラマのアウトプットは、プログラミングの経験を持った人間でないと評価ができない専門性があり、このため下流工程の品質が十分に議論されないという問題があります。そして一番の問題は、こうした問題が上層部に認識すらされていないということではないでしょうか。このような企業は保守フェーズや新規開発にかかる人件費をどうしても下げることができず、いずれ営業面において競争力を失っていくと思います。

*1:SI 業界におけるクラウドの現状は、今はまだ単なるwebシステム化にしかすぎないのかもしれませんが、近い将来、複数の企業にまたがる分散システム連携まで進化すると思います。なお私が「クラウド」という単語を使う場合は、主に分散コンピューティング技術あるいは分散システム連携の意味で使用します。
コメント(0) | トラックバック(0) | 18:19:04

2011/01/11(火)


日本の上流・下流の分離構造には確かに多くの問題点があり、欧米を見習って一刻も早くこうした構造を解消すべきだという主張を時折目にするのですが、私としてはそのような論調にも若干無理があるのではないかと思っています。結局のところ、スキルの低い人間が質の悪い仕事をすることが問題なのであって、それは上流と下流の垣根がなくなったからといってたちどころに問題が解消される類いのものではないと思うのです。

上流から下流までを一人で担当するわけですから、当然必要とされる技能・技量はぐんと上がります。一人前になるまでの道のりは遠く、結果として質の低い仕事をしている状態が今まで以上に長くなることでしょう。特に上流設計の質の悪さは、そのソフトウェアの商品価値や戦略的資産としての有益性において致命的です。上流設計は下流と比べ、より多くの目的や意図を持ち、その品質は下流工程にも影響を及ぼします。スキルレベルの高い人間が上流から下流までを担当する分には何も問題はありませんが(むしろ良い方向に向かう)、低スキル者が上流までを担当することで、その人の質の悪い仕事がソフトウェアに与える影響は恐ろしく拡大してしまいます。極端なまでに製品(サービス)の品質を求められる日本の社会においては失敗が許されません。企業としてもこのような人材を抱えることができなくなってしまい、今でさえ難しい状況にある人材の確保の面でさらに困難を極めることになってしまうのではないでしょうか。

日本特有の分離構造はこのような背景の下に、生まれるべくして生まれたものだと思います。少なくとも上流に優秀な人材を配置することで低スキル者の影響を局所化するというメリットがあり、全体のスキルレベルになるべく左右されることなく、ソフトウェアの有益性を確保することに適した組織構造なのです。また作業範囲を分担することで個々の専門性が増し、きめの細かい作業が可能になるという特徴も持っています。上流工程と下流工程にはそれぞれ必要とされるスキルに差異があり、例えばプログラミングが得意だからといって機能要件整理が得意であるとはかぎりませんが、1つの分野に特化した職人的な仕事をする人をたくさん雇うことができます。この場合個々の連携が非常に重要となってきますが、チームプレイを得意とする日本においては有効な組織構造と言えるでしょう。

分離構造の解消を訴える方の主たる要旨は、上流従事者のプログラミングに関わるスキルのなさを問題視しているように思います。確かにこのような組織構造は、下流の知識が著しく低い上流従事者を数多く生み出す要因となっています。とは言え前述のようにそれなりの原因があってこうした構造が生まれたのであり、いまさらガラガラポンと世界が変わることは難しいような気がします。やはり問題の本質は上流従事者のスキルレベルであり、プログラミング周辺の手法や新技術の習得、下流工程で発生する問題を吸い上げる能力をきちんと身につけることで、ほとんどの問題は改善されるのではないでしょうか。

またよく耳にするのが、下流従事者の地位が低いせいでより重要な工程に対して意見が通らない、という話です。特に上流と下流で会社が分かれる請負構造となっている世界では、日常茶飯事的に聞かれる話でしょう。しかしこれは単純に地位うんぬんだけの問題ではなく、上流側の能力的・体質的・人事的・経営戦略的な都合に合わさざるを得ない下流側の事情であったり力量の話であり、分離構造上の問題というよりも発注者と受注者、上司と部下といった主・従の関係によるところが大きいと思います。

そもそも上流と下流の線引きはプロジェクトによっても異なりますし、優れたIT技術者を目指すプログラマはおのずと上流に目線がいくので、そういった方は上流にも下流にも精通する技術者となり、欧米で言うところの「プログラマ」とほぼ同等のスキルを持ってそれなりのポジションで仕事をしており、日本でも中小規模のプロジェクトではそういった方が案外多いのではないかなと思います。どちらかというとプログラマ自身の向上心や目指すキャリアパスの違いといった要因が少なからず影響しているのではないでしょうか。
コメント(0) | トラックバック(0) | 18:19:49

2011/05/04(水)


以前のエントリーでは日本特有の上流・下流の分離構造について、それが必ずしも諸悪の根源とは言えないのではないかというお話しました。ただ、だからと言って、この分離構造に問題がないとはまったく思っていません。分離構造の一番の問題点は、下流工程をブラックボックス化しやすいことにあると思います。

上流設計の技術的・工学的・戦略的議論は十分になされている感があるのに比べ、下流工程の質に対する問題認識が非常に遅れているイメージを持っています。要するにプログラマのスキルに関する問題で、下流工程にいる低スキル者の仕事がいかにソフトウェアの保守性を下げるかという問題の認識や、スキル向上のための良い施策が見つからない、あるいはその工数が確保できないという問題に、一刻も早く解決策を見出す必要があると思っています。
コメント(3) | トラックバック(0) | 12:40:07