update it, Inc.社長のブログ

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

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

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

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

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

隣の公園シリーズ

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

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

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

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

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

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

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

お先に失礼する

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

Have fun 🙂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オブジェクト指向は当初はソフトウェアの部品化と再利用を促進するため、という理由付けが行われることが多かったのですが、一般に普及した現状ではあまり声高に再利用を唱える人は少なくなりました。実際に振り返ってみると、オブジェクト指向によって再利用が促進された対象には偏りがあると思います。

例えばGUIの部品などは再利用されやすいものです。一度作った使いやすい部品はプロジェクトを超えて容易に再利用化されます。他にもデータベースとのインターフェースの仕組みやロギングなど、システム的でかつ一般的な部品は比較的再利用されやすいといえます。

それに対して業務に即した部品など、何かに特化した部品はなかなか再利用されません。例えば金融向けのアプリケーションの場合、もしあるシステムで債券や株などを表すクラスを定義したとしても、それをそのまま他のシステムに流用できるとは限りません。対象の用途を限定して同じようなシステムに適用する場合にはある程度は流用可能ですが、ちょっと使い道が異なるシステムとなると役に立たないことが多いのです。

つまり何をオブジェクトとして表現するのがちょうどいいのかが、対象の業務によって異なるということです。例えば同じ債券を扱うシステムでも、それを取引管理システムの中で扱う場合と、在庫リスク管理システムの中で扱う場合では同じ債券という概念でもシステムの中での取り扱われ方が異なるということです。

ただし業務寄りの部分でも、もう少し大きな粒度では比較的再利用がしやすくなります。例えば上記の例では取引管理システムとか、在庫リスク管理システムという単位での再利用はむしろやりやすいのです。もちろん同じような取引管理をする場合とか、同じような在庫リスク管理をする場合に限られます。業務的にみて似通っている場合には再利用がやりやすいというわけです。

業務的な観点で対象業務毎にフレームワークを持つことができるかどうかが再利用化の鍵だといえます。

プロジェクト・マネージメントは人をリソースとして扱うことから始まりますが、私はこの、人を「リソース」と呼ぶことが嫌いです。なぜならば人は一人ひとりが異なり、基本的には交換できないものであり、お金や資産などといった顔の見えない何か物質的なものと同等に扱うことに抵抗があるからです。

確かに人はマニュアルどおりに動きさえすれば良い、といったような職種も世の中にはあるかもしれませんが、システム開発のプロジェクトに関わる人達というのは単純にマニュアル通りに動けば済むような簡単な仕事ではありません。各自がそれぞれ過去の経験を通じて様々なノウハウを培っていて、そういったノウハウを活用することで始めて成り立つ職種です。この人達は簡単には交換できないのです。

一方でシステムが特定の人に依存してしまう状態のことを「属人的」と呼んで、一般には避けるべきこととしています。が、本当にそうなのでしょうか？　例えばある複雑なシステムに関与した人が非常に優秀で、いろいろと湧き上がる問題を次々と解決していたとします。そうすると周りがその人がいないとシステムが成り立たないと考えて、属人的になってしまっている、と判断する場合があるかもしれません。

確かに上記のケースではもしその優秀な人がいなくなってしまったらどうするのか？　というリスクが存在します。でもそのような複雑なシステムに関与する人は、それについて徹底的に理解するしかありません。理解してマスターするには時間がかかるのです。つまり複雑なシステムを扱っている以上、その人は本質的に簡単には交換できないのであり、「属人的」と呼ばれる状態にならざるを得ないのだと私は考えます。

これはドキュメントを整備してあれば済むというものではないことも皆さんは感づいているでしょう。もちろん最低限、ドキュメントはそろっているべきなのですが、それが揃っているからといって事が起こってからドキュメントを見ればいつでも対処可能なんてことはありえませんよね。ドキュメントやマニュアルでは未知の問題に対する対処法は書けません。やはり事前そのシステムを十分に理解しておくことが必要であり、その理解度が十分に問題に対処可能になるまで深まるには時間がかかるのです。

究極的にはシステムの複雑さを減らすことがベストなのですが、元が複雑なものから単純なものへ変えることができるのはよっぽどの天才でなければできない仕事で、まさに「属人的な」仕事が要求されます。

見方を変えると、属人的なのが問題なのではなく、その人がいなくなってしまうリスクが問題なのだと思います。まずはその人がいなくならないよう努力すること、そして時間をかけて同じレベルまでこなせる人を育て上げることこそ、本当のリスク回避と言えるのではないでしょうか。