以前からSourceForge.JPさんで、ドキュメント執筆者とテスト担当者を募集しているのですが、残念ながら良い人が来なくて、自己顕示欲の強いというか思い込みの激しい人が来て手間ばかりかかって結局ご遠慮頂きましたということでそのレポートを。
こんなことはわざわざ書かなくてもよいかとも思いますが、こちらもドキュメントを書いて欲しいため、チャットまでして説明した手間もありせっかくなのでネタにしたいというのもありますし、また変な人がこられても困るのでその予防線と、一応開発日誌と銘打っているブログなのでこういうマイナスなことも隠さずに書くのも面白いかと思ったので書いてみます。
その方（以下Aさんとします）は、某大手のIT企業に勤めているらしいのですが（わざわざご自身で大手IT企業と言ってしまうところはどうかと思ったのですが）、ご自身でもプログラミング言語を作成しているとのことで互いに勉強にもなるかとも思いました。
何回かメールでのやり取りで、簡単な自己紹介、技術概要、開発方針、ドキュメント作成のポイント等を説明し、チャットでさらに補足説明をしました。
で、ドキュメント作成を行わなければならないのですが、Aさんは片手間にしか参加できないとのことで、レビューをやってもらおうとその旨をお伝えしたところ、Aさんから
『後、気になっているのは(もしもですが)参加者がたくさん増えたときに大藤さんの心構えが実はできているか？です。』
とのコメントを頂きました。私はオープンソースに対する心構ができていないとのことなのですが、そもそも『心構え』ということが理解できなくて、真意を確かめることも含めてまずは今回はご遠慮いただく旨のメールを送りました。そうすると、
『確かにメール受け取りました。想定通りの回答です。』
で始まり、
『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』
と来て、
『話をしていて、大藤さんはまだノーの様な気はしていたんです。』
『色々な人の意見を採り入れたいと言っていたが、まだその時期ではないのではと。』
と結論付けておられました。どう突っ込んだらよいのか困ったのですが、まぁ今回はご遠慮いただいてよかったかと思いました。
Aさんの勘違いを指摘しますと、私はADPをGPLで配布していますが、これは利用者が好き勝手にできることを私が認めたことになります。つまり、
『他の人に触らせること』
については私もライセンス上認めております。AさんはGPLをご存知ないのでしょうか。
また、『色々言われること』についてですが、実際にSkypeでAさんとチャットしているときも『Prologが解らない人向けのドキュメント作りを』と指摘されそりゃもっともだと思ったでのでSourceForgeのチケットにも登録しました。
もちろんですが、人の意見を聞きたいといっても、必然的に他の方の意見を取り入れる面と取り入れない面があります。その取捨選択はアーキテクトである私の仕事だと思っています。
もっともADPはプログラミングの初心者を対象としています。ので初心者の方の意見というは極力尊重したいです。ちなみにですが、PHPのようなお手軽な言語を目指しています。のでご意見どしどし受け付けています。
自分自身の若かりしころの反省も含めてITエンジニアの方にコメントしますと、他人とのコミュニケーションをとる上で相手の内面についての不用意な否定はやめた方がよろしいかと思います。Aさんは私に心構えという単語を使いましたが、根本的にオープンソースのプロジェクトをやろう！、という人間が心構えができていないことは、ほぼないです。
本当に心構えができていなくかつ教育が必要な新人を除いて、このような単語を使うことは相手を怒らせるくらいしかできません。もしくは相手から『こいつはコミュニケーション能力がない』と思われるでしょう。
これは仕事の面でもいえるかと思います。大手のIT企業に勤めていたら、出来の悪い協力会社の担当者に向かって思わず『やる気があるのか？』等、同様のことを言ってしまうこともあるかもしれませんが、そう思ったときはじっとこらえて『なぜ、私はこの人がやる気がないと感じたのか？』とじっくり自問自答しましょう。そのときに根拠となる理由が1つでは足りないですし、またその理由が思い込みではないと、確認する必要があります。
『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』
『話をしていて、大藤さんはまだノーの様な気はしていたんです。』
私の話のどこにそう思ったのか不明ですが、私がソースをオープンにし、GPLでリリースした時点で、ノーということはありえません。このように多角的な検証が必要です。
相手を批判する場合（相手の内面の場合は特に）、思い込みで論理を展開しないで自分の考えを吟味する必要があります。さらに、相手の置かれている立場や考え方も考慮に入れましょう。
私も若かりしころ上司から、『口のきき方が悪い』と怒られたりしたことがありましたが、そのときは何で怒られたかよく解っていませんでしたが、おそらくAさんのように思い込みが激しかったのかもしれません。
最近では、あまりこういう面で他人から指摘を受けることもなくなっていましたが、今度は自分が指摘をする番になったようです。
OpenBlocks600の記事で紹介しましたブログビューアーですが、その後、バグ修正やRSS関係の対応をしてから1週間経ち、apacheのエラーログにもエラーが出ていないので、そろそろリリースしようかなと思いソースを眺めていたのですが、あまり教示的なソースでなく『公開すべきか、せざるべきか・・・』と悩んでおったのですが、こういうときは他人はどうしているのかと、最近のWEBアプリの動向でも探ろうかとネットを検索しましたところ、面白い記事を見つけました。
http://satoshi.blogs.com/life/2009/10/rails_mvc.html Ruby on Railsの「えせMVC」の弊害
http://satoshi.blogs.com/life/2009/10/ormappingmvc.html O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
ブログ主（Satoshi Nakajimaさん）の主張ですが、要するにモデルとコントローラの役割はきちんと分けようねということで、『ビジネスロジックをコントローラに書くのはNG』とのことのようです。
ちなみに私ですが、ちょい書きのアプリだとまぁコントローラでビジネスロジックどころか、SQLを書いたりします。またブログビューアーの構造も思いっきりMVCモデルから逸脱しているので・・・という訳でブログビューアーを書き直そうかなとか思ったのですが、もう少し調べてみようということで、以下、Rubyの作者のまつもとさんの記事を見つけました。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080610/307218/ まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails
この記事の
7ページ目の表2にRailsのMVCということで従来のMVCとの比較がありますが、その表から2パラグラフ目の説明を引用しますと
一方，HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは，相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし，モデルとビューのインタラクションも不要です。ですから，モデルをデータベース層とビジネス・ロジック層に分割して，下層をモデル，上層をコントローラと呼ぶようにしたのでしょう。
ということで、まつもとさんの説によるとビジネス・ロジック層はコントローラに記述することになるようです。
かの有名なRubyの作者のまつもとさんが、このように言っておられるのでこの勝負は『Railsでは、ビジネス・ロジック層はコントローラに記述する』で軍配が上がりそうですが、実は先のブログ主さん（Satoshi Nakajimaさん）も知る日とぞ知る方で、過去にマイクロソフト社に勤務されておりWindows95の開発では、Windows3.1との互換性を保つために尽力されたらしく、そのあたりの話は
こちらで参照できます。また先の主張は、実際に
Ruby on Railsを使ったプロジェクト通して行き着いたようでしてそれなりに説得力があります。
このように著名なエンジニアの見解が異なる場合、どのように解釈すればよいのか悩ましいところですが、実行速度についてとか明確に白黒つく場合のように客観的に測定できる事実が無い場合、
『どちらでも良い』
というのが私の経験から来る見解になります。
この手の議論はエンジニアを引き付けるものがあり、熱くなったりするのですが、議論してもみのりは少なかったりします。
私も過去にこの手の議論に巻き込まれたことがあるのですが、特に個々のエンジニアが持つバックグランドが異なる場合、あまり前向きな議論にならなかったです。
今はインターネットがあるので様々なエンジニアの見解を比較することができるので、このように『他の人はどう考えているか？』というのをわざわざ議論しなくても解るので改めていい時代になったと思います。
というわけで、まぁブログビューアーは作り直さずに公開したいと思います。
チョット野暮用が入りADPの開発（というかブログの更新が）滞ってます。自慢にもなっていない記事をそのままにしておくのも何なので、ちょっとしたネタをアップします。
他人が作ったソフトウェアにバグがあったり仕様変更で改修したりする場合、新規で作り直すか、改修するかが議論になったりすることがあります。
良く聞く意見に
『バグバグでソースも汚いので新規で作り直しましょう』
というのがありますが、この『ソースが汚い』という意見ですが、往々にして主観が入っていることがあります。つまり、
その人のコーディングスタイルに合っていない→ソースが汚い
ということを言っている場合があり、この意見を鵜呑みにして新規開発の道に行くのは危険だったりします。
良くあるミスが、既存のコードに入っていたノウハウ（エラー処理や例外的な処理など）が新規開発で消えてしまい、却ってバグバグになったり、実際にはそう見栄えも良くなっておらず結局、工数だけかけたということになったりします。
新規なのか改修なのかというのはケースバイケースの面があり、あまり一般論では語りにくいのですが、私の場合、以下のルールで新規開発を行います。
- 既存のコードがある場合、基本は改修で行います。
バグがあるからとかソースが汚いという理由で新規開発を行いたくなりますが、その程度では新規開発はしません。
- 改修に工数が掛る場合、仕様を完全に把握できかつコーディングテクニック上ではなくパラダイムだったりアルゴリズムが元のコードよりも有効なものが使える場合、先ずは関数レベルから置き換える。
オブジェクト指向を使っていないコードにオブジェクト指向を行ってみるとか、サーチアルゴリズムを別のものに入れ替えるとか、if文の条件が複雑だか良く見ると簡単にできる場合に簡単にするとか、コピーペーストしているコードで共通部分を関数にするとかです。
- 出来ることならテストプログラムを書き、デグレードを防ぐ。
- 徐々に改修するコードを広げてゆく。
とまぁこんな感じでやってます。
ちなみに、自分が過去に作ったコードは結構大胆に書き換えたりします。自分が作成したものの場合、1回目より2回目の方がソースが綺麗に書けるということと、『仕様を完全に把握している』という条件をクリアしやすい為です。
先週は、嫌なお客の話をしたので、今週は、もう一度ご一緒に仕事をしてみたいお客様の話をします。
そのお客さんは、とあるCEサイトを業者に作ってもらったのですが、残念ながらバグバグのシステムで大変不満を持たれていました。おりしも不況と重なって会社もリストラを始めたり、元々の担当者が止めたりで、新しく担当になった方は、業務は解るが、IT（WEBサイト）のことはよく知らないといった感じの人でした。色々不満もあったかと思いますが、そういったことは表に出さないで真面目にプロジェクトに取り組まれていました。
もっともITのことはあまり詳しくなかったので私が業者との交渉（バグの伝え方から、改修予算の値引き交渉やら、相手から来たメールの意図を翻訳したり）のサポートを行っていたました。
ただ、ECサイトによくあることですが、いかんせん売上が上がりませんでした。そういう中で次期開発の話が出てきたのですが、当然やりたいことにお金（予算、売り上げ）がついてこないので、そのギャップに担当者の方が悩んでいまして、ミーティングで愚痴を言われていました。そこで、思わず私が、
「今までの経験上、上手く行かないやり方を続けていてはダメになるばかりでっせ」
と言いました。
つまり、売上を上げていないのなら、無理に開発を進めるのではなく現行のシステムは修正にとどめたり、儲からないサービスやめたりするのも手ですよというある意味当然のことを言ったのですが、ただ、多くの日本人は『止める』という発想がなかなかできないようで、私も過去にこのようなことを言ってプロジェクトから外されたこともありました（本音を言ってくれてありがとうという人もいました）。
今回もこれは言い過ぎかなとも思ったのですが、この一言が担当者を救ったらしく、サービスメニューの構成を変えるように話しが進みました。以前なら『生意気なことを言うな』と言われるところだったのですが、平成不況も長くなると営業の現場の人もプライドを捨てて話をされるようになったようです。
その後、残念なことにやはり改修の規模が大きくなり、コストがかさむと同時にリストラが進み担当者もご勇退されプロジェクト自体が空中分解して、結局はそのECサイトはまったく改善をされずに閉鎖になりました。
私自身は営業的に失敗したプロジェクトをいくつも経験しているし僭越ながら自社のシステムを含めて成功しているプロジェクトも経験しているのですが、そのプロジェクトが終了したことは残念でした。もちろん予算がないプロジェクトだったので私自身もアドバイザーという形で週に1回しか打ち合わせに参加していなかったので、私のかかわり方として不完全燃焼な面もありました。
次回、その顧客と仕事をする機会があればぜひもっと良い結果を出せるように頑張りたいと思いました。
不況が長く続きますが、こういう難局を乗り越えるのもソフトウェアエンジニアというよりビジネスパーソンとして真価を問われていることだと思います。頑張りたいものです。
私は今でも顧客の元で仕事をしたりするので、この手の話題は避けたい面もあるのですが、たまには、ADP以外の記事を書いてみます。
私はかれこれ20年近くITエンジニアとして働いていますが、今ちまたで問題になっている以下の話題ですが、IT業界では昔からありました。
・鬱
・派遣切り
・モンスターカスタマー（パワハラ）
鬱は、昔からテクノストレスという言葉があり、私も十数年前にストレスに悩まされたことがありました。
今では結構気軽に鬱という言葉が使われますが、昔はそういった認識もあまりなく、ただひたすらいらいらする毎日でした。。。そういえばストレスチェッカーなるサイトをよくみていました。
派遣切りも昔からありました。もともとIT業界自体がはやくから派遣が可能だったというのもありますし、ソフトウェア開発プロジェクトは労働集約型になる為、プロジェクトが佳境に入ると人を集め、プロジェクトが終了すると人も減らすということが行われていので小規模ながら派遣切り（というかお役御免）ということが行われてきました。
モンスターカスタマーというかパワハラも昔からありました。私が受けたもので一番印象に残っているものですが、もう15年程前の話になりますが、風邪で休んでいるところを、無理やり出社させられて、
出社すると顧客の担当者は満足そうに笑みを浮かべており、
私がそのまま、イスに座ってボーといたら（風邪をひいているのでとうぜんなのですが）
『ぼさっとしないで、ちゃんと仕事をしろ！』
とお客の担当者に怒られ、そのままありがたい講釈を聞いたことです。
別にトラブルがあった訳でも、カットオーバー等のイベントがあったわけでもなかったので、今でもなんでこのようなことをされたのか理解に苦しみますが、まぁご自身の力を誇示したかったようです。
それ以降、幸いにして今現在に至るまで皆様良いお客様で感謝しております。
あと、35歳定年説というのもありました。35歳を過ぎるとITエンジニアとして価値がなくなるという都市伝説ですが、今これを転職市場に置きかえますと確かに35歳を超えると転職も難しと聞きます。
ということは現在ITエンジニアがおかれている労働環境は、20年後の日本の労働環境を占うことになるかと思いますが、ITエンジニアの皆様の労働環境は明るいでしょうか？、暗いでしょうか？