【Disc】至上の愛/ジョン・コルトレーン

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

ジョン・コルトレーンの1965年(録音は1964年)のアルバム。ジャズの世界では超メジャーなアルバムです。もう語りつくされているのでしょうが、つい最近ジャズをききはじめた私が、これまでロックばかり聴いていた私がこの偉大なアルバムについて少しだけ触れてみたいと思います。

そもそもジョン・コルトレーンに興味をもつきっかけとなった曲は、Moment’s Noticeという曲なんですが、なんともいえないまばゆい青春のきらめきを放っている名曲です。この曲が発表された当時(1957年)、若者たちはこの曲に、ジャズに夢中になっていた・・・と伝え聞きました。それもわかります。すごくキャッチーな曲です。コルトレーンのテナーサックスも吼えています。

それから10年たらず後に発表されたアルバムが今回紹介するアルバム「至上の愛(A Love Supreme)」です。上で紹介したMoment’s Noticeとは全然違います。1曲が1曲が長いし。組曲なんですね。テーマも重い。くわしいことは知りませんが、コルトレーンの宗教的観念が全面にでたようです。コルトレーンは来日した時のインタヴューで「聖人になりたい(I would like to be a saint)」と言い放った人ですからね。宗教的なアルバムがでてもおかしくありません。

しかし私がこのアルバムに惹かれるのは、そういった理屈を抜きにして、サウンドがもの凄いことになっているからです。はじめて聴いたときは、1曲目の「ア、ラーブ、シュプリーム」という唱和(チャント)の印象がやたら強かったのですが、聴きこめば聴きこむほど、「これはよく構成されたアルバムだな、これはプログレだな」と思ったものです。

このアルバムには、通常盤に、ライブ+別テイク盤を加えた2枚組のデラックスエディションが存在するのですが、これがまた素晴らしいのです。ライブ盤なんて完全にプログレだと思うのです。主役がギターからサックスになっているだけでやっていることはプログレ的だなと思ったものです。組曲にしているくらいですからクラシカルな風味もあり、しかし(特にライブ盤は)ブラックミュージック独特のファンキーなリズムもあり、しかし、どこからどうみてもジャズだというアルバムです。

マイルス・ディヴィスの「KIND OF BLUE」とともにジャズの超名盤として語られることが多いようです。私はもちろん「KIND OF BLUE」も愛聴しています。「KIND OF BLUE」のクールな雰囲気も最高ですが、「至上の愛」がもつ、少しづつ違う世界にとんでいくような、狂気を思わせる楽曲、雰囲気もまた最高です。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

デジタルトランスフォーメーションはシステム開発をどう変えるか

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

これからの、システム開発ビジネスについてふと思ったこと。

*****

普通は、いきなり「システムを開発しよう」と考えるわけではない。最初に、何らかの「目指している状態」や「解決したいこと」があり、そのための手段として「システム」が浮かび上がってくる。

その後で、システムの利用について考える。どんなシステムがあれば「目指している状態」に近づくことができ、「解決したいこと」を解決できるのか? 考えた結果システムのカタチが浮かび上がり、「おー、こりゃあいいぞ」と思えるのであれば本格的にシステム開発に取り掛かることになる。

思い描いたシステムのカタチは、仕様書なり設計書として書き起こす。場合によっては手書きのメモでも構わないかもしれない。全世界で3億を超えるアクティブユーザー数を誇るTwitterも最初は手書きのメモから始まっている(*1)。人は忘れやすい生き物だし、システムのカタチを複数の人で共有し開発するのであれば仕様書なり設計書なりのドキュメントは欠かせない。

で、そのドキュメントを主なインプットとしてソフトウェア、うごくモノをつくりテストする。テストしてはじめて「思った通りに動いてくれない」とか「思った通りに動くけど、何か想像していたのと違う」という事がわかったりもする。思った通りに動くし、想像通り、あるいは想像以上にいい感じになればそこでテストは終わり。あとは実際に使ってみる。

*****

すごく乱暴に言ってしまえば「システム開発」ってこういう事だ。「システム開発」と言っているけれど、その中心にあるのは「システム開発」ではない。「開発したシステムで得られること」にこそが真ん中にあるし、そうでないと意味がない。

「システム開発」は複雑で、その方法もバリエーションに富んでおり、また、知的な行為であるからこそ、多くの労力を注ぎ込むだけの魅力がある(・・・必ずしもそうとは言えないケースもあるが)。それゆえ、ついつい「開発したシステムで得られること」よりも「システムを開発すること」にフォーカスしてしまう。「手段の目的化」というヤツだ。言い換えれば(少なくともその瞬間は)「成果よりもプロセスが大事」という状態に陥っているとも言える。

成果よりもプロセスが大事?

そんなことはない。成果こそが重要だ。もし「プロセスを経ることこそが重要だ」と考えるのであれば、実はそれは「プロセスを経る」ということそのものが「成果」なんだと思う。

この意味で、SIerやITベンダーは真にシステム開発を行うことはできない。今では「外注さん」とか「下請け」という言葉を使わずに「ビジネスパートナー」と呼ぶことが増えてきているが、ビジネスパートナーにはなりえてないのではないか。「ソフトウェア開発能力」を武器にビジネスパートナーとなることと、「ソフトウェア開発能力」を切り売りすることは似ているようで違う。SIerやITベンダーがSIerやITベンダーである限り、永遠にビジネスパートナーにはなれないのではないだろうか。

では「ソフトウェア開発能力」を武器にビジネスパートナーになり得る企業とはどういう企業か?それは、SIerやITベンダー側からみた「ユーザー企業」だと思う。ユーザー企業Aがユーザー企業Bのビジネスパートナーとなり、ユーザー企業Bがユーザー企業Aのビジネスパートナーとなる。

例えば、ユーザー企業Aはマーケティングには強いがソフトウェア開発は苦手だとする。この場合に、マーケティングには弱いがソフトウェア開発を得意とするユーザー企業Bがユーザー企業Aと協力してひとつのビジネスを進める。これこそがビジネスパートナーの関係ではなかろうか。

数年ほど前から「デジタルトランスフォーメーション」といういかにもバズワードっぽい言葉がはやりだしたが、この、「デジタルトランスフォーメーション」が進むと、必ず「ソフトウェア開発能力」に優れた企業(上の例でいうユーザー企業B)が増えてくることになる。こうなるとSIerやITベンダーは永遠に「外注さん」「下請け」に留まってしまうことになりかねない。

「外注さん」「下請け」が悪いといっているわけではない。また、すぐに仕事がなくなるわけでもないと思う。ただ、SIerやITベンダーは気をつけなければならない。「デジタルトランスフォーメーション」が進めば、社会全体で「ソフトウェア開発」の仕事は増えるだろう。しかしその仕事が自分のところに転がり込むようになるとは限らない。先ほどのユーザー企業Bのように「デジタルシフト」を果たした企業が、その「ソフトウェア開発」の仕事を担うようになってくるからだ。ということは、これから先、「ソフトウェアの開発ができます」だけで食べていくのは難しくなるだろう。何か、プラスα、固有の付加価値が必要となる。

<追記>

ユーザー企業が「デジタルトランスフォーメーション」化していく一方で、SIerやITベンダーは「ソフトウェア開発」というデジタルビジネス以外の何かを求めて「アナログトランスフォーメーション」が必要になってくるのかもしれない。冗談みたいな話だけれども。

*1 参考「ツイッター創業物語 金と権力、友情、そして裏切り」

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

なぜプロジェクトはトラブるのか

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

最初に断っておくが、これから書くことは、まったく持って個人の考えであり一般的かどうかは知らない。それでも長年の経験から私はこう考えるようになってきた。

プロジェクトがトラブる原因はさまざまあるが、なんといっても一番の原因はその計画(厳密にはプロジェクト憲章か)にあると思っている。計画が正しいとか正しくないということもあるが、一番はそうではなく、プロジェクトにかかわる人たちのプロジェクト計画に対するスタンスに問題があるような気がしている。プロジェクト計画はチームで動くための約束ごとでもあるし、システムオーナーとの約束でもある。逆にいえば、プロジェクト計画に記載されていないことはする必要もないし、やってはならない。貴重なリソースを別のこと(プロジェクト計画にないこと)に振り向けていることになるからだ。もちろんプロジェクト計画が常に完璧であるということはない。だから、必要だがプロジェクト計画にないこと(タスク)がでてくれば、そのタスクをチームで共有し適切に管理されるべきだと思う。この、一見当たり前のことをやらないから、誰が何をしているのかわからくなるのである。「時間がない、時間がないというが一体何でそんなに時間がないんだ」といことで話を聞いてみると、確かに必要不可欠なタスクを受け持っている。なるほどそりゃー時間ないわな・・・ではなく、計画にAddすべきなのである。それなくてい時間・リソース・課題・進捗を管理できるわけない。こんなごく当たり前の事なのになぜか誰もプロジェクト計画を振り返ることをしない。なぜなのか。思うに人は、自分ですることは自分で決めたいからだと思う。自分以外の誰かが決めた計画に寸分違わず沿って、何日も何日も仕事をするなんて面白いはずがない。だから計画を立てるときは、最初は一人の人でえいやっとつくり、途中、関係者全員に考える余地、意見する余地を与えるべきだと思う。当然、いろんな意見がでるのでまとまるはずはない。しかしそれでもやるべき。その上で、意見を申し立ててくれた人にはケアしながらも、最後は一人で決断すべきだと思う。昔読んだ本に、マネジメントの極意は「衆知を集めて一人で決める」ことであるというような事が書かれてあったように思う。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

アジャイルによるソフトウェア要求の探索についての雑感

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

働く上での目線の違いを表す逸話として、レンガ積みの職人の話があります。1人は「レンガを積んでいる」といい、1人は「壁を作っている」といい、1人は「大聖堂を造っている」といいます。

「いわれたことしかしない」というような指摘は、「あいつは何も考えずにレンガを積むだけで、壁を、ましてや大聖堂をつくっているという意識がない」というのと似たようなものだと思います。

まぁ…わからないではありませんが、これって、経営に行き詰まりつつある経営者が「これからは社員全員、経営者の目線でものごとを考えてほしい」などと言いだすのに似ていますが、本当に全員が100%経営者目線で考えだしたら組織は成りたたないでしょう。全員が同じように同じことを考えるのはやはり非効率な感じがします。

システム開発についてたような事を思いました。

システム開関連本の多くは「どのようにつくるのか?(How)」を中心テーマとしていますが、実際にシステム開発業務に携わっていると、その前に「なぜつくるのか?(Why)」「何をつくるのか?(What)」を強く問われる(あるいは問う)フェーズがあります。

どんなにうまくつくっても、WhyとWhatが的はずれだと、結局は無駄なシステムとなってしまうからです(もちろんその逆でも同じことですが)。

オブジェクト指向+アジャイル開発なんてのは、つくりかた(How)をテーマとしつつも、実はそのつくりかたを実践すること自体がWhyとWhatを探索する方法でもあるんだなと思いました。

WhyとWhatを探索する方法はオブジェクト指向+アジャイル開発だけではありませんし、寧ろ、オブジェクト指向+アジャイル開発だけでは不十分だと思います。しかし同時に、かなり強力な探索方法だとも思います。

そういう意味で、従来型のシステム開発にどっぷり染まっている組織において「オブジェクト指向+アジャイル開発に梶を切る」というアプローチをとっても「あれができないこれが足りない」といってやれ(ら)ない理由が噴出するだけで、実はあまり筋がよろしくないのかもしれません。

そうではなく「オブジェクト指向+アジャイル開発という方法論を(一部)利用する」というアプローチがいいのかもしれません。これは何もソースコードのリファクタリングという局面に限らず、システム構想やシステム企画などの局面を含む話しです。…と、いうわけで、思いつくまま勝手気ままに書き殴りましたが、機を見てこのようなやり方を試してみたいと思います。

おまけ

正直なところ「オブジェクト指向」ってよくわからなかったのですが、私のような非エンジニアにもなんとなくわかった気にさせてくれた本がこちら。オブジェクト指ってよくわからんなーという方には一読する事をおすすめします。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

見積とKKD(経験と勘と度胸)

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

システム構築費用の見積なんて所詮は勘に過ぎません。「見積根拠」なる言葉がありますが、その中身はといえば「A機能の開発に10かかり、B機能の開発に15かかるから、見積は合計で25です」といった具合です。

「ではA機能の開発に10かかるというその根拠は?」と問うと「A機能はA1とA2およびA3という機能から構成されており、一つの機能に3~4はかかる見込み。なので合計して9~12。機能間に類似している箇所もあるのでうまく作って10ってところかな」みたいなやりとりが繰り広げられます。

「ひとつの機能に3~4かかる根拠は?」「過去に似たような機能開発をした経験があるから」「ひとつの機能について更に分解すると参照画面がいくつで云々」というようなやりとりになります。

繰り返し生産可能な物理的なモノであれば、(過去に生産した実績とその時のデータがあれば)「勘」を根拠としない「製造原価」の見積りもできます。しかし「開発原価」の見積もりはそうはいきません。そもそも、過去に作った実績があるのであれば、それは「開発」とは言えません。

情報システム開発とは、その名の通り最初から最後まで「開発」であって、「製造」要素はほとんどありません。あるとすればビルドするという行為が製造に当たります。

そんなわけで、開発原価の見積りはどこまでいっても「勘」にすぎません。その「勘」は「経験」から生み出されます。経験がなければ勘は働きません。その経験をより精緻に活かそうとして機能ごとに分解するなどして見積りを行います。この「分解して見積もる」という行為は、システム開発費用の見積もりに限らず、皆さん普段からやっている事です。

例えば、A地点からX地点までの移動時間を見積もる場合に、ストレートに「A地点→X地点の移動時間」と見積もるよりも、「A地点→B駅」「B駅→C駅」「C駅→X地点」という具合に分解した方が確からしさが増す感じがします。(分解しすぎると逆効果ですが、どの程度分解すべきか?は結局「経験」に基づく「勘」に依ります。どこまでいっても経験と勘です。)

確たる根拠はなく経験と勘で“はじいた”見積であっても、提示したが最後、その見積もりに責任を持たなければなりません。

最後に「この見積もりでいく!」と決めるには「度胸」が必要です。見積もりは「この仕事はこの金額でやってみせます!」という宣言でもあります。

逆に言えば、このような宣言性のない見積もりは見積もりとは言えません。ただの費用試算です。

世の中には様々な見積もり手法がありますが、それらはあくまでも「経験と勘と度胸」をどのように機能させるか?というアプローチの選択の問題です。見積もりは結局「経験と勘と度胸」なのです。その辺りを理解せず、「根拠がない!そんなのただの勘じゃないか!」と声高に叫ぶのは止めたいものです。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る