ソフトウェア開発の神話-吸血鬼に効くニンニクはない?
Amebaでブログを始めよう!
1 | 2 | 3 | 4 | 最初次のページへ >>

メモ術

仕事上のメモというと、各々色々な取り方がなされていると思いますが、

自分の場合は単純にノートに殴り書きしていくという方法を取っています。


そうするようになったきっかけは超整理法 という本を読んでからです。


内容は人間の記憶は時間に沿って形成されると考え、

書類を分類するのではなく、時間軸に並べることを奨励するものです。



機能設計での覚書、コーディング作業での覚書、打ち合わせでの覚書、便利なコマンド集

などのように個人メモまでいちいち分類しようとする人はあまりいないかもしれませんが、

これってやっても分類する労力に見合うほどのメリットが得られませんでした。


で、結局一つのノートに順々に書いていく方法に回帰したわけですが。



ちなみになぜテキストエディターやルーズリーフではなくてノートかというと。。。


テキストエディターの場合、紙ほど表現の自由がないし(着色や図形表記が困難)、

ルーズリーフの場合、自分のだらしなさ故にファイリングし忘れたり

手荒に扱って穴が破けたりして無くしてしまうことが多いからです。


今まで3回買いなおしたウォークマンの故障の原因が全て自分にあるという男には

あんな破けやすい紙を扱うのは無理な話です。


そのうちノート自体も破くんじゃ...、っていう突っ込みはナシ^^;



皆さんはどんなメモの取り方をされていますか?

エンジニアの二極化

いまIT業界の開発の現場で進んでいることと言えば、以下のような事象ではないでしょうか。


・モジュール化
・ブラックボックス化
・開発環境の充実
・開発言語の高度化


開発の現場はより担当機能や専門分野によって分けられ、
必要とするものは自前や手で作らなくとも、
開発ツールやコンポーネントというもので補えるようになってきているでしょう。
システムそのもののアーキテクチャーを知る人とそうでない人の割合の差は
ますます広がるのではないでしょうか。



IT業界の人口増加と同時に、
ITそのものにはあまり興味が無い肩書きエンジニアも増えているように思います。


またJavaからプログラミングを始めたプログラマーとか結構いるんじゃないでしょうか。
C言語でやっかいだった問題をプログラマー自身が悩まなくても、
StringやVectorといったクラスで解決できてしまうのがJavaです。
便利になった分、メモリ管理とか基礎的なアルゴリズムを知る機会は減ってきていると思います。




そう、ここまで書いて言いたいのは、
今後エンジニアの二極化が進むのではないかということです。


第一のパターンは上に書いたような細分化やブラックボックス化の波に飲まれて
開発における歯車の一つとなってしまうエンジニア。

第二のパターンは情勢に甘んじず、付加価値を生み出すエンジニア。


付加価値とは、例えばブラックボックス化されたところに関して深い知識を持っていたり、
ブラックボックス化されたものを組み合わせて何かを生み出すことができるとか
そういったことです。


前者のようなエンジニアの将来は暗いですが、後者のIT業界での寿命は長いと思います。


SE35歳定年説、なんてのがありますが、
今までよりも、むしろこれからのIT業界にこそ当てはまる現象ではないでしょうか。


・・・と思う今日この頃です。

分かりやすいプログラム

悪態のプログラマさんの記事 へのトラックバックです。



入社して間もないころ、研修の講師がこんなことを言っていました。

 

「箇条書きが得意な人は設計やプログラミングも得意なんです。」

 

この仕事を続けて、あーあのときの言葉は当たってるなと思うときが何回かありました。

 

 

分かりやすい文章ならず、分かりやすいプログラムとはどんなプログラムか。

自分はこう考えます。

 

・処理が的確に分けられている

・構造化が行われている

 

まさに箇条書きできてしまうようなプログラム。

それが分かりやすいプログラムと呼べるものではないでしょうか。

 

 

5月というとちょうど就職活動の時期ですが、

IT企業の会社説明会ではよくこんなことが学生の口から聞かれます。

 

「学生時代にやっておくべきことは何ですか?」

 

 

自分なら是非、論文の執筆に力を注ぐことをお勧めします。

それもうまく目次を作れる(=うまく構造化できている)ような論文です。

 

SEになったときにきっと役立つはずです。

システム開発の理想と現実

■ 1ヶ月の険しい登山

 

ここ1ヶ月はオフィスがかつてなく人間臭くなったときでした。

 

徹夜は日常的に行われ、PM11:00頃に会社を出ようとするものなら、

「え? もう帰るの?」なんて言われてしまうような始末。

 

 

依然としてシステムの品質は最良とは言えません。

しかし、結合試験から開発の最終フェーズである統合安定化試験への移行も成功し、

山は越えたと言えると思います。

 

以前の記事で、数千ものテスト項目を消化しなければいけない、と書きました。

結局どうやってそのエベレストを越えたのか?ということを今日は記述したいと思います。

 


 

■ 山の頂上を削る

 

さて・・・結論から言うと、超えてはいません。

 

 

プロジェクトが惨然たる状況になっているとき、チームの間では二つの考え方が台頭していました。

「とにかくやるしかないんだ!」という考えと「本当にやるしかないのか?」という考えです。

 

前者の方がカッコ良く聞こえますが、あのまま突き進めば、

エベレストの頂上にたどり着く前に我々は高山病で力尽きていたと思います。

自分はどちらかというと後者の考え方に組するようになっていました。

(単に楽をしたかったという気持ちもあったことをここで告白しなければなりません。。。)

 

 

ついに後者の考え方をマネージャーが唱え始めると、プロジェクトの流れは一気に変わり

我々はテスト結果の確認観点を絞り、いくつかの項目を実施することを放棄しました。

と同時に、マネージャーは担当機能ごとに分けられた各チームの間にあった縦割り意識を取り壊し、

一致団結してテストに取り組む体制を作り上げました。

 

チーム間の縦割りは薄れましたが、その代わりテストを行う上での分業は進められました。

テストケースを作成する人。テストを実施する人。テスト結果を確認する人。

バグを解析する人。マシンタイムや実施スケジュールを管理する人。

 

皆、重要だと決められたところのみを重点的にみるようになりました。

皆、自分の役割を認識しそれのみに打ち込むことができるようになりました。

そして皆が結合試験の完了という一つの目的のみに焦点を合わせることができました。

多くの無駄が省かれました。

 

 

こうして結合試験から統合安定化試験への移行は成し遂げられました。

エベレストを越えたというよりは、頂上を削って低くしてしまったのです。

(現実には不可能ですが)

 


 

■ 理想と現実

 

以前、僕はテストの真の目的は「期限内にテストを完了させる」ことでなく、

「バグを見つけ品質を上げる」ことだと書きましたが、もうそんなことを言っていられるときではありませんでした。

フェーズ移行を完了させ、期限内の納品に結びつけることが最優先でした。

納期というものがIT業界において、いかに影響力のあるものかを思い知らされました。

 

いくつかのバグは隠蔽」されました。

「完了」したと顧客に報告した影で、今あの「放棄」したテストが秘密裏に行われています。

 

 

人間は理想と現実に折り合いをつけなければなりません。ITプロジェクトも一緒です。

理想と現実どちらに拘りすぎても、大事なことを見失い前に進めなくなる事態に陥りかねません。

 

納期と品質。

どちらも切り捨てることはできないので、IT業界では嘘は恒常的につかれているのではないでしょうか。

こんな業界の現状を皮肉ることは簡単ですが、二つに折り合いをつけた結果がこうだったのかなと思います。

あなたは本当にITが好きですか

★ コミュニケーションシリ~ズ第2弾 ★



SEは今も昔も技術偏重の人が多いと言われますが、

果たしてそうでしょうか。


僕の職場を見てみましょう。

確かに、うちの人間はビジネスや業界動向に興味がある人はほとんどいません。

だからといって技術ばかりに関心がある人が多いかというと、

そういう人もほとんどいない。



多くの人は仕事上のことや、個人的な事柄にしか興味がない。

あの機能は作るのめんどくさいとか、あの部長はイヤなやつだとか、

好きな車だとか、好きなアイドルだとか、好きな野球チームのことだとか、恋人や家庭のこと。

プログラミングや自作PCが好きだという人もいるけれど、それは暇なときにやる趣味の範疇でしかない。



本当の意味で技術偏重の人がどれくらいいるというのでしょう。




オブジェクト指向の起源や概念に興味がある人が職場にどれくらいいるでしょう。


Linuxがどういうアーキテクチャで作られ、UNIXとどう違うのか、

そしてOSというものの仕組みに興味がある人が職場にどれくらいいるでしょう。


COBOL,PASCAL,C,C++,Smalltalk,Java,C#,PHP,XML

時間が許せば全ての言語を習得したいと考えている人が職場にどれくらいいるでしょう。


そして、SEのコミュニケーション能力が重視される風潮の中,IT企業の面接で

「私は技術が大好きだ!」と真顔で言った学生はどれくらいいるのか。




コミュニケーションも確かに欠けているのでしょう。

しかし、今IT業界に最も必要なのは、ITへの熱意ではないでしょうか。


・・・と思うのは僕だけ?

コミュニケーション能力って何ですか

★ コミュニケーションシリ~ズ第1弾 ★

今ほどIT業界で「コミュニケーション能力」の重要性が

叫ばれている時代は無いのではないでしょうか。


でもちょっと行きすぎだなって思ったこと、1度や2度ありませんか?

自分はあります。



それは学生時代の就職活動でのことです。

面接で多くのIT企業を回りましたが、こんなことを言っていた人事担当者がいました。


「いくらJavaとかCが抜群にできたって、

人前で緊張してうまく話せないような人間はダメですね。」


いくらプログラミングができても話せない人はダメ。

逆に言うといくらプログラミングができなくても人前で話せればイイ。

じゃあ、吉本興業にでも会社説明会やりにいったらどうですか。



そもそもコミュニケーション能力って何でしょう?


顧客との折衝力?

自分の意志や考えを分かりやすく伝える能力?

人の話を理解する能力?

幅広いことに関心があり、どんな人種とも喋れる能力?

場を盛り上げてくれて一緒にいると楽しい奴みたいなことを言われる能力?


それともそれら含めて全部?


コミュニケーション能力とは一体何なのか。

誰が、いつ、なぜ、それが重要だと叫びだしたのか。

 

コミュニケーションのスキルもいいけど、

そういうこともちょっと探求してみようと思います。

なぜSEをやるの?

今日は、自分にとっての「プロのSE」とはどういう存在か、

ということについて書いてみたいと思います。

 

 

学生時代にある授業でなぜSEをやりたいのか?

と聞かれて答えたら、

 

「なぜSEをやりたいのかが伝わってこない」

 

と教授に言われことがあります。 

以来その問いは、SEになった今でも自分の中で探求し続けられています。



なぜSEをやりたいか。

なぜその技術を極めたいのか。

なぜプログラミングが好きなのか。

なぜ面白いと思うのか。

 

 

「なぜ」と問い続けられたとき最終的に行き着く答え。

ちょっと恥ずかしい表現で言うと、それは魂の叫びにも近いものなのでしょう。

 

それ以上「なぜ」と問えなくなるくらい核心的で強い思いを持って仕事をやっている人。

 

そんなSEが自分にとっての「プロのSE」です。

 

 

技術や業務知識について学ぶだけでなく、

「なぜSEをやりたいのか」、

定期的に自分に問うことによって色々なことが見えてくるのではないでしょうか。

ホリエモンよりガースナー

『巨象も踊る』




かつてのコンピューター業界の帝国IBMを蘇らせた経営者、ルー・ガースナーの自伝的著書です。


ビル・ゲイツやスティーブ・ジョブズ、ラリー・エリソンのようなハデさはなく、

自分は地味な男だと言い切るガースナー。


自伝といっても子供時代の思い出だとか、高校時代の恋愛話だとか

そういった「仕事」と関係ない記述は一切無い。

情に訴えるような精神論や大企業の経営者としての夢のような構想も書かれていない。


いまIBMに必要なのはビジョンでない。

重要なのは冷静な判断に基づく日々の実行だ。


そんな信念の下に冷徹に、そして着実にIBM復興策を実行していく彼の姿勢からは、

優れた経営者であると同時に洗練された職人の魂を見ることができます。

 


 

堅物かと思いきや、

「競争相手の顔の皮をはいでぶっ飛ばせ!」

などと公言する意外なフッ切れっぷりも面白い。


いま一緒に働きたい(ムリだろうけど)経営者NO1です。



P.S.

この本には経営やIT業界に関することだけでなく

顧客思考(読者思考)、

コア・コンピタンス(専門テーマを持つ)、

などブログ運営にも役に立つ考え方が多数示されています。


読者獲得を目指すブロガーにもお勧めです。

思考を冷凍する

何となくブログをスタートし早2ヶ月たちましたが、どうも何が書きたいのかが定まりませんでした。

ブログタイトルも気まぐれだったりします。



何となく書くのではなく、忙しい時期の一部をブログに費やすからには、

実りある書き物にしたいものです。

そこで今後の方向性についてちょっと考えてみました。



まず、なぜブログを書くかってこと。

それは思考を冷凍するためです。


思考を例えるとしたら、水のようなものだと思います。

思考は放っておくと、流れたり蒸発したりして消えてしまう。

そして頭の中にある間は形がないですが、表現することにより何らかの形にすることは可能です。


ブログは思考を冷凍して保存しておく、いわば冷考庫として利用するには最適です。



では今後の方向性としてブログをどうするか。

ブログ指針3ヶ条を設定することにしました。



1.疑問を発する

→ 僕のような若輩者ができることは高尚で的を得た論を発することよりも、

  権威ある考えや最もそうな理論に対してなぜそうなのか疑問を表明し探求することです。
   そして若手の目から見て管理者や先輩SEの行動がどう映っているか。

  ということに重点を置いてブログを書きます。

   目指すべき読者層は共感していただける方だけでなく、中堅、上級のSEや管理者です。


 

2.ナイスなことを見つける

→正直なところ今までは愚痴を一般論にしたような記事が多かったのですが、

  これからは色々なナイスだと思ったことを見つけて記録していきたいと思います。



3.顧客思考のブログを書く

→読者というお客様があってのブログですから、顧客が分かりやすく楽しめるような

  ブログを書いていきたいです。コメントやトラックバックしてもらえるような記事がモットー。

   なるべく短く言いたいことが明快な記事を書くよう心掛けます。



って言ってる尻から結構行数長くなったり。汗

まだまだ道は遠そうですorz

モバイル業界が熱い

久々に日経コミュニケーションを読んでみたら、興味深い記事が。

固定電話と携帯電話の融合についてです。


学生時代はゼミでモバイル業界について研究し、

今は某大手モバイル企業から移動体通信システムを受注し開発していますが、

どうもこの業界は目立った動きがあまり無くてつまらないなぁと思っていました。


でも最近はナンバーポータビリティの導入だとかソフトバンクの参入騒動だとかで

動きがダイナミックになってきましたね。


au VS ドコモの第3世代携帯電話の戦いも気になります。


実はこの二社は通信システムの開発手法の面でも異なっています。

KDDIは自社中心の開発。NTTドコモはベンダー中心の開発。

今後この異なる手法のどちらが功を奏するか、という視点からも二社の動向は面白い。


とにもかくにも今年はモバイル業界が熱そうです。

加熱しすぎて沸騰しないといいですけどね。

1 | 2 | 3 | 4 | 最初次のページへ >>