2010/04/30

問題を解きやすいように変形する

算数で言えば、(37 + 68) を (37 + 70 - 2) のように変形すれば、1の位から10の位への繰り上がりの計算がなくなり、計算が簡単になります。数学では、幾何上の難問を等価な代数的処理に置き換えたり、反対に代数上の難問を等価で直感的な幾何に置き換えたりすることも多いようです。

数学の様に厳密に等価性が維持されるわけではありませんが、ソフトウェアの開発でも、処理し易い形に問題を変形してしまうことは有効な手段です。

例えば、設計の問題は、データ ⇔ ビジネスロジック ⇔ UIの各間で変換可能な場合があります。またxUnitは、テストの一部を実装に変形するツールと考えることができます。あるいは要求仕様書の作成を日本語によるコーディング、プロジェクトマネジメントをプロジェクトの設計・実装・テストと捕らえることで、解決しやすくなる問題もあるでしょう。

正攻法では難しい問題に遭遇した場合は、難しい部分を解き易い形に変形/変換することができないか、考えみてるよいでしょう。

2010/04/28

人に教えるつもりで学ぶ

学習の方法論の1つに「人に教えるつもりで学ぶ」というのがあります。

「今日勉強していることを、明日誰かに説明する」ことになっていると想定します。判らないところを曖昧なままにしなくなります。人に伝えるには自分で順序立てて説明しなくてはいけないので、全体的な構造を意識しやすくなります。自分が難しいと感じたことについて、どうやって説明しようかと、図を描いてみたり、例や喩えを考えたりすることも、記憶の定着と理解の深化に役立ちます。

さらに本当に人に教える機会が得られればラッキーです。復習になる上に、思わぬ質問や指摘から新たな理解が得られることも多いです。

このブログで偉そうなことを書いている所以です。

2010/04/26

秀丸grepで良く使うワイルドカードを登録する方法

秀丸でディタの grep検索でよく使用するワイルドカードの組み合わせを秀丸に登録しておく方法を紹介します。
プロジェクトの作業で、テキストエディタ(秀丸)のgrep検索をよく使用します。
ただ、検索対象ファイルの種類はよく変わるのが難点です。
  • C++のソースコード(*.h;*.cpp;*.c)
  • VBのソースコード(*.bas;*.frm;*.cls)
  • 障害ログファイル(*.csv;*.log)
  • HTML関連ファイル(*.htm*;*.js;*.css)
  • 設定ファイル(*.ini;*.msg;*.csv)
  • etc...
ファイル数が少なければ *.* で問題ありません。しかし、広範囲をgrepする場合や、Subversionを使用していて「.SVN」フォルダがある場合などは、少し手間取ります。検索に時間がかかったり、検索対象にしたくないものも検索結果に引っかかったりしてしまうからです。かと言って、都度、ワイルドカードを手入力するのも面倒です。
対象ファイルの絞り込みが簡単にできると便利ですね。

(1)設定の追加/編集/削除
「その他」->「動作環境」で「動作環境」ダイアログを表示。
左のツリーから「ファイル」を選択。
「ファイルの種類の編集」ボタンをクリックして「ファイルの種類の編集」ダイアログを表示。
「「開く」のダイアログ」タブを選択。
ファイルを指定するワイルドカードの組み合わせを追加、編集できます。

(2)grep検索で登録済みの設定を使用する
grep検索実行時に、「検索するファイル」ボックスの右横にある三角印ボタンを押下すると、上で設定したワイルドカードを選択できます。

2010/04/25

解体の誤謬

本日4/25(日)の毎日新聞の朝刊コラム
時代の風:解体の誤謬を考える=同志社大教授・浜矩子

「解体の誤謬」とは逆転の発想的で、良いネーミングですね。

  • 合成の誤謬:解体の誤謬 = 部分最適:全体最適 = ミーイズム:ファシズム

ということでしょうかね。

ところで、何が部分で何が全体であるのかは自明ではありません。よね。何を全体とするのかは、恣意的に決められます。物事を分類する方法はいろいろで、これも恣意的に決められます。
個人、家族、友人、地域コミュニティ、会社、日本、アジア、世界、人類、哺乳類、地球生命、この宇宙全体(ユニバース)、平行宇宙も含めた宇宙(マルチバース)。
何を全体とし、何を部分としますか?結局それはTPOと価値判断に依存するだけです。

合成の誤謬、部分最適、全体最適、個人主義、全体主義、ミーイズム、ファシズム、etc... あるいは「もっと***全体のことを考えろ!」等。
出くわしたときは、話者の価値観と意図に注意しましょう。

2010/04/23

仲間によるレビュー

皆さんは、成果物のレビューをしてもらっていますでしょうか。正式なレビューでなくても、ちょっと誰かにコードを見てもらうだけでも、レビューには大きな効果があります。

動作が変なものに関してはテストで発見できます。しかし、無駄な処理や過度に複雑な処理は、テストでは発見できません。また仕様書や設計書の場合は、普通は動かないので、テストすることもできません。なにより、誰にも見てもらっていない成果物を、いきなりお客様に納品することからくる不安から解放されます。

1人のプロジェクトでレビューができないという場合は、別のプロジェクトの方に相互レビューを提案してみるのも良いかと思います。もちろん守秘義務に反しない範囲でですが。

開発に追われて時間がない場合は、無理に時間を作ってでもレビューをした方が良いというサインです。慌てて開発すればするほど、欠陥がたくさん埋め込まれていきます。結局それがテスト時やリリース後でのやり直し作業となって、もっと忙しくなってしまいます。ほとんどの場合、品質が最優先事項と考えて間違いありません。

お客様ではなく、プロジェクトの仲間に欠陥を見つけてもらいましょう。リリース前に欠陥が見つかることは、喜ばしいことです。

2010/04/21

Webデザインの『プロだから考えること』

「Webデザインの『プロだから考えること』」インプレスジャパン

「デザインをする時に何を考えているか?」について、トップWebデザイナー達がそれぞれ語っています。表紙カバーが「ど」ピンクだったこともあり、最初はかなり警戒していました。しかし読み始めてみると、ソフトウェア開発にそのまま当てはまることが多く、抵抗なく読むことができました。考えてみると最近のWebサイトはインタラクション性も高いです、ソフトウェア開発と考え方が共通する部分が多いのも頷けます。

ざっと全デザイナーの考えを無理矢理に要約・列挙すると、以下のような感じになります。
(1)顧客について
(2)デザインについて
(3)プロジェクト管理について
(4)自己研鑽について

(1)顧客について
・顧客とのコミュニケーションが大切
・要求について最も詳しいのは顧客
・顧客の直接の担当者だけでなく、現場の声も重要
・顧客の担当者がコミットしていなければ良いものができない
・クライアントと一緒に作り上げる

(2)デザインについて
・利用者の立場に立って考える
・(開発者でない)一般の方に使ってみてもらう
・最先端や流行の技術 ≠ 最適なソリューション
・コンセプトを伝えるのにストーリーを利用する
・アイデアと実現可能性のバランスをとる

(3)プロジェクト管理について
・顧客レビューを繰り返しながら洗練させていく
・自分が経験したことのない作業は他人には上手く依頼できない
⇒信頼して任せてしまうか、自分でやるかのどちらか
・チームメンバーの個性をかけ合わせる

(4)自己研鑽について
・新しい技術に積極的に触れておく
・専門分野だけでなく、幅広く情報収集し視野を広げておく

なんかもう、ITエンジニアの日常の世界ですね。

2010/04/19

ITエンジニアにとっての教養

教養主義の没落が叫ばれて久しいですが、この数年来、再度「教養」がスポットライトを浴びています。実用性無視の人格陶冶、あるいは受験エリートの自己正当化の手段としての教養主義ではなくフラットな21世紀を生きるうえでの基礎体力としての教養が求められているのでしょう。

しかし、教養の定義は曖昧です。人間性や行動の品格までをもその射程に置く言葉です。ここでは、道徳面には踏み込まずに、ITエンジニアにとっての実利という観点で、教養とは何かについて、考えてみました。

(1)ストックとしての教養

(a)深い知識
(b)広い知識

(2)フローとしての教養

(a)継続学習への意欲
(b)新たな知識を生み出す力

(1)ストックとしての教養

(a)深い知識
  • 自らの専門分野について体系立った深い知識を有していること
  • ドイツの影響を受けた旧帝大系の教養。
  • ITエンジニアにとっては、ITやプロジェクト管理の知識
(b)広い知識
  • 専門分野に関係なく、科学・文学・音楽等の幅広い知識
  • 所謂リベラルアーツ、アメリカ的教養、旧制高校的教養

(2)フローとしての教養

(a)継続学習への意欲
  • 学び続ける力。
  • 知的好奇心、無知の知、好きこそものの上手なれ
  • この宇宙の全知識をストックすることはできない
  • その時々で必要な知識を学び続ける必要がある
(b)新たな知識を生み出す力
  • 特定の問題を解決するために知識を現実世界に適用する
  • 知識を深める新たな発見をする
  • 既存知識体系の溝や矛盾を乗り越えるパラダイムを考案する
  • 複数分野の知識をマッシュアップして、新しい応用を行っていく
  • 暗黙知を形式知に転換する
  • ITエンジニアで言えば、
    • プロジェクトの問題を分析して改善策を考える
    • プロセスをカスタマイズして適用する。
    • 成功・失敗事例をポイントを捕らえてドキュメント化する
    • 顧客の要求を実現するための技術の組み合わせを提案する
    • etc...

まとめ

ストックとしての知識がなければ、新しい知識を生み出すことは非常に困難です。さらに知識はどんどん陳腐化していくので、常に学び続ける必要があります。教養人目指して頑張ります。

参考図書
 「グロテスクな教養」高田里惠子(ちくま新書)
 「大人のための『学問のススメ』」工藤庸子、岩永 雅也(講談社現代新書)
 「教養主義の没落―変わりゆくエリート学生文化」竹内洋(中公新書)

2010/04/12

法学とITエンジニア

私は、法学部出身のITエンジニアです。時々、法律と直接関係のないエンジニア職についたことに疑問をもたれることがあります。エンジニア職についたこととは直接関係ありませんが、仕事の進め方や考え方は、かなり似ている部分があります。抽象化してしまえばほとんどの知識労働に当てはまりそうですが、両者とも問題解決のプロフェッショナルであることに違いはありません。
  1. 解決対象の問題を特定する
  2. モデルを適用または創造して問題を解決する
1. 解決対象の問題を特定する
全ての問題が、法律やITで解決するわけではありません。顧客の要求は、曖昧で漠然としており、時として間違ってもいます。また、現実世界はあまりも複雑です。銀の弾丸はありません。法律やITで解決すべき問題とそうでない問題とを切り分けて、解決対象の問題を特定します。

2. モデルを適用また創造して問題を解決する
法律や判例はモデルです。社会で起こるすべてのことを事細かに規定することはできません。さらに社会は常に変化しているので、事細かに決めすぎると変化に対応できなくなります。そのため、抽象的な記述(=モデル)が必要です。法解釈学は、モデルの適用方法を考える学問であり立法学は、モデルの創造方法を考える学問と言えます。

IT分野においてのモデル適用は、皆さんご存知の通りです。GoFのデザインパターンにはじまり、アーキテクチャパターンなども提唱されています。私を含めて多くのITエンジニアが、統一モデリング言語(UML)を使ってモデル化とモデルの適用を実践しています。

いろいろなモデルのメリット/デメリット、対象のケースに適応する場合の個別具体的な課題などを考慮して、限られた時間とコストの中で実現可能な解決策を実施していくことになります。

2010/04/11

しゃべって歩くお父さん人形

年度末に2Gだった子回線の携帯を3Gに変更しました。
で、「しゃべって歩くお父さん人形」が先日届きました。
しばらく忙しくて放っておいたのを漸く開封しました。

で、みんなが気になる(?)お父さんの足の裏です
ちゃんと肉球までデザインされいました。
で、これを私にどうしろというのだ、ソフトバンク。

2010/04/10

論理とひらめきと直感の雪だるま

 なぜなぜと考える、その考え方にもいろいろあるかと思います。
  • 論理的に考える 
  • 寝て起きたらひらめいた 
  • よくわからないが直感的に違和感を感じたので調べ直す
 論理的に考えることについては、昔からよく言われていることです。なので、今回はひらめきと直感の勝手定義から、雪だるまについて考えていみます。

≪ひらめき≫
  • ひらめいた後は、内容を論理的に説明できる 
  • 論理的に考えた経験が多いほどひらめき易くなる 
  • 脳科学的には、意識と無意識とのフィードバックループから生まれる 
  • 無意識をうまく活用することも大切 
  • たとえば、1日中論理的に考え詰めた後に、帰宅・入浴してリラックスすると、ふと設計解がひらめく 
≪直感≫
  • 答えだけが何となくわかるが、その理由はわからない 
  • 身体動作を伴う経験が多いほど直感が働き易くなる 
  • 脳科学的には、無意識と身体とのフィードバックループから生まれる 
  • 反復訓練が大切 
  • たとえば、GUIのテスト中にテストケースとは全く関係のない(ように見える)処理が気になって動かしてみたら、都合よくバグを発見する 
次に、ひらめきや直感が普段どのように働いているのかを、考えてみます。
日々の業務において、全ての可能性を意識して論理的に考えていたのでは、わずかな時間でへとへとに疲れ果ててしまいます。というか、可能性は(ほぼ)無限大なので、実際上は不可能です。そこで多くの場合、考えるきっかけを与えてくれるのが、直感です。「あれっ、何だか変だな?」と思えれば、どこに違和感を感じたかを考え始めることができます。そこで、「どこがどう変なのか?」について、小さなひらめきがいくつか浮かんでくれば、ゴールは(大抵)近いです(よね)。
もちろん、論理が重要でない、ということはでありません。常日頃から論理的に考えることをしないと、ひらめきは、訪れてくれないし、育ちもしません。日々の訓練を怠ると、直感は何も教えてくれなくなります。

そろそろ、まとめます。
思考の多くは、「直感 ⇒ ひらめき ⇒ 論理」の連鎖です。たくさん考えることでひらめきが、たくさん経験することで直感が、鍛えられます。ひらめきや直感が優れていれば、(意識的には)より少なく考えるだけで済み、他のことを考えたり経験したりできる余裕ができます。そうすると、よりたくさん考えてたくさん経験できるので、さらにひらめきや直感が鍛えられて....と、雪だるま式の自己増殖回路になっていくと思います。

2010/04/09

書く力 v.s. 読む力

ビジネス文書や技術文書というと
書く方に注意が行きがちです。
また、近年の他責NGの流れからか、
書き手と読み手とでは、
書き手の方が批判されがちです。

コミュニケーション能力向上の観点からは
片手落ちではないでしょうか?

1.使用頻度 ⇒ 書く力 < 読む力

平均的なITエンジニアにとっては
何かものを書くより読む方が、
時間が長く、量も多いのではないでしょうか。

新聞、雑誌、書籍、ブログ、メルマガ、Twitter
メール、議事録、仕様書、設計書、ソースコード、
試験仕様書、障害報告、ユーザーマニュアル、etc.

本当にたくさんのものを読んでいますね。


2.責任 ⇒ 50:50

コミュニケーションにおいては、
発信者と受信者は対等です。
結果責任も、対等に50%ずつです。

仕様書に記述がおかしいと思えば、
そのまま作らずに確認するのが普通でしょう。


3.読む力は書く力の基礎


読めないものは書けません。
読む力が上がれば、書く力も上がります。

ビジネス書の内容をざっくりと知りたいときは、
次のような読み方をします。
・目次を眺めて章のタイトルから内容と構成を知る
・前書をざっと読んで、著者の意図や目的を知る
・全体をパラパラめくりながら気になった箇所をちょっと読む
これがやり辛い本は、構成が悪いです。

これは、ソースコードを読むときも同じです。
ということは、書くときも同じですよね。 
この読み方を知っていれば、
・関数(メソッド)の呼び出しを、本の目次の様にする
・クラスのヘッダコメントに、意図や目的(責務)を書く
ように意識が働き易くなります。

また長大で複雑な大河物語を熟読するときは
登場人物の相関図を書いたり、
出来事を時系列で整理したりします。
巨大なソースコードを読むときに
分かりやすいクラス図やシーケンス図などがあると
よく理解できるのと一緒ですね。

2010/04/08

バイト配列 から長さを指定してstringを切り出す

バイト配列 から長さを指定してstringを切り出す

    std::string str;
    char* byteData = new char[MAX_SIZE];
         :
    (バッファにデータを追加)
         :
    int bufSize = getDataSize(); // 切り出す文字列の長さを取得する
    str.assign(byteData, bufSize);



バイト配列など'\0'で終端しないデータを
長さを指定してstd::string に 切り出す場合など。

set の要素を、vector の末尾に追加する

set の要素を、vector の末尾に追加するSnipet

    std::set inList;
    std::vector outVector;
         :
    (それぞれに要素を追加)
         :
    std::copy(
     inList.begin(),
     inList.end(),
     std::back_inserter(outVector)); 


コンテナの変換、
複数のsetを1つのvectorに纏めたい場合(?)など。

2010/04/07

'Do Things Right' & 'Do Right Things'

故ピーター・ドラッカー氏は、人々が成果を上げられる存在になるためにはどうすればよいのか? ということを考え続けられました。それはつまり、物事を正しく行うこと(Do Things Right)と正しい物事を行うこと(Do Right Things)の両方をどうやって実践するのかということを追求することでした。
Do Things Right とは、プロジェクトを納期通りに所定のコストで終わらせることを指します。しかし、納品したソフトウェアが顧客に価値をもたらさなかったとすれば、Do Right Things にはなりません。プロジェクトの参加者はどうすれば顧客に貢献できるのか、常に考えて行動する必要があります。

「ネクスト・ソサエティ」P.F.ドラッカー(ダイヤモンド社)

2010/04/05

開発コスト削減 と顧客利益

 「コストを削減する」ことと「顧客の不利益のもと自分たちが楽をする」こととは異なります。当たり前のことのようにも思えますが、日常の業務に追われていると、ついつい陥りがちな落とし穴ではないでしょうか。

 例えば「***画面の@@@処理は、やっぱり+++に変えて欲しい」というような要望は、納期が近づけば近づくほど「やめてくれ~」と言いたくなるのが、人情ってものでしょう。とはいえ、迅速かつ柔軟に対応できる能力が高ければ高いほど、要望を受け入れられる可能性も高くなります。また、仕様決定や設計の段階で顧客の望みを十分に引き出すことが出来きているほど、納期間際に仕様変更が発生する確率も下がります。
もちろん、顧客の言いなりになることが、必ずしも顧客満足度を向上させることとは思っていません。コスト超過が続けば継続的にサービスや製品を提供し続けることも出来なくなくなり、結果として顧客に不利益を与えることにもなりかねません。こちらからの提案等も含めて、費用対効果の高めることが求められていると思います。それに応えるためには、
  • なぜ、この要求が生まれたのか?
  • なぜ、この仕様とするのか?
  • なぜ、このプロセスで開発するのか?
  • なぜ、このプログラムを書くのか?
  • なぜ、このテストを行うのか?
  • なぜ、このタイミングでリリースが必要なのか?
  • なぜ、このツールを使うのか?
  • なぜ、etc...

のように様々な「なぜ」を考えて日々の仕事を見つめ直すことが必要だと思います。

2010/04/03

The Fun Theory Award Winner

先月末に、The Fun Theory Award Winner が発表されていました。

ドライバーにどうやって楽しくスピード制限を守らせるか?


原資をスピード違反の罰金とするところが良いですね。


TheFunTheory.com
We believe that the easiest way to change people's behaviour for the better is by making it fun to do. We call it The fun theory.

淀川河川公園にピクニック

今回のピクニックは淀川河川公園(枚方地区)
混雑の予想される桜を避けて、
のんびりと行ってみました(See All Photos)。


道なりに歩いていくと、怪しげな建造物が出現。


地下で淀川と繋がっていて、
水位を観測しているらしい。へぇ~。

裏側には目盛りがありました。
「危険」どころが「注意」でも
ここにいたら溺れてますね。


最後は、やっぱり桜です。
但し、淀川ではなくて天の川です。


枚方市役所のHPによれば、
平安時代、天野川流域の枚方市・交野市一帯は「交野ヶ原」と呼ばれ、桜の名所として、また貴族の狩り場として知られていた。当時の貴族は、天野川の川砂が白く光って見えることから、この地を天上の天の川になぞらえ、多くの歌が詠まれた。
そうです 。