update it, Inc.社長のブログ

システムの開発現場では今まではたいていの場合、経験年数に応じた支払い体系になっていることがほとんどです。これは日本の年功序列制度が根底にあるためだと思います。しかし実際にシステムの開発能力で見た場合、必ずしも経験年数と能力は比例関係ではないですよね。

プログラマー３５歳定年説がささやかれるのも、こういった背景があるからではないでしょうか？　つまり年齢が上がるに従って給与が上がることが暗黙の了解となっているために、給与を上げ続けることができないばかりにプログラマーを続けられなくなる、ということです。

プログラマーというのは特別な能力が求められる職業です。（プログラマーと単なるコーダーの区別がつかないような人はこのブログを読んでいる人にはいないでしょう）　従って能力が高ければそれだけ払う、低ければ安い、というのは非常に当たり前の話に思えます。本来は優秀なプログラマーなのに、年齢に応じて給与を上げ続けなければならないという呪縛のためにプログラマーを辞めなければならない場合があるとしたら、非常にもったいない話だと思いませんか？

技術の進歩は日進月歩なので付いていくのが大変だという面もありますが、大変なのは若い人でも同じはずです。新しい技術を吸収するスピードそのものがそんなに大差あるわけではないと思います。そして新しい技術の学習を開始するタイミングは若い人でも経験年数が多い人でも変わらないはずです。だからマスターするタイミングもそんなには変わらないことになるのですが、そこは経験年数が多い分、若い人よりもなんでもかんでも優れていなければならないという暗黙の了解、つまり新しい技術に対して若い人と同じ水準でいいのか、という「良心」が彼らを苦しめているのだと思うのです。

日進月歩の技術とは別に、システム開発に関するノウハウや知見というのもあります。これは基礎的な能力であり、短期的な技術の変化で評価が変わらない部分で、その人の本来の能力の大きな部分を占めているはずです。この本来の能力を正当に評価して支払うことこそ、能力に応じた支払いなのだと思います。

管理者に向かない、優秀なプログラマーがいるのは事実です。また全員が管理者になれるわけではないことも明白です。そういった人たちが気持ち良く働けるようにすることが、競争力の強い会社とする１つのポイントではないでしょうか？　「スーパープログラマー」と呼べるレベルの人たちに対し、管理者と同等か、もしくはそれ以上の給与を得られるチャンスを提供していくことも検討すべきでしょう。

以前曖昧な仕様や一人が仕様を決める、とはという内容で、1名のプロジェクト・オーナを決めて、その人が勘と度胸ですべての仕様を決めていく方式のほうが実は費用対効果が優れているという話を書いたのですが、今日はそれに類する話で、「ヘッドは誰か」というテーマです。

うまくプロジェクトを進めるためには、やはりユーザ側の意思決定者、つまりヘッドを１人に絞り込んでもらうべきだと思います。経験上、ユーザ側の意思決定者が不明確な状態でうまくいったプロジェクトはありません。（私自身、何度もこれでだいぶ痛い目にあってきました）　このヘッドとは形式的な話ではなく、実質的に、１名のヘッドが意思決定をしているかどうかという話です。もちろん組織的にその人が対象案件におけるヘッドであるという裏付けは必要です。

もしユーザ側に裏の意思決定者がいたり、誰も意思決定をしていなかったり、本来ヘッドであるべき人がその機能を遂行していない場合には、ユーザ側に対し「これではプロジェクトがうまくまわらない、改善しないことには手を引く」ぐらいの厳しい態度で臨むべきだと思います。

もちろんサブシステム毎に機能が分かれていて、そのサブシステム内に閉じた意思決定については、そのサブシステムのヘッドが判断すれば良いのです。ある事象を判断するのが誰か、ということが明確になっていて、その対象者がきちんと機能していればよいわけです。

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

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

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

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

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

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

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

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

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

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

隣の公園シリーズ

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

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

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

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

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

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

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

お先に失礼する

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

Have fun 🙂

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

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

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

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

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

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

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