小さな会社で働くことのメリット1 経営者の近くにいられるということ

小さな会社で働くことのメリットは、なんといっても、

社長(=経営者)の近くにいられる

ということだと思う。経営者の近くにいられると、何が良いか?それは、

ビジネスの本質を学びやすい

ということだ。

社会人になったら、多くの人が仕事で活躍したいと考えると思うが、その仕事で活躍するためには、そのビジネスの本質を理解する必要があると思う。なぜなら、

ビジネスの本質を理解しないまま努力を続けても、会社の内外からの評価を得られない可能性があるし、自己満足で終わってしまう可能性もある。

ビジネスの本質というのは、末端の仕事をし続けているだけではわかりにくい。例えば、ハンバーガー店でハンバーガーを焼く仕事を続けていても、どうしてそのハンバーガー店が儲かっているのかまでは、わからない。ハンバーガー店が儲かる仕組みを理解するには、ハンバーガーがどれだけおいしいか、ということ以外に、顧客のニーズ、コスト(原材料費や設備費用や人件費)、競合店との戦力比など、さまざまなことを理解する必要がある。

プログラマも同様であり、顧客のニーズや人件費、競合との戦力比などを考えて製品を作らなければ、どんなに効率的で、ユーザインターフェースが優れた直感的なプログラムを作成しても、売れない可能性があり、結果的に社内外から評価されない。

小さな会社の社長というのは、その会社を起業した本人である可能性が高いと思うが、その人と直接接する機会が多いということは、必然的にビジネスの本質を理解する機会に恵まれ、仕事で活躍するための近道になりやすいと思う。

では、社長とそれ以外の従業員には、どんな違いがあるのか?

小さな会社の社長は、自分を評価する人が他にいない。(小さな会社は株主を気にしなくていい)だから、常に会社の外を見て、自分の行動の基準が会社の収支や顧客満足度になる。

逆に従業員の多くは、自分の上司(の顔色)を見る。だから、自分に対する上司の評価が行動の基準となる。上司以上に頑張ろうとする従業員は稀で、基本的には上司のやっていることを真似し、無意識のうちに自分の限界に設定してしまうと思う。

つまり、

経営者は従業員とはまったく異なった視点をもって仕事をしているのだ。

この視点は、普通の人が普通に頑張った程度では身に着かないと思う。

僕や他の同僚のプログラマは、そうしたことを完全に理解しきれず、その視点の違いのせいで、苦しんだこともあった。つまり、自分ではすごく良いアイデアだと思うことを思いついても、会社の利益につながらないものが多かったし、どんなにソフトウェアの最新技術を勉強しても、優れたコーディングスタイルやコーディングスピードをアピールしても、会社の売り上げに貢献できなければ社長は評価しなかったし、達成感もなかった。

つまり、従業員プログラマは、プログラミングを勉強する以外に、ビジネスの本質を理解する必要があり、理解できなければ、従業員プログラマは、頑張っても頑張っても評価されない、というジレンマにすら陥ってしまうことがある。

経営者の視点を持って働くことの重要性を説いている書籍などはたくさんあるし、自分の給料がどこから来るものなのかを理解していれば、至極当たり前のことなのだが、特に経験の浅いプログラマは、こうしたことに気付いていないことが多いと思う。

社長は、そうした技術的なところは

市場が要求するタイミングで即座に提供できる程度のものがあれば良い

と考え、それ以上のものや、関係ないスキルをいくらアピールされても、嬉しそうにするかもしれないが、本質的には、ほとんど興味を示さない。もちろん経営者としては技術力が高い従業員が好きなので、ある程度の人数は会社にいてほしいとは思っているが、実際に社員としてどれくらい評価するかは、別問題だと思う。

また、小さな会社であれば、直属の上司が社長であることが多く、社長と話す機会が多くなる。そうすると、早い段階で自分の間違いを指摘されることもあるし、ちょっとした会話の中から社長と自分の考えの間のギャップを見つけやすくなる。

皆さんの中で、小さな会社の社長と話をする機会があった方の中で、全然会話が成立しにくい、予想もしない回答が返ってくることがある、という経験をしたことはないだろうか?

僕は自分の会社の社長と話す時、いつもそうしたことを感じてきたのだが、最初は、「人生で起業をしてしまう人の頭の中と言うのは、そうでない人の頭の中とは、全然違うのだ。」「宇宙人みたいな人だ」と結論づけることがあったのだが、最近は、それは違うのではないか、と思いつつある。

それは、社長というのは、常に先読みをしているからではないか、と思う。会社の利益のことを考えたら、先読みをする必要があるのだが、

成功している社長ほど、先読みする量が半端ではない

と思う。

そうすると、先読みなんかせずに目の前の業務のことばかり考えている従業員とは、知識の量や考えていることがまったく違うので、会話自体がかみ合わなくなってくるのではないか、と思うのだ。

この間、この社長から言われた面白いことがあったのだが、それは、この社長自身が、より成功している会社の社長と話をしたとき、「私の話は全然聞いてもらえなくて、会話が全然かみ合わなかった。宇宙人みたいな人だった。」と言っていたのだが、その話を聞いて僕は「僕はいつもあなたと会話していて、そう思ってますけど。」と心の中で思った。

つまり、より成功している人は、より先読みをしているのであり、その差が会話の不成立に寄与しているのではないか、と思った。

そうした会話の不成立は、すなわち自分の考えとビジネスの本質のギャップを表していることが可能性があり、そうした経験が身近にできるということは、小さな会社で働くことの大きなメリットだと思う。

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

人気ブログランキングへ 人気ブログランキングへ 人気ブログランキングへ 人気ブログランキングへ

| | コメント (0) | トラックバック (0)

小さな会社で働くことのメリット2 物作りから販売、導入までの多くを経験できること

大企業では、仕事が区分けされ、専門性の高い仕事を求められることが多いと思うが、

小さな会社では、その逆で、さまざまな仕事を求められる。

例えば、僕の会社では、ソフトウェアを作っているが、プログラマと言いながらも、以下のような業務に関わる。
 1.設計
 2.プログラミング
 3.テスト
 4.ドキュメント作成
 5.ユーザサポート
 6.ユーザ支援・トレーニング
 7.セミナ企画、講師
 8.展示会出展・イベント支援
 9.プリセールス・営業・見積作成

僕はこの会社で10年目だが、1年目の時点から、設計以外の業務は全部やってきた。

このほかでは、マーケティングやコアな設計は社長の業務となっているが、社長限定の仕事というわけではない。マーケティングは会社の行く末を決める業務であり、コアの設計は製品の良しあしを決定的に決める業務である。したがって実力差があるうちは、さすがに任されることはない。しかし、実力があれば、マーケティングやコアの設計に参加できるはずだ。

このほか、ソフトウェアとは直接関係ないものでは、以下がある。
 10.社内外システム管理(webサーバ、mailサーバ、ファイアーウォールなど)
 11.正社員、アルバイトの採用
 12.新人研修

もちろん、本業はプログラマなので、営業の仕事の多くは営業の人に任せることが多かったりするが、それでも多くの業務に携わることができる。やらない業務と言ったら、経理くらいではないだろうか。ただし、経理はやらなくとも、会社の収入と支出はわかるようになるので、自分の給料がどうやって出ているのかは、すぐにわかる。

しかし、中にはこうしたことをメリットではなくデメリットと感じる人もいるだろう。R&Dなどを専門にやりたい人もいると思う。そういう人は、特に理由がないなら大企業の方が専念できると思うが、実力がなければ、やりたいことを任されることはないだろう。

小さい会社であれば、会社の方針にもよると思うが、会社の中で相談して自己主張しても良いと思う。要は、その会社が一番儲かる体制になればいいわけなので、小さな会社だから誰もが上記の業務を兼務しなければいけないというわけではない。その代わり、上記のような業務は、他の誰かが行なわなければいけないだろう。そのことは理解しなければいけない。

また、プログラマにとって営業の仕事は慣れないものであり、どちらもうまくやることはかなり難しい。僕は、プログラミングも営業も1級の人物というのは、見たことがない。しかし、

営業は成熟した市場を相手にしたビジネスをする場合は必須であるから、プログラマと言えど営業を経験すること、理解することは非常に大事である。

こうした多くの業務に携わることにより、ユーザに接する機会も多くなるというメリットがある。さらに、より、ビジネスの本質への理解が深まるし、もし、他の会社に移るという時に、これらの経験が自分の強みになると思う。

たまに、自分は何でもできると言いながら、結局は自分は開発だけをやりたい、と後から主張してくる人もいるが、それなりの実力がなければ、その会社に居場所は見つからないだろう。

とはいうものの、小さな会社に属したことがある人が、すべてそうした業務を見ているわけではないようだ。

僕の見聞きした、ある会社では、社長のみが営業をし、方針を決め、他の社員はプログラミングとユーザサポートのみを行なう、という会社があった。その会社の社員は、会社の収入と支出がどうなっているのかがわからない。そうすると、リーマンショック後の不況時に、社長だけが営業で忙しく外回りをし、社員は暇になってしまって社内で自社サーバの整備や、気になっていたプログラム開発などをしていたが、そうするうちにそのプログラマはリストラされてしまった、というのだ。

その会社の社長がどんな経営方針だったのかは知らないが、おそらく社員の首を切ってしまったのは、本意ではないと思う。では、どうする必要があったかと言うと、やはり社長だけでなく、社員も一丸になって会社の利益を上げるためにどうすべきか考え、実行すべきであったはずだ。つまり、プログラマがプログラミング以外の仕事をする必要あったのだ。それは小さな会社が生き残るためには仕方のないことだと思う。

しかし、その会社の社長と社員は、営業は社長の仕事、と決めつけていたのかもしれない。

冒頭で前述したように、大企業にいたら専門職に就くことが多いので、こうした会社が成り立つ仕組みを近くで見ることは難しい。そうすると、そうした仕組みがわからないまま40代、50代になってしまい、そのまま終身雇用されればいいが、途中でリストラなどされてしまった時、ビジネス全体における本質的な経験と知識が欠けたまま再就職先を探さなければならず、やはり大企業の、同じような専門職を探さざるを得ない。

こうした自分自身の欠けた部分を認識できずに、小さな会社に就職したとしても、そうした年齢ではアジャストすることが困難であり、結果として、まったく歯車がかみ合わないという例を何回か見たことがある。

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

人気ブログランキングへ 人気ブログランキングへ 人気ブログランキングへ 人気ブログランキングへ

| | コメント (0) | トラックバック (0)

パッケージソフト開発と受託開発という選択肢

僕が入社を選んだ会社は、パッケージソフトの開発会社だ。パッケージソフトとは、仕様や価格を開発会社が決めることができ、不特定多数のお客さんに向けて販売ができる。対して、受託開発というのは、仕様はお客さんが決めるものであり、主にお客さんごとに納品するものだ。

プログラマとして、このどちらの会社に勤めるか、という選択肢は、その後の仕事の仕方にものすごく影響する。

(このブログでは、一貫して小さい会社のことについて説明しているが、あくまで僕の勤めた会社の実例に基づいているので、受託開発の会社では当てはまらないこともある。)

僕は受託開発の会社に在籍したことはないが、短期で仕事(つまりお金)を得やすく、そのお客さんから気に入られれば、継続して仕事を請け負うことができる、というメリットがあると思う。

しかし、1つのお客さんに、そんなにたくさんの仕事があるわけではないし、小さな会社が提供できるソリューションはそんなに幅広くないはずなので、その後は、また別のお客さん(仕事)を探さなければいけない。

また、仕事の種類も様々で、新しい技術や知識をその都度、覚えなければいけないかもしれない。もちろん、蓄積していく経験が役に立つこともあるはずだが、徹底して1つのテーマに絞らなければいけないような案件は手掛けにくいし、成熟したパッケージ製品とコンペになった場合は、競合に負けやすいかもしれない。

受託開発だとゼロベースからの開発になってコストも大きくなるが、価格設定も確固たるものがないので、値引きを要求されやすい。ゼロベースだとプログラマとしてはやりがいがあるかもしれないが、作ったものを他のお客さんに転用できないことが多く、ビジネス(採算)から考えると非効率的だ。

また、業種にもよるが、不況時に仕事が少なくなりやすい、というデメリットもあると思う。リーマンショック以降、会社をリストラされた、というプログラマが非常に多くなったが、僕が出会った人たちのほとんどが受託開発の会社出身の人たちだった。

対して、パッケージソフトの開発会社であるということは、自社製品を持っている、ということだ。これは、この自社製品の出来不出来も関係してくるが、良い出来の製品を作ることができれば、大きなメリットになる。

パッケージソフトであれば、お客さんや代理店から要望を集め、仕様として取り込むかどうかは、開発会社側が決める。ある程度の要望を集めることができれば、個々のお客さんや代理店に対して、先行できることになる。つまり、

こういうことで困っているんですよね、と先に立って言うことができる。

それは、外部に対して、主導権を握れる、ということだ。これはビジネスをする上で、すごく重要なことだと思う。

また、個別のお客さんの要望を必ずしも取り入れる必要はないので、開発も主要な要望の解決のために集中することができ、開発コストを抑えることができる。その結果、受託開発のソリューションより、低価格で製品を提供でき、受託開発型の競合会社に対して優位に立てるかもしれない。

そして、パッケージソフトウェアの場合は、毎年バージョンアップを続けることで、1つのソフトで長く儲けることができる。つまり、長期的なビジネスが可能になる。1つのテーマを長くやっていけば、それだけ専門性が高くなり、新規参入企業と比較して強みを持てるし、その業界の老舗としてブランドを持つこともできるかもしれない(これはあくまで製品が成功した場合だが)。

また、受託開発の会社では、仕様と納期はお客さん主導で決められるケースが多いと思う。当然、ほとんどのケースではプログラムはこれから作るという段階での交渉になり、受注が欲しいために何でも「できます」と言ってしまいがちだ。

開発工数は事前に見積もるとは言っても、やってみないとわからない開発もあるし、お客さんには多少は見栄を張りたいということもあるので、納期はついつい短くしたくなる。そうすると、いわゆるデスマーチ、という状態になりやすい。

パッケージソフトの場合は、自社の都合でリリース日を決められる。もちろん、リリース日の直前は、夜遅くまで会社でリリース準備をすることもあるのだが、受託開発のようにお客様ごとの個別開発に比べれば、1つの開発で複数のお客様へのメリットにつなげられるので、効率的になる。(と言っても、初回リリース時は受託時と同じような状態になりやすいが)

そして、時間的に余裕が持てるので、実装する機能の仕様決定にかける時間も多くなる。より、汎用的な機能にした方が、お客さんに喜ばれるので、時間はできる限り、多く持ちたい。そのかわり、そのパッケージソフトが売れるものであるのか、事前によく調査する必要があり、その事前調査がもっとも大事な時期であると言える。

しかし、残念ながら、日本でパッケージソフトで成功している会社の数は、そう、多くはない。

自動車や電化製品などが海外で大きなシェアを占めている一方、日本のソフトウェアの海外におけるシェアは低い。現時点でおそらく、ゲーム以外では、ほとんどないと言っても良いと思う。

その原因は、日本人がソフトウェア画面の見た目は細かく正確に表示する方を好み、欧米人は、そういったごちゃごちゃした見た目を嫌ってシンプルなものを好むとか、日本人は機能的にコテコテでハイエンドなものを望み、途上国ではシンプルでローエンドのものを好むとか、そもそも日本人は新しいことを発想するのが苦手だとか、そういった理由があると思うが、詳しいことは別の機会で、このブログに書こうと思う。

そんな少ないパッケージソフトウェアの開発会社でも、

探せば存在するので、根気よく探すと良いと思う。

まずは業界を選び、展示会に足を運ぶとかインターネットを利用するなどして徹底的に企業調査をするのが良い。とにかく人づてでも良いから、いろいろな情報を集めよう。

また、海外のソフトウェア開発ベンダーの日本支社に勤める、という選択肢もあると思うが、そうした会社の仕事の多くは営業やローカライズ(ソフトウェアや資料の翻訳)であり、プログラマとして腕をふるう機会は少ないのではないか、と思う。なので、日本を飛び出して、海外でプログラマになれるのであれば、それは素晴らしい経験になると思う。

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

人気ブログランキングへ 人気ブログランキングへ 人気ブログランキングへ 人気ブログランキングへ

ビジネスブログランキング

| | コメント (1) | トラックバック (0)

小さい会社で働くプログラマの労働時間

今や大企業であれば、残業は積極的に規制されるところもあると聞く。私の先輩の大企業(自動車製造)では、ある時間以降に会社に残ることを禁止され、また、仕事の持ち帰りも禁止されているという。別の同僚(大手銀行勤務)の話では、自分のPCの起動時間がチェックされる仕組みになっており、累計で一定時間以上起動していると、所定の部署からチェックされて上司などに通知が行くようになっている、とのことだ。

こうした規制は、短時間のうちに集中して仕事をした方が効率が良い、という考え方からも来ているかもしれないが、やはり、社員が働きすぎて、体を壊したり、鬱になったり、家庭との関係が悪化することなどを防ぐ意味合いも強いだろう。最近ではライフワークバランスという言葉も出てきている。

企業側にしても、残業時間が多すぎて社内に不満が広がると、最近はインターネットで簡単に内部事情が外に出やすい環境下にあるため、社内外からの評判を意識した体制にする必要が出てきているのかもしれない。

今や大企業は、会社が管理体制をしいて、上司は部下が残業を繰り返さないよう、チェックしなければならないわけだ。

しかし、大企業と言えど競争社会の中にあるので、競合に勝つためには仕事量が物を言うところもある。少し単純な話かもしれないが、同じリソース、能力を持つ企業同士が競争した場合、一人あたりの労働時間が長い方が競争に勝つ可能性が高まるだろう。

上述した僕の先輩や同僚の話を聞いても、結局、仕事を持ち帰っている人が多かったり、自分のPCのイーサネットを引っこ抜いて勤態チェックシステムからの監視を逃れ、所定の部署や上司から何か言われたら、PCが壊れていましたと嘘をつく、などと言っていたので、結局のところ、労働時間は減っていないことが現状のようだ。

それに、そもそもそうした残業規制が徹底されている企業は、まだほんの少数のはずだ。なぜなら、主要都市やおよびその近郊では終電近くまで電車を使っている人がごった返しているからだ。僕の最寄り駅では終電で帰る人が非常に多く、駅から自宅に向かって暗い夜道を歩く群衆を見ると、毎日が祭りのようだ。

一方で、大きな工場などでは、労働時間がわりときっちり決められており、定時にきちんと帰るところが多いようだ。

前置きが長くなってしまったが、それでは、小さいソフトウェア会社では、どうか。まず、小さなソフトウェア会社で、そうした残業規制がある、というのは聞いたことがない。そして、やはりというべきか、

傾向としては残業時間は比較的、長い方だと思う。

さらに、小さい会社は給与体系も能力主義であることが多いため、

残業代が出ることは少ないと思う。

つまり、残業しないように所定の勤務時間内に集中して働きなさい、ということだ。

しかし、企業にもよるが、ずっと残業ばかりの会社もあれば、ある程度の波があるだけの会社もある。僕の会社は、後者、帰ろうと思えば17時にでも帰れるときもある。

プログラマが忙しくなるのは、バグ対応が重なった時や、新製品のリリースやバージョンアップの前だろう。ピーク時は、毎晩のように終電で帰ることになるし、帰れないこともある。

僕の会社では、ソフトウェアのバグ報告が夕方から深夜にかけてくる傾向がある。これは、客先でバグに遭遇したSEや仕事終わりのユーザがが、業務が終わった後でその日のうちに報告してくることが多いからだ。なのでベンダー側のプログラマは、定時に帰ろうというところに、「明日までに調査結果の回答をください」「すぐに直してください」というように緊急の問合せを受けて、帰ることができなくなることが珍しくない。

また、プログラマ自身も、独身の若い男性であれば特に、早くから家に帰ってもすることがないので、そうした仕事をしていた方がいい、と考える人が多いと思う。また、若いプログラマは集中力があるので、プログラミングやバグ修正作業に専念するとあっという間に時間が経ってしまい、定時を気にしない傾向があると思う。

定時が何時だ、というのもあると思うが、正直、僕は今の会社の提示が何時だか、正確には知らない。僕は残業が多い方の人間だが、入社直後から今までの僕の退社時間はおおよそ、20時~22時の間である。別に、定時で帰りにくい雰囲気がある、とかではないし、残業代は出ないので、残業代を稼ごうとも思っていない。

また、小さな会社では、そもそも組織が体系立っておらず、未熟な状態である事が多く、何をやるにしても常に人が不足している状態である。小さな会社は、あったとしても営業部と開発部くらいで、役割担当が細分化されていない。つまり専任者がいない。なのでプログラマが社内のシステムの管理、採用試験問題の作成、新人教育メニューの作成などをすることもあるし、見積書や契約書のフォーマットが洗練されていなければ、プログラマが必要に応じて修正することもある。そして、時間外に取引先やお客さんと飲みに行くこともある。その上、プログラマは自分自身のスキルも磨かなければいけない。

小さな会社にいると、

会社を成り立たせるためには、つまりビジネスを成り立たせるためには、いろんなことを同時並行でやらなければいけない

ということが身にしみてわかる。プログラマなのだからプログラミングに専念したい、と思っても、それでは会社が成り立たない。専念できる体制づくりは重要だが、限界がある。

プログラミング以外の仕事も積極的に手掛けるプログラマは、社内での信頼を勝ち得やすいし、ビジネス自体の理解度が高くなる。そして、往々にして、

プログラミングのパフォーマンスも高い

と思う。なので、小さな会社でプログラマとしてやっていくためには、そうした数々の仕事をこなすために多くの時間を費やすことを厭わない感覚が求められることが多いと思う。

2010年5月16日

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

| | コメント (3) | トラックバック (0)

プログラミングスキルを上げるには

プログラミングスキルというのは、その人の才能にもよるのだが、どれだけソフトウェアの本質を理解しているか、に依存する。では、どうしたらソフトウェアの本質を理解できるのか、と言えば、

できるだけ多くのプログラムを読んで書いて動かす以外に方法はないと思う。

入社直後のプログラマは、他人からプログラムを引き継いでいる可能性が結構あると思う。そうした人は、

そのプログラムの量が膨大である場合のもっとも効率的な勉強方法は、ソースコードをただ漫然と読むことよりも、そのプログラムのバグを修正することである

ということを体験的に習得すると思う。

なぜ、バグ修正でプログラムの理解が深まるかと言えば、まず、バグの原因が分からなくて繰り返し再現を試みているうちにプログラムの挙動の理解が深まる。そして、ブレークポイントを張ったり、ログを出力したりしてバグの原因を突き止めるためにソースコードのあらゆるところを、繰り返し読むことになる。そしてバグの発生箇所らしきところを突きとめたら、今度は、どうしてそのような現象が起きてしまうのかを検証することになる。簡単なバグであれば、バグの原因個所を突き止めた瞬間にプログラムの修正方法がはっきりすることもあるが、そうでない場合は、どうやって修正するのが一番良い方法なのかを考えることになる。

バグはランタイムエラーばかりではなく、フリーズや、パフォーマンスの極度の劣化もある。バグ修正がきっかけで、そのプログラムのパフォーマンスのボトルネックやオーバヘッドを見つけることもあるが、同時に、

どうすればプログラムが速くなるのか、そして遅くなるのかを経験的に学習することができる。

こうしたバグ修正を繰り返すとソフトウェアの本質が理解できるようになる。何にも替え難い経験であるし、本を読んだだけでは身につかないスキルが身につく。

やっかいなバグである場合は、非常に時間がかかることもある。やっているうちにわけがわからなくなって、整理して最初から考え直すこともあるし、深夜になるまでインターネットで情報をあさり、他人のブログからバグ修正のヒントを得ることもあるし、日本語のサイトでは解決方法が見つからないので、海外のサイトを調べることもある。

これを何回も繰り返すことにより、そのプログラムのソースコードの理解は嫌でも深まるし、バグが出やすいコードがどんなものかわかるようになり、プログラミングスキルが向上する。

また、バグを修正するということは、誰かの役に立っているという、わかりやすい図式に見えるので、修正した後は達成感を感じられる。逆に、修正できないうちはどうしてもモヤモヤした気分になって気が済まないので、途中で切り上げて帰る気分にならない人も多いのではないか。

しかし、この

バグ修正の達成感はビジネスとして考えた場合は必ずしも褒められたものではない。

というのは、バグ修正というのは、生産的な仕事ではないからだ。バグを修正すれば、お客さんからお金が貰えるなら別だが、そんな話は聞いたことがない。そもそもバグは初めから存在しない方が好ましいのであり、後から出てきたバグ修正という仕事は、言わば負の仕事なのだ。

したがって、

そんな負の仕事を減らすために、1つのバグ修正を起点にして、同じようなバグが起こりえる個所を同時に直すように気を配ることができるようになる

ことや、

いかにバグを減らすか、ということに目線を向けて開発体制を改善したり、バグ発生を未然に防ぐ仕組みを作れるようになったら、

プログラマとして、さらにスキルを上げたことになると思う。これをやるには、

あきらめない

ということだ非常に重要になってくる。1つのバグを修正したら、それで仕事を終わりにしたくなるものだが、どうしたらもっと良いソフトウェアにすることができるのかということをとことんあきらめずに考え、ソフトウェアと顧客と正面から向き合うことが大事である。本人はあきらめている実感はないかもしれないが、そこで思考を止めてしまう人がとても多いように思う。それは、結果的にあきらめたことと同じである。その違いが、その人のその後を大きく左右すると思う。

また、頭のいい人、要領のいい人は、そんなに時間をかけなくても高いレベルの仕事をこなすことができるが、しかし、やったらやった分だけ身に着くので、そうした優秀な人、センスのある人でなくても、かけた時間や馬力で、ある程度のところまで行きつくことができるのがプログラミングの良いところだと思う。

逆に言うと、

プログラミングがそこまで好きでない人は、小さい会社で頑張ろうと思っても難しいかもしれない。

僕は、プログラミングスキルをあまり身につけていない状態で入社してしまったが、学生時代に「プログラミングって何か良いな」と直感的に思っていて、学生なりにプログラミングに打ち込んでいたので、入社後にそこまで真剣に取り組むことは、当たり前だと思っていた。(これは後から記述するが、単に好きなだけでプログラマをやっていると、最初は良いが、あとで行き詰ることになるのだが)

以前、入社したばかりの若い社員に、深夜2時に寝て6時に起きることは珍しくない、と話したら本気で驚いていた。その社員は9時から18時まで働くのですら、疲れてしまい、土日はずっと寝ていなければ体が持たない、と言っていたが、ほどなく会社を辞めてしまった。

ちなみに、僕が一番忙しかった時期は、入社6年目くらいで新機能の開発項目が僕に重なってしまい、2~3ヵ月ほど、ほとんど毎日、26時まで働いていた時がある。そのころは10時出社だったので、まだ良かったのだが、終電がなくなった後、原付で家まで帰った。

もっとしんどい労働をしている人が世の中にはたくさんいるのは知っているが、それでも僕には身体的にも精神的にもしんどくて、そのときは、10000枚の布団の下に押しつぶされていて、進んでも進んでも布団の中、という感じだった。さすがに、その年の健康診断ではいろんなところが悪くなっていた。しかし、仕事自体は嫌ではなかった。他のプログラマに仕事を分けることも可能だったのだが、成長する機会を失いたくなかったので、それだけはしたくなかった。なので、やらされているという感じはまったくなかった。

やはりプログラマとしては、プログラミングは夢中にでできる楽しい仕事だったし、小さな会社ということで、仕様作成からプログラミングまでほとんどすべてを任せてもらえたのが良かった。やはり重要なことは、プログラミングが好きだ、ということと、本当のプロと呼べるところまで行きつきたいという向上心だと思う。

実際、そこまでやって、そしてそれを積み重ねることが、着実にその人のプログラムスキルを上げる道につながると思う。たまに、残業が多いという話をすると、「それは労働基準法に違反している」という話をする人がいるが、それでは世の中で成功していると言われる人は、定時で帰っているだろうか?大企業のトップは?今売れている芸能人は?日本の首相は?残業どころか、ほとんど土日なしで働いている。そうしたほとんどの人は、やりたくて仕事をしているし、そうしないと他人より秀でた仕事ができないのだと思う。もちろん、小さな会社のプログラマが、皆、土日なしで24時間働かなければいけないわけではないが、いわゆるプロフェッショナルと呼ばれるプログラマが学ばなければならないことは非常に多くあり、短期でプログラミングスキルを上げるには、

時間を忘れるほど打ち込む時期が必要だと思う。

そのときの給与に見合わない場合もあるかもしれないが、そのときに打ち込んだことは必ずその人のその後に影響してくる。小さな会社は、そうした下積みの機会にあふれており、その後の成長の可能性を広げてくれる。

ただし、やりすぎは良くない。この見境は難しいのだが、やりすぎてしまって、それがストレスになり始めてしまうと、ちょっとしたきっかけでモチベーションを激しく失ってしまうことがある。それが極度にひどくなると鬱のきっかけになってしまうので、要注意だ。僕も、頑張るだけ頑張っているのに、本人にその意図がなくても、ちょっとした意見を受け取っただけで、それが猛烈に心ない批判の一言だと感じてしまって急激にモチベーションを失ってしまったことが2回くらいある。やりすぎてしまうと、プログラミングや同時並行でしている仕事のパフォーマンスが劣化するようになるので、それを1つのサインと見て良いだろう。

2010年5月16日

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

| | コメント (0) | トラックバック (1)

自分に合った小さな会社を選ぶには

このブログでは、小さい会社でプログラマとして働くことについて紹介しているが、小さい会社の方が良いとか悪いなどと言っているわけではない。小さい会社の事例があまりないので、実例の1つとして挙げているだけなのだ。

しかし、どちらかと言われれば、小さい会社で働くことの良い面を余すことなく取り上げようと試みているが、

 小さい会社が皆、良いというわけではない。

当たり前だが、小さい会社は皆、特徴が異なる。

それは、前述したパッケージソフトベンダーと受託受注の会社の違いもあるし、そのベンダーのマーケット、そして、そのベンダー自身がその業界で何番手の会社なのか、などで大きく異なってくる。なので、その中で、

自分自身が合う会社かどうかを事前に良く調べる必要がある。

そのためには、その会社の社長と話す機会があるのであれば、話を聞くことを強くお勧めする。なぜなら、

小さい会社であれば、社長の影響力はとても大きく、会社の方針のすべてを決めている可能性が高い。

つまり、
 自分自身が会社に合うかどうか=自分自身がその社長と合うかどうか
ということになりやすいからだ。

社長とよく話し、この人ならついていける、と感じることができれば、何にも替え難い判断基準になるだろう。いきなり社長と話をするなんておこがましいと感じる人もいるかもしれないが、小さな会社は常にやる気のある人材を求めているので、社長からしてみれば、そうした積極的な行動をとる人はウェルカムであることが多いと思う。

では、具体的にどのようなことを評価すべきだろうか。人によって違うとは思うが、僕なりに挙げてみる。1つは、その会社(社長)の将来のビジョンだ。その会社は何を信念に仕事をしていて、今後、何をしようとしているのか。社長自身がそのことに誇りと自信を持っているのかどうか。それに対して、どんな人材を求めており、それに対して自分自身が合っているのかどうかを判断・アピールできる。数年後、会社を大きくしようとしているのか、していないのか、というのも聞いておくとよいだろう。小さい会社で働き続けたいと思っているのに、これから大きくしようとしている会社に入ってしまっては意味がない。逆に、会社が大きくなるまでのスタートアップを経験したい人もいると思うので、実際にそうであるかどうかを確認しよう。

中途採用であれば、ビジネスモデルの詳細も聞くべきだ。中途採用であれば、少なくとも面接の段階で、入社後にどのような仕事・貢献ができるのか、と聞かれるので、事前に調べておく必要もある。逆に、社会人経験がない人の場合、ビジネスモデルを聞いても理解できないことが多いのではないか。なので、ビジネスモデルは概要だけ押さえておき、直に接した一人の人間としての社長の話を基準にした方が良いと思う。

なので

社長とは、できれば1回ではなく、複数回、話をしたいところだし、面接という形式ではなく、飲みに行ったりして砕けた雰囲気の中で話ができれば非常に理想的だ。

そして、その会社を訪問すれば、オフィスの場所、つくり、雰囲気などでさらにその会社のことがよくわかるはずだ。都心の高層ビルの中にある会社であれば、これから大きなマーケットで躍進を狙う会社である傾向が高いし、都心から少し離れた小さなビルであれば、小さいマーケットを狙っている会社であるかもしれない。また、小さな会社の社長には、オフィスにはなんらかのこだわりを施していることがあり、それが社長と会社の特徴をよく
あらわしていることが多いと思う。

そして、既存の社員にどんな人がいるのかも、できれば知っておきたい。社長が社員のことをどう思っているのか、優秀な社員がどれくらいいるのか、なども重要な評価ポイントだ。優秀な社員がいれば、互いに切磋琢磨できる可能性がある。

社員同士のコミュニケーションがよく取れているのかどうかも1つのポイントだが、仲が良いだけで仕事に熱心に打ち込めていないという可能性もなくはない。個々の社員の仕事に対する情熱まで感じられれば非常に良いと思う。

それと、小さい会社に勤めていると良く聞かれることだが、社員の出入り(つまり、入社と退社)がどれくらいあるのか、ということだが、

出入りが多い会社は悪い会社である、とは短絡的に考えない方が良いと思う。

小さい会社というのは、このブログで前述したとおり、一人に求める仕事が、大企業のそれよりも広く深い傾向があり、課される仕事の責任も大きいことがある。そうすると、その能力に合わない人は辞めざるを得ないのだが、多くの人は入社してみなければわからないので、結果的に辞める人が多くなる。だが、これはこのブログで書いている注意点を良く調べておけば、間違いは少なくなる、と思う。

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

| | コメント (0) | トラックバック (0)

成功している会社で働くということ

ここで言う成功している会社とは、その業界のNo.1の会社と、あとは追加投資を繰り返すことなく、定常的に黒字でい続けられる会社のことだ。逆に成功していない会社とは、赤字続きであったり、赤字と黒字を行ったり来たりする状態であったり、資金繰りに四苦八苦するしている会社である。

今まで成功体験を持っていなかったり、負け癖がついてしまっているようなタイプの人は、成功している会社に入る機会があったら入ると良いのではないか。なぜ、そのような提案をするかと言うと、僕が以下のような経験をしたからだ。

僕は大学で、その大学の中でもっともハードと言われる運動部に属していた。創立から100年以上の歴史を持つ部であり、年間の300日を合宿をして練習をする。学校には、その合宿先から通うのだ。夏休みは月曜日以外をすべて練習にあてるので、バイトもできないし、遊ぶ暇もない。なにせ、一番の山場である大学選手権が8月にあるからだ。

そのようなハードな部であることは大学内では知られていたので、その部員たちは他の学生からは一目置かれる存在なのだが、我が部は、そのハードな練習生活にも関わらず、成績は振るわなかった。僕の大学はもともとスポーツが得意な人たちが集まるような大学ではないので、体力がない部員が多かったし、他の大学の部員もやはり合宿をしながら練習をしていたのだ。創立100年余りの歴史の中で、大学選手権や日本選手権で華々しい成績を収めたことがある年はほんのわずかであり、ほとんどの部員は大きな大会に出ても、優勝とは無縁の戦いをしていた。それでも部としての目標は優勝であったり、ベスト8であったりするので、引退する4年生たちはその目標がかなえられずに涙を流しながら引退することがほとんどだった。実際のところは知らないのだが、東大の野球部のようなものだ。

青春と言えば青春なのだが、試合に出れば好成績を収めて部が盛り上がるというよりは、やっぱりダメでした、という結果に終わることが多く、そしてそれでも合宿生活が続くので、合宿所の中はどんよりとした空気がながれることが多かった。

皆、その状態を脱するべく、学生なりに努力するのだが、高校での経験者をセレクションで集めているような有力私大に勝つには、並大抵の努力ではかなわず、また、すでに合宿生活でかなりの時間を練習に費やしているので、どうやったら強くなれるのか、方法がわからずにただ闇雲に練習してしまうこともある。モチベーションも弱いので、考える力も弱い。

特に僕は部の中でレギュラーにもなれなかった。その結果を単なる学生スポーツのそれ、と割りきることができる人はいいのだが、僕は人間性というか人としての能力にまで自信を失ってしまい、いわゆる負け癖がついてしまっていた。

そんな中で僕は、ある小さな会社に入ることができたのだが、そうした大学での経験があったので、それはもう今まで以上に必死で仕事をしなければ生き残れない、と意気込んでいた。

しかし、入ってみると、これはまったく勝手が違っていた。

その会社は、業界No.1に君臨していた。僕は入社するまで、業界No.1であることはうっすら聞いてはいたが、ついていこうと思える社長かどうかだけが会社を選ぶ要素だったため、業界No.1であるかどうかということを会社選びの比較要素にはしていなかった。

しかし、いわゆる勝ち組と言われる組織というのは、こうも違うのか、とカルチャーショックを受けた。もちろん学生スポーツと企業は異なるのだが、組織で戦うということは同じである。それなのに、まったくガツガツしておらず、精神論や根性論が論じられることはまったくなく、そして、業界No.2以降の会社のことについては目もくれず、常に顧客とその先の未来しか見ていなかった。後にNo.2やNo.3の会社の方と話をする機会が増えるのだが、そうした会社の人たちは、会話の中にも、常にNo.1を意識していることが見て取れた。しかし、No.1は、そうではない。

僕は入社後しばらくの間、なぜ、この会社が業界No.1でいられるのか、よくわからなかった。そして良く考えようともしないで、たぶん製品が良いからだろう、と考えていた。なので、入社後、その製品開発を行なう立場になって、製品開発とユーザサポートを一生懸命に行なった。

しかし、ビジネスにおいてNo.1になるためには、いろんな要素が必要なのだ、ということを、数年かけてじわじわと分かりかけてきた。優秀でセンスのある人なら、若くてもすぐにわかるのかもしれないが、僕は真面目だけが取り柄のような凡人なので、すぐになんてわからないし、正直言って今でも、わからない部分が多い。おそらく、それは経営者として体験してみないと分からないことなのだろう、と今は思う。

しかし、少なくとも成功している会社に入ることで、負け癖がついていた頃の考え方から少しは脱却できる機会を得た。負け癖がついている頃は、努力はしているのに、結果につながらない、ということが多いと思う。しかし、真理としては、

努力の量を減らしても結果として勝てれば良いのだ。

そうするためには、

努力が確実に結果に結び付くようにしなければいけない。

しかし、これは簡単なことではない。

これを学力テストに置き換えてみる。学力テストで良い点を取ろうとしたら、どういうアプローチ方法をとれば良いか。
 ① どんな問題が出ても良いように、あらゆる勉強をして準備する。
 ② 学力テストの出題傾向を調べて、勉強する範囲を集中する。

僕は出題傾向を事前に調べるのは邪道であり、学問とはテストで良い点をとるだけがすべてではない、という理想を追い求める考えが子供のころからあったのと、そうした傾向と対策を調べることが苦手だったのもあって、いつも①の姿勢でいた。このせいで、自分は要領が悪いということを自覚していて、かけた時間の割りにはテストの結果が中途半端になることが多かった。しかし、②のような発想の転換ができず、いつも範囲を限定せず、目の前にある問題を解くことの繰り返ししかしていなかった。そのくせ、負けず嫌いな面もあったので、結局、勉強に多くの時間をかけざるをえず、いつも馬力で勝負していた。僕がいわゆる本当の一流大学に合格できなかったのは、こういうところが原因だったんだろう、と思う。

高校・大学レベルの学力テストであれば、出題範囲が決まっているので、①でも、ある程度の結果は出るが、ビジネスに関しては出題範囲は決まっていないことがほとんどだ。そして、問題の解法も明確な正解があるわけではないので、時間をかけた努力が必ずしも結果に結び付くわけではない。僕が大学時代に経験した部活動においても、自分自身の能力の理解ができていなかったので、効率的な練習ができていない面があった。

成功している会社には、必ず、②ができている人がいると思う。自分の経験では、今の社長がそうだったのだが、負け癖がついてしまっていた僕にはそうした出会いがなければ、①をそのまま続けてしまい、結果につながらない努力を続けているうちに口の多い人間になってしまっていたのではないかと思う。また、努力を続けることにより、自力で結果に結び付けられるようになれれば素晴らしいが、その途中であきらめてしまうことも多いと思う。

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

| | コメント (2) | トラックバック (0)

褒めてもらうことを期待しないほうが良い

入社後の数年間は、プログラマとして、そして1社員として、一生懸命働いた。前述したとおり、夜遅くまで働くことを厭わなかったし、プログラミング以外の仕事も積極的に行なった。

良く吟味して入社したこともあり、あらゆる仕事を高いモチベーションで行なえていたが、1つだけ、入社前に思っていたことと異なることがあった。

それは、

仕事をいくら頑張っても、社長から褒められることはない

ということだ。そんなにしょっちゅう褒められることを期待していたわけではない。しかし、何年働いても、1回も褒められないのだ。自分としては、出来る限りの仕事をしているわけで、ある程度の貢献もできるようになってきている中で、しんどいな、と思うこともあった。なので、20代の頃は「○○君はがんばっているね」「○○君は良い仕事をしているね」みたいなことを言われたい、という気持ちがあったし、そこまで行かなくても「お疲れ様」とか、「ありがとう」みたいな感謝の言葉の1つくらいは、何年か働いたらかけてもらえるのか、と思っていた。そうこうしているうちに、社長は自分のことをどう思っているのだろう?と思うようになった。

しかし、僕の入った会社では、これは大きな間違いのようだった。

社長からしてみれば、小さな会社と言えど、各社員の些細な頑張りに注目している暇はないし、そんなことよりも自分のやりたい仕事に注力したいはずだ。それに、1社員がどんなに努力をしたところで、社長自身の努力に比べれば微々たるものであるし、働いた分の代償として給料を払っているのであり、それ以上に本当の意味で会社を救ってくれるような活躍がない限り、褒めたり感謝したりするほどのことはないのだ。

つまり、企業は顧客満足と利益を追求する共同体であり、社員同士が慰めあう場ではない。顧客満足と利益を定常的に獲得するということは日々の努力が欠かせないし、非常に厳しいことである。終わりはないし、今日うまくいったからと言って、明日もうまくいくとは限らない。常に前を向いて努力し続けなければいけない。そんな中で、ある程度仕事ができるようになったくらいで、ねぎらいの言葉を期待する方が間違っているし、そこを終着点と見るようでは甘い、ということなのだろう。これは明確に言われたわけではないが、何年も働いていると、そういうことなのだということは自然に分かってきた。

しかし、凡人の社員には、これがすぐには理解できないし、理解しようにも時間がかかるのではないか、と思う。凡人の社員とは、経営者視点が分かっている社員と言いかえられると思うが、社員というものは、常に上司を見ており、社長もしくは上司にちょっとでも褒められたり感謝されたりしたら、それがうれしくて働きがいになり、パフォーマンスも劇的に向上することが多いのではないか、と思うのだ。また、ちょっとでも頑張っている自分を見てほしい、とも思うだろう。なので、経営者にとっては明確な論理であっても、凡人の社員にとっては、そうでないことが多いと思う。

しかし、

経営者視点がわかるかどうか、というのは、サラリーマンとして非常に大きな分岐点にあるように思う。

特に給料がまだ低い若い社員は、経営者視点がわからないままだと、会社への不満の元になったり、自分の目的を見失うことにつながるのではないかとも思う。給料が良かったとしても、お金の問題ではない、と思う人もいると思う。その結果、転職をしてみたりする人もいるのではないだろうか?また、大半の人は、理解しないまま、定年まで行ってしまうのではないか、と思う。

小さな会社にいると、その経営者視点にいる人が身近にいるので、それに気づくことができるチャンスがある。ほかの人はどうなのかはわからないが、僕は些細なことにもこだわるタイプなので、すぐに理解したり、受け入れたりすることができず、いろいろな経験を経て長い時間がかかってしまった。今でも完全にその視点に立てているかどうかはわからない。しかし、大きな会社に入っていたら、経営者視点というものにどれだけ近くなれたかわからない、と思う。

一方で、今回記述したことは、もしかしたら、社長によっては随分変わってくるかもしれない。つまり、社長の社員に対する接し方が、社員をうまく引っ張っていけるタイプであれば、社員の満足度も変わってくると思うが、経営者視点を学べるかどうか、とは、また違う問題なのではなかろうか、と思う。

(続く)

にほんブログ村 就職バイトブログ 就活・就職活動へ にほんブログ村 転職キャリアブログへ にほんブログ村 IT技術ブログ プログラム・プログラマーへ
にほんブログ村

| | コメント (0) | トラックバック (0)

あれから10年、経ちました。

10年ぶりに更新してみよう。(未更新が長く続くと更新できなくなると言う連絡をもらったので)

| | コメント (0)

またさらに1年が経ちました

再び、削除回避のために更新。

10年前、心の中にモヤモヤとしたものが溜まってこのブログを始めたけど、ようやく今になって、そのモヤモヤの原因がわかったように思います。

| | コメント (0)

«あれから10年、経ちました。