良いプログラマとは何かを組織で共有できているか？
幾つか引用します
- 技術に対して情熱がある。情熱が無く、プログラミングが賃金を得るための仕事でしかない人は駄目。
- 家で趣味でコード書くぐらいが必要。
- 技術的な話題を話し出したら止まらないような人が良い。促されても技術的な話題で眼を輝かす事ができない人は駄目。
- 自分で勝手に最新技術を学び続ける。「ああ、それなら出来ますよ。会社の費用で研修を受けさせてくれれば、やれるようになります。」と言うタイプの人はアウト。
これと関連するのが次の記事です。
ソフトウェア開発が好きでないサラリーマンエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
職種別採用をしない大企業の場合「たまたま割り当てられた仕事がソフトウェアエンジニアだった」ということが起こりやすいので、この記事で言われているサラリーマンエンジニアが生まれやすいでしょう。
たまたまソフトウェアエンジニアになったとしても、それまでコードを書いたことが無かったとしても、良いプログラマとはどういう人のことを言うのかという価値観が組織的に共有できていれば、向上心さえあればその人は伸びてゆくでしょう。学ぶことの楽しさを覚え、新しいことに挑戦し、儲けに貢献できるでしょう。
逆に上記の良いプログラマの条件を見て「どうしてこれが優秀なんだ？」と首をかしげる人が多い組織に入り、良いプログラマとは何かを知らないまま過ごせばサラリーマンエンジニアの仲間入りです。サラリーマンエンジニアというのは脆弱なジョブアンカーです。ジョブアンカーというのは職業人生の最初の数年で形成される仕事への取り組み姿勢のことであり、これが脆弱というのは「生活のために仕方なくやっている」「必要以上のことは勉強しない」という姿勢の人材、良いプログラマとは真逆の人材を生み出してしまう由々しき状態です。
邪推かもしれませんが、Life with open mind: パナソニックを退社しました の方は元々良いプログラマの価値観を理解しており、理解していない組織に入り、去っていったのではないかと思います。勿体無いことです。
このエントリを読んで、自分の組織は怪しいなと思った方は組織の中で議論する機会を設けることを強くおすすめします。
辞めた人の意見を誰でも見られる良い時代
ここ1年で退職エントリというのが増えました。こんなやつです。人それぞれのキャリア観や、色々な会社の事情がわかって、面白いですね。
「退職しました」ブログエントリのまとめ - NAVER まとめ
この流れは一言で言えば「そこがどんな会社なのか誰でもわかるようになること」です。これは誰にとっても歓迎すべきことなのではないかと思います。もう少し話を大きくすると、これはソーシャルメディア時代の賜物であり、すなわち「隠し事のできない時代」を意味すると思います。どんなに隠しておきたいことも、明らかにしようという意志があれば、それを止めることはできません。
退職エントリ以外に、このようなウェブサイトも流れを押しています。
- 「社員による会社評価」 就職・転職リサーチ Vorkers
- 年収・口コミ・企業評判・面接情報など転職に役立つ情報サイト | キャリコネ
- 現場を重視した生のニュースをタブーなく追求・配信:MyNewsJapan
仮に、どんな会社であるか隠し事ができなくなるとすれば、会社はどう変わるでしょうか。採用はどう変わるでしょうか。
初めて就職しようとする人達にとっては、理想と現実のギャップがあるということをあらかじめ知ることができる。体感することはできなくても、どんなに良さそうな会社に行っても受け入れなければならないことがある。それでも諦めずに頑張ってる人達が沢山いる…ということを知ることができるだけで十分です。明らかなミスマッチも防げます。
企業にとっては、良い労働環境にしようというポジティブな力が働く。従業員が何を考えて働いているかがわかる。応募してくる人が何を求めているかがわかる。マッチした人を採用できる。自分の所だけではなく、よその会社の従業員がイキイキしながら働いているのか否か、どうしてそうなのかがわかり、負けないように頑張るきっかけになる。退職エントリとは逆に、企業側からリアルな現場を伝えるエントリを書いたっていい。むしろどんどん書くべき。着飾ったってどうせ後でバレます。
「隠し事なんてできないというのであれば、辞めたときのことだけじゃなくて、"普段働いていて楽しいです！"っていうエントリも書けばいいのに」という意見があるかもしれません。確かにその通りです。ただそれはブログのエントリとしてではなく、もっとリアルタイム性の高いソーシャルメディアに表れるのではないでしょうか。楽しいことって、すぐ「楽しい！」って言いますよね。
さすがに今はまだ「隠し事のできない時代」とは言えません。ただ、流れとしては確実に進んでおり、実際に退職エントリが一般化している今を形容するなら「辞めた人の意見を誰でも見られる良い時代」と言えます。
「大企業辞めた自慢」の若者増加 | 東スポＷeb – 東京スポーツ新聞社
私が良い時代だと思う一方で、退職エントリを書くことを「大企業辞めた自慢の若者増加」と捉える人もいるようです。もちろん実際の退職エントリを読めばわかるのですが、自慢している文章は見当たりません。あっても、少数でしょう。
すぐ諦める根性の無い人が増えているのであれば確かに問題ですが、それ以外の理由で辞めている人が増えているとしたら？しかも、特に優秀な人ほど該当するとしたら？礼賛でも批判でもなく、淡々と事実が書かれているだけなのに悪い印象に見えてしまったら？企業にいる身としては真剣に考えなくてはいけません。「余計なことを書いてくれてまったく」とため息をつく方もいるかもしれませんが、もしそれが採用・就業環境・インターナルブランドを真剣に考えるきっかけになれば、それだけでも大きな利益の種となるでしょう。
開発者のテストとテストエンジニアの機能テスト
前から薄々思っていたのですが、両者はケースの作り方が全く異なります。
期待値のあるテストとその限界
開発者の考えるテストケースは想定した入力に対して期待した出力があるかというもの。ユーザ操作などの入力に対して、処理・分岐・値の更新・APIコール・メッセージの送信・ログの記録…等、設計したことが実際に行われているかを確かめるものです。ユニットテストがまさにそうです。ASSERT(result==expected)というのは
「ある条件で、あることをすると、こうなるはずだ。」
というものです。
テストエンジニアがエンドユーザの行える操作を駆使して行う機能テストにも同じ考えで作られるケースがあります。例えば「ユーザが○○画面の戻るボタンをしたら△△画面に移るか？」というのも結局人間の言葉で書いているだけでASSERT(result==expected)と同じ発想です。抽象度が異なるだけでやることは同じ。
もちろんこの発想だと、設計通りか？を確かめることはできますが、設計し忘れたことが無いか？を確かめることはできません。処理1,2,3をやればいいと考えていれば、4を忘れていたという欠陥は検出できません。機能Aに関するテストは機能Aに関することだけとしていれば、機能Bに影響してしまうという欠陥は検出できません。完璧なテストなど作れない本質的な理由です。こういった問題は設計の段階で人数(視点)を増やして気づきやすくすることによって解決すべきもので、テスト自体は誰が行っても同じ結果になることが望ましいと思っていました。しかしそれは間違いだと実感するようになりました。
期待値の無いテスト
文書化されていない全くオリジナルのケースを行ってバグをよく見つける人がいます。開発スキルが優れているわけではありません。どうしてその操作をしようと思ったのか聞いても「たまたま」「なんとなく」という曖昧な答えが返ってきます。世間的にこういったスキルを持つ人種が存在するようです。"テストエンジニア 直観力"で調べると出てきます。
息の長いエンジニアでゆこう: 女性の直感力が生きるIT分野 －テストエンジニア－
私はとても重要なことに気づきました。彼らの作るテストケースとは
「どうなるかわからないけどやってみよう」
という姿勢から生まれたものなのです。テストとは「ある条件で、あることをすると、こうなるはずだ。」という期待値が無ければならない発想とは全く違います。そもそも「どうなるかわからないけどやってみよう」というのは設計者としては言ってはならないことだと思います。「原因はわからないけどここを変えたら直るかな？」と、あての無い試行錯誤をする人はチェンジニアと揶揄されたりします。
しかし事実、彼らの作る突飛な発想のテストケースによって我々設計者は非常に助けられています。設計者の発想では何人がかりでも非常に想定しにくいケースを拾うのは彼らしかいません。設計者はこうしたケースからあらかじめ何に気をつければよいかを学ぶべき…なのですが、中には学びようが無いことも少なくない気がします。「次から気をつけて下さい」と言われても「何に？」というオチにならざるを得ない場合がある気がします。
とは言っても、バグを見つける突飛なテストケースを思いつくスキルは形式知にできません…と諦めては前に進めません。色々なプロジェクトから突飛なテストケースを集めれば共通項がわかるかもしれません。今のところは、もしチームに期待値の無いテストで多くのバグを見つけるテストエンジニアがいるならば大事にすべきかと思います。つかみ所の無いテーマですが、今後も考えてゆくつもりです。
「あなたが普段使っているツールを教えてください。」
あなたが普段使っているツールを教えてください。
http://saltheads.blog134.fc2.com/blog-entry-64.html
というプログラマー向けの記事を見つけました。ツールと言っても色々ありますが、質問の内容からすると「個人ユース」「無償で提供されていることが多い」というツール群を指しているのかと思われます。わからない質問やツールを使わないケースもありますがそれらは後で勉強しておくとして、この機会に今を正直に書き留めておこうと思います。色々な人の回答を見てみたいです。
- -
■ ソースコードを編集するとき。
xyzzy：Windows用のEmacsみたいなもの。学生の時によくLinuxでEmacsを使っていたのでその延長上でなんとなくこれにしました。そんなにEmacsファンでもないのですが、CtrlとCaps Lockは必ず入れ替えることにしています。
■ ディレクトリの下にあるたくさんのファイルから、指定した文字列をファイル名に含んでいるファイルを検索するとき。
Windowsの標準機能：探すだけならこれです。
Cygwinのfind：見つかったファイルに対して何か処理する場合はこちらです。案外出番低い。
■ ディレクトリの下にあるたくさんのファイルから、指定した文字列をファイルの中に含んでいるファイルを検索するとき。
Windowsの標準機能：探すだけならこれです。
Cygwinのgrep：見つかったファイルに対して何か処理する場合はこちらです。わりと出番ある。
■ 二つのテキストファイルの内容を比較するとき。
Tortoise Merge：大抵はSubversion管理下のソースファイルなのでTortoise SVNに含まれているこれを使います。
WinMerge：Subversion管理下に無いテキストファイルを比較する場合はこちらを使います。出番低め。
■ エクスプローラで見つけたディレクトリで、コマンドプロンプトを起動するとき。
これが必要な状況になったことが無く、やり方もわかりません。
■ zipファイルを解凍するとき。ファイルを圧縮するとき。
Lhaplus：ダブルクリックで解凍、右クリックメニューで圧縮ができれば何でもいいです。
Cygwinのzip/unzip：圧縮・解凍した後に何か処理する場合はこちらです。
■ プロセスフローダイヤグラムを描くとき。
この図を知りません。描いたことがありません。
■ 箇条書きや段落を作って入れ替えながら文章を練りたいとき。アウトラインプロセッサを使いたいとき。マインドマップを描きたいとき。
テキストエディタ上でやります。マインドマップは描くこともありますがツールではなく紙に描きます。アウトラインプロセッサは使ったことがありません。xyzzyでもできるみたいですね。 http://d.hatena.ne.jp/kamuycikap/20091230/1262191457
■ スクリプト言語で処理を書きたいとき。
Bash：Cygwinを入れているので、よくやるバッチ処理はBashで書いています。
Ruby：定型的なソースファイルや、ちょっとしたcsvを生成するのに使うことがあります。かじりかけなので使っているとは言いがたいレベル。ちゃんと覚えたい。
■ そのほか、今使っていて、おすすめのツール
bluewind：コマンドライン型ランチャー。よく使うアプリケーションや、よく開くフォルダを登録しています。画面を占有せず、キーボードから手を離さなくてもよいのがお気に入り。同系統のツールは比較していないので、もっといいのがあるかもしれません。
Sphinx：reStructed Text(reST) 形式のテキストファイルを書くとHTML等に変換することのできるドキュメント生成ツール。章や図の参照ができ、章ごとにファイルを分けることができます。また、テキストなのでSubversionでの変更管理がしやすいです。機能だけ見れば「さらばWord」と言いたいくらいのツール。今のところ出番が少ないのでどんどん増やしたい。
■ 今は使っていないけど、使ってみたいツール
UML等の設計図を描けるWebアプリケーションがあるらしいので調べてみたいです。
- -
常用しているけど使いこなせているとは言えないツールや、類似ツールの比較をさぼって使い続けているツールがあるので、これを機会に見直そうと思いました。
「昔書いたコードだから覚えていない」
…というのはよく聞くフレーズですが、必ずしもそうではないかなと思うようになりました。勿論、触れていなければ忘れていくものだとは思いますが、考えて設計したものであれば年が過ぎても覚えていて、逆にやっつけで書いたコードや理解が浅いコードは何日もしないうちに忘れてしまう…自信を持って組み立てた論理は覚えているが、馴染みの薄い言語で手探りで書き始めたコードや、意図を理解しづらいコードに対する修正は忘れやすい。自他共に何年か見てきた経験上の感覚でしかありませんが、そのように感じます。
「昔書いたコードを覚えているかどうか」というのは
- そこが設計されている箇所かどうか
- 設計のできる人かどうか
を測るのに使えるのかもしれません。
(e.g.)
「え？さぁー当時の私ってそんなこと書きましたっけ。ちょっとソース見てみないとわからないですね。」
「○○は△△のときに××を呼び出すから、☆☆が起きたとすれば…まず□□を確認してみるのがよいのではないか。」
HTC Desire(X06HT, SB公式Froyo) のrootをとってみた
HTC Desireを使っています。日本でソフトバンクモバイルからX06HTとして発売されて早1年以上経ちました。よく言われることですが、スマートフォンはその使い方から電力消費量が多く、バッテリーがすぐになくなります。ちょくちょくTwitterやWEBを見てると1日が限度です。外付けのバッテリーを持っていますが、持ち歩くのはかさばりますし、家に忘れることもあるので何とかしたいなと思っていました。
- 電池がすぐなくなるんだよな。もっといいバッテリーないかな。
- あるじゃないの。 Amazon.co.jp： HTC Desire X06HT＆II 大容量バッテリー3000mAh＆専用設計カバー: 家電・カメラ
- 標準バッテリーは1400mAhだから倍以上だなー。
- 電池容量が倍になるんならクロックアップしても良さそうだし、逆に使ってない時にクロック落とせば更に節約できそう。そもそもできるのかな。
- あるじゃないの。 SetCPU for Root Users - Android Apps on Google Play
- root必須…やるしかないのか。
ちょっと調べてみたら手順自体は楽そう。というわけでrootをとることに。(こちらを参考にしました)
HTC Desire の rootをとってみた - Misty Moonlit Night
unrevokedが勝手にやってくれるようです。
おや？
Error: failed to get root. Is your firmware too new?
ROMはソフトバンクの公式Froyoです。too newなのでしょうか。なんてことを考えても仕方ない。とりあえず思いつきでEasy TetherのEnable to allow USB tetheringのチェックを外して再試行。
うまくいってしまいました。さらば公式保証。SetCPUについてはまた後日。
…後々探してみたらunrevokedのバージョンを古くすれば(Error: failed to get root. Is your firmware too new?)の問題は回避できるという情報が見つかりました。
SoftBank X06HT Wiki - root化
忘れられたモジュール指向設計
OOとかMDDとか言われてますが
組込み…(と、ひとくくりにするのは大間違いな気もするこの頃ですが)…では、
- 使用言語のトップは未だCだがC++が増えてきている。
- UMLやSysMLからコードを生成できるツールが登場してきている。
- 大抵のプロセッサ向けのCコンパイラはC++もコンパイルできる。(と勝手に思っている)
- ある程度大きくてWEBに繋がるシステムならAndroidが選択肢に入る。
という、「昔ながらのCでの構造化設計はいずれ段々なくなっていって、みんなOOしてMDDしてフレームワークを使うことも覚えてハッピーになるんですよー」と言えば「そうかー」と言われそうな状況なのかもしれませんが、私にはあんまりそうは思えません。むしろちゃんと構造化設計ができないまま言語がC++やJavaになったところで…モデリングという考え方を覚えないままMDDツールを使ったところで…ゴミはゴミ、スパゲッティはスパゲッティという状況は変わらないか、悪化するのではないかと懸念しています。
言語仕様は構造を考えるスキルを解決しない
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して
私はよく知りませんがSI業界という業界があって、そこではJavaを使って開発するのが一般的らしいです。が、この文を見る限りではせっかく言語がJavaでも考え方が処理中心設計のままで、それが構造に現れていますね。
あまり語られなかったモジュール指向設計
処理中心設計とオブジェクト指向設計の間にある考え方…モジュール指向設計。この辺の話はC言語の書籍に無いかと探してみましたが、全くもって載っていません。よく書いてあるのが以下の2エントリーです。(私のエントリーよりこっち2つを良く読んだ方が良いです)
オブジェクト指向
モジュール指向プログラミングのすすめ - 千里霧中の犀
このような考え方が処理中心設計とオブジェクト指向設計の間にあるはずなのですが、そのことはなぜか全然語られないまま時は過ぎ…必ずオブジェクト指向になると謳われた仕様を持った言語ができました。しかしそれは構造を考える人と考えない人の差を埋めるには至りませんでした。ましてや職業プログラマでCのみ使える人がスコープ・依存関係・責務のマッピングの重要性に気がつくことは少ないです。…というのが職場や同職の友人や上記に紹介したようなブログから考えられる職業プログラマの印象です。
私の周囲ではC言語しか触ったことが無いという人も多いのですが、Cでも
というのを理解できることが、目の前に来ているC++やMDDにサクサクと進むための前提条件ではないのかなと思います。
