全社員で朝礼と社内清掃を実施するSIerを、山形で見た

「客先を訪問すると、先方のパソコンを拭きながら営業する」「顧客が本社を訪れると、全社員が一列になって出迎える」――そんなSIerがあると聞き、この夏、山形市を訪れた。噂の会社は、社員数55人、売上8億8100万円の中小SIer。独特の営業スタイルは、社長の信念を体現したものだった。
　就業時間は8時30分～17時30分まで。しかし、社員はそれより早く出社して本社ビルの前に集合する。8時25分、集合した社員は輪を作り、そこでラジオ体操を始める。それが済むと8時30分に全体朝礼を開始。まずは社長を筆頭に全社員の出欠を確認し、次いで前日の売上や目標達成率などの実績、その日の来客予定、前日受けたクレームなどを20分かけて報告する。その後の10分間で部門別の朝礼を実施し、社員は9時から仕事を始める。
　さらに、月に1回の頻度で「環境整備の日」を設けている。環境整備の日には、全社員が通常の出勤時間より1時間早い7時30分に出社。朝礼までの1時間をかけて、窓拭きや本社ビル周辺の草むしり、18台ある営業車両の洗車といった社内清掃を実施する。ちなみに、トイレ掃除など日々の社内清掃も、社員が交代で担当している。
　同社ではグループウエアを導入しており、朝礼で報告する内容はすべてグループウエアで確認できる。それでも同社が朝礼や環境整備の日の実施にこだわるのには、二つのわけがある。
　一つは、創業者である社長が、「技術や知識、ノウハウを身に付けることも大切だが、まずは人間として立派であることが先」という信念を持っているからだ。朝礼や早朝の清掃活動は、モラルやマナー、礼儀、礼節、あいさつといった作法の大切さを、社員に浸透させる狙いがある。
　二つめも「立派でいい会社を作るため」という社長の信念に基づくもの。社長は、「会社は株主だけのものではない」と言う。本当に会社を育てているのは社員自身。彼らこそが、他の社員と協力して会社を作り上げていかなければ、本当の意味で「立派でいい会社」には育たない。全社員が毎朝決まった時間に集合し、同じことに取り組むことで、社員に連帯感を生み、協調性やコミュニケーションの大切さを気付かせる。
「株主重視」や「成果主義」の副作用を解決するヒントに
　ここ数年の経営スタイルの潮流を象徴するキーワードとして、「株主重視」や「成果主義」が挙げられるだろう。これらキーワードを実践してきた企業から見ると、上で紹介した会社の取り組みはいささか古臭く、ややもすると鬱陶しく感じてしまうかもしれない。実際、年間2～3人ほどが、「考え方が合わない」と同社を去っていく。
　しかし、ここにきて「株主重視」や「成果主義」の副作用も表面化している。最たる例が、閉塞感にさいなまれて“心の病”にかかる社員が急増していることだ。その瞬間の数字だけで社員を評価するのではなく、人間としての成長を促す同社のような取り組みが、解決のヒントにはならないだろうか。
　とは言え、山形のSIerの取り組みは地方の中小企業だからこそ徹底できる部分もある。数千人の社員を抱え、全国に拠点を張り巡らせている大手SIerが、全社員を毎朝、本社に集めて朝礼をするのは、まず無理。それでも何らかの方法で実践できれば、そこから新たな社風が生まれ、社員に活力を与える大きなきっかけとなる可能性はある。
　創業15周年の節目を迎えた同社は現在「第二の創業、原点に帰る」をスローガンに、仙台市、郡山市など山形県外に新たな拠点を開設し始めた。交通の便に恵まれて、今はまだ山形市内からの通勤圏内にあるが、いずれは東京にも進出したい考え。同社の場合、ラジオ体操は社員からの提案で始めたという経緯がある。社長の信念は、既に社風として定着しているのかもしれない。

ソフトを一人で作るということ

最近，WebアプリケーションやWindowsソフトの取材で，“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく，会社が商品として提供し，不特定多数のユーザーが使っているアプリケーションを一人で作って，一人でメンテナンスしているという点に興味を覚えた。

　先週都内で開催された開発者向けイベント「ITpro Challenge!」でも，ドワンゴの戀塚昭彦氏がニコニコ動画を一人で（しかも3日間で）作ったと語っていた（関連記事）。よく考えてみれば，ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても，企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。

　アプリケーションの規模や内容，また開発者のスキルにもよるだろうが，おおむね一人で開発するほうが，
・低コスト
・開発/修正のレスポンスが早い
・マネジメントが容易
・情報共有のためのコミュニケーション・ストレスやギャップが少ない
といったメリットがある。

　もちろんその反対に，
・一人の人間に会社の資産が依存する
・ノウハウや技術，人材が流出する
・品質や納期に不安が残る
といったリスクがともなう。だが，これらは会社側から見たリスクだ。開発者側にはデメリットはあまりない。強いて言えば，失敗したときの責任逃れができない，という点があげられるかもしれないが，それはチーム開発でも同じだろう。

　つまり，可能であれば，一人で作るほうが良いのではないか。そんなことを考えながら，冒頭の事例のそれぞれの開発者に話を聞きに行った。

営業一人，開発一人のWebアプリケーション

　Clogger.jpというサイトをご存じだろうか。Amazon.co.jpやぐるなびといった様々なWebサイトから，自分が欲しいものや興味がある/気になる商品などを集めて，オリジナルのカタログを作成し，他人と情報交換ができるというサービスだ。yatai（グレープシティの子会社）が運営している（関連記事）。

　このWebアプリケーションを一人で開発し，メンテナンスしているのが，グレープシティ未来事業部の高倉真一氏だ。グレープシティと言えば，学校向けの業務システムや.NET/Javaのコンポーネント・ベンダーとして有名だが，高倉氏は，そのどちらでもない研究・開発のチームに所属している。

　Clogger.jpのアイディア自体は，別の人物が考案したものだ。当時グレープシティは，一般ユーザー向けのWebアプリケーションの開発実績はまだなかった。そこで，研究・開発チームの高倉氏にお鉢が回ってきた。当初は，Clogger.jpを実現するためのInternet Explorer（IE）の拡張機能の開発だけを依頼されたそうだ。しかし，それだけではデモをしてもわかりにくい。そこで，クライアントのGUIを含めてトータルに開発し，早々に公開してフィードバックをもらおうというということになった。

　開発を始めたのは，2006年9月頃。サーバー側はASP.NET（Visual C#）＋PostgreSQL，クライアントではJavaScriptを活用するAjaxアプリケーションだ。この時点では，まだ高倉氏が一人で開発すると決まっていたわけではない。パートナーとなるベンダーを探していたが，適当な相手が見つからず，結局一人でこつこつ作ることになっていった。

　アイディアはあったというものの，きちんとした仕様書があったわけではない。実際の開発にあたっては，販売担当である中野康剛氏と話し合い，必要な機能を洗い出しながら実装していった。開発担当は一人なので，会議というほど大げさなことをすることもない。メールや電話で好きなときにコミュニケーションを取れる。多少不明な部分があっても，自分で判断してとりあえず作ってしまうことができる。小回りがきいて，効率の良いプロジェクトだったと高倉氏は振り返る。

　とはいえ，初めてのことばかりだったので，開発は容易ではなかった。特に「Webブラウザの互換性には苦労した」と高倉氏は言う。Clogger.jpが対応するブラウザは，IE，Opera，Firefox，Safariの四つ。どのブラウザでも同じように動作するように，どれかに依存するコードを注意深く見つけて，書き直していく作業が必要だった。また，ドメインを超えてコールするスクリプトを実現するのも難しかった。

　しかし，こうした難題をひとつ一つ乗り越えていくことは「開発者として大きな自信になった」（高倉氏）と語る。問題を解決したときやアプリケーションが完成したときの達成感は，かつてないほど大きなものだった。

　結局，2006年12月にVer.1.0のClogger.jpを公開した。9月の時点で2006年内には公開したいという要望があり，それに応えることができた。2007年5月には，携帯電話からアクセスできるモバイル版も公開した。今もって，高倉氏が一人でメンテナンスし，機能拡張を続けている。

　担当が替わったときのためのドキュメントは残しているか？という質問に対しては，「ぜんぜん書いてない」と笑った。仕様を考えながら実装していったので，途中時点のドキュメントを残してもあまり意味がないと思ったからだと言う。担当替えになったらドキュメントを書くつもりだが「開発者はソースコードを見ればわかる」（高倉氏）。

　では，一人で開発することで困ったことは何か？ 「強いて言えば，逃げられないこと。こんな機能はできないかと聞かれたときに，できないとは言いにくい」と言う。つまり，自分のスキル・レベルを理由に“できない”と言ってしまったら，アプリケーションの機能性は小さくなってしまう。難しそうなこと，やったことがないことに積極的に取り組んでいかなければならない，それを高倉氏は「逃げられない」と表現した。それは「責任感」と言い換えることもできるだろう。

　ずっと同じことをやっていて飽きないか？──実は，これを一番聞きたかった。すると高倉氏は「ぜんぜん飽きていない！」ときっぱり言い切った。やりたいことがまだまだあるのだと言う。「特に，サーバーサイドはデータベース・アクセスの高速化や，スケラービリティ確保などの課題がある。クライアントでも，Silverlight（Microsoftのリッチ・クライアント技術）対応などにチャレンジしたい」と熱く語った。

もう一人の今井浩司氏の話は，きわめてユニークで興味深いものだった。

　ITpro読者であれば，プログラムのソースコードを読み込んで，クラス説明書や機能定義書などの納品用ドキュメントを自動生成するツールをご存じの方は多いだろう。ドキュメント自動生成ツールというジャンルで，一時は複数のベンダーから多種多様な製品が販売され，市場をにぎわしていた。

　その草分けとも言える製品に，【A HotDocument】（以下，HotDocumentと呼ぶ）がある。1996年にこれを開発し，その後の機能拡張やシリーズ製品の拡充を一人で担当していたのが，前述の今井氏である。現在は，その名もずばり【A HotDocument】という会社の社長だが，開発当時はセントラル・コンピュータ・サービス（CCS）というSIベンダーの社員だった。しかも「落ちこぼれ社員」（今井氏）だったと言う。

　1990年代初期，今井氏は，コンピュータのことをまったく知らないにもかかわらず，CCSに入社した。SE/プログラマを大量募集していたバブル期には，そうした学生も少なくなかった。しかし，CCSに入社してみると，同期社員はみなコンピュータを知り，プログラムを書けるものばかりだった。「同期と自分の差がどれぐらいあるのかすらわからない，完全な落ちこぼれだった」と言う。

　3カ月の新人研修後，同期はみな開発の現場に配属されて仕事を始めた。しかし，プログラムを書けない今井氏は「お菓子とカップ麺を買いに行ったりする雑用係」になっていた。いろいろな雑用の中で，唯一開発に近い仕事が，開発プロジェクトのドキュメントを作る仕事だった。

　FORTRANやCのソースコードを一太郎（当時）に打ち込んで，定義を記述し，表紙や目次を付けてファイル化する。今井氏は，いつの間にかドキュメント書き専業社員になり，あちこちのプロジェクトからドキュメント書き要員として呼ばれた。なんと丸2年間，ドキュメント書き専業だったと言う。しかし，本人は「それを喜んでやっていた」というからおもしろい。

　その後，少しずつ開発に携わるようになったものの，メインの仕事は相変わらずドキュメント書きだった。そして入社から4年ぐらいたったころ，20歳そこそこの新入社員が書いたプログラムを見てドキュメントを書いているときに，ようやく「このままではマズいと思った」と言う。

　本人だけでなく，今井氏をかわいがってくれていた先輩社員もそう思ったようだ。社内で天才プログラマと呼ばれていたその先輩は，それから3カ月をかけて，みっちりと今井氏にプログラミングを教えた。具体的には，先輩が作ったすべてのプログラムのソースコードを今井氏に読ませ，なぜこういう処理をするのか，なぜこういう書き方をするのかを徹底的に議論した。今で言う，ソースコード・レビューだ。

　それを終えたとき，今井氏は先輩と近いレベルで，プログラムを書けるようになっていた。そして何か役に立つツールを作りたいと思うようになった。「オリジナルなもの，自分が得意な分野であること，簡単に使えること，確実にニーズがあること」という自分なりの条件を考えたとき，たどり着いたのは必然的にドキュメント生成ツールだった。

　しかし，今井氏がこのアイディアを会社で提案しても誰も相手にしてくれなかった。企業システム開発が主流のCCSにとって，たかだか数万円のパソコン向けパッケージ・ソフトを販売するという発想は当時にはなかったのだ。

　結局，今井氏は仕事ではなく，自宅でプログラムを作り始めた。日本語版Visual Basic（VB）2.0が普及し始めたこともあり，これとExcel/VBAを連携させて，VBプログラムのソースからドキュメント（Excelファイル）を生成するというものだ。最初に作ったVBプログラムのファイル名はすでに「hotdoc.vbp」（ほっとくとドキュメントができる）だった。VBの言語仕様そのものを理解しながら作らねばならず，完成までには半年かかった。

　プログラムが完成すると，会社に持ち込み，あちこち説明して回った。最終的には，社長のところまで説明に行った。そして，1996年にWindows 3.1版のHotDocumentが発売された。ただ，仕事としては認められたものの，会社から見れば，先行き不明の小さな商品だ。人員を割くことはできない。作るのも売るのも今井氏一人の仕事だった。

　おみやげを両手に抱えて，秋葉原のパソコン・ショップをあちこち訪問した。荷物の搬入を手伝ったり，店の前を掃除したりもした。「そういう雑用は得意だった」と今井氏は笑う。そうすることで，店員さんが今井氏を覚え，商品を覚えてくれるようになった。

　そうした努力に加えて，VBとパソコンのブームに乗ったこともあり，HotDocumentの販売は1年目から軌道に乗った。年間で数億円を売り上げるようになると，ついに今井氏はHotDocumentチームのリーダーになった。とはいえ，ほかのメンバーは電話サポートがメインの仕事であり，プログラムをいじるのは相変わらず今井氏一人だった。でも，そうした状況を「不満に感じたことはない」と言う。一人で作って一人で売り歩く仕事が楽しくてしょうがなかったからだ。

　一人のプロジェクトの最大の魅力は「作ってから売るまでのプロジェクト全体を決められること」と今井氏は言い切った。最初にプログラムを作っているときから「お店で売るときのことを想像してワクワクしていた」と言う。作ったとき，売ったときの達成感がたまらないのだと，奇しくも前述の高倉氏と同じことを言った。

　今井氏は現在，一人だけの会社を興してHotDocumentの機能拡張を続けている。飽きないですか？と聞いてみると，「まだまだやりたいことがある」と，また高倉氏と同じ答えが返ってきた。「どこかにドキュメント書きを担当している社員がいるなら，なんとかして手助けしたいから」（今井氏）。

　さて，本当は“一人でソフトを作る功罪”という点をもっと聞きたかったのだが，今井氏の生き様のほうがおもしろく，そこまで踏み込めなかった。本人が喜んでやっていて，会社が放任してくれたのなら，功罪も何もなかろうという気がする。二人の話を聞く限り，一人で開発することは，デメリットよりメリットのほうが多いようだ。

　“Windowsソフト一本ぐらい，誰でも一人で作れる”と思うかもしれない。確かに，その通りだ。それほど難しいことではない。しかし，それで会社に数億円の売り上げをもたらすことができるかどうか。それは，決して簡単なことではない。

　同じ開発者でも，所属する会社や組織によって，それぞれ事情が異なる。一人で作りたくても作れないケースのほうが多いだろう。だが，開発者たるもの，いつでも自分一人で完成品のソフトを作れるという自信とスキルを持つ必要があるだろう。いつかどこかで，そのチャンスが巡ってくるかもしれないのだから。