上司とのつき合い方

アジャイル・サラリーマンの心得　上司とのつき合い方

　サラリーマンを１０年以上続けると、様々な上司に出会います。この前は、上司が部下に対して、感情的な気持ちだけで命令を下しているケースに出会いました。私の知っているその上司は、目上の人に対しては理論武装して対峙していたのを思い出します。ですが、今回のその上司は、部下に対して「俺の立場を分かってくれよ」と言わんばかりに、苦しい状況を空気で理解をしてもらいたいようでした。

　たまに「部下と上司は平等だ」と言う人いるかも知れませんが、なかなか平等にはならないのです。上司がリーダシップのある人であり、成果を上げているのならば、その話に乗ってもいいかもしれません。ですが、今の日本企業の約８０％の管理職の方は、今の状況を見る限り成果を出せていません。ほとんどの管理職の人の思いとは、会社からなるべく目をつけられず、今の役職を維持し、サラリーマン余生を自分だけは乗り切れるよう、祈っているだけの弱い生き物なのです。

　さて、「私の気持ちをあなた理解してよ」的な上司に対しても、有能な部下は（内心「このバカヤロー」と思いながらも）、友好関係を維持しつつ、決断を迫る必要があります。今回のお話はそんな上司に対する部下の振る舞い方について論述致します。

まずは共感する

　上司に対して決していきなり結論を言ってはいけません。まずは共感しましょう。論理性に欠けるだらだらした話を聞かされるのは苦痛かもしれません。ですが、早めに結論を急がないことです。上司の気持ちがほぐれてくるように、話をしっかりと傾聴することが重要です。絶対に否定してはいけません。「そうですね、部長...」と積極的に傾聴して、上司から「イエスマン」として認識されましょう。

　優れた医師はナラティブセラピーに長けているとのこと。優れた部下は、上司が話す物語を最後まで話させて、完結させるのです。さらに、「〇〇本部長（上司の上司）は結構厳しいこと言いますね〜」、「市場はやっぱり厳しいですね〜」とか、間の手を挟むことで、物語をさらに盛り上げることも必要です。

プランを提示する

　物語の中で解決すべき課題が見えくると、その課題に対する解決策を結論づけて話してしまいがちです。ですが、その行為はサラリーマンの上下関係の中では死を意味します。決してやってはいけません。解決策の正しい言い方はプランとして提示する方法します。しかも２つから３つ以上のオプションを添えて提示し、相手に選択させましょう。そして、それぞれのプランについて、メリット・デメリットを説明しましょう。

　解決策が１つしかない場合で、「グダグダ言わんととりあえずやったらええやん」と思うような場合であっても、決して結論付けてはいけません。ゼロベースで何かしらのオプションプランを探し出しましょう。どう考えても出てこない場合には、選択できないようなプランを提示するのもありです。１つめは「うんこ味の...」、２つ目は「カレー味の…」、３つ目に解決方法を提示してあげて下さい。

　上司の悩みというのは解決策が１つしかないようなケースがほとんどです。ですが、上司は決断できないのです。怖いんです。責任逃れしたいんです。そんな上司の気持ちを理解することが、サラリーマンとしての部下の努めなのです。

コミットメントする

　解決策が提示されたので、あとはそれを実行するのみです。そこで上司にコミット（宣言）させることが必要となります。が、上司の心には、まだ不安が残っています。「…のリスクが残っている。」、「...の時には失敗したから慎重にならなくてはいけない。」など、実行しないための言い訳を探し出します。

　優秀な部下は、今までのアプローチとは打って変わって、肉食系に変身します。「〇〇部長、やりましょう！私にやらせて下さい！」と、強引にアプローチします。情熱をあらわにし、声を荒げ、まっすぐ目を見つめ、上司に「やりましょう」と積極的に迫るのです。そして、上司が「お前がそこまで言うならばやってみよう」というコミットメントを引き出すのです。

　相手のコミットメントを引き出すためには、あなたのコミットメントが必要です。部下の目の中の燃え盛る情熱を見て、上司は決断するのです。それでも、上司がモジモジするようであれば、イエスマンの仮面を取って「それじゃダメだ！」と叱りつけてあげましょう。そして、M性を軽く引き出すようにdisってから、アプローチを仕掛けるというテクニックもあります。

　上司は理解してくれない部下は嫌いですが、従うだけの部下は面白くないのです。そんな上司の気持ちを察して動くのがサラリーマンとしての部下の努めです。

幽体離脱して対話する

　これまでのプロセスをストレスなく完結させるには、自分が幽体離脱してしまうテクニックが有効的です。対話とは、自分の考え（自分軸）と相手の考え（相手軸）が互いに存在します。自分の考えだけで話をすると自分勝手です。相手の考えに従うだけだと単なるイエスマンです。

　そのような対話にならないように、自分と相手とを客観的に見れる、もう一つの視点を創り出す必要があります。これが幽体離脱です。幽体離脱した場合、相手がどれだけ理不尽であっても、感情的になりません。相手からコミットメントを引き出すための情熱的な自分をかっこよく演じさせることもできる。自分という演者を監督として見るというイメージですね。幽体離脱して、常に客観的な視点で、自分と相手をコントロールして、成功のための対話プロセスを演出するのです。

サラリーマンとは実に不自由なものです。ですが、どこの組織においてはこのヒエラルキーが存在するのです。転職しようが、離婚しようが、決してこの理不尽からは逃れられることは出来ないのです。なので、そのような場面に出会ったら常に幽体離脱で切るよう、禅修行のように自分をコントロールするのが処世術かと。

Engineering, Marketing, Designing

最近のエンジニアが必要とされる能力
私も１０年ほどソフトウェアで飯を食ってきたわけですが、いわゆる「デキるエンジニア」が持つスキルとやらがはっきりしてきたなということ。それは大きく３つの技術です。

• Engineering（技術）
• Marketing（マーケティング）
• Designing（アートやら認知工学）

需要がありそうなサービスをMarketingしちゃって、おしゃれで使い易いインタフェースにDesigningしちゃって、プログラムをEngineeringして公開しちゃいなyou！、ってことです。
ひと昔前のように「俺、Oracleマスターです」じゃ、なかなかエンジニアの価値になりにくくなってきてしまっていることです。

日本大手電機が陥る分業化の罠
高度成長期の日本企業でも、製品を企画・開発していた人たちにとっては、これら３つのスキルは持っていました。
それが、効率化の追求や製品品質の過剰化に伴い、エンジニアの分業化が進みました。
そのため３つのスキルをトータルで持ち合わせた人材が少なくなります。
ソフトウェア業界も分業化が進み、ネットワークエンジニアだとか、データベースエンジニアだとか、プロジェクトマネージャだとか、超上流SEだとか。たくさんありすぎて、何が何やら。。。
日本のソフトウェア企業に勤めるエンジニアは、この分業化の時代の中で、具体的なスキルセットを可視化して売り文句にしてきたのです。

統合型のエンジニアになろう
さて、時は流れ、最近のソフトウェア業界は価格破壊が進んでいます。価格破壊が起きている原因は、主にこのキーワードは「クラウド」、「グローバル化」、「オープンソース」。
とくに「クラウド」の時代では専門知識を必要としないままサービスを立ち上げることが可能となりました。これまでのオーダメイド型のソフトウェア一括請負というビジネスを根幹を揺るがす「破壊的イノベーション」です。
他の業界に比べ比較的安定的であった「ITサービス」という業界自体が、じわじわと存亡の危機に瀕している状況です。
このクラウドの時代に新たにサービスを起こそうとすると、資本金はほとんど必要ありません。GoogleやAmazonのクラウドサービスを使えば、非常に低コストでビジネスを始められます。 そんなリーンスタートアップなエンジニアになるための技術は、やはり「Engineering」、「Marketing」、「Designing」をトータルで扱える統合型エンジニアが重要になる時代なのです。

とまぁ、私もそんな統合型エンジニアになれるよう、家の中で「芸術」に触れる機会を増やそうかと思います。だって外は寒いんだし。

生レバー、最小不幸社会、オーバー・コンプライアンス

嗚呼、生レバー

　生レバーがとうとう禁止となりました。私としては焼いたレバーはモソモソとした食感があまり好きではなく、生レバーの方が食べやすいと思っていた生レバー推進はだったので、今回の厚生労働省のオーバー・コンプライアンスに基づいた法令制定にはデモを主催してやろうかと考えていた次第です。時を同じくして、カリフォルニア州においても、フォアグラが禁止になっています。こちらはガチョウや鴨に対して強制的に餌を与えて太らせるという飼育方法が虐待だということです。世界の贅肉の３分の１を抱え込む米国でこのような法案が可決されるのは、非常な皮肉な結果かと。

最小不幸社会

　さて、日本の生レバーが禁止される経緯において、ブラウン管越しでも衝撃的にまで「痛さ」を感じさせ、お茶の間を震撼させた、某焼き肉屋社長の功績が大きいのかと。いくらデフレでも３００円のユッケをメニューにしたらいかんやろ、と。しかし、このような特定の失敗事例に基づいて、この日本では逐次新たな規制（コンプライアンス）というものが設けられていきます。目指す社会は、どんな経営者や消費者でも、限りなくノーリスクで焼き肉を供給・消費出来るあり得ない社会なのでしょう。ですが、このオーバー・コンプライアンスにより、焼き肉という生肉をも美味しく頂くクリエーティブな生業が死んだことになります。このようなオーバー・コンプライアンスは、最近の日本電機企業がグローバルでの凋落している状況を生んでいるという話もあります。「過剰品質」、「PL法」、「個人情報保護法」等など。いつぞやの首相が目指した「最小不幸社会」というノーリスク社会。

日本のソフトウェアはレシピ作り

　日本でソフトウェアを開発するにあたり、徹底した品質管理の元に開発されています。これら旧来の品質管理では、不具合（バグ）がないよう、ソースコードよりも多くのドキュメント（設計書、テスト仕様書）が生成されます。例えば、正しい設計であるか品質測定するために、「レビュー指摘件数を〇〇件以上」という指標を与えられてプロジェクトが進みます。すると、設計書のレビューで「句読点がない」やら「ここに改行が必要」とか、ドキュメントに対するほぼなんの価値もないレビュー指摘が列挙されます。そして「レビュー指摘件数が〇〇件以上あるから、品質が保たれた」ということが当たり前のように行われている。「アホ」かと。レストランのメニュー開発で、ただひたすらレシピをレビューして、失敗するリスクがほとんどないメニュー開発してるということです。

オーバー・コンプライアンスの罠

　日本の大手IT企業に勤めているエンジニアで、ソースコードを見ないで仕事をしている人が約８割程度ではないかと。その状況でレシピ作りだけに勤しんでいても、Dropboxは生まれないんじゃないかと気づかないといけないと思うのです。日本から正しいソフトウェアでパッケージングされたヒット商品が出てこない理由は、ノーリスクでソフトウェアを開発しようっていう「最小バグ開発」が原因ではないかと（ちゃんとリスクを取って、バグが少ないのは良いことですけど）。クリエイティブにはやはりリスクを取ることが必須であると思う訳で。

　さて、この理屈で言うと、某焼き肉屋社長はクリエイティブということになります。しかし、クリエイティブな作業にはもう一つ重要なことがあります。まさに「間抜けを無力化する-Joel on Software」。能力って平等じゃないっていう事実を踏まえ、プロジェクトはマネジメントしなくてはいけないという教訓かと。

プログラミングの３ワード

未来へのお手紙

 以前、プロジェクトメンバーに「君が今書いているソースコードは君ではない誰かが修正することに間違いなくなる。その未来の仲間に手紙を書いているようなもんなんだから、ちゃんと分かりやすく書いてあげるようにしなさいよ。バグ修正する時に君も悲惨なプログラムをなんぼも見たやろ！」というような話をプロジェクトのメンバーに言いました。そんな話をしたら、「そうですね〜」と、そのメンバーは言ってくれてました。長髪ではないが金八先生並みの熱い指導力を持っていたことでしょう。

 １年以上経ったこの前、そのメンバーがソース書いているところを横目で見てたんですが、まー悲惨に読みにくいこと。なんの成長も感じられない。どんだけ、金八的に熱く語ろうが、「読みやすく」書くこと自体が難しいテクニックなのだなーと実感します。実際、その人に払っている給料はそこまで高くありません。そんなソフトウェアが日本のインフラをしょっているという現実。本当に「読みやすく」書ける人がいたら、ここでは仕事をしていなく、海外企業やベンチャーでバリバリやってるわなと、脱金八で邪推するのであります。

「正しい、読みやすい、速い」

 会社の別部署のベテランプログラマさんが、とある講座で言っていた話。「プログラム」において一番重要な３つの要素は「正しい」「読みやすい（保守性）」「速い（性能）」であるということ。ベテランはさらに言葉を続け、「この順序が重要である。まず、正しく動作することが最重要で、次に見易いことで、最後に性能を求めよう」という。

読みにくいプログラムが出来上がってしまっていたとしたら、他の優秀なプログラマーが性能を良くしようとしても出来ません。チーム開発をする上では、やはり保守性が重要であるというお話でした。

 別のアジャイル開発の指導者的な人と話をした時に、この３ワードの話したところ、「読みやすい、正しい、早い」でしょうと。ペアプログラムをしていると、ソースコードが会話みたいなもんだから、話が通じること、つまり「読みやすさ」が一番拘るべきで、そうじゃないと正しいかどうかもわからんと仰っていました。やはり、チーム開発においては、この「読みやすい」というファクターが最重要とされているのでしょう。

美しいコードを書こうとするのは悪いプログラマー？

 Dropboxの生みの親になるYコンビネータの創業者ポール・グレアムさんは、こんな常識を全く覆す説「美しいコードを書こうとするのは悪いプログラマーだ」を唱えています。つまり、使われないサービスのソースコードがどんなに美しくても、意味が無い。それよりは、使い心地のよい性能の良いプログラムを書からないと、そもそも使ってももらえないということかと思います。この話はつまり、作り手は作って終わるマスタベーションではなくて、ちゃんと使ってもらえるサービスを作ることが重要だよと言っていると思います。こんなマーケティングの姿勢を持ち、かつプログラム書ける人が世界で通じるハッカーであると思う訳です。今後、日本もこんなマーケティングと技術を兼ね備えた人材が創出できないと世界ではやっていけないなと。フラッシュメモリを開発していた現東京大学教授の竹内健さんの著書「世界で勝負する仕事術」で読んだ、MOT(Management of Technorogy)にも話が通じるなと思いました。

３ワードを組み替えろ！

 さて、プログラムの３ワード「正しい、読みやすい、早い」の優先順位について再度考察します。

スタートアップビジネスで必要とされるのは、より魅力的なプロトタイプであるため、「正しい、早い、読みやすい」の順序、つまり保守性は低くなるということ。そして、ソフトウェアを受注する旧来型ビジネスでは、「読みやすい、正しい、早い」という順序で、保守性を大事にするということ。規模が大きくなればなるほど、後者の優先順位が望ましく、規模が小さければ前者の優先順位が望ましいということになるかと。

 これは吉野家の牛丼のキャッチフレーズ「早い、うまい、安い」が、市場動向によって「うまい、安い、早い」等、優先順位を変化させていたことに似ているかと。これは答えは一つではなく、ビジネス形態や市場動向によって「常に組み替えること」が最も重要であるということが今回の結論とさせて頂きます。

私のプログラムにコメントがいっさい書かれていないことに不満を抱いているレビュアーの方。私はスタートアップ企業だということでご了承お願い致します。

デザイン思考が大事

ひどいユーザインタフェースに出会った怒り

 他人が設計したユーザインタフェースを見て思うのは、センスがある人とない人でユーザインタフェースの完成度が全く違うということです。最近みた画面で一番センスないなーと感じたのは、ワイドディスプレイ一杯にボタンやツリーが貼付けられた画面でした。多分、パワーポイントを使って設計したのでしょう。とりあえず、広がったワイドディスプレイ一杯に機能が盛り込まれています。カタログを見たら「たくさん機能があるな〜」と感じます。しかし、実際使ってみると、フルHDの右側と左側を交互に見るはめになり目線が左右に散らばるため本当に疲れます（マウスも右へ左へ行ったり来たりします）。最後にボタンを押せば、必要性を全く感じさせない確認画面が表示され、苛立ちを覚えます。さらに、デザインに統一性がないため、マニュアルなしでは何処に何の機能があるのかがさっぱりわからない始末でした。こんなユーザインタフェースでお金を取っていること自体、犯罪だと思います。どんな言い訳をしても死刑です。

ひどいユーザインタフェースが出来るまで

 こんなひどいユーザインタフェースが出来るまでの過程というのは、まさに日本企業の悪い文化が出ているなと感じます。
フルHDになった画面に対して設計した上記の例では、今までの画面設計を見直さずに、画面が広くなって空いているところにただ機能を詰め込んだだけでした。
「使える画面が広くなった」ということで全体的に設計を見直すことなく、ただ広がったところに機能を追加しただけです。
設計者は、きっと追加された画面の一部分に対して細やかに設計していましたが、全体的なユーザインタフェースについては、見直すことに躊躇したのだと思います。
全体的な見直しを行わず、今ままであった部分を直すこと無く、機能を追加したのでしょう。
設計者はきっとこう言い訳するはず。
「互換性を重視」、「上司に言われたとおり追加しました」。
まさしく、日本人特有の悪しき文化である、前例主義、部分最適、他責文化がまざまざと現れています。

ユーザインタフェースとは芸術

このGUIを設計できる技術を向上させることは、社会人になってからでは遅いというのが私の持論です。
ユーザインタフェースを作る作業は芸術品を作るものと同じです。
もちろん美意識が強くないと駄目で、さらには、ユーザ（他人）に対する洞察力、斬新的なものを作るための想像性、統一性を持たせるための論理性等、様々な能力が必要とされます。
会社員になってから、これらの能力は著しく伸ばすようなことは出来ません。
それは、才能であり、多感な時期である10代に以下に創造的な挑戦を行っていたかどうかだと私は考えます。
ですが、日本の企業はこういった人材を大事に出来ません。
こんな才能を持っている部下がいたら、上司だった扱いづらい部下に見えるでしょう。
これらの能力はお客さんを喜ばすことにはなるかも知れませんが、上司や会社に対して反抗的になりがちであり、部下として扱うにはめんどくさいものです。
日本企業でやはり必要とされるのは委員会的に調整する人であり、気難しい芸術家を大事にできないのでしょう。
最近のソニーが作るモノが面白くないのは、まさに「委員会による設計」のアンチパターンに陥っているのではと考えたりもします。

日本に必要とされるデザイン思考

今後、日本だけでなく世界的にCreator or Serverの時代が進みます。
アジアの安い労働力と日々進化するコンピュータ性能、そして満たされた生活。
その中で、ビジネスとして必要なのは高いコンセプトとデザインであると考えます。
まさにハイ・コンセプトの時代に変わりつつあるということです。
技術力はあるが、借金まみれの日本という国は、何故か対フランスでは貿易赤字になります。
車やハイテクなモノを世界で売って輸出したとしても、ブランド志向の高い日本女性が、資生堂ではなくフランスの化粧品、日本製鞄ではなくプラダやディオールを買うから、イタリア・フランスに対して貿易赤字になるのです。
そう考えると、世界的な日本製ブランドがたくさん出来て、今後消費が伸びるであろうアジアで鞄・靴・化粧品を売れるようなブランドになれば、日本という国は高齢化社会を迎えてもある程度やっていける国になるのではと考えています（という考えをデフレの正体という本を読んでおもしろいなと思ったわけです）。

優秀な現場の人がパッケージをだめにする

３月１日のとあるドラマ

201X年3月1日、地方銀行向けパッケージの開発ルームでは、異様な雰囲気の中、メンバー全員がその日の朝を迎えた。その日は北海道、長崎、そして兵庫の３つの銀行で一斉に稼働する日であり、多くのメンバーは現地に立ち会う等の臨戦態勢が敷かれていた。稼働後２時間が経った朝１０時頃、開発チームに同時に２つのトラブル報告が入った。いずれもデータベースがダウンし、待機系システムに切り替わったという致命的な内容だった。開発メンバーの一人がデータベースのログを調査し、データベースがダウンした原因が接続プロセス数の制限を超えたことよるものと判明したため、急遽、現地で立ち会っているフィールドSEにパラメータ設定とシステム再起動を指示した。昼１２時に、最高責任者である事業部長は、事態の改善を行うべく、担当部長と担当課長を現地投入することを決断した。昼１３時、運用系システムの再起動が行われ、それぞれの銀行で運用系システムに無事切り替わったとの報告があった直後、更なるトラブルが現地から報告された。運用系システムの発番プログラムが正常動作せず、データ重複によりシステムエラーが複数で発生し始めた。事業部長はさらに現地に開発メンバーを投入し、早急にデータ復旧を行うよう、迅速に指示を出した。事業部長は「お客様のシステムを決して止めてはいけない」と鼓舞し、開発メンバーを送り出した。。。

隣のプロジェクトで起きていた今週の出来事をシリアスタッチに書いてみました。そのトラブルの様を見ながら思ったことは、「ちゃんとトラブらないモノを作ろうよ」です。

パッケージ開発の失敗例

このパッケージは大規模向けに販売されていたパッケージを移植して、中小規模向けに販売するというコンセプトの商品でした。データベースの変更に伴うプログラム修正は中国でオフショア開発され、日本ではプロジェクトマネージメントを中心に作業するという方法で進められました。いわゆる品質指標も丁寧に数値化されていたため、一定の品質が担保できているだろうという認識でした。

ところが、ふたを開けてみると、移植元のパッケージがぼろかったりとかして、トラブルが続発しています。バグがあっても、一体誰が作り込んだのかがさっぱり分からないようで、早急に修正できないという困った状況です。さらには、稼働させるためにはデータベースのチューニングなどのSE作業が必要となるため、初期導入費用がかかってしまい製品競合力も低いです。まさにパッケージ開発における失敗のオンパレードといった感です。

サポートしている同僚は自嘲的に言いました。「生まれてこなければ良かったのに」。まさに不毛な子です。

優秀なSEとパッケージのジレンマ

私が勤務する会社は大手の日本法人のIT会社で、星の数ほどパッケージ製品をリリースしていますが、利益になるパッケージはほとんど存在していません。この理由は、優秀な現場のSEが数多くいるから、良いパッケージが生まれないというジレンマだからだと思います。現場で働く有能なSEが存在するから、場当たり的になんとかしてしまうから、パッケージにフィードバックされないのではないかと思います。

当の私もパッケージを開発していますが、粗利益が非常に高いです。その理由は、インストーラー、導入ツール、マニュアル、プロモーションツール等の「仕組み」が充実しているからです。「仕組み」が充実していると、２５〜３０歳くらいの若い女性インストラクターさんで導入できます。導入費が安くできます。なんとかやりくりしてくれる優秀なSEさんが存在してしまったら、この「仕組み」を作ろうという気持ちになりません。現場の人が「楽して儲け」させるように「仕組む」思考がパッケージ開発には必要なのです。

今回のリリースされたパッケージの場合、「有能な現場SEを最大限に活用する」というコンセプトが存在しました。しかし、このコンセプト自体がパッケージには合わないということを経営者が理解できなかったのが根本原因だと考えます。

日本人は「仕組み」が下手

歴史を振り返ると、日本人は「仕組み」を作るのが下手な民族性だと思います。社会に存在するほとんどの「仕組み」は欧米から持ってきたものが実際に多い。しかし、それは、現場の日本人が優秀すぎるというジレンマだと考えられます。

例えば棚田とかを見ると、年貢が厳しい中、農民が工夫して作り上げた芸術作品です。ですが、牛も入れないような田んぼなので、効率的とは言えません。これも優秀な日本の農民が場当たり的になんとかしちゃったのでしょう。エルピーダメモリの会社更生法についても、グローバル時代の中でDRAMを販売するというのは厳しい状況であったにも関わらず、優秀な現場の人が場当たり的にコストダウンに取り組んだために、撤退という経営判断が行われずに、今の今まで持ってしまったのだと考えられます。この前の日本の戦争においても、世界で最も優秀な現場の兵隊が存在したから、明確な戦略という「仕組み」を大本営が見いだせず、結果、あのような悲惨な状況になったと考えられます。

「仕組み」を作れる人になるためには、「真面目」じゃだめで、「楽して儲ける」的な発想が重要かなと思います。しかし、この発想は、従来の日本の美徳に反するところがあるようです。実際にうちの会社の執行役員常務と話をする機会があったのですが、私の主張する上記の話についても「上手く行ってるビジネスの上であぐらかいてんじゃねぇ」的なことを言ってました（この人の経歴を調べたんですが、うちのプロジェクトのような粗利を稼げるビジネスが一つもない部署のご出身のようでした）。これからのグローバル時代で乗り切るためには、このような割り切った発想を持つことが重要なのではと思います。

モックアップビジネスモデル

初期費用０円受託開発

　永和システムマネジメントさんが初期費用０円の受託開発をやっていることを、人づてに聞きました。この話を同僚の何人かに話したところ「こんなの出来る訳ない！」と口を揃えて言ってました。私の会社はＩＴゼネコン大手です。従来の「受託」ヒエラルキー構造でビジネスを行っていたため、このような新しいビジネスモデルに理解を示そうとしないのでしょう。しかし、私はこのビジネスモデルが生まれたこと自体が日本のソフトウェア業界が変化の兆しと捉えています。

モックアップビジネスのメリット

このビジネスモデルは、最初の試作品（モックアップ）を０円で開発し、その試作品を気に入った会社は、その後利用料を月額で払っていくという、いわゆるクラウド型のビジネスモデルです。このビジネスモデルは、通常の受託ビジネスモデルに比べ、以下のメリットがあります。

     １．利益率の向上

私が所属している部署はパッケージ提供型の箱売りビジネスですが、たんなる「受託」に比べると利益率が２～３倍以上に上がります。受託ビジネスの場合、赤字を抱え込むリスクはなくなりますが、「人月」あたりの利益額は一定となります（極論、「無能」なプログラマをできるだけ安く集めて、マネジメントでなんとかプロジェクトを完了させることが、最も利益率を上げる手法となります）。自前で企画から開発までをサービスとして提供すれば、どこかの会社に中抜きされることなく、高い利益率のビジネスを実現できます、また、このモデルの場合、お客さんを「囲い込み」しますので、利益の継続性という観点でも魅力です。

     ２．低コスト化の実現

通常受託の場合、開発言語やＯＳ・データベース等のミドルウェアは、お客の都合で決まります。そのため、様々な技術に対して人材教育・人材配置が必要となり、そのままコストとしてビジネスに乗っかります。モックアップビジネスモデルの場合、自社が得意とする開発言語とミドルウェア構成で試作品を作ってしまえば言い訳で、リソースの選択と集中が可能となり、開発コストを大幅に下げることが可能となります。さらに、一度開発した共通部品や各種基盤系フレームワークは、次のモックアップでもそのまま流用できるため、コスト低減だけでなく、納期短縮や製品品質の向上も実現できます。

    ３．開発者のモチベーション向上

試作品開発では、ＧＵＩから大枠の仕様を自社で決められるため、開発者のモチベーションは上がります。開発者の気持ちとしては、出来上がってからの仕様変更は苦痛そのものです。最初に試作品を作り切ってしまうことは、お客さんとのイメージの共有が簡単になるため、大きな仕様変更が発生しないことになります。さらに、今回のモデルの場合、仕様変更は月額に移行した段階で発生するため、「仕様変更しないと金払わんぞ、ゴラ！」という、よくあるお客さんの脅迫タイミングを奪うことが出来ます。

　このように、モックアップ型ビジネスモデルには上記のようなメリットがあるため、初期投資が「０円」でも採算があうのではと考えています。もっと言うと「０円」じゃないとダメです。「０円」という言葉はマーケティング的には絶大な効果を発揮します。だから５０００円じゃだめなんです。（「０円」の言葉の力については、「予想どおり不合理」にも詳しく書かれています。）

モックアップビジネスを成功させるポイント

そうは言ってもこの新しいビジネスモデルは、従来型の「人月」モデルに比べると、失敗するリスク顕在化します。私が考えるに、このモデルを成功させるためには、以下のポイントが重要だと思います。

　　 １．有能なデザイナーの投入

  受注を成功させるためには、試作品のデザイン性が最重要です。「痒いところに手が届く」という機能要求については、月額の段階で対応するようにして、モックアップ段階で訴求すべきは「見た目」になるはずです。そのため、優秀なデザイナーが必要となるのです。「ハイ・コンセプト「新しいこと」を考え出す人の時代」や、「デザイン思考が世界を変える―イノベーションを導く新しい考え方」にも書かれていますが、これからは感性の時代に突入します。そのため、優秀なデザイナーを社内で育成することが重要課題であると考えます。

２．再利用の徹底によるコスト削減

モックアップでは低コストでアジャイルに作り上げることが重要です。そのためにはプログラムを徹底的に再利用させるよう、共通フレームワークを拡充することがポイントとなるでしょう。モックアップ段階では、入社２、３年目の新人プログラマーと、優秀なデザイナーの組み合わせだけで開発できるくらいの、使いやすい部品ライブラリがあれば理想的なのではないかと思います。きっと、永和システムマネジメントさんの場合、開発言語はＲｕｂｙでアジャイルに開発しているのだろうと思いますので、この点で言うと問題は無いかと思われます。

３．創造性の追求（受託意識からの脱却）

　受託開発の場合、製品の魅力が乏しいと感じられても「お客さんが言ったんだから、そのままやっておけばいい」という、一種の逃げが許されたりもします。しかし、自前でサービスを提供するということは、常に創造的であることを要求されます。本当に使いやすいユーザインタフェース、創造的な機能を創り出せる「センス」は、誰しもが持っているものではないというのが、私の持論です。魅力的なユーザインタフェースを想像すること自体、アーティストと同じ活動だと考えます。なので、そのような人材がキーマンとして社内にいるかいないかがポイントになると考えています。 

イノベーションのジレンマ

最近は、Ｎさんも赤字体質に苦しんでいる訳で、インドや中国の買収されるなんてことも現実味を帯びている状況です。今までのような受託ヒエラルキーの構造で、同じように受注できればいいのですが、クラウドの登場により市場価格が急速に押し下がっている状況を見ると、そんな大金をソフトウェアに出せるお客さんがどれだけいるか疑問です。日本のソフトウェア業界において、クラウドはまさにイノベーションのジレンマです。デジタルカメラを自社で開発しておきながら、フィルムビジネスの急速な落ち込みに対応できず、コダックはあえなく潰れました。今、日本中のＩＴ企業がクラウドを進めていますが、まず自らの仕事のやり方を見直さない限り、コダックの二の舞になってしまってしまうと私は考えます。

ニーズをシーズでウォンツに！

ビジネスモデルって何やねん？

５、６年前くらい前に、会社でビジネスモデル特許を書けという至極あいまいな業務命令が私に下りました。技術特許については、それまでにも何件か出願依頼していましたので、十分理解していましたが、「ビジネスモデル特許」については、一種の「ハイパーメディア」なにがし的な胡散臭さが感じられていたため、意識的に避けていました。が、「ハイパービジネスモデルは胡散臭いのでちょっと。。」なんて、サラリーマンとして上司に対して言えないため、教育嫌いな私ですが、「ビジネスモデル」関連の社内教育を探し出して、理解を深めようとした訳です。

さて、その「ビジネスモデルなにがし」の社内教育に出向いてみると、片手に携帯よろしくノートパソコンに向かっている「チョイワル」な壮年男性が講師の席に座っておられました。周りの受講生は、その「チョイワル」講師をまるで有名人を伺うかのように、興味津々に見つめていたので、自分がえらく場違いな場所に来てしまったと後悔していたのを覚えています。講義を進めて行くと、著作「コンサルタントの質問力」の紹介がありました。その方がコンサルタント業界では有名な野口吉昭さんであることが初めて分かりました。

ニーズとシーズでウォンツを！

講義の内容は当初期待していた「ビジネスモデル特許」とは全く関係がないものでしたが、オフィス用品販売「アスクル」や、大田区を中心にお弁当を販売している「玉子屋」等を事例に、様々な業態でのビジネスモデルを分析するという、知的欲求を満たすとても有意義な講義内容でした。特に私が感銘を受けたのは、「新たなビジネスモデルを創出する過程において、ニーズとシーズでウォンツすることが必要」という話です。

ニーズはいわゆるお客さんの声。具体的ではあるが、視野が狭く、短絡的な内容が多いです。それは決して本当に欲しいモノ、いわゆる「ウォンツ」ではない。スティーブ・ジョブスは「客は本当に欲しいものを知らない」と言っていたとか。だけど、お客の誰もが知らない「ウォンツ」を創り出すなんて、簡単には出来ない。でも、社内のどこかにあるシーズ（技術）を最大限に活用すれば、「ニーズ」を「ウォンツ」に変えることが出来るという話でした。

iPhoneが出来上がるまで

「スティーブ・ジョブス」でiPhoneが世界中で圧倒的な驚きを持ってリリースするまでの話を読んだとき、まさに「ニーズをシーズでウォンツに！」のケースに全く以て当てはまるなと感心しました。iPodが世の中を席巻していた頃、iPodを脅かすのはウォークマンではなく携帯電話であるとAppleは考えていました。デジタルカメラがカメラ付き携帯電話の登場により販売が落ち込む様を見ていたので、危機感を強く持っていたのでしょう。さて、AppleはMotorolaと共同でIPod付き携帯電話を開発し販売しました。しかし、これは大失敗に終わりました。携帯にiPodが内蔵した、「ニーズ」をそのまま具現化した「だけ」の製品だったからです。特にデザインがしょぼかったらしく、「スティーブ・ジョブス」の本の中でも糞味噌にこき下ろしていました。

ここで、Appleは既に開発を進めていたタブレット技術に目を付けます(iPhoneより先に、iPadを開発しようとしていたというのが面白い)。このマルチタッチ機能を「シーズ」として組み合わせ、徹底的にブラッシュアップを重ねた結果、まさにお客の誰もが想像もつかないようなiPhoneという「ウォンツ」が創造された訳です。

「現場」はフィールドだけじゃない

さて、私の仕事はソフトウェア開発なので、それに立ち戻って話をします。日本のソフトウェア業界に働いている人は必ずこの言葉を聴いたことがあると思います。「お客様の現場に出向いてお客の話を良く聞け！」。この言葉は半分は正しいですが、半分は間違いです。お客さんが欲しいモノを提供するためには、お客さんの現場に出向いて「ニーズ」を聞くことは重要ですが、それだけでは本当にウォンツなモノは作れない。「シーズ」は常に開発現場に落ちている訳で、開発現場にも同じように、いや、それ以上に出向かないと、本当に売れるウォンツな商品は出来上がらないと思う訳です。これから日本ではモノを作ったら当たり前のように売れるという時代じゃありません。客を感動させ、ワクワクさせる「ウォンツ」なモノを作るためには、やはり「ニーズ」と「シーズ」を繰り返し組み合わせながら、新たな「ウォンツ」を作り上げる思考パターンが必要とされるのでしょう。

この話は今週の重役向けスピーチのネタです。当初は（http://blog.livedoor.jp/kazu_fujisawa/archives/25610490.html）を元にアレンジして、「ソフトウェア業界における少子化問題を考える」を用意したのですが、「無駄に炎上させてもしょうがないだろう」という上司判断により、今回の話のネタを日曜夕方に書き下している訳です。上司の命令を従順に従う私こそサラリーマンエンジニア。

緊張と緩和

お笑いの緊張と緩和
 この緊張と緩和という言葉は最近テレビでもよく耳にするキーワードでありますが、もともとは関西落語の桂枝雀さんが、「全ての噺は緊張と緩和で分類できる」という主張が最初とのこと。この「緊張」と「緩和」理論について、落語の世界を通して説明している動画がyoutubeに掲載されていたので、じっくりと見てしまいました。
 近年のお笑いは、いかに「緩和」させるかではなく、いかに上質の「緊張」を演出できるかだと思います。例えば、大晦日に放送された「笑ってはいけない」等の番組では、シュールレアリズムによる緊張と「アウト〜」による緩和と考えれば、まさにあの「緊張」の間が重要なのではないかと考える訳です。また、M１グランプリを振り返ってみても、徹底した変態キャラのチュートリアルや、徐々に盛り上がる喧嘩のブラックマヨネーズ等のコンビは「緊張」できる「場」を上手く演出しているな〜と改めて考えさせられます。桂枝雀さんは１９９７年にお亡くなりになられてますが、「緊張」と「緩和」は、お笑いの現場に最も取り入れられている理論だなぁと感心します。

音楽の緊張と緩和
 緊張と緩和の動画を見た上でiphoneの曲を聴いていたら、ヘビーローテーョンされる曲のほとんどが、緊張と緩和のダイナミズムがしっかり構成されている曲ばかりであることに気づきました。

例えば、ライブ曲での終盤のジャムセッションがラストのコーラスに向けて盛り上げる曲は何度聴いても脳内アドレナリンが分泌されます。最も重要なのは、ジャムセッションの質が高く、間延びしない程度の「緊張」を演出しているかだと思います。


レッチリのBy the wayなんかは、ライブじゃなくても曲自体が緊張と緩和で構成されてるため、ダイナミズムがあって、チャートインもなるほどなと感じます。

高校の時に流行ったダンスミュージックもやはり、ドラムが一定間隔で鼓動する「緊張」と、休憩時間？的な「緩和」がしっかりと構成されている曲だったなと思い出しました。

創出の緊張と緩和
古来中国の諺で、「良い考えは馬上、枕上、厠上で生まれる」と言われるそうで、ブレークスルーはリラックスされた「緩和」の中で生まれるとのこと。なるほど、私の仕事のソフトウェア開発でも、長時間かけて作ったものが全て必要なくなるくらいのアイデアは、家に帰ってお風呂に入った時に生まれたりすることが多い。様々な切り口で物事を捉えようと努めても、やはり緊張している状況では、視野が狭くなっているのでしょう。では、ずっと緩和（リラックス）すればいいのかというとそうでもない。本当に質の高いブレークスルーが生まれるためには、突き詰めて物事を考える緊張や、悪戦苦闘して実行する緊張が、過程に必要なのです。緩和しきった中での「軽い」アイデアを聴いても、聴いている人は魅力を感じないものです。

プロジェクト活動の緊張と緩和
良い作品をプロジェクトで成果を出すには、緊張と緩和のダイナミズムをチーム全体で形成する必要がある。各メンバーがそれぞれ持つ「緊張」と「緩和」の波長が、チーム全体で大きな波長になり、それは共振作用を起こし、信じられない程のパワーが生み出される場合がある。まさに「狂熱」である。このようなプロジェクトにするためには、各メンバーの波長を検知し、マネージャ自身の波長を乗せながら、チーム全体の波長に化けさせるマネジメントが必要だ。つまり、プロジェクトマネージャの目指すべき仕事とは、Excelでガントチャートを書いて報告することではないということだ。
このような考えは一般的なソフトウェア開発のPMとは異なる考えなので、私はPMにはなりたくないというのが結論。今年の春の情報処理試験は何も受けません！

Excelの列数と品質管理

作業標準化で品質は向上するか？

会社ではQMS（品質管理システム）と言う大運動会の時期です。「品質管理」という仕事を「やらされ」て思うのは、「属人化」した個人能力に頼るのではなく、プロセス改善により「組織的」に品質を担保することが、日本の会社では重視されていることなんだということです。つまり、野中郁次郎さんが言うところの、「暗黙知」から「表層化」された「形式知」で品質が管理されているかが重要視されている。理由として考えるならば、日本の会社は、実力主義を好まないムラ社会的な組織が多く、要は実力がないヒトでもある程度の品質が確保されるよう、作業を標準化（形式知）が必要となったのではないかと考えます。

さて、本当に作業標準化によって品質とは確保されているのでしょうか？

日本企業とExcel文化

日本企業では非常にExcelが好まれています。前にインドのプログラマと話をしていた時に、日本人から5mm四方のさいの目が並ぶExcelのドキュメントを渡された時に、その方が「クレージー」と思わずこぼしてしまったと言っていました。これほどまでに日本人がExcelが大好きなのは、やはり縦の横の枠にはめ込まれることを「日本人」の血が望んでいるのでしょう。

今回の私の仕事場での品質活動において、ある問題（トラブル）１件（１行）あたりに、Z列まで存在する項目を埋めるExcelの品質文書が届きました。これを埋めることで品質プロセスが担保されるということでしょう。そのExcelの歴史は長いらしく、どっかよそのプロジェクトで利用されているが「改善」され、私のプロジェクトに流れ着いてきました。１件の内容に対して、チェックする列が多く網羅性が高いことから、品質が向上するというロジックなのです。

さて入力してみると、ある列についてはほとんど同じ内容が入るか、もしくは適当にならざるを得ない項目が多く存在することに気づきます。それを入力している内に、その作業の単純さに怒りが覚えてきます。ある項目については当たり前すぎる内容だったため（OSがWindowsの製品にも関わらず「OS」という区分が存在するため）空白にしたのですが、そしたら品質担当のAさんが言うに「とりあえず埋めないと品質を確保したことにならない」とのこと。いや、本当に「クレージー」です。

増え続けるExcelの列数

品質管理する人にとっては、Excelの列を増やすことが「改善」になっているという意識が高いようで、その結果何かのプロセス改善を行えば、Excelの列が増えることになります。しかし本当に品質を確保するためには、列数を追加するときに一緒に列数を削除しなきゃいけない。開発者はそこまで時間に余裕があるわけではないし、市場はタイムリーに製品を要求してくる。お客様のニーズ・ウォンツを満たすためには、製品を効率的にリリースするということが最重要課題なわけです。それであれば、本当に大事なのは、必要のない無駄な「列」をいかに省けるか、必要のない仕事を以下に減らせるかが、本当の意味での品質活動になると考えるのが筋ではないか？

今回私が「クレージー」だと思った品質管理者は、きっと埋まってないと気が収まらないという性格なのでしょう。きっと、私が埋めたExcelを見て壮観だったのではないかと。本当に良い「管理」とは、「管理」されることなく、効率的に組織が機能するように仕組むこと。より列数が多いExcelを埋めることが「管理」したことにはならない。今回の例で言えば、単なる品質管理者のマスターベーションに私がつきあわされたということです。

前例主義による列の増大

日本の会社において、「列」を増やすより減らすことが難しい理由は、「前例主義」によるものと考えます。「前例」を破ってまで良くすることにリスクがある、またはリスクがあるように思われているのでしょう。かくいう私も、以前、問題点管理をExcelからTracというOpenなWebツールを使うようにした時には、「会社で前例がないもの使わない方が良い」と言われ、それどころか「おれが君の頃には土日出勤して工程表を手書していたんだ！」という精神論を聞かされる始末でした。つまり、前例を破って「失敗」したときのリスクを考えた場合には、前例を守ってやり過ごした方が、結局楽ということなんでしょう。このサラリーマン精神で、本当に製品の品質は良くなるのでしょうか？絶対に違います。常に向上する気持ちを持って、変化し続けるものしか残れないのが自然の摂理なはずです。

Creators or Servers

作業標準化により本当に品質が良くなるかという議題に結論を出すのは難しいですが、未来における作業標準化の必要性について語ってみます。IBMの人工知能コンピュータ「ワトソン」は米国のクイズ番組で76週連続チャンピオンに買ったそうです。クイズではもう人間はコンピュータには勝てないのです。コンピュータの得意とする仕事は「標準化」された作業です。もし今、標準化されて品質が保たれているような作業は、１０年もしないうちにコンピュータでやらせた方が良いという時代になる訳で、そうなれば人間にやらせる必要はないはず。「標準化」された時点でアルゴリズムにしてしまえば、「標準化」Excelツールは必要ないということです。

で、長くなりましたが、私が言いたいことは、「品質文書を俺のプロジェクトに適用するんだったら、適用される「お客様」の気持ちにたって、創造性を十分に発揮して、こだわりを持った作品に仕上げて、ツールを適用しろ！」ということです。いまどきIT企業がExcelって。。。

電子立国日本の自叙伝

  １０年前くらいに放送されていたNHKスペシャル「電子立国日本の自叙伝」を最近NHKオンデマンドで見る機会があったのですが、その内容が非常に面白かったのでご紹介。

  １９６０年代後半、当時コンピュータといえば、机と同じくらいのサイズが当たり前の状況。日本では「そろばん」という文化があり、世界でも珍しく卓上計算機のニーズが高く、当時の複数の日本大手電機が電卓開発にこぞって乗り出すこととなり、そして日本国内で「電卓競争」が始まる。「電卓競争」が激化する中、計算装置や半導体装置の小型化が進む。そして世界最初のLSIを搭載した小型計算機を「ビジコン」が開発する。だが、厳しい競争に耐えきれず「ビジコン」は倒産。当時「ビジコン」とLSIを共同開発していたIntelが、「ビジコン」から独占販売権と基本特許をそのまま買い取り、Intelが世界No.1の半導体企業として誕生することとなる。

  大学在学中、当時授業を教えてくれていた教授が番組の編集に協力していたことから、この番組を授業で流していたのを思い出す。世界の覇権を握るくらいのイノベーションを簡単に海外に流出させてしまう、当時の経産省を批判していたような思い出があります。Intelの覇権が現在に至っても続いていることを考えると、とんでもない確かにトンでもないことです。

 さて、最近は、原発の事故もあったため、自然エネルギーやスマートグリッドが注目されていますが、それらを実現するための最重要技術が電池・バッテリーと技術となります。一昔前は、そのほとんどが日本メーカで提供されていましたが、これがもう昔の話。今は韓国が１位で２位も中国に奪われています。日本の大手メーカは、バッテリー産業を２１世紀版「産業の米」と捉え、いち早く研究開発費を投入し、また、ハイブリット車などの需要もあったため、バッテリーでは世界のトップを走り続けていました。それが２１世紀に入ると、サムスンがメモリや液晶でやってきたやり方と同じ手法でバッテリー産業に参入してきています。つまり、日本の研究者を高額な報酬で引き抜きを行うアノ手法です。ちなみに、５年ほど働くだけで、日本での一生分の給料となるそうですから、引き抜かれた日本人を非難できないです。

 本来、バッテリー技術者の流出を止めるためには、まず、特定の研究者の給料をあげる等の優遇を行う必要があるわけですが、そんなことは日本企業では難しいのが現実のようです。ちなみにこの話は、私が勤める会社の元副社長がブログで書いていた内容です。元副社長は「日本は妬みの文化なので、このような格差を生むと会社がバッシングを受けるだろう」のようなことを書いてました。なるほど、確かに今のマスコミの報道を見る限りだと、そのように思います。

 「技術立国」だと言われている日本ですが、２つの事例を見返す限り、「技術」を簡単に手放しすぎていると思うわけです。せっかく生まれたイノベーションを上手にオペレーションできないところが日本ってことなんでしょうね。

プログラマー飲み会

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

課題の先送りについて

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

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

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

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

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

プログラミングの心得

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

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

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

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

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

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

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

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

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