update it, Inc.社長のブログ

皆さんのところではどんなコーディングルールが採用されていますか？　最近は対象言語の標準的なコーディングルールを採用するケースも多くなってきていると思うのですが、そのような標準的なコーディングルールとは異なる社内標準が存在するケースも良く聞きます。そのような場合、従うのは当然としても、なにか割り切れない感じを受けませんか？

開発プロセスとかを事細かに定義しているところほど、この手の標準から離れた社内標準のコーディングルールを採用していることが多い気がします。

問題なのは、そのような社内標準のコーディングルールを決めた人たちがその言語環境についてあまり良く知らずに、他の言語で作ったルールをそのまま持ち込んでいる場合です。たまに見るのですが、オブジェクト指向言語のクラス名やメソッド名に管理番号が入っていることがあります。まあ、C言語とかで書いていたときにはこれも有りだと思うのですが、オブジェクト指向言語の場合には既にその言語内にパッケージ（あるいは名前空間）とかクラス名とか、管理番号に相当する、もっと良い仕組みが既に存在しているのですから、そんなルールは要らないというか、可読性を下げているだけだと思うのですが、「ルールだから」の一言で押し切られてしまうのですよね。

やっぱり、何のためのルールなのかを良く考えて、適宜必要であれば見直すという姿勢が必要ですよね。

Google Developer Day Tokyo の鵜飼さんのプレゼンをまとめたメモ（ブログ）へ?たのめも「Google のソフトウェア・エンジニアリング」を読みました。Googleは既にテレビを始め、いろいろなメディアで開発スタイルが紹介されていまずが、実際に中で働いているエンジニアの方自身による、社内での開発の様子というのは非常に参考になりました。

いろんなところで持ち上げられているGoogleの開発スタイルは、実際にこうやって聞いてみてすごいな、と思う部分が多いのですが、一方で、あ、これは実は基本的なことをきちんとやっているのにすぎないのだな、と感じることも多く、そういった意味ではなにか自分のまったく知らない世界があるというわけではないという点で、ちょっと安心した部分もあります。

私が一番感銘を受けたのは、Googleでは偉い人（フェローとか）ほどコードを書きまくっている、という話です。日本とは逆ですね。私の会社でもぜひこれを目指したいです。

メモの中に「Design Doc」というのがあるのですが、これは一般にいうところの「システム概要設計書」（会社によっては基本設計書と呼ぶこともあるらしい）そのものですね。同じじゃん、と思ったのですが、一方でさすがだな、と思ったのは「一般的にはあんまり長くない。」ということ。これです。無駄に分厚いものが良いのではありません。（読んでいない人はぜひ過去の私のブログ?設計書に書くべき範囲を読んでみて下さい）

あと、

・パフォーマンス重視
・スケーラビリティ重視
・信頼性重視

というあたりは、Googleならではのプロフェッショナリズムを感じます。ぜひこうありたいですね。

皆さんの会社や組織では、何か定期的な行事のようなものはありますか？　例えば毎週全員参加で部会をやっているとか、そのようなことです。で、その行事やミーティングは何のために行われているのでしょうか？　そして参加している人たちはみんな、その目的を理解し、かつ必要性を十分に認識した上で参加しているのでしょうか？

ただなんとなく集まって、参加意識も希薄なまま時間が過ぎるのを待つ、という人がいるとしたら、おそらくその行事やミーティングはうまく機能しているはいえないでしょう。社内を見渡して、そうなってしまっている行事やミーティングがありませんか？

もしあるならば、今一度、真剣にその行事やミーティングの意義、目的をとことん話し合い、納得できる状態にする必要があるのではないでしょうか？　特に重要なのは、経営サイドから、本音ベースで何をそこに求めているのかをきちんと知ってもらうことだと思います。いいこと、悪いこと全部含めて、お互いにきちんと納得した上でその行事やミーティングに臨むことができるのだとしたら、だいぶ違ったものになるのではないでしょうか？

そして、たまにはその目的と現状の「たな卸し」を行って、見直しを行うことも重要だと思います。個人の評価では期初に目標を立て、期末にはその目標と達成度の比較などを行うわけですが、同じように社内行事やミーティングについても、定期的に目標を立て、期末にその達成度を評価するプロセスがあったほうが良いのかもしれません。

皆さんはシステムテストを行うときのテストデータはどうやって準備していますか？　全パターンデータを手作りという場合もあるかもしれませんが、むしろ本番データを活用することのほうが多いかもしれません。個人情報などの部分をマスキングした上で本番データを一部コピーしてシステムテストに利用するというのは比較的よくやる話だと思います。

本番データをシステム・テストデータに使う場合、一番問題になるのはテストパターンのカバレッジに関する部分ではないでしょうか？　つまりテストしたいパターンについて十分なカバレッジをもったデータの場合にはそれをそのまま使えばよいわけですが、本番データだけではテストしたいパターンを網羅できていない場合も多いと思います。そのような場合にはなんらかの形で人工的にパターンデータを作り出す必要がでてきます。

場合によってはテストデータを作るためのツールやプログラムの別途開発が必要なこともあるかもしれません。そのためには工数もかかります。いざテストという工程になってからでは間に合いません。

つまり、システムテストへの準備はシステムテスト工程になってからでは遅い、ということです。システム開発と同時にシステムテストに向けたデータ準備を忘れずに。

プロジェクトマネージャの重要な業務のひとつとして、プロジェクトメンバに対する評価があります。これは単にそのメンバへの支払いを決めるということではなく（そもそも普通のプロジェクトマネージャの場合、そこまで権限をもっていないことが多いですね）、プロジェクトメンバのやる気を高めるための1手段として評価を行うという側面が多いのではないでしょうか。

あるプロジェクトマネージャの人から聞いたのですが、その人はできるだけプロジェクトメンバーが日常で話した、何を目指しているのかとか、どんなことがしたいとか、そんなことををノートなどに記録するようにしているそうです。そして評価のフィードバックのときなどで、以前こんなことを言っていたけど、こうだったね、みたいに伝えてあげるようにしているそうです。

プロジェクトメンバからすると、ああ、この人は私のことをちゃんと見ていてくれているのだな、と感じることになります。この『見守っているよ』感がうまく伝えられればチーム運営上、大きなアドバンテージとなるに違いありません。プロジェクトマネージャからはプロジェクトメンバは1対多の関係なのですが、プロジェクトメンバからみれば1対1の関係だと考えてあげることが重要なのだと思いました。

ある人から、こんな問題をもらいました。「今あなたは新しく人を採用しようとしています。候補として次の2タイプの人しかいない場合、どちらを採用しますか？」

１．協調性が良いが技術的には平凡なタイプ
２．協調性が低いが技術的に非常に優れたタイプ

これって実際良くある話かもしれません。協調性が良く、かつ技術的に非常に優れたタイプであれば即採用なわけですが、そんなスーパーマンはそんなにいるわけではありません。

私の予想では、通常は１のタイプを取る人が多いのではないでしょうか？　特にチームワークを重視するプロジェクト運営を目指しているならば、絶対１の人を取るのだと思います。一方、短期間にアウトプットを出すことを求められているプロジェクトの場合、２のタイプを取るのではないかと考えました。

ただいずれのタイプにせよ、長期間プロジェクトメンバとして一緒に仕事をするのであれば、その人の足りない部分が補われるように育てていくことが重要なのだと思います。そういった意味では技術力が平凡なメンバーは、優れた技術力の持ち主の人の下に付けて技術力を育てるべきだと思いますし、逆に協調性が低いメンバーであれば、優れたプロジェクト・リーダーの下に付けてリーダーシップを身に付けさせるというのもいいのかもしれません。

働くことが好きな人ってどの程度いるのでしょうか？　私の場合はやりがいのある仕事の場合には、どんなに多く残業しても苦になりません。（やりがいの感じられる仕事の場合には、という条件付ですよ。）　いろいろ周りの話を聞くと、この業界には同じような考えの人も多いのかな、と思います。

私の場合は今は労働者としては扱ってくれないので、働き過ぎでくたばったとしても誰も文句を言ってはくれないのですが、通常、会社のプロジェクトの場合、そのプロジェクトメンバがどんなに仕事好きで、がんばって残業したくても会社としての労務管理上、それが認められない場合があります。またコストを圧縮したいという経営からの要求のために、できるだけ残業をしないようにコントロールしているという話も聞くことがあります。現場でプロジェクト管理をしている人であれば、プロジェクトメンバがもっと仕事をしたいと思う気持ちと、さっさと帰さなければならないという立場の板ばさみに苦しんでいる人も多いのではないでしょうか？

働きすぎで健康的を害するというのは絶対回避すべきことなのですが、おそらくそれは単に時間が長いということが問題なのではなく、長時間強いプレッシャーを受けながら仕事をしていることが問題のような気がしています。逆に上記で書いたような、自分から好き好んで残業仕事をしているプロジェクトメンバというのは、おそらく少なくともその仕事に関しては、プレッシャーの強さよりも仕事を楽しむことのほうが勝っているから、進んでやっているように思えます。

そのようなケースで少し問題なのは、プロジェクト管理者側がなぜそのメンバが残る必要があるのかが把握しきれない場合があることです。メンバ側も、いまやっていることがなぜ必要なのかを、管理者側にきちんと理解してもらうよう、説明責任があるといえます。

いずれにせよ、楽しんで仕事ができるというのはまさに理想的な状況だと思います。もしそのような状況が実現できているのであれば、度を越さない範囲で好きなだけやってもいいよっ、というような選択権を与えることはできないものでしょうかね？

日本ではシステム開発の現場でシステムエンジニア(SE)とプログラマー(PG)を分けている場合が多いですが、この違いって何なのでしょうか？　経済産業省の平成１７年特定サービス産業実態調査という資料において、情報サービス業の概況には、平成１７年のシステムエンジニアが242,098人、プログラマが101,986人となっており、情報サービス業全体に関わる割合はそれぞれ42.2%、17.8%となっています。つまりSEのほうがPGの倍以上いることになります。さらに平成１６年との比較で見ると、この数値はSEは0.3%増えているのですが、PGは-3.6%と大幅ダウンしていることがわかります。これは何を物語っているのでしょうか？

システムエンジニアの定義をWikipediaで見てみると、『情報システムの要求定義、設計、構築、運用に従事する職』となっており、『日本では企業情報システムの開発に携わる者に対して主に使われる用語』という説明があります。一方のプログラマは『設計に基づいて実装を行う人』という意味で使われることが多いと思います。では上記の統計によると、日本では情報システムの要求定義などを行う人が増えて、実装を専門に行う人は減っている、ということになるのですが、本当でしょうか？

上記の特定サービス産業実態調査においてどのような区分けでシステムエンジニアとプログラマを分けたのかはわかりません。Wikipediaにはプログラミング環境が進化した現代のシステム構築ではシステムエンジニアがプログラマを兼任することも多い、という記述が見られるのですが、プログラミング環境が進化した（？）から兼任が増え、プログラマの数が減ったというのは実感が伴ないません。あくまで仮説なのですが、おそらくシステムエンジニアとプログラマの区分けは自己申告制でありそもそも区分けがはっきりしないこと、そしてプログラマよりも上級のイメージを持つ「自称」システムエンジニアが増えたためと考えたほうがより自然な気がします。

もしこの仮定が正しいとして、みんながプログラマよりもシステムエンジニアのほうが偉いんだ、とか上級なのだ、と考えているとしたら、それは嘆かわしい事実のように思えます。おそらく派遣業において、プログラマというタイトルよりもシステムエンジニアというタイトルのほうが単価が高くなっている、という事実からきているのでしょう。でも仕事の職種の違いは必ずしもその人の能力差を表しているわけではなく、例えばバリバリ仕事ができるスーパープログラマのような人たちもいることを考えても、システムエンジニアがプログラマよりもランクが上だ、なんてそもそも間違っているとしか思えません。

生涯プログラマというのもカッコいいと思いませんか？　システムエンジニアとは本来異なる職種ということで、プログラマという職種をもっと肯定的に捉えられるようにイメージを変えていきたいと、私は願っています。

一般に会議って無駄って言われますよね。　って、言いすぎかもしれませんが、無駄な会議の多さを良く聞きます。私も今まで無駄だなって思う会議が数多くありました。こんなの皆を一同に出席させなくてもいいじゃん、ていう会議です。中でも自分がその会議にいる必要性が感じられない場合（当事者意識が感じられないテーマの会議のとき）には特に強く感じたものです。

一方で以前Face-to-faceでダイレクトコミュニケーションの重要性を書いたのですが、会議というのはうまく実施できればまさにこのダイレクトコミュニケーションの場として非常に有効になります。例えばドキュメントを読むよりも人に説明してもらったほうが早く内容が理解しやすいということがありますよね。会議の前に事前に各自ドキュメントを読んでおいて会議の時には質疑応答だけにしろ、なんていう堅苦しい会議運営が行われる場合もありますが、実は事前には何も時間を取らずに、会議の場で説明をしてもらった方が効率的な場合も多いかもしれません。

会議を無駄にしないために大切なことは、出席者を絞り込むことだと思います。本当に出る必要のある人だけに出席してもらい、内容を押さえておけばいいだけの人ならば冒頭でさっさと帰してあげるようにするか、内容を理解するためのプレゼンコーナーだけに出席してもらって後は帰してあげるとか、ちょっとした工夫で意義の高い会議運営ができるのではないでしょうか？

昨日の「能力の応じた支払い」に関連するテーマなのですが、作る人と指示する人の違いについて書きます。

ある人から、本来のプロジェクト管理者が自分でプログラムを作っているためにプロジェクトが管理されていないことがあった、という話を聞きました。これは小さいチームでは仕方ない場合もあります（現に私の会社では人が少ないこともあって私自身がバリバリコーディングしています）。しかしプロジェクトがある一定の人数になったら、プロジェクト管理者はプログラムを作ってはなりません。プロジェクト管理者、つまり指示する人はプロジェクト・メンバーが少しでも作業がやりやすいように環境を整えてあげるのが仕事であって、自分が一緒になって作業者になってはいけないのです。

私の会社の場合でいうと、今は社長の私自身も一緒にプログラムを作っているのですが、これは７月末までと予め宣言してあります。本来の社長業（といっても零細企業の社長業ですけどね）を行うためです。（ということで、社員のみんな、よろしくね！）

さて本題に戻って、指示する人のやるべき仕事とは、プロジェクト・メンバが少しでも作業がやりやすいように環境を整えることだと書いたのですが、ここでいう環境には非常に広い範囲のことが含まれます。クライアントとの調整はもちろんのこと、仕事の優先順位付けやタスク管理、プロジェクト・メンバへのケアなどいろいろですが、こういった仕事はすべて、プロジェクト・メンバが作業をやりやすくするために行うことだと思います。考え方の問題だと思うのですが、決して仕事を「やらせる」のでなく、彼らが仕事がしやすいように手はずを整える、ということです。つまり指示する人、と書きながら、実際にやるべき事は、仕事を事細かに指示することではなく、中のプロジェクト・メンバに対するある種、奉仕のような仕事だと考えるべきではないかということです。

ただし、これはシステム開発の現場のプロジェクト・メンバがプロフェッショナル集団である場合に可能な話です。プロジェクト管理者はプロフェッショナルに対する奉仕者であるべきだ、ということです。この形態は非常に理想系なのですが、中のメンバーがすべてプロフェッショナルであるという前提条件が付いていることには注意してください。