update it, Inc.社長のブログ

会社とは利益を得るために存在しています。ですので通常はプロジェクトが赤字の場合、そのプロジェクトは「悪い」プロジェクトである、とされます。でもそれは常にそうなのでしょうか？

もちろん赤字というのはあまりいいことではないのですが、プロジェクトマネージャーを育てるためとか、将来のより大きな案件のための種まきのためとか、戦略的な理由があるのであれば、必ずしも赤字プロジェクト＝悪とはいえないでしょう。これは将来に向けた投資だからです。

逆も真かもしれません。黒字プロジェクトは常に正しいのでしょうか？　黒字を確保しているのだけれども、中にいる人たちが疲弊しまくっているとか、やる気が出せないでいるとか、辞める人が続出しているとか、もしそのようになっている場合、そのときだけみれば確かに黒字かもしれませんが、将来に大きな負債を抱える結果になってしまっているかもしれません。

でも会社というのは、非常に短期的に赤字・黒字だけで良し悪しを判断しがちです。スタート時点は戦略的意味を強調して赤字でもいい言っていても、いざ決算期を迎えるとやっぱり赤字はだめ、と手のひらを返すようなケースもあります。

なかなか難しい問題ですが、やはり重要なのはコンセンサスでしょう。戦略的に赤字プロジェクトを行うのであれば、その意義について関係者間で十分なコンセンサスを得ておくのが肝要だといえます。

先日、以前買ったドラッカー名言集の経営の哲学（ダイヤモンド社　P.F.ドラッカー著　上田惇生編訳）という本を読み返していたら、「オーケストラが明日の組織のモデル」ということが書いてありました。オーケストラとは団員それぞれが専門家で構成され、全員が同じ楽譜をもつことで演奏できると書いてあります。

これってシステム開発プロジェクトでも同じことが言えますね。プロフェッショナル集団で構成され、プロジェクトマネージャーというコンダクタ（指揮者）の下、同じ楽譜（仕様書や設計書）を見ながらシステムを作り上げていくわけです。

オーケストラでは指揮者とは纏め上げる作業をする人であり、もちろんとても重要なのですが、いくら指揮者が華麗にタクトを振っても各団員の能力がなければ音楽はまとまりません。システム開発でも同じ事で、各プロジェクトメンバの専門的な能力がなければシステムという楽曲を纏め上げることはできませんし、各自が調和して行動することも求められます。

ドラッカーさんはこのような、高い専門性をもった人たちが調和して進めるプロジェクトスタイルこそが「明日の組織のモデル」であるとしているわけです。ぜひそのようなスタイルを目指したいですね。

皆さんのプロジェクトではスケジュールにおいて、バッファをどのように設けていますか？　またどのようにコントロールしていますか？

だいぶ前ですが、エリヤフ・ゴールドラット博士の書いたクリティカル・チェーンという本では、TOC（Theory Of Constraints：制約条件の理論)に基づくのであれば、各タスク毎に満遍なくバッファを分散して取るのではなく、複数のタスクの合流点（それらのタスクが同時に終わらないと先に進めない=クリティカル・パス）の直前にまとめて置くべきだと説いています。こうすることで、「仕事は期限が延びれば伸びだ期限の直前までかかる＝パーキンソンの法則」を克服することができる、と説明されていました。

この本を読んだときにはなるほどな、と思ったのですが、私の場合、実際に適用してみると2つのことがわかりました。

１．（悲しい事実ですが）プロジェクトのスケジュールに明示的にバッファを書くと、それを削れという圧力がかかります。各タスクに分散してバッファを書かないでおけば、そのようなことはないでしょう。
２．クリティカル・パスが頻繁に変化するプロジェクトにおいては意味を成さないことがあります。特に目標が変化するアジャイル的なプロジェクトには向かないと思います。

TOCの理論はもともと生産工程管理の最適化のために作られたものなので、工場向けの理論です。ウォーターフォール的に工程管理している場合には有効だと思いますが、イテレーティブな開発モデルにはあまり有効ではないのかも知れません。

いずれにせよ、スケジュールに「バッファ」を明示的に書くことができなかった、というのは非常に悲しい事実でした。ぜひバッファの正当性が認められるようにしていきたいですね。

あるプロジェクトマネージャから、プロジェクトのチーム体制作りで悩んでいる、という話を聞きました。その人は今、ウォーターフォールモデルで詳細設計まできちんと設計した上で、プログラミングに大量に人を投入するスタイルにすべきか、それとも以前に紹介したセル生産方式というべき、エキスパートのエンジニアを揃えてその人たちに自主的に設計からプログラミングを任せる方式にすべきか、ということで悩んでいるという話でした。

エンジニア達に受けが良いのは後者のタイプです。そのほうが仕事が楽しいと感じられるようです。ただ、できるだけそうしたいのだけれども、なかなか人が集まらなかったり、プロジェクト管理の立場では管理しづらい部分があるという点でなかなか結論が出せないでいる、ということでした。

私が感じたのは、作るもののタイプによってどちらのほうがいいのかは変わるのではないか、ということでした。毎回同じようなものを繰り返して作っていて、システムの仕組み上特別に難しい部分がないということであれば、プログラミング工程で人海戦術が可能な前者のスタイルのほうが効率がいいと思います。プロジェクトの遅延に対しても（あまりお勧めしませんが）人を投入することで回復しやすいと思いますし、管理もしやすいでしょう。

一方、作る対象が非常に高度で難しいもので、研究・開発色の強いプロジェクトの場合には、高い専門性が必要とされることなどから後者のスタイルのほうが良いように思えます。このようなものの場合「作ってみないとわからない」ことが多いので、そもそも詳細設計まで落としてからプログラミングに入るというのが難しいことが多いと思います。

作るものの対象に応じてプロジェクトの体制を切り替えるというのが現実的なのかもしれません。

最近、学生の就職先として情報系（IT系）の企業の人気が下がっているという話を聞きます。へー、そうなの？程度の軽い気持ちで聞いていたのですが、良く良く考えてみると由々しき事態なのですね。

先日、京都大学出身の人と食事をしたのですが、その人が言うには今現在、京大の工学部で一番不人気なのが情報だ、と話していました。私が大学生のころは情報工学というのはある種憧れの分野だったと思うのですが、その話を聞いて時代の変遷を感じてしまいました。

やはり新３K（きつい・厳しい・帰れない）のイメージが一般にまで定着してしまったということの裏返しなのでしょうか？　昔は最先端の技術でよくわからない、何が神秘的で遠い存在だったコンピュータが、いまや非常に身近な、コモディティ的な存在に変わってしまったこともあるのかもしれません。

新３Kの汚名返上のためにはどうすべきか。やっぱり「そう（＝きつい・厳しい・帰れない）ではない」ように、この業界を変えていくしかないのだと思います。でも、世の中には同じか、それ以上にきつく、厳しく、帰れない業種にも関わらず、こういったことがささやかれない業種も存在します。たとえ「きつい・厳しい・帰れない」であったとしても、やっていることが楽しくやりがいのある仕事だと感じられるのであれば、そんなにネガティブなイメージにはならないと思いますし、ネガティブに伝える人も減るのではないかと思うのです。

要は仕事に対してどれだけやりがいが感じられるか、ということにかかっているのだと私は思っています。他の業界に比べれば確かにちょっとはきつくて厳しくて、残業も多めかもしれない、だけどやりがいのあるすばらしい仕事だよ、って紹介できるように変えていきたいと私は思います。

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

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

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

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

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

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

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

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

あと、

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

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

このブログを見ていただいている方の中には、安中はいったい何をやっているんだ？と思っている人も多いと思います。たまには私の会社でやっていることも書きましょう。タイトルのAPISとは現在開発中のプロダクトのコードネームです。（ちなみに商品・サービス名はこれとは異なる予定です）　

ホームページにも書いたのですが、弊社は現在、「まったく新しい形のコラボレーション・サービス」を目指して研究・開発中です。プロジェクトのチームワークの力を高める手助けとなるシステム・サービスを提供したいと考えています。このシステム・サービスを提供するためのプロダクトのコードネームがAPISというわけです。

APISとはミツバチの学名（正確にはミツバチ属の名前）です。ミツバチは社会性のある昆虫で、それぞれが役割を担いながら巣を作っていくイメージを、チームがプロジェクトを進めるイメージと重ねあわせて、APISというコードネームにしました。

現在、開発は7月末のM2を目指しているところです。その後、8月末にRC1、9月末にRC2とし、10月には1.0をリリースする予定です。RC1もしくはRC2についてはClosed βという形でお披露目できるかもしれません。

で、肝心な中身というか、どんなものなのかについては、今後このブログを通じて少しずつお伝えしていきたいと思います。お楽しみに。

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

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

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

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

皆さんはアプリケーションが使いにくくてイラついたことはありませんか？　私は根が短気なのか、よくあります。つい先日も会社で使っている、あるバックアップソフトのあまりにもの使い難さに腹を立ててブーブー言っていました。

その時に腹を立てていた理由は、こんなことでした。

１．単純なことをインスタントにやる方法がない。（すべての処理について一旦ウィザードを使ってタスクを生成し、その後で実行する形になっている）
２．処理をしている間のリアルタイムのフィードバックがわかりずらい。
３．エラーが発生したときに、正しいエラー原因が提示されない。
４．処理が失敗しているときに、ログを見てもなんだかよくわからない。

おそらく作る側は、バックアップの日々の運用の自動化を第一の目的として作っているので、１．については仕方ないのかな、とは思うのですが、ちょっとテープのVerifyがしたいな、と思った程度のことでもいちいち同じ手順を踏まなければならない、ということでまずちょっとイラつきました。

次に２．ですが、一応リアルタイムのフィードバックはあるのですが、起動した処理との関連がわかりずらい。この「わかりずらさ」でさらに　イラつき度++（インクリメント）されました。

で、３．ですが、処理が失敗すると画面上に赤いエラーという文字が点滅するのでエラーであるのがわかるのですが、このエラーの原因がおそらく見当違いなエラーメッセージになっているのです。昔、MS Officeで「メモリーが足りません」というエラーメッセージが頻発したときに、知人から実際にメモリーを増設してみたのだけどだめだった、という話を聞いたことがあるのですが、まあそんな感じの話です。エラーが発生しているときに見当違いの原因を提示されると、イラつき度 *= 10（10倍して代入）ぐらいになります。

最後に４．のログを見てもわけがわからん（そもそも失敗していることがでていない、結果には「完了」と出ている、など）に至って、ついに throw new IraIraException() したわけです。

まあ、「またひとつ勉強させてもらった」と考えれば良いのかもしれません。こういった一つ一つのことを反面教師として捉えて、自分が作るシステムがそうならないようにしていきたいと思いました。