知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ

仕事で資料を作ってレビューを依頼すると、やたらと細かい点にこだわって指摘をして来る人がいる。曰く、この英単語は単数形ではなくて複数形を使うべきだ等々。確かにその指摘は（それなりに）当たっていて指摘としては有り難いのだけど、実際問題としてこちらが求めているのはそんな枝葉末節ではなく、もっと広い視点での指摘だったりする。 資料全体の論理構成に問題はないのか？ 主旨の展開をもっと直した方が良いのではないのか？ 議論の方向性は他と整合性が取れているのか？ そんな「お願い」を明記しておいても、大局的な視点での指摘をくれる人はあまりいない。細かい箇所にこだわるのは簡単だが、大きな枠組みを踏まえた上での指摘をするのは意外に難しいようだ。 特に厄介なのは「自分の若い頃は...」と自分の現役時代の活躍を忘れられないリーダの指摘であり、思わず「アナタの仕事はそんな事ではないでしょ」と突っ込みを入れたくなってし

開発現場では、新規の開発案件等に対して必要工数の見積もりを要求され、それはそれなりに難しいものが有るけれど、それ以上に難しいのは障害対応の工数見積もりだと思う。もちろん、内容を一目見て容易に原因と修正内容が分かるものがある一方で、原因の調査に難航し、さらに修正確認にも手間取るものが珍しくなかったりする。 何故そんなに時間がかかってしまうのだろうかと思って改めて考えてみたところ、対応に時間を要するものはこんな特徴を持っているようだ。 障害レポートに記載されている再現手順に従っても問題が再現しない。記載されていない情報に相違があるらしいので、レポートの報告者に詳細を問い合わせをする必要があり、そのやり取りに時間がかかってしまう。 原因調査のためにログ出力を追加したら問題が発生しなくなってしまう。ログ出力処理が、タイミングを何か変えてしまっているらしいが、その原因や影響理由が分からない。 不特定

ソフトウェア開発の現場では様々な作業が発生するけれど、コミット毎の自動ビルドや回帰テスト実行など、人間の手を介さずに実行できるものは出来るだけ自動化を図るようにしている。最近はJenkinsを始めとするCIツールや上手い使いこなし方などの情報も豊富に出まわってきており、作業効率化を積極的に推し進めようとする人の熱意には感動を覚えるほどだ。たぶん、ちまちまとした手作業を嫌う人は世の中に多いのだろう。（ワタシもその一人） この辺の感覚は、普通に自動化ツールを使いこなしている現場では当たり前のことなのだけど、便利さを知らない人には、実はなかなか理解してもらえない類のものだったりする。なんせ、慣れた作業だから手作業でもスイスイと進められるし、操作に迷うことも失敗することも無いのだ。そんな「仕事の充実感」を覚える作業をわざわざ自動化するなんて、一体何の意味があるのさ？という訳だ。さらに喧しいケースだ

開発の仕事を行う時にはソースコードだけではなく、仕様書、バグレポート、再発防止策まで様々な資料をまとめる必要がある。そんな情報は、通常「社内ヒエラルキーの上位の人」が確認するわけで、それはそれで組織として必要なプロセスだし、記載の問題を指摘してくれるなら有益なことだと思う。 しかしながら、そのような確認作業が現場担当者の反感を買うこともある。その一例。 確認レベルが人によって異なる あるリーダがOKと言ったのに、同じ記載を見た隣のリーダはNGと判断してしまう。部門としての統一基準が無く、確認する人の思い込みや気分次第で判断はバラバラ。両者で認識合わせをして現場の混乱を招かないようにして欲しいところだが、「あの人にはあの人の考えが有るから」等という非合理的な言い訳がなぜか平気で通用してしまう。 資料記載の基準が存在しない 特に明確な基準が無いので、今までの資料の記載内容に合わせる形で追記した

開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった（行かなかった）事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現場での取り組み事例などは非常に気になるトピックスだったりする。 そんな事を考えつつ或る人と話をしていたら、その内容が強烈だったので差し障りの無い程度に紹介してみたい。 現場で使えない人間は退職に追い込む。わざわざ教育しなくても代替の開発者は他に幾らでもいる。 毎年xxx人を採用して、同じ数の退職者が出る。生き残った者だけが仕事を続けられる。 開発現場を回すのがマネージャの仕事。そのためには人月単価の安い下請けを使うことが必須だし、常に安い所を探している。 Excelさえ有れば仕様書を書けるし、人員計画、ガントチャートや進捗報告も作れる。だから、他のツールは

どういう訳か知らないけれど、日本の会社では「頑張って働く」という意味が「夜遅くまで残業して働く」ことと同じと思われているフシがあるように思う。作業時間にリニアに比例する仕事ならそのような関係が成り立つのかも知れないけれど、長い時間働けば当然疲れて能率は落ちるはずだし、その疲れが翌日まで残って業務に影響するのであれば、そもそも残業した意味なんて無くなってしまうはずだ。それなのに、残業を礼賛してやまない精神論重視の風潮が残るのは嘆かわしいことだと思う。 会社というところはつくづく不思議な場所だ。特に開発の現場では、いくら能率の悪いやり方をしていても怒られることが無いし、品質の低いアウトプットを出していても残業を続ける限り「頑張って働く良い奴」と前向きな評価が得られてしまうし、何もせずに会社に残っているだけで残業代というお金が貰えてしまうのだ。一体いつからこのような社会システムが構築されてしまっ

チーム内の作業が上手く回っていないという開発の様子を観察すると、なかなか興味深いものがある。 リーダはなぜか常に忙しい 夜遅くまで残って残業するほど忙しいようなのだが、その忙しさの原因を聞いても本人の口からまともな説明は返ってこない。つまり、何が原因で忙しく、今後の見通しはどうなっているのか、本人自身が分かっていないのだ。自分自身の忙しさに酔いしれているリーダは、とにかく忙しいことが嬉しいらしい。 問題の全貌が見えない プロジェクトのヒアリングを進めると、アレも有ってコレも有ってと次々と問題が出てくるものの、その総数が不明で、現在どの段階まで達しているのか不明だ。問題が残っているという点だけは同意だけど、それに勝るとも劣らず解決済みの問題も多数存在するはずであり、その日々の変化を追跡していけば最後の着地点が見えてくるはずだ。それなのに、同じ問題を何度も繰り返し取り上げて堂々巡りの議論を続け

開発現場で問題の再発防止策を検討すると、その結論として出てくるものの一つにチェックリストが有る。曰く、このチェックリストに従って確認を行えば、同じような問題の発生を防ぐことができるし、誰でも同じレベルで作業を行うことが出来る。チェックリストは素晴らしい、是非ともチェックリストを作るべきだ、チェックリストに従わないのはけしからん等々。 確かにその指摘は正しくで、実施すべき有力な対策の一つではある。優秀な開発者が自分の作業を終えて、万が一のミスが無いか確認する程度の使い方なら充分に有効だと思う。しかし、チェックリストの有効性を信じて疑わない人の姿を見ると、ちょっと待って欲しいと言いたくなってしまう。現場の人なら既に知っているように、チェックリストは同時に問題も多い存在だ。例えば、開発現場でこんな状態を見かけることは少なくないだろう。 確認作業の形骸化 「チェックリストで確認する目的は？」と聞か

好きでやっているソフトウェア開発の仕事だけど、周囲を見渡すと実はこんな仕事は好きではないと言い切る人が多くて驚いたことがある。与えられた仕事だけをやっておけば万事OK、チーム全体のレベル向上やプロセス改善、新しい創意工夫なんて自分には関係ないことだし、そもそも仕事に関係しない余計なことに巻き込まないで欲しいと、面と向かって言われたこともある。会社で働く人の目的は実に様々なのだ。 このような開発者が増えてくると、チーム全体としての品質・生産性向上なんて見込めなくなるし、投資対効果を求める会社としては「スキルなんか要らないから人月単価の安い人が欲しい」と外部の会社に求めるようになってくる。一部のやる気とスキルのある人たちが方針と手順を決めて、残りの人はそのルールに従うのみという「ソフトウェア工場」が出来上がるわけだ。 ソフトウェアエンジニアとそれを取り巻く不幸な環境は、長い年月に渡って形成され

開発現場で良く聞くプロジェクト評価の表現として、こんなものがある。 バグが多い 忙しくて残業が多い レビューが少ない 経験に基づく直感というものは凄く大事（しかも意外に良く当たる）だし、当事者間で意識共有を図るには何も問題ない表現だと思うけど、同じ文脈を持たない部外の人には理解が難しい言い回しだ。仕事だから忙しいのは当たり前の事だし、同程度のバグ密度でも開発規模が大きければそれに比例して障害件数も増えるのは当然というわけだ。 だから、関係者以外に対してプロジェクトの状況を説明するには、簡潔な結論と共に、その根拠となる理由を客観的なデータと共に説明する必要がある。 過去3年間のプロジェクトにおける平均バグ密度はxx件だったのに対して、今回はxx件となりxx%増加している。 前回のプロジェクトでの平均残業時間は一人あたりの平均で毎月xx時間だったのに、今回はxx時間に増えている。 社内の開発規

技術者として必要なスキルは色々あるけれど、その中で最も大切なものは何だろうかと知人と議論したことがある。その中には、「自分の手で新しいモノを生み出せる力」や「曖昧な要求を確実に取りまとめる力」「プロジェクトを成功に導く力」「開発チームを引っ張る力」など広範囲に渡る能力が含まれるわけで、そのような個々のスキルを片っ端から列挙していったらキリが無いように思う。 もちろん、ITスキル標準(ITSS)や組み込みスキル標準(ETSS)のように「標準」としてまとめられた物差しもあるから、これを使えば良いではないかという主張もあるのだけど、レベルというランク付けが必ずしも意義有る評価基準とは思えないし、「私はレベルXのスキルを持っています」と自己紹介する人なんて見たことがない。せいぜい、社内の人事評価の参考として使う程度ではないのだろうか。 もう少し現実的な考え方を求めてみると、最も必要なスキルは「好奇

UMLの図面を描いていてもどかしく感じるのは、モデルで表現された概念が本当に矛盾・モレ無く実行可能なのか確信を持てない点だと思う。シーケンス図やステートマシン図なら動的な振る舞いを示すものなので理解しやすいし、動作をシミュレーションできるツールも有るけれど、検証しているわけではないから「ある特定の条件下では失敗する」ケースなんて、なかなか読み取れない。充分な経験を積んだ開発者がモデルの良し悪しをコメントしてくれるなら有難いものの、そんな人がいない職場も珍しくないし、そもそもそのような属人性に頼る開発も好ましくないように感じる。 そんな中、形式手法のAlloyについて書かれた本が出版されたので目を通してみた。Alloyは全くの初心者なので警戒していたのは事実だけど、（細かな文法はともかくとして）内容的には容易に理解できるもので、それほど難しくないことが分かった。著者の言う「軽量形式手法」が「

ある人から開発現場におけるプロセス改善活動の目的は何か？と聞かれたことがある。きれい事を言えば、成果物の品質向上であり、手戻り作業の削減や、前回の開発経験をフィードバックした効率的な作業ということになるだろう。もちろん、それはそれで間違っていないし、教科書にも載っているような典型的なものだけど、開発現場では何もしなくてもそれなりに作業が出来てしまうので、実は何もやらなくても良いではないかという意見を持つ人も少なくない。 改善作業に手間をかけるだけのメリットがない。 改善活動をしても、開発者個人には何の利益もない。 どうせバグは出るのだから、品質管理部門でカバーすれば事足りる。 改善の結果として残業代が減るのは困る。 品質は組織の問題であって、開発者個人の問題ではない。 個人的には、開発者個人として、或いは開発組織全体として改善活動を継続していかないと、国内・国外を問わず他者（他社）に負けて

ソフトウェア開発現場に種々の不満は尽きないけれど、そんな担当者の不平、不満、要望、要求を一つ一つ取り上げて対処し、決して無視しないのがリーダの大切な仕事ではないかと思う。担当者が快適に、しかも気分良く仕事を進められるからこそ、チームとしての力が発揮できるのであり、成果物のQCDにも繋がるのだろう。チーム管理というとメンバに対して「あれをやれ」「これをやれ」と指図することが仕事だと思われがちだけど、同じくらいに大切なのはその仕事がスムーズに進められるようにお膳立てをすることだと思う。 優れたプロジェクトリーダは、メンバとの話の中から種々の問題を確実に捉え、解決に向かって努力することが多い。仕事の進め方、作業方法、工夫など、仕事に直結することから間接的なことまで、チームや開発者の個人レベルで改善出来る問題は少なくないはずだ。「チームとしてここまでは改善出来る、これは理由があって対処できない、こ

Life is beautifulでお馴染みの中島聡さんの本。ブログの方はいつも目を通しているけど、ブログや雑誌記事がまとめられたこの本を読んで、エンジニアとしての生き方を貫き、若い人達を叱咤激励する中島さんの熱き想いを改めて知ることが出来たように思う。 日本のエンジニアは、その労働の割には社会的地位が高くないし待遇も恵まれていないので、話をしても愚痴ばかりで悲しいものがあるけれど、例えば米国へ行って現地の開発者と親しくなると「同じような仕事をしているのに年収のケタが違う！」ことを知って驚くことがある。そんな夢のような（？）世界がこの世の中に存在することを知ると、自分たちとのギャップにさらに自己嫌悪に陥ることもあるようだ。 もちろん、お金が全てではないし会社を取り巻く環境も大きく異なるので、単純に米国の方が良いと言うつもりは無いけれど、少なくとも「自分の好きなことをやって人生の満足感を得る

昔、ソフトウェア開発のベテランの方に質問したことがある。 「どうしたら優れた開発者になれるのでしょうか？」 予想していた回答は「この本を読め」とか「あれを学べ」と言ったものだったのだけど、実際の回答は全然違っていた。 「自分の作業を箇条書きで表現出来るようになることだ」 これだけでは腑に落ちないので、その理由を聞いてみたところ、こんな説明が返ってきた。自分がやるべき範囲がどこまでなのか、何が必須項目の作業であり、何が見送り可能な項目なのか、作業に必要なものは何なのか等々を全て考えば、簡潔に箇条書きで表現できるはずだ。箇条書きで表現できないのなら、それは自分がやるべき事を自分自身で分かっていないことの証拠に他ならない。開発者は実際の作業の中でアレコレと疑問を持つはずなのに、それを確認しないまま勝手に作業を進めてしまい、後で予期せぬ問題を引き起こすことが多い。本当の開発者なら、その確認、検証、

残業や休日出勤で仕事を片付けるのは悪くはないし、納期を守るプロ意識として結構なことだとは思うのだけど、そうやって力任せの解決をいつまでも続けていると、本来解決すべき問題の本質を見失っている気がしてならない。毎日残業して仕事を続けなければならない状況には、何か別の要因が有るはずだ。 担当者間で仕事の割り振りが上手く出来ていない。 仕事をうまく片付けて回すためのノウハウが共有されていない。 知恵を出せば効率的に進める方法が有るのに、面倒なので何も考えていない。 効率の悪い方法を繰り返すことに何の疑問も持っていない。 言われた通りの仕事の進め方に従うことが必須だと思い込んでいる。 例えば、納期のように明確な締切りが存在するだけで、脇目もふらずテキパキと仕事を片付けられる人は多い。そんな状況になると無駄なことは省くようになるし、少しでも効率的な進め方をするためにいろいろと頭をひねって考えるはずだ。

技術者はどちらかと言うと生真面目な人が多くて、例えば営業の人のように「口だけ上手いので話をするときに気をつけねば」と思う人は少ない。営業の人が絡むとややこしい話も、技術者同士で話をするとうまくまとまることも多い。多分、技術者は嘘をつかない（つけない）のが取り柄なのだと思う。 そんな真面目な性格が影響するのか、技術者はつまらない作業でも一人で片付けてしまうことが珍しくない。もちろん、開発の現場で定型化出来ない仕事も多いし、これはこれで立派な仕事の一つだから悪くはないのだけど、少しだけ考えてみればもっと効率的な方法が有るはずだ。 Excelファイルで障害管理を行うので、他の人は情報の更新ができず作業が止まってしまう。 TracのようなBTSを使えば、同時に複数の開発者で更新出来るので効率的。 毎回手作業でテストを繰り返している。 単体テストやスクリプトの利用による作業の自動化を計れば、もっと短

開発チーム以外との情報共有用としてQuestion2Answerを導入してみた。従来はメールやExcelファイルで問い合わせ事項のやり取りを行うことが多かったけれど、その方法ではどうしても手間がかかるし、情報が関係者のみに留まってしまって共有範囲に制約が出てしまう。Tracを使っても良いのだけど「チケット」という用語を始めとして専門家向けのインターフェースなので、開発者以外の人には少々取っ付きにくい。 Question2AnswerはPHPベースのQ&Aシステムで、質問と回答をシンプルにやり取りするためのツールだ。嬉しいことに日本語に翻訳してくれている方がいるので、その日本語リソースも使わせてもらった。今回のインストール環境は下記の通り。 MacOS X 10.6.4 (Snow Leopard) Question2Answer 1.2.1 MySQL 5.1.48 (MacPorts)