[レポート]
Developers Summit 2008
〜越境しよう！コードで世界を変えよう！〜
参加レポート
株式会社オージス総研
大村伸吾
去る2月13,14日(水,木)、今年も目黒雅叙園において、ソフトウェア開発者たちの祭典Developers Summit 2008が開催されました。
今年は『〜越境しよう！コードで世界を変えよう！〜』というスローガンのもとに
- 開発プロセス
- これからのアーキテクチャ
- Development Style
- SaaS Development
- プロジェクトマネジメント
といった様々な視点で、日本における各分野のコミュニティリーダー達による熱い講演が行われました。
この記事では、多少偏りがありますが、筆者らが参加したセッションで受けたほとばしる情熱を交えながらセッションの内容をレポートします。
もくじ
- 開発プロセス
- Development Style(Language & API)
平鍋健児氏 / 株式会社チェンジビジョン 代表取締役社長
このセッションでは、まずアジャイルの現状を概説し、
- これからソフトウェア開発はどこへ向かうのか。
- 製造業で大成している事例であるトヨタ生産方式(TPS:Toyota Production System)からソフトウェア開発が学べることとは何か。
- 製造業とソフトウェア産業は直観的には全く異質なものにとらえられるが、よくよく見ていくと深いところでは共通の本質が姿を現す。 TPSに源流を持つリーンソフトウェア開発の本質を考える事でそれが見つかるのではないか。
というソフトウェア開発の未来を一緒に考えることのできる熱いご講演でした。
アジャイルの現状
ソフトウェア開発では、「技術」「プロセス」「人の心」が一体となってソフトウェアを生み出しますが、「人の心」が及ぼす影響は50%だと確信する。その「人」をキーワードにして1990年代にFDD,Crystal,DSDM,ASD,XP,SCRUM等の手法が生み出され、2002年にアジャイル宣言を持ってそれらのキーワードを包括するような"アンブレラワード"としての「アジャイル」が生まれた。それ以降も発展を続けアジャイルの国際会議であるAgile2007では次のようなキーワードが目立った。
- Enterprise
アジャイルを、単なるソフトウェア開発手法からスケール(適用範囲を拡大)させて、いかにして企業全体へ適用するかについてのセッション。
- People
「ソフトは人が人のために作る」。どのように人をサポートしてソフトウェア開発を円滑に進めるのかについてのセッション。
- Test-Driven
テスト駆動開発についてのセッション。
- Lean and Agile
リーンソフトウェア開発とアジャイル開発についてのセッション
また、特徴的なものとしては"ISO9001 and Agile","CMMI and Agile"といった一見アジャイルと相反すると取られがちな標準と呼ばれるものについてもアジャイルは共存可能なのだという意見のセッションもあった。
Agile2007は、1000名以上の参加者がホテルに缶詰めになって、１週間アジャイルについてだけ議論をする会議である。参加者にはGoogle, Yahoo, Salesforceといった大企業や、ユーザ企業の参加者が大多数を占めた。近年の傾向として、次のような事が見えつつある。
- Leanという考え方のおかげでマネジメント層にもアジャイルが浸透しつつある
- 人間系のセッションが非常に充実（コミュニケーション・信頼構築・教育）
- テスト駆動開発技術の大きな発展
- アジャイルをスケールさせるKanbanの可能性(流れの見える化)
- ソフトウェ開発にフィットするリーダーシップ像とは
TPS/Leanとアジャイル
Leanとは、大きく言えば「顧客が定義した価値の流れ(Value Stream)を作り、それをスムーズにムダを抑えた形で流せるような状態を作る」という考え方である。もう少し詳しく言えば
- 投資効果のある、（ビジネス価値）
- ちゃんと動くソフトェアを、(テスト駆動)
- ムダなくつくり、 (MMF: Minimum Marketable Feature)
- 維持・変更し続ける、 (繰り返し開発)
- それを支える「人」が大切。(よりムダをなくすプロセス改善)
これらの考え方はTPSの中にもさまざまな場所に現れている。
分割の仕方(MMFで切る。層で切らない）
Leanの考え方でムダなく作るという観点でいえば、テストされていないコードを作ることはムダだと考えられる。ムダなくValue Streamを作りだすためには機能単位に作るべきである。Leanではそれをもう少し抽象化してMinimum Marketable Feature、すなわち顧客にとっての価値のある最小単位の機能という風に表現している。
これまでは層で切って作られることが多かったが、これからはMMF(機能)で切って作るべきである。MMFごとに作っていけば当然先に作った部品の変更を余儀なくされるが、それをサポートするのがオブジェクト指向、自動テストといった技術なのだ。なので今では「オブジェクト指向」という技術を「変更容易性・テスト容易性を提供する技術」と捉えている。
Mary Poppendick氏も"These days we do not program software module by module; we program
software feature by feature."と言っている。
必要なリーダーシップの種類
ソフトウェア開発におけるリーダーシップの分類として次のようなものが見られる(The Toyota Wayより引用)
|
|
高い管理能力 |
その分野の深い理解 |
|
ボトムアップ |
グループファシリテータ
「皆さんが決めるんです！」 |
学習する組織のリーダー
「これが私たちの目的です。
いっしょに行きましょう！」 |
|
トップダウン |
官僚的管理者
「ルールに従え！」 |
作業管理者
「これがやるべきことです。
この手順に従ってやりなさい！」 |
このうち、「学習する組織のリーダー」タイプが現在のところ一番ソフトウェア開発において「良い」リーダーなのではないかと考えている。
Lean開発の本質
- 「人」が中心となって開発を行う
- ソフトウェア開発の特徴をとらえている。
- エンジニアは大きな絵に参加しなければならない。
受注→納品→運用といった大きな流れにエンジニアは責任を持たなければならない。アジャイルは各工程ごとに離れて立っているサイロのようなものではない。Flatで価値の流れを作りだすものだ。
- 価値を引っ張り出す企業の手法がリーンでありアジャイルなのだ。
片山信昭氏 / 株式会社日立製作所 オートモティブシステムグループ 理事 技術長
200億円〜300億円かかるといわれている新車開発のプロジェクトはどのように行われるのか？何百人、何千人とかかわり、生産開始までに数年はかかるといわれている大規模プロジェクトをどのように成功に導いてきたのか。長年チーフエンジニアとしてそのような新車開発に携わってこられた片山氏がその秘訣を語られました。新車開発のプロセスの概要から、最後には大プロジェクトを率いるリーダーとしての心がまえ、リーダーから若手へ向けたメッセージがいただけました。
新車開発のプロセス(先行開発が鍵を握る)
新車開発のプロジェクトは３つのフェーズ（先行開発、実車開発、生産・販売）に区切って行われるが、プロジェクト全体の成功のカギをを握っているのは最初の先行開発であるといっても過言ではない。このフェーズでは「どんな車を作るのか」という本質的な部分が作られる。このフェーズでは納得するまで何度でも繰り返す。ものづくりの世界では作ってしまってから欠陥が見つかった場合のリスクが非常に高い。紙の上、コンピュータの上で繰り返せることはとことんまで繰り返すことが行われる。専門的にはフロントローディングと呼ばれる。
- コンセプト
- スタイル (エクステリア・インテリアはどんな風にするか？)
- Market Research (通常行うような市場のニーズを調査するのではなく、作成したコンセプトが受け入れられるかの確認のように用いる。
- ユニット先行開発
- 原価・利益の目標値設定
- 開発費・必要工数・設備投資の目標値設定
大規模プロジェクトのマネジメント
企画・コンセプトのマネジメント
- バックボーンの明確化（どうやって売っていくんだ？）
- 明確なアピールポイント（魅力は何なんだ？）
- 完璧な企画を目指す
- 広い視野から複数案を検討する
- 全体をスルーして○×△で評価する
- 見切り発車はさせない
- 先輩等の検証
このようなプロジェクトの重要なファクターとなる先行開発では、通常異なる環境にある複数チームで行われ合格するまで行う。コンセプトを作り上げることは車の印象を作ることであるため作り方にも気を使い、文字だけでなく、視覚的に訴える資料を作成した。コンセプト企画書を作成する段階からデザイン部に背景を頼んだこともあった。
開発進行マネジメント
- 強力な専任リーダーの設定
車体の開発は様々な分野の多様な技術が必要となる。チーフエンジニアが決定のかじ取りをするのではなく、それぞれの分野の専任リーダーに大きな 権限を与える。お互いに尊重する体質を作り、決定の際には組織上の上下関係を無視し専任リーダーとしての決定を尊重することを大切にする。
- 明確なマイルストンの設定
マイルストンを必ずクリヤさせる体質を作ることを重んじる。そしてクリヤさせないと次に行かせないルールも徹底する
- 手遅れにさせない体質づくり
"Bad News First"という風に言っているが、「悪いことほど早く報告する」を徹底する。第３者による検証を行ったり、開発者どうしが本音でコミュニケーションできる風土も大切にする。
- 早期の確実なバックアップ案検討
リソースマネジメント
- 自転車操業に落とし込ませない
開発や開発の質を見える可視、管理することで防止する
- 人数管理からの脱皮
人数によるどんぶり勘定ではなく
- 1.5人×10か月：0.3人×10か月→0.2人差
- 1500hrs: 1300hrs = 300hrs差
という徹底的な数値管理を行う
- プロジェクトのスリム化
製品コストマネジメント
- 原価低減→収益に直結
全部品の原価を一覧にして見える化。原価低減は「聖域なし」と呼ばれるほどに、「誰でも、いつでも」を徹底。全員がちょっとずつ提言すれば全体として大きな低減になることを心に留める。
- データの解析・管理
品質を作りこむためのデータの蓄積・解析を確実に。一歩一歩の積み重ねを図る。
- Value Engineering
会社は技術力そのものである。性能・価格・品質の作りこみはすべて同格である。
- 原価と責任分担
実務と責任がリンクするように徹底。専任リーダーは専任としての決断に責任が。チーフエンジニアであれば役割の割り付けや調整に責任を持つ。 しっかりと各自が自分の責任を自覚するように徹底する。
ベンチマーク活動
日本の製造業では敬遠されがちだが、グローバルに競争力を高めるには必要なことだと考える。
- 敵の戦略を知り、それに勝る製品を開発するために
- コピーするという意識は卒業するように徹底
- 負けているところに注目し、その上を行く製品を作るために
- 開発は数年かかる。その時間差を加味して開発する品質を決定する。
リーダーシップとは
リーダーシップに必要なことは３つあると考える
- 情熱
その開発にかける熱い思いを忘れずに。
- マクロな視点
開発のどんな時にあっても、全体を広く見渡すことを忘れずに
- 組織（チームワーク)
チームワークをいかにみんなが発揮できるようにするか。時には一方に頭をさげ引き下がってもらうくらいの調整が必要だろう。
OBからのメッセージ
これまでのプロジェクト経験を生かして、老婆心ながらメッセージをさせていただく。
できるまで v.s. 締め切り時間までやる
常に十分な時間があるわけではないが
- 「この業務は私がやりました」と胸を張って言えるように。
- 「この仕事は彼がやったんです」と胸を張っていってもらえるように。
大学ノート v.s. 提案書
- 提案書・企画書は相手に読んでもらうもの、説得するものであることを忘れずに
- 仕事をお願いするもの、支援をお願いするものであるのを忘れずに
- なので必ず相手の立場に立って書くこと。関心事は明確に書いてあるのか、専門用語はわかるように書かれているのかを気にかける。
どんな事もあるレベルを超えればきっと役立つ
何事も中途半端は役に立たないものだ。講演だったり、飲み会の幹事だったり、原稿執筆といったこまごまとしたことも何度か経験してくればきっとなにかの役にたつので意欲的に取り組もう。そしてやる時は自分なりに満足いけるレベルまでしっかりやる。そうすればきっと新たな知見・知力・将来に役立つ。ある程度になればきっと相手も認めてくれるから。
戦争をやる人 v.s. 見る人
F1とかラリーとか花形とよばれるようなものは外見はかっこいい。チーフをやってきたときにもチームに入れてくれというオファーは山ほど来る。しかし中でやっている人はみんな戦争をしているかのように必死に頑張っている。あこがれるよりも、今与えられていることをとことんやろう。
気分転換・健康
やはり体は資本である。自分から意識的・意欲的に気分転換をしよう。問題を抱えているときも、一度そこから離れてみる事で糸口が見つかったり、新しいやる気が生まれたりするものだ。
羽生田栄一氏 / 株式会社豆蔵 取締役会長
Java VM言語上で動作する関数型とオブジェクト指向が融合した新世代言語Scala。Scalaの魅力が詰まった贈物のようなセッションでした。
Javaとの融合
- ScalaからはすべてのJavaクラスを簡単に利用可能である
故に膨大なJava,J2EE,JavaME CLDCの資産がすべて、より合理的でコンパクトな形で利用可能。
- JavaからScalaのクラスを呼び出すことも自由（一部制限あり）
- ScalaはJava VM上で実行される
- しかも速い。
- 作者はMartin Odersky教授で、JavacやJava Genericsの開発貢献者であり、Java VMに精通している人間が作っている。
- Ruby, Groovyなどに比べて数倍〜10倍程度高速に動作する。
純粋なオブジェクト指向かつ本格的な関数型言語
- Scalaのデータはすべてオブジェクト。配列・文字列もオブジェクト。
- 関数も全部オブジェクト。なので関数をデータとして自在に操作可能（高階関数、クロージャ、カリー化）
- 演算子などの特殊な処理はなく、すべてメソッド呼び出し。（オブジェクト間のメッセージとして表現)
1+3は1.+(3)という風に"+"というメソッド呼び出しとして解釈される。
この先も安心な開発体制
- Odersky教授は今後１０年間はScalaを開発していくと公言している。
- 開発体系はOdersky教授をはじめ非常に強力なメンバーが集結している。リリースも速いペースで行われており、ドキュメントも近年充実してきている。
- Scala言語処理系は2008年1月現在Scala 2.6.1-final.
Traitによる多重継承が可能(Mixin機能)
- TraitというJavaのinterfaceに似た概念が用いられる。
- Mixin的にTraitを複数組み合わせて多重継承が可能(Rubyのモジュールのように使える)
- インスタンス生成時にwith節を伴ってTraitをMixinすることができる。
DSLとしてのScalaの可能性
- 関数をデータとして受け渡せるので、独自の制御構造を定義できる（例：独自のWhile文を定義可能)
- 使い慣れたリテラルや演算子が使える(+,-,*等といった通常の演算子のオーバーライディングが簡単)
- 暗黙の型変換と呼ばれるものがある。(型変換（キャスト）のための関数をユーザが定義することによって、通常の継承関係によるキャスト可能性以外にも、型どうしのキャスト可能性を定義できる)
- 無名関数(ラムダ式)が書ける。
番外
- 非常に柔軟なリスト構造の処理
- 総称型や型変換といった高度な型処理
- 強力なパターンマッチング機能(case クラスで実現)
- 遅延評価機構がある。
- 構造的サブタイピング（Duck Typing)
- XML操作機能(XMLリテラル、Scla式の埋め込み、DOMツリー操作)
- PEG(Parsing Expression Grammar)とJSONパーサ
- アクター理論に基づく並列性ライブラリ(Ruby のFiberに相当)
- LiftというRuby on Rails風の強力なフルスタックのWebアプリ開発フレームワーク
参考・関連記事
|
© 2008 OGIS-RI Co., Ltd.
|
 |
HOME |
|
TOP |
|
