itの最近のブログ記事

中規模以上のプロジェクト運用の秘訣
に書いたことの焼き直し格言。
管理者の立場に立ってこそ実感する…はずなんですけどね。
さて、顧客の感情(満足)は当然として、開発者(プログラマ)の感情についてですが、開発者は大抵ほうっておいても生産的活動を勝手にするのでほうっておければ一番良いのですが、やはり人間ということと、技術力の差の問題により、規約や進捗管理などで縛る必要はあります。良くできた開発者はそれらもほうっておいてもできるんですけどね。
で、しぶしぶ一見面倒そうだけど管理上必要な作業などをお願いしたりするケース(*)が出てくると思いますが、それを行う意義を納得してもらわないと、最終的に好きなようにやらせるよりも全体の成果が出ないということが起こってきます。

(*)のような作業の意義について、管理者自身は理解できているでしょうか？あるいは理解できていたとしても、それが必須であることを理由に目的化して、まず管理ありきになっていないでしょうか？どちらにせよ、「管理」を嬉々としてやるような人がよく開発者の槍玉に上がります。開発者がある規約の意義についてたずねた時に管理者が期限を悪くするようだとプロジェクトはどうなるでしょうか？管理者は気分で管理してはなりません。開発者の気分を害してはいけません。それがマネジメントってもんです。

管理者の作戦として、開発者を怒らせることで動かす、という高等戦術もありますが、これは本当に高等戦術です。管理者の役割って、子供をしつける親みたいなものです。子供を叱ることはあっても怒るのは十分にその結果を考えた結果でしょう。親は我が侭な子供を躾けつつ、子供が遊びの中から見つける新しいことを微笑ましく思いながら成長を見守るものです。子供の怒りに怒りで返すのではなく納得を与える。そして、いざというときにはきちんと責任を取る。

理想としては、管理者は開発者を信頼して、責任だけは取る、という態度でしょう。信頼できる開発者を自分で手配できない環境の管理者は厳しいですねぇ。

最近、CodeZine：Reflectionを利用して再帰的にオブジェクトの内容を文字列化する の記事がよく紹介されているのを見て、それならば、と、昔作ったコードを晒します。

XMLSerializer.java
Encoder.java

オブジェクトへの復元ができるのがキモです。
どんなものかは過去の記事にて。queue の日記 - Java オブジェクト <-> XML変換

sidebar.jp での applet との通信や、サーバ上でのオブジェクトの保存/復元、及びデバッグログなどで使っています。
本当はこれも含めた各種ライブラリをアップデートして公開したいところですが、公開すると API を弄りにくくなるということでへろっています-_-。
上記はソースだけの公開ということで、切り貼りして使ってもらおうが一向に構いません。

また唐突にプログラミングネタ。

檜山正幸のキマイラ飼育記:ウォーターフォール擁護論

ウォーターフォールの利点、というか、私がよいと思うところは、実は大多数である(理解力/向上心/責任感的に)信頼できない開発者が混ざっても何とかさせようとした方法論であることです。
欠点は、実際には手戻りが当たり前なのに、手戻りのための手続きコストを下げる策がなく、(そのため終盤になると仕様変更に異常に拒否的になってしまい)最終的には顧客の要求を全て満たすことができないため顧客を満足させにくいことです。

いわゆるアジャイル(この言葉、何を意味してるかよく解らないので好きではありません)だと、Win-Win になれる可能性が高いのですが、全員に「考える」というスキルを要求するのでまさしく大規模な開発現場ではまず成功しないと思っています。

当然自分のプロジェクトでは「考える」ことができると確信している人しか加えないですけど^^;。

(追記)
「考えさせるな」について補足すると、ウォーターフォール(に限らず比較的多くのソフトウェア工学的)は、プロジェクトメンバーの最低レベルに合わせて作られるのが普通で、なんというか、そのいわゆる最低レベルに当たる人が中途半端に「考える」と、ひずみが出てしまう、という点と、できる/意欲ある人が「考える」と、多数の「うまく考えられない人」がついていけなくなったり、それを真似した結果悪い影響が出てしまったりすることを懸念した結果、意欲ある人まで「考えるな」と言ってしまうようなことが起こるのだろうと思っています。
どちらの方法論も、プロジェクトのメンバーの立ち位置をどちらか一方に集約することが前提になっているため、「通常の」ばらばらの能力の人たちが集まったプロジェクトにおいては、どちらの方法にしてもおかしなところが出てきてしまいます。

ということは、メンバごとにスタンスを選べればよいのではないか？と短絡的に考えられるわけですが、「考える」ことにあまり意欲がなかったり、向いてないと考えられる人が、自ら受動的スタンスを選んだとしても、本当にそれがしたいわけではないので、結局あんまり良い成果には結びつかなかったりします。

私だったら、やっぱりその人が一番好きなことの中でそのプロジェクトに役に立ちそうなことを探すのに一番集中するかな。まぁ既に方法論の話から逸脱してますが^^;。ただ、これを踏まえて言えば、「メンバーの気質に合わせて方法論を切り替える」ようにする、というのが自分なりの答えです。大規模プロジェクトに対する答えにはなっていませんが、大規模であっても、基本的な考え方は変わらないです。

void GraphicWizardsLair( void ); // 設計書コーディングとアジャイルとより。

「設計書コーディング」というキーワードと、naoya さんの「プログラミングは詳細に設計された設計書を実際の形に落とし込むための手段に過ぎないとか」と言ったフレーズに(つまり設計書の存在)、「静的型付け」がバインドされたようなニュアンスになっているところに(ありがちな話ではありますが)引っかかったりします。
両社には相関関係はない、というと御幣がありますが、静的型付けは設計書コーディングのためのものではないことは明らかです。
が、世間的には静的型付けについて、「設計の正しさの検証可能性を上げるためのもの」と認識されてしまっている恐れはあります。悲しいことに。
私的には、型を宣言するのは(いま思いつくまま書いてるので正確ではないと思いますが)、コンテキストを明文化し、設計をしやすくし、後で読みやすくするため、といったところです。

前者の意義も付属的についてきますし、それも重要な利点ですが、それが目的だとは思っていないです。サボって書いてもそこそこの可読性を確保できるのは便利だったりしますし、(interface により)応答可能性を宣言できるというのは(作成中/後の可読性両方の観点で)特に重要と思います(*)。

型を宣言しているからインスペクションが楽になって、利用者が実際に利用できる機能をすぐに一覧できるようになっています(eclipse など)。perl や ruby だと、できるけどちょっと面倒そう(動的にメソッドを付与とかしてるとほとんど不可能)。

Java で非設計書コーディングをすると、かなり楽だったりするんですが、みんなこのへんどう思ってるんでしょ？興味深いなぁ。

*:
Java が万全とは思いませんけどね。inner class ですら冗長で気軽にクロージャ的使い方がしにくいところとか。それに、「呼んでみなきゃ分からない」を「とりあえず呼んでみることができる」と考える非静的型の考え方もまったく否定する気はないです。自分にはあまり向かないけど^^;
私のプログラミング手法は、大雑把にいうと、「とりあえず呼ぶコードを書く」です。そうすると、(その時点でオブジェクトの必要性はもう定まってるのは前提)呼ばれる側を書かなきゃならないことが静的に分かるので、後で書かなきゃとか意識せずに思考を進めることができるんです。インターフェイス指向と呼んでますが、こういうインターフェイスに応じることができる役割が必要だな、というのをトップダウンで考えていく感じです。

Java の実装の話です。

この文章は内輪向けにさっと書いたものを、読んでみていくらか一般的なことかなと思いこちらに掲載してみたものです。事実誤認が含まれる可能性も多分にあることをご了承ください。

sidebar.jp で実験してて、ほとんど害を感じていなかったわけですが、最近解ってきたことも踏まえて、整理してみます。

メイルアドレスのみで認証するシステムには少なくとも以下の問題がありました。

1.メイルを受信できない場所で認証ができない
2.メイルアドレスが無効になった(到達性がなくなった)場合にそのアカウントは完全に使用不能になる
3.メイル盗聴による成りすましの可能性

これ(特に1,2)を回避するには、メイル到達性以外の本人確認手段を併用するしかありません。

a:他の個人情報を入力しておいてもらい、メイルアドレス到達性がなくなった場合の本人確認情報とする

b:メイルアドレスをユーザ識別に用いるが、認証手段として、メイルを受信することに加えて、ユーザが設定したパスワード認証もサポートする

c:メイル認証に加えて、パスワードリマインダ相当の仕組みを導入する

d:USB token/生態認証など

e:他に何かよい本人確認手段はないか…？

a はこちらが保持する情報量が本人確認の確かさに影響します。しかし、正しいとされる情報量の基準が存在しないため、どれだけやっても確実とは言い切れません。持ちたくない個人情報を持たなければならないという問題もあります。また、1のケースにはまったく役に立ちません。

b だと POP3 パスワードを設定する人が続出しそうというのが問題です。パスワードを忘れた際にはメイル認証が使えます。両方の手段が使えなくなった場合はアウトです。

b は a の特殊系ともいえるので、中間案が考えられます。
c のパスワードリマインダ(秘密の質問)はこれにあたります。
世の中のパスワードリマインダは個人情報も集めた上で実施してたりするのでなんだかなぁと思うわけですが、これも、個人情報だけでは本人確認として不適切であるという証拠といえるかもしれません。

しかし、パスワードリマインダはどうしても(推測可能性の面で)パスワードより脆弱になるので、この認証が通っても、登録メイルアドレスにパスワードを送る程度のことしかしません。この認証だけで本人確認とするのは危険ということになります。

d のキーボード以外の入力デバイスを用いた認証というのも最近は現実的になりつつあります。USB-token のほか、指紋認証を供えたノートパソコンもあるくらいで。でもこれはネット越しの認証に使うのは危険すぎ、且つ普及度の点でまだまだ一般的な方法にはできません。
これらのデバイスに対して charrange & response 形式をネット越しにサポートできるようになったら、そして利用者が十分に増えたら有力かも。

まぁ、現状最も使われているのは結局 b なわけで、当面は b 方式の問題点が出ないように注意書きするくらいしかないのかもしれません。

(以下余談)
ところで、3 の問題点(メイル盗聴)を回避するにはメイルを暗号化するしかないのですが、受信者側が暗号化メイルのための鍵ペアを持っていないことが多いので厄介です。リレーポイント間で暗号化通信を行えるようにして、最後は POP3 パスワードを暗号解除キーとして APOP で取り出すようなプロトコルが実装できれば不完全とはいえだいぶ違うのですが…。

エンドポイント間の暗号化は、各SMTPサーバが公開鍵を宣言する(*)か、SSL 等でトンネリングするか、でしょうか。このあたり、最近どういう方向になろうとしているのか追いかけていないのですが…。
本当は送り先メイルアドレスごとに公開鍵があればいいだけですけど。

ユーザが鍵ペアを持てないでいるのは、鍵作成ソフトなどは無料で存在するのに、リポジトリが有料だったり(S/MIME)、手順が MUA で統合されていなかったり(PGP)するからなので、例えば国が証明書リポジトリを運用するとかすると、任意サービスが個々のユーザ向けに暗号化メイルを送れるようになるのかもしれません。

定義無しに謎概念に名前の付いたものがコード上に現れたときに感じること。

最近 DI (Dependency Injection)とか言って、カプセル化を破壊する過去に戻るような概念がもてはやされたりしてます。
自分は昔から設定ファイルベースの pluggable な仕組み自体は多用していたからこそ言いますが、DI が buzzword 化して流行りだすととんでもないことになります。

hibernate 等では RDB のリレーションを解決する方法を hibernate 側の設定として書けることを以て、「依存性を外部で定義する」＝DI の一種と呼ばれているように思います(詳しくは知らないので間違っていたらご指摘ください)。
こういうのは、はっきり言って外部化したことが便利なのではなく、コード中でリレーションを解決するコードを書くと長くなりがちで、最終的なオブジェクトグラフが読み取りにくくなるため、宣言的記法によって解消する、といった可読性面の意義でしかないと考えます。他に、依存性定義を一箇所にかけるなどがりますが、一元化したければ関数(static メソッド)にでもすればいいのです。

もし、ここで「ソースを書き換えなくても依存性の変更が可能」等と言い出してしまうと、buzzword の罠にはまっています。
そんなことができても便利にはならないです。そのかわりに失っているものがあるのだということが世間的に気づかれるのはあと１年くらいかかるかもしれません。

なお、hibernate は私もかなりいいツールだと思っています。使い手の問題なんです。

J2EE が間接参照を多用して、「柔軟性を上げた」と標榜して、概念の複雑化と実装負担(書かなければならないものの種類の増加)で嫌われた流れを踏襲するという予感がひしひしとします。

しかし、「謎概念」ってのがまた問題で、自分だけ知らなくて実は設計上当たり前ということも確かにあって、この業界では、知らないことが罪みたいな空気もなくはないので面倒です。デザインパターンなんてその典型です。しかも、言葉を知っているかどうかだけが重要視されていて、その意味は知らなくても良いかのような空気が:p。

新しい概念を定義し、名前をつけることは重要なのですが、過度に抽象化された定義が流行ると必ず正確な意図は掻き消えて、とんでもない使い方のほうが蔓延するものです。
技術者たるもの、宗教家のように論理的に説明できない用語を乱発するより具体的な定義を提唱することを心がけるべきでは？と思います。ちなみに(少なくとも GoF の)「デザインパターン」はかなり厳密に定義されています。念のため。

ところで、タイトルですが、管理者が buzzword に踊らされると使いたくないものを使わされて大変な思いをするということも一般的にはありがちではあるんですけどね…。私の場合、技術者が buzzword を生み出すことのほうがいやんな感じがするということです。

多数の、言われたことだけやって済ませようとしている作業員のモチベーションを上げること。みんなほんとは仕事も楽しいほうがいいと思っているはず。まれに、仕事だからこそ楽しくなってしまうと没頭してしまうから良くないという人もいるしその気持ちもよく分かるんだけど…その点は置いておいて。

そのためには、プロジェクト環境をよくしようとしている一部の人間のモチベーションを下げないこと。数少ない味方を減らしたら悪循環になり全体が破綻する。
つまりは自分に直接来た下からの正当な意見を政治的な理由と言って却下することを如何に避けるかである。
お客さんの機嫌を損ねると元も子もないが、現場全体の機嫌を損ねても元も子もない(*)、けれど、上司の機嫌を損ねてもプロジェクトは成功しうる、ということ。

*:馬車馬のように使って完成するかもしれないが効率が上がらないのでコストがかかる

上司自身がその意識を持っていればプロジェクトの成功率は格段に向上するが、縦に並んだ全ての人員がそのような意識を持っているケースはほとんどないので、大抵のプロジェクトはどこかで壁が出来上がる。その壁を突き破るのは誰の役割だろう…。

個人的意見では、それは「自分」でしかないと思っている。つまり、どの立場の人間でもいい。突き破る人は、下の意見を吸い上げようとするし、上に何がなんでも意見を伝える(押し通すではなく。もちろんそれが真に妥当性を持つ正当な意見であれば)。そういう人が意見できない環境にしようとする人および空気が続く限り、プロジェクトの破綻は目に見えている。

…なぁんてね。最近の感想として。
更新頻度を下げているので今に始まったことではないですが、現在並行案件が増えまくって今後ますます過去やっていたようなネタを出す頻度は下がりそうです_o_。忙しいので書けませんの報告を兼ねて、ネタを書いてみました^^;。

どうでもいいけど、壁に遠くからでも見える大きさのフォントで用語集とか詳細ではないスケジュールを貼ればいいのに、とよく思う。壁に何も貼ってないのはもったいないなぁ…。
ま、それは環境に拘らない人間だからこその感覚であって、その手のことをやって圧迫感などを感じてモチベーションに悪影響が出る可能性もあるのだとは思いますが。

関連ネタ(過去に書いたもの)
分析とはあらゆる要素を挙げて、整理すること
SE/コンサルタントって何だろう
プロジェクト失敗原因となる典型的症例

檜山正幸さんの新しいプロジェクト(?) chimaira が始まっています。最終的には「Chimairaアーキテクチャは、XML技術の一部に対する再構成の試み」ということで、XML 文書の処理や構造設計手法にインパクトを与える仕組みを定義するものになるようです。現在はまだ導入部であり、Chimaira の「コンポーネント・アーキテクチャ部分」に絞っているとのことで、XML の話ではなくプログラミングに纏わる分析/設計例のような話になっていて(多分これから続くであろう話と比較すると)読みやすかったです。