Fujitsu Software Interdevelop Designerに関する日経記事がきっかけで、という訳でもないのだけれど、コーディングという行為について、コードを書いたことがない素人が思うことを。
基幹業務を対象に、一定の日本語書式で作成された設計書からプログラムを自動生成するソフトウェアで、システム開発費の4割を占めるプログラミング費用が不要になるという日経記事は、様々な意味で反響があったようで、ざっと検索した限り、概ねネガティブな評価が多いようだ。テストデータの生成も可能といった点をポジティブに捉えたコメントも一部あるものの、「設計書作成が実質的にプログラミングと変わらない」、「この怪しいツールの後始末で大量のSEが泣かされる」といった酷評が総じて目立っている印象だ。まあでも、それ自体はどうでもいい。考えたいのは、このツールの実用性ではないからだ。そんなものは、1年もすれば歴史が証明することになるのだから。
俺が思うのは、それでも「コーディングレス」というのは1つの志向性であり続けるのかなということだ。イノベーションは、往々にして非効率や不便、あるいは素人からみた困難や分かりづらさが起点となって生まれる訳で、現在のシステム開発における「コーディング」という行為に、イノベーションの種がないとは思えない。一方で、コードがビジネスをある程度まで規定するようになっている昨今、業務ニーズと戦略さえあれば、コーディングレスでアプリケーションを作成できる世界というのは、ITの理想郷として、ずっと存在するのかなという気がする。その実現が、数年後なのか、十数年後なのか、あるいは数十年後なのかは分からないけれど。
でも、ここでもう1つの観点が頭をもたげてくる。
日経のヘッドラインは、プログラマーという職種の今後にどこか消耗戦の雰囲気を想起させたけれど、どちらかというと、プログラマーの重要性は今後むしろ高まっていくのではないだろうか。いや、こう書くとやや誤解を招くかもしれない。より正確には、ハイスキルなごく一部のプログラマーの存在感が、（この世界における）他の職種を圧倒していくのかなというのが、なんとなく感じていることだ。
コーディングレスといっても、バックエンドでコードを自動生成する訳で、誰かがコードを書いているという事実は変わらない。コードを自動生成するためのコードを、より高い次元で、より生産的かつ効率的な方式で、より美しく、より汎用的に書ける人間がどうしても必要になってくる。宇宙の果てを考えると、果ての先が分からなくなるのと同じように、コーディングレスの世界を考えていくと、バックエンドに不可知の領域が横たわっているのは当然で、あまりにこの志向性が強くなりすぎると、最終的にはバックエンドを司る人間が、かなりのパワーを持つことになるような気がしないでもない。
そういえば先日、ある業界イベントで"Infrastructure as a Code"という考え方について、40分ほどの講演を聴いてきた。オープンソースの構成管理ツールであるShefを活用して、システム基盤をソフトウェア的に管理するというものだ。Shefでは、Recipeと呼ばれる基盤の構成情報をRubyプログラムで記述して、サーバーに自動実行させるのだけれど、プログラムに管理させるということは、プログラムの品質が管理品質に直結するということだ。まあ、俺自身はエンジニアでもないので、そこに求められるプログラムのレベルもよく分からないけれど、Shefに限らず、ソフトウェアで諸々の挙動が制御されていく世界では、機能的に（そしておそらくは、それ自体としても）美しいコードを書ける本物の職人が、極めて重要になっていくはずだ。
Fujitsuの取り組みがどう転ぶかは、静かに見守っていればいい。
でも、コーダーは大切にした方がいい。少なくとも、世界を握るかもしれない特別なコーダーと、その卵のことは。
Sunday, August 31, 2014
Wednesday, August 20, 2014
『The DevOps』、水天宮前を歩きながら。
朝。地下鉄に揺られて会社に向かい、水天宮前で降りるといつもの光景が待っている。
改札を出て比較的長めの動く歩道を越えると、必ずぶつかるのが渋滞だ。そこから先、4B出口までの階段が狭すぎてボトルネックになっている。そんな訳で駅員さんは毎朝、動く歩道の終端で通勤者を誘導している。「申し訳ありませんが、左側に大きく迂回ください」って。終端付近で渋滞してしまうと、動く歩道から降りられず危ないからだ。
でも、ダメなんだよ。毎朝、心の中でひとり呟いてしまう。
出口では解決しないんだ。動く歩道の入口をコントロールして、流量制限しないと。階段幅は、急には広がらないのだから。
さて、本書だ。
書評を書くのは随分久しぶりだが、個人的になかなか興味深かったので紹介したい。
パーツ・インターナショナル社の社運を賭けた新システム開発、「フェニックス･プロジェクト」をめぐる幾多の困難を、新任VP(Vice President)としてIT運用を担うビルが乗り越えていく物語。有名な『ザ･ゴール』（エリヤフ･ゴールドラット著）のシステム開発版と思ってもらえば、ほぼ問題ない。ITプロジェクトにまつわる典型的な問題を、小説という形式の中でデフォルメすることで、分かりやすい形で提示した著作だ。それでもIT特有の用語が多く、業界関係者でなければ読みづらい部分はあるかもしれないが、一方で、システム開発に携わった経験がある人間にとっては、楽しく読める内容になっていると思う。ちなみに、書店で見かけて購入を決めた理由の1つは監修者だ。個人的にもお世話になっている榊原彰さんと来れば、買わない訳にはいかない。それにしても、こうした著作の監修までされているのには少々驚いた。
この形式の先駆的著作といえば、やはりなんといっても『ザ･ゴール』なのだが、本書のストーリー自体においても、『ザ･ゴール』でエリヤフ･ゴールドラットが提示した制約条件理論が、その中核となっている。主人公のビルにとっての事実上のメンターとして、彼を成功へと導くエリックは、「4つの仕事」、「3つの道」というフレームワークを道標として、プロジェクトにおけるボトルネックを見極め、適切にコントロールすることで、スループットを最大化させるために示唆を与えていく。詳細は本書を読んでもらいたいが、極めて合理的な考え方だと思う。『ザ･ゴール』の制約条件理論が、必ずしも工場の製造工程だけに該当するものではないのは、まったくもって自然なことだ。システム開発を工場とのアナロジーで考えるのも、目新しいアプローチでは決してなく、極めてオーソドックスなものだと思っている。その意味で本書の価値は、理論的な側面からの斬新性にある訳ではない。どちらかというと、エンターテイメント性と分かりやすさだろう。
ただ、本書を読んでいて、改めて考えてしまった。
ゴールドラットの制約条件理論がシステム開発にも十分に適用できるように、システム開発における改善アプローチは組織運営全般にも適用できるのではないかと。
この物語が提示する課題認識に共通するものは、日常の中にいくらでも感じ取ることができる。ボトルネックに手をつけなければ、それ以外の部分をどれほど改善してもスループットは上がらない。一方で、特定のワークセンター（あるいはキーパーソン）がボトルネックとなる理由の一端は、「自分がいなければ廻らない状況」を彼ら自身が（意図的かどうかは別として）作り出してしまっているからだ。ボトルネックのリソースは、徹底してスループットを最大化するための活動に費やされなければならない。どれも、至るところに転がっている話じゃないか。開発じゃなくても、たとえば営業活動でも同じように。
本書の主題はシステム開発プロジェクトであり、この流れの中でキーワードとなるのがDevOpsだ。Dev(elopment)Op(eration)s、つまり「開発と運用の一体化」だ。もちろん、曲がりなりにもこの業界で仕事をしている1人として、DevOpsというコンセプトには非常に興味を持っている。「IT業界ではお馴染みのバズワードじゃないのか」といった向きもあるのもしれないが、とやかく御託を並べるのは一旦先送りにして、素直に乗っかってみたいと個人的には感じている。理由はシンプル。それが本質的にはプロダクトでもテクノロジーでもなく、「人間のふるまい」にフォーカスしたコンセプトなのかなと思うからだ。結局のところ、人間が一番面白い。いつだって、中心にあるのは人間そのものだ。
ただ、本当に考えたいのはDevOpsというよりも、"Something like DevOps"なのかもしれない。
組織で生きている以上、組織を考えない訳にはいかないからね。水天宮前の階段のように、解消できないボトルネックばかりではないはずだ。
Subscribe to:
Posts (Atom)