update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お先に失礼する

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

Have fun 🙂

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

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

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

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

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

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

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

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

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

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

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

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

今までのシステム開発を通して、ユーザから言われたことの中で、心に残った一言を１つ御紹介します。

「システムとは皆が使う入れ物なんだ。」　これは今から１０年以上前、あるシステムをリリースしたものの、なかなか現場で利用されない状態になってしまったときに、あるユーザの方から言われた一言です。

私はそのときまで、カッコいいシステムに憧れて、最先端の技術をふんだんに使ったシステムを作ることにやりがいを感じていました。そのときに作ったシステムも技術的には自分なりに「いけてる」と思って取り組んでいたのですが、特定ユーザのニーズのみを考え、関連する他のユーザのニーズの取り込みをおろそかにしたために、業務的にうまく回らない状態になってしまっていたのです。

その当時親しくさせて頂いていたあるユーザの方が、机の上のトレイを手に持ち、こう言ってくださったのです。「このトレイは単なる入れ物に過ぎないけど、みんながルールを決めてこの上で書類をやり取りしだすと、これはもう、立派なシステムになっているんだ。」

そう、システムというのは皆が使って初めてシステムになるのです。ことわざに「仏作って魂入れず」というのがありますが、私はまさに魂を入れ忘れていたのでした。

今でも新しいシステムを設計するときにはいつも、このときのユーザの方の言葉を思い出し、このシステムは皆が使ってくれる器になってくれるのだろうか？　そんなことを考えるようにしています。

タイトルを見てニヤリとした人はおそらく競馬ファンの人ですね。  :cool:（ちなみに私自身はまったくやらないので、実はこのハロンというのは知りませんでした）

最近社内でやっていることに、この第１ハロン、第２ハロン、第３ハロンというのがあります。ハロンというのは距離の単位で、競馬では一定の距離ごとにハロン棒というのを立てているそうです。私たちのプロジェクトにおいては、このハロンがそれぞれある決まった時刻を指しています。そしてその時間になるとみんなで集まって、前のハロンから今のハロンの間に自分がした事、そして次のハロンに向かって自分はどんなことをやろうと考えているか、を各自表明します。

つまり２?３時間という非常に小さな単位に対する目標を立てて、それを全力でがんばり、結果を確認する、という至極単純なことを繰り返すだけなのですが、こうすることで２つのメリットがあると思います。まずは小さな目標を立てるということです。２?３時間後というのはとても手軽に、気軽に立てられる目標になります。

そしてもうひとつはリズムです。少しの時間集中した後、ハロンの間は気軽にみんなと話し合うことで少しリフレッシュする、このリズムがちょうどいいように思えます。

弊社の社員が考えついたことなのですが、いまのところいい感じで回っているので、当分続けてみるつもりです。

皆さんのところでも試してみてはどうでしょうか？

昨日、弊社のホームページを立ち上げたことを告知いたしました。見ていただいた方は気づいたと思いますが、Communityというコーナーにはプロジェクト・アンチパターンとして、UMLのアクターの形をした主人公が活躍するユースケース記述が書いてあります。

(もし就業中に見ていて、上司からとがめられた人は、ぜひ「参考となるユースケース記述を見ています」と言ってみてください。ただし結果は保証しません。)

このようなコーナーを用意したのは、決してふざけているのではなく、実際にこれに近いことがこの業界でごく普通に起きているという現実を何とかしたいと考えたからです。実際にどこでも良く起こりがちなプロジェクト・アンチパターンをみんなで共有することによって、改善していくためのきっかけぐらいにはならないか、そんなことを考えてこのコーナーを企画しました。

ですので、ぜひ皆さんにも参加していただきたいのです。皆さん自身が体験した、もしくは見聞きしたプロジェクト・アンチパターンを教えてください。プロジェクト・アンチパターンを集めることができれば、実際にそのような状況に陥りそうになったときに、これを参照することによって、場合によっては役に立つことがあるかもしれません。

みなさんからの積極的な参加をお待ちいたしております。

タイトルはスパムメールの話ではありません。

システム開発のプロジェクトではメールは必需品だと思いますが、あまりにも大量のメールがやり取りされていて、結局良く見ていない、なんてこと、ありませんか？

メールって言葉でのやり取りと異なり、やり取りしたことが記録に残るし、後で検索とかもできるので、使って当たり前、いまや空気のような存在に近い（？）のかもしれません。またCC:（カーボンコピー）で関係者に一斉に配布できるので、周知という意味でも非常に優れています。でもその便利さが故に、メール依存度が非常に高まり、システム開発プロジェクトにおいても非常に大量のメールがやり取りされるようになりました。

しかし結果としてあまりにも大量のメールのために、プロジェクトメンバが見なくなってしまっている場合があるとすると、情報共有という観点では本末転倒なのかもしれません。

メールの問題点として、以下のようなことがあると思います。

１．情報が分類されていない。欲しい情報にフォーカスしずらい。
２．メールで意見を表明すると「とげとげしく」見える。

メール自体には情報を分類するための仕組みがないので、自分で振り分けルールを一生懸命作ったり、件名の書き方に統一ルールを作って徹底的に守らせる、などといったことする必要があります。しかしなかなかこの分類をきちんと運用するのは難しいものです。でもこれが無いために、見る側が見たい情報かどうかが中身を見ないとわからないために、いちいち全部チェックするのが面倒くさい→見るのやめた、となってしまうのではないでしょうか？

もうひとつの問題点として、メールで意見を表明すると「とげとげしく」見えるっていうか、よく『炎上』したりすることがありませんか？　Face-to-faceのコミュニケーションだと相手の表情がわかるので、相手の感情を考えながら話す内容を変えることもできるわけですが、メールって書いた後にしか、しかも相手のリプライの文面からしか相手の感情が読み取れません。なのでメールだけでやり取りしていると、ちょっとしたことで炎上したりするんだと思います。

プロジェクトの中でそういった現象が起こると、傍から見てよくわからんことで大量のメールがやり取りされることになり、当然その中身はまともに見ない人が増えることになります。

ここはひとつ、メールの代わりにFace-to-faceのコミュニケーションをもうちょっと増やしてみませんか？