プログラマー飲み会

お世話になった協力会社のメンバーを送別する飲み会に参加してきた。飲み会の会場は京急蒲田の商店街の真ん中にあり、３００円均一の料理、発泡酒の生ビール、不自由そうにメニューを繰り返す中国系スタッフと、デフレな世の中をまざまざと感じるお店でした。

さて、今回送別した方は私が尊敬するプログラマです。ズバ抜けてコーディング技術が高く、さらにJavaの知識も深く広い。彼の書いたコードはとてもシンプルで分かりやすく無駄がない。インテリジェンスとモノ作りに対する愛情がコードからにじみ出ている。

宴もたけなわになり、そのスーパープログラマが飲み会の最後にスピーチし始めたのだが、酔いも手伝って内容が非常に熱かった。

「ソフトウェアエンジニアとは労働者ではなくアーティストだ」

「製品を作っているのではなく、作品を作っている気持ちが必要だ」

飲み会の席でこんな言葉を語れるプログラマに出会えることは非常に稀な経験だ。

日本のソフトウェア産業はクラウドという時代を迎え、大きく変わりつつある。企業は自前で「作る」ことをせずに、世界中で使われている優れたサービスを「使う」時代となった。そんなクラウドの時代では、Google, Microsoft, IBMのトップベンダー、そして世界中の新興企業との競争相手となり、より「使われる」サービスを提供した企業が勝ち残る。 このまま今の日本のITゼネコンベンダーが、旧態依然と過ごしていけば間違いなくビジネスを縮小させていくだろう。

まさに今までの日本のソフトウェア業界は江戸末期。多重請負構造という封建制度。日本語の壁という鎖国制度。

今後は日本古来の請負ビジネスが縮小し、中小ソフトハウスの倒産が発生する。出来ないプログラマは自然淘汰されていく。（ましてやプログラムを読めないシステムエンジニアっていう部類は真っ先に淘汰されると思う。）「使われる作品」を提供できるエンジニアでなければ、この世界は生き残れない時代になってしまった。

「作品」を提供できるプログラマーはあの飲み会の中で何人くらい出てくるのだろうか？

我々は良い「作品」を作らないと、１０年たって発泡酒も飲めなくなってるかもしれない。

人に上下なし。工程にも上下なし。

「超上流」という言葉が一昔前流行していた。多分データさんが普及させている考えだと思われる。設計作業等を「上流」と呼ぶ傾向があり、さも「製造工程」（プログラミング）が「下流」であるかのような言い方である。この「上流」、「下流」の言い回しが日本のソフトウェア業界をダメにしている。

ある社内会議に参加していた時に、開発品質について議論となった。その社内会議では、様々な製品を担当するプロジェクトリーダー級の担当者が品質状況を報告し、重要な情報はその場で横展開するという場となっている。

最近は上級幹部も参加しており、あたかも、公開処刑の場のように幹部は担当者に指摘を浴びせる。公開処刑のやり方変わってきて、最近の主流はトヨタ流のなぜなぜ分析だ。「コーディング誤り」、「設計考慮漏れ」等に障害を分類し、どの「工程」で失敗かを議論するやり方。

ただ、この分析であまりにも「ソースコード」が見えてこない。プロセス改善はいいことだが、本当に本質的な改善なのか疑問に感じる。コードが一度も資料として出てこないのに、設計書の書き方や、レビューチェックシートを追加するとか、訳の分からない議論をして満足している。調理をあまりしないコック長が、食材そっちのけで、レシピの書き方を改善してても、そんなレストランにお客さんを来ないと思うのだが。

これはまさに「上流」であるプロジェクトリーダが「下流」のソースコードを理解できないまま、プロジェクトが運営されていることの象徴であると考えるわけで。日本のソフトウェアがダメになっているのはまさにこういう文化だと思う。つーか「上流」、「下流」っていう、この言葉自体をなくさないといけない。

誰がコーディングに工程を持ち込んだ？

　本当に使い勝手の良い製品には、説明はいらないはずである。つまり、マニュアルなんて必要なく使えるものがユーザビリティが高い製品と言える。カタログも必要ない。使って見れば勝手に流行る。それは、とても魅力のある製品であり、そこに説明が必要ないから。

　本当に作りやすい構造には、設計書なぞいらない。それ自体の構造が最適化されているため、改修もしやすく、構造自体が作り手にさらなる創造を与えるから。

　本当に美しいコードには、他に何も必要としない。それ自体が全てを語る。

　コードを書くとは、知性、感性、創造の活動と考える。本当のプログラマーのコーディングとは、設計、製造、テストという工程というものは存在しない。ただ感じ、考え、書いて、確かめるという、単純な創作活動だ。誰がコーディングに工程を持ち込んだ？

　ソフトウェア開発において品質専門組織というのが存在する会社があると思うが、そんな組織になんの価値がある？本当にお客さんに評判の料理を出すレストランでは、多分レシピの書き方にこだわっているレストランがあるとは思えない。素材、技術、調理法に重点をおいて、調理人が切磋琢磨しているはずで、マネージング力だけでおいしい料理が出来上がるとは思えない。日々の調理技術を磨き、湧きたつアイディアを何度も試作し、試行錯誤した結果、本当においしい料理ができあがるはずだ。そして本当の有能なマネージャはそうした思考試作を数多く経験した人間ではないか？

デザインパターン

デザインパターンはとは、書籍「オブジェクト指向における再利用のためのデザインパターン」において、所謂GoFと呼ばれる先人たちが、ソフトウェアに導入にしたオブジェクト指向におけるプログラム設計のパターンです。

これらのデザインパターンを使用してクラス設計することで、開発チーム内の用語統一化が進み、意思統一が図りやすくなります。

GoFのデザインパターンでは、23のデザインパターンが用意されています。

生成に関するパターン

• Singletonパターン
• FactoryMethodパターン
• AbstractFactoryパターン
• Builderパターン
• Prototype パターン

構造に関するパターン

• Adapterパターン
• Bridgeパターン
• Compositeパターン
• Decoratorパターン
• Facadeパターン
• Flyweightパターン
• Proxyパターン

振る舞いに関するパターン

• ChainOfResponsibilityパターン
• Commandパターン
• Interpreterパターン
• Iteratorパターン
• Mediatorパターン
• Mementoパターン
• Observerパターン
• Stateパターン
• Strategyパターン
• TemplateMethod パターン
• Visitorパターン

Singletonパターン

Singletonパターン(シングルトン)を使用する場合、そのクラスのインスタンスが1つしか生成されないことを保証することができます。

Singletonパターンでは、様々なクラスから呼び出しが可能となります。

ただし、ステートフルに実装してしまうと、グローバル変数のように、プログラムの依存性が煩雑化し、構造が悪化するケースがあります。

安易にシングルトン化することは、非常に危険な行為ですので、十分に考慮する必要があります。

実装例

• コンストラクタはprivateで定義する。
• staticで、かつprivateで自分のインスタンスをもつ。
• staticメソッドでgetInstance()メソッドを定義する。

---


public class MySingleton {
private static final MySingleton singleton = new MySingleton();
private MySingleton(){}
public static MySingleton getInstance(){
return singleton;
}
}


---

誤った実装例

以前、以下のような中途半端なSingletonを見たことがあります。

---


public class MySingleton {
private static MySingleton singleton;
private MySingleton(){}
public static MySingleton getInstance(){
if(singleton == null){
singleton = new MySingleton();
}
return singleton;
}
}


---

上記の実装を行った場合、getInstance()が非同期呼び出しに対応できていません。

そのため、getInstance()をsynchronizedする必要が出てきます。もし、synchronizedした場合、呼び出し単位で同期をとるため、性能への影響が発生します。

ハーバード白熱教室

マイケル・サンデルさんの東京大学での講義がNHKでやってるのを見ました。

以前も海外バージョンで放送されているのを見た覚えがありましたが、今回の講義は、日本を取り巻く具体的問題を取り上げているため、非常に面白い。

「正義」を以下の３つの考えを元に議論を進めていた。

• イギリス功利主義哲学者ベンサムの「最大多数の最大幸福」
• ドイツ哲学者カントの「人間の尊厳に価値をおく」
• 古代ギリシャ哲学者アリストテレスの「美徳と共通善をたたえ育むこと」

３人の船員と１人の給仕「リチャード・パーカー」が救命ボートに乗り、気分が悪くなった若い給仕を殺して、その肉を食べて生き延びたという事例から、議論を行い、道徳観を浮かび上がらせている。

そして原爆と謝罪。コミュニティに対する考え。非常に楽しくテレビを見れたわけです。

インパール作戦―最初からデスマーチ―

野中郁次郎さんの講演を聴く機会があったのですが、いくつかの深い話を聞けて感心したわけです。まさに賢人と言っても、過言ではないと思います。そんなきっかけから、以前買った「失敗の本質」を読み直したわけです。この日本的な組織作りに関して、いかにも野中さんらしさのある、非常に鋭い考察がされている。

さて、私がこのまえまで進めていたプロジェクトが10月に完了し、やっと一息つける状態になったわけですが、乗り越えてみたものの様々な反省点がある。何と言っても、プロジェクト当初からデスマーチ化することを予想し得るほどの、超短納期なプロジェクト計画に無理があった。本来は、納期というものは大概プロジェクトを担当する人間が、本来計画するもの。ただし、今回は部門の長が先に納期を決めてしまった。

たしかに、最近の市場の要求の早さから、納期をより短くしたいという経営者の考えは分かるが、とは言っても無理は禁物である。やはり、その中で様々な構造の問題を抱えたままの出荷となり、今後のメンテナンスでそれらを改善するしかない。

さて、今回のプロジェクト計画における、意思決定プロセスがいかにもインパール作戦の牟田口司令官の意思決定と類似していたことが、非常に関心深かった。様々な参謀が「司令官が言ったことだし。しょうがない」という空気を読んで、作戦を下していくという雰囲気も、似ているに違いない。そして、そんな無茶な目標に対して、帰納的計画を設定し、そして兵隊をデスマーチに送り込む。

誰が牟田口司令官を止めることができる？

それは、彼の直近の部下が死ぬ気になって止めること。

帰納的計画ではなく演繹的計画のもとに、精神論ではなく論理的な考えのもとに、机上ではなく現場主義で。そんな覚悟のある人が、牟田口司令官を止めることができるのでしょう。

課題の先送りについて

課題に対峙する姿勢が人それぞれに異なる。その中で重要なことは、決断できないは課題として再度「先送り」し、解決できる課題を先に実現することが重要となる。

プログラムの設計作業を行う中で、様々なパターンを仕様書に落とし込んで、「このケースの場合には解決できません、なのでこの設計では進めません」と作業を止めてしまい、ただひたすらにその課題に対して「あーでもない、こーでもない」と一人考え込むプログラマによく出会う。

私はそういった状況におちいった人に対しては、課題を最小化するよう、要件を大幅に減らすことにしている。最小限の課題に絞り込まれた場合、プログラマは安心して開発を進めることになり、通常のパフォーマンスを取り戻すことになる。

「先送りした課題が残ったままではないか？」と思われるかもしれないが、他のメンバーを含めて検討したり、システム全体を見回して課題解決の方法を探った方が、よりシンプルで簡単な解決方法を見つけられるものである。

上記で重要な点は、最小化された課題解決が「必ず解決すべき課題」であることを、プログラマに対して信じ込ませることである。粘り強くプログラマとコミュニケーションをとり、お互いの信頼関係を強くすることにより、初めて各個人のパフォーマンスが最大化されると考えます。

プログラミングの心得

　プログラムコーディングを行う上で、最も重要なポイントを以下の３点に絞られる。

1. 正確であること
2. 保守性が高いこと
3. 性能が高いこと

　他にも必要なポイントがあるのでは？という意見もあるかもしれないが、上記３点が揃った時点で、プログラムは非常に高い品質を維持し、非常に美しく仕上がる。

　さて、この３つポイントを議論するうえで最も重要なことは、それらの優先順位にある。

　まず、要求仕様に対して「1.正確であること」がプログラムとして必要最低限の要素であることは、議論の余地はないものであると考えられる。

　ここで、問題となるのは「2.保守性が高いこと」と「3.性能が高いこと」の優先順位である。この優先順位が逆転しており、プログラムソースが分かりにくいことを指摘すると、「このループ処理で複数の処理を行うことで性能が良くなるのです」と、当たり前のように答える開発者に度々出会ってきた。

　そんな開発者に対して、「プログラムソースはお手紙だ」という例えを聞かせることがある。

　プログラムを初めに開発するのはあなたかもしれないが、保守をするのは大抵その後輩、又は全くの他人になることは間違いない。そのため、他人が保守できないプログラムを作成した場合、例え性能が高くても、それはマスタベーションにしか過ぎないことになる。性能は常に改善できる状態にあるべきであり、その機会を決して途絶えさせてはいけない。

　保守をする人に分かりやすいメッセージ（プログラムソース）を伝える力こそが、プログラム開発者にとって必要な要素であると、私は考える。

bonnou open

つれづれなるままに。。。