update it, Inc.社長のブログ

プログラマーの間に一般に浸透してきたリファクタリングという言葉ですが、誤用が目立つという話を聞きました。プロジェクトのメンバーがいつまでたっても進捗が進まず、何をやっているのか聞いてみると、延々とリファクタリングをしていると言う。でもどう考えてもやっていることはリファクタリングではない。確かにこの手の話は私もたまに聞きます。

上記の例では作り直すことをリファクタリングと称していて、実際にやっていたのはリストラクチャリングだった、ということでした。確かにリファクタリングとは作り直すことの一種ではありますが、外から見たときの振る舞いを変えずに中身を洗練させる作業であり、振る舞いが変わってしまうような場合にはそれはリストラクチャリングと呼ぶべきです。しかしリストラクチャリングという言葉が一般化していないためか、もしくはリファクタリングという言葉がかっこよくて、ある種免罪符のように使えるからか、なんでもかんでもリファクタリングと称してしまう場合があるようです。

リファクタリングは常に推奨すべき行為だと思いますが、リストラクチャリングとなると通常時間、つまり工数がかかるので、実施すべきかどうかはプロジェクトの状態によって判断が分かれると思います。それが今後のシステムの開発を阻害するような問題を含んでいる場合にはリストラクチャリングすべきですが、そうではない場合には無理に行うべきものではありません。

行っている行為がリファクタリングなのか、それともリストラクチャリングなのかの判断は、厳密にやろうとするといろいろ議論があって難しいと思いますが、１?２時間以内、どんなに長くてもせいぜい半日以内に完了するレベルがリファクタリングであり、それを超えるレベルの場合にはおそらくリストラクチャリングになっていると思います。もし皆さんのプロジェクトのなかで何日間にも渡ってリファクタリングをしているという例があるのであれば、それは本当にリファクタリングなのか、もしリストラクチャリングであるならば、それは本当にいますべきリストラクチャリングなのかを判断させるべきだと思います。

これ、隣の公園での平日の一こまです。

以前、少量多品種生産に向いたセル生産方式という考え方をシステム開発の現場に適用する話についてブログで書きましたが、今回はそれを実施するにはどんな問題点があるのか考えてみます。

やる人のモチベーションを高く保ちやすいという点でメリットの大きなセル生産方式でうが、最大の問題点は人がどれだけ確保できるか、という点にあると思います。セル生産方式は非常にスキルの高いエキスパートをベースにした生産方式なので、おのずとそのようなエキスパート人材をどれだけ確保できるかで、できることが限られてしまいます。実際、そのようなスキルの高いエキスパートというのはそうそう確保できるものではありません。

最近、システム開発時に実際にこのセル生産方式に近いことを適用しているケースについて聞いたのですが、そこでは最初の雛形の作成をエキスパートに作らせ、そこでいいものが出来上がったらそれをベースにして、大量に作る部分をもう少しジュニアレベルのプログラマを大量投入して作らせる、という折衷案方式にしているとのことでした。確かにこのやり方ならば少ないエキスパートを有効活用していることになります。また優れたエキスパートの成果物をベースに仕事を進めることで、ジュニアレベルのプログラマ達のスキルアップにもつながるかもしれません。

もうひとつ考慮すべき点として、テスト工程について専門部隊でするべきか、同じチームの中でやるべきかという点があると思います。エキスパートチームの負荷を少しでも下げて生産性を向上させるためには、その中のテスト工程は別のチームにさせたほうが良いのではないか、という点です。

これについては（１）どのレベルのテストを専門部隊でさせるのか（２）テストチームのモチベーションをどう確保するのか、という点をうまくコントロールできるのであれば、専門部隊化して分業体制にするのも良いのかもしれません。専門部隊として切り出してテストを実施するというからには、ある程度形式化して分業できるようにすべきでしょう。

隣の公園シリーズ

この間オープンしたホームページのコミュニティー欄に、プロジェクト・アンチパターンとして「社内共通基盤を利用する」というストーリー（ユースケース？）を載せました。

この話の背景として、採用を強制させられそうな基盤技術が既に陳腐化してしまっているということがあります。では基盤技術の陳腐化がどんなときに起こりうるのかを考えてみました。

１．要素技術（使用言語、対象OS、対象とするサーバ、データベース、ハードウェアなど）が陳腐化しているとき
２．要素技術側のバージョンアップに追いつけなくなっているとき
３．メンテナンスが行われなくなったとき、もしくはおこなわれにくくなった状態のとき
４．メンテナンスがボランティアベースの場合に、メンテナンスする人々の興味が失われた場合

最後のは最近のオープンソースでたまに（良く？）見かけるケースです。  😀

こうやって考えてみると、基盤技術というのは生き物のようなものなのだな、思いました。作ったらそれで終わりということではなく、手間ひまをかけてメンテナンスしていかないと、放っておけばあっという間に死に絶えてしまうのです。

基盤技術をうまく生きながらえさせるには、なにかエコ・システムを作り出さなければならないのだと思います。

会社のホームページに「アクター君の毎日」プロジェクト・アンチパターンを追加しました。

お先に失礼する

システム化対象範囲を検討する

Have fun 🙂

今日は天気が悪いですね。

この写真は昨日撮ったものです。
このブログに載せている写真はすべて社員の人が撮ったものです。なかなかでしょ。

拡張ポイントは計画的に、の第２弾です。

仕事で統合開発環境のEclipseを良く使っているのですが、このEclipseが偉大だな、と思うのは拡張ポイントがソフトウェア的に定義されている点です。通常アプリケーションに新しい機能を追加する場合には、ソースコードに手を入れる必要がありますが、Eclipseでは拡張ポイントを外部に対して公開することで、Eclipse本体のソースコードには手を入れずに様々なプラグインを組み込んで新しい機能を統合して使うことができるようになっています。

正直なところ、Eclipseの中のコードそのものはあまりきれいだとは思わないのですが（失礼！）、統合開発環境としてのフレームワークとしては非常に良く設計されており、特にこの拡張ポイントをどこにどのように設定すればよいかという部分は統合開発環境としてのノウハウの集大成のように思えます。

こういった概念は一般の業務系のシステムでも同じように定義されていて良いものかもしれません。そうすることによって本体のコードは同一のものを保ちながら（シングルソースコード）、ユーザ毎のカスタマイズが可能になるわけです。

そして各業務システム毎に、どういった部分を拡張ポイントとして設計するのかが大きなノウハウ部分といえましょう。

最近「ご利用は計画的に」というフレーズがある業界のCMで流行っていますが、今日のテーマは「拡張ポイントは計画的に」です。

システム設計にはできるだけ対象の事象を一般化し、拡張性を考慮した上で設計することにより、様々なケースに対応できるようにする、という一種の美学があると思います。確かに美しいのかもしれませんが、その美しさが役に立たつことのないままシステムが寿命を迎えるということも多いのではないでしょうか。そうなってしまうと、その美学のために費やした時間とお金は無駄になってしまう、ということになります。

このことへの反動からXP（エクストリーム・プログラミング）では、「YAGNI = You Aren’t Going to Need It.」（今必要なことだけ行う）というスタンスで、最初から無駄に拡張性を考えてプログラムを作るな、今必要な機能だけをシンプルに作れ、と説いています。これもこれで一理あるのですが、そうは言ってもはじめから必要性がわかっている部分についてはきちんと拡張性を考えて作らないと、やっぱり大幅に作り直しが必要になって無駄な作業が増えることになりかねません。

むしろ重要なのは、どの部分には拡張性が本当に必要なのかを十分に検討しておくことだと思います。拡張性が明らかに必要な部分だけ、拡張性を考慮した設計にすればよいのです。それ以外のところは「この方が拡張性に富むから」という理由で無駄に複雑なものは作らない。このようなスタンスでシステムを開発するのがもっとも効率が良いと思います。

業務的な観点からどこを拡張できるようにすべきか、その拡張ポイントをきちんと明確にして、クライアントとよく「握って」おきましょう。

これは私の知人から教えてもらった、心に残ったユーザからの一言です。

「システムを作るのは一時かもしれないが、私たちはそれをずっと使い続けるのです」

システムを作る側は、作っている間はそれに打ち込んでがんばるわけですが、リリースしてしまうとそれで終わったと考えがちです。しかしユーザはむしろリリースしてからが本番で、そこからシステムとの長い付き合いが始まります。

作る側も、そのシステムをどんな人達がどのように使い続けてくれるのか、またそのシステムについてどう思うのだろうか？　そんなことを考えながらつくるべきなのでしょう。そしてリリース後、何年間もユーザが使い続けられるシステムとしなければならないという責任感も、よりいっそう沸いてくるのではないでしょうか？

ビジネス的な観点では「凝る事」はコストがかさむだけであまり評価されないことが多いですが、ユーザ側の視点で喜んでもらえるようにシステムを凝ってみて、長い間喜んで使ってもらえるようにすることは、長い目でみれば大きなプラスのリターンが得られるのではないかと考えます。