UML、RUP、Essenceの創設者であるIvar Jacobsonへのインタビュー

UML 、 RUP 、 SEMATの創設者であるほぼ伝説のIvar Jacobsonは落ち着きがなく、ソフトウェア開発業界の秩序を取り戻そうとしています。 そして、質問：「何がそんなにアクティブになり続けるのに役立つのか」という答え：「楽しい！」



サンクトペテルブルクへの秋の旅行の前夜に彼​​がSECRカンファレンスの主催者に与えたIvarとのインタビューの翻訳を読者に提供します。

RUP、UML、 EssUP 、EssWork、SEMATの作成と作成に参加するようになったきっかけは何ですか？

人々がエネルギーを費やし、融合し、昼も夜も仕事をしているとき、私はそれを我慢できないと思います。 そして、私がまだ若いときに最初に変えたのは1967年でした。 私はスウェーデンのエリクソンの非常に重要なシステム開発チームのプロジェクトマネージャーでした。 当時、私たちは最初のコンピュータ通信交換システムを開発しました。



ソフトウェアを開発する既存の方法が不完全であることにすぐに気付きました。 プログラムの1つの大きなリポジトリと1つの大きなデータリポジトリがありました。 これは、常に変更する必要があるシステムを構築するための非常に非効率的なアプローチでした。 そして、今日コンポーネント開発と呼ばれるものを提案しました。これは、相互接続されたコンポーネントを使用してすべてのシステムを構築することを意味します。



このアプローチが受け入れられるためには、人生で最も強い抵抗に直面しなければなりませんでした。 誰もそれを望んでいませんでした。 プログラマーとそのリーダーはそれを好まなかった。 ソフトウェア開発に対する提案されたアプローチを承認したのは1人だけでしたが、それは私たちの上司であり、彼は彼の計画を実行することにしました。 その結果、スウェーデンの歴史上最大の商業的成功を収めました。 ボルボ、ABBAなどよりもさらに成功しています。



それがすべての始まりです。 これらの素晴らしい人々がすべて非効率的に働いていることを見ることができませんでした。 そして同じ理由で、突然ユースケースのアイデアを思いつきました。 要件をいかに不当に扱うかを観察できませんでした。 後で、RUP、そしてUMLの作業を続けました。 この背後には同様の理由があり、一般的なプログラミング方法と実践を探求しました。 13年前にOMG エッセンスの標準になりました。 10年かかりましたが、今日は成功しています。

あなたの意見では、今日のソフトウェア開発の主な問題は何ですか？

最大の問題は、ソフトウェア開発を含む共通理解の欠如です。 商用ソフトウェアの作成方法を十分に訓練していません。 コンピューターサイエンス、プログラミング言語、オペレーティングシステム、基本技術の開発は得意ですが、商用アプリケーションを作成することはまったくできません。 多くの素晴らしい企業が素晴らしい製品を開発しています。 しかし、製品は素晴らしいアイデアと素晴らしい人々の結果であり、ソフトウェア開発の洗練された科学的基盤ではありません。 特に現在、柔軟な方法論の時代には多くの優れた開発プラクティスがありますが、一般的に、それらは堅実な理論に基づいていないため、継続的に改善し、その結果を予測することができます。



人々は世界中でソフトウェアを開発しています。 残念ながら、一般的に品質が悪く、開発に時間がかかり、費用がかかりすぎます。 実際、私たちはあまりにも長い間人々を訓練してきました。有能な専門家などを獲得するのは難しいです。

一番下の行は、ソフトウェア開発やソフトウェアエンジニアリングが何であるかについての共通の理解を持っていないということです。 そして、私の意見では、これは今日最大かつ最も深刻な問題です。 人々は、知識を再利用する代わりに、あまり複雑でも賢くないことでも多くの時間を費やします。 知識の再利用、ソフトウェア開発に必要なものの再利用は、最も欠けているものです。 そしてこれがまさにSEMATコミュニティの主なメッセージです。

SEMATはこれらの問題の解決に役立ちますか？

はい、最初の本当のSEMAT結果は2014年のエッセンスでした。 エッセンスは共通の基盤です。 実行する必要がある基本的なこと、最新のソフトウェアの開発に必要な基本的な能力について説明します。 これは、チームが作業中にプロジェクトの進捗とステータスを測定できる「辞書」です。



現在、この共通のフレームワークは、スクラム、ユーザーストーリー、ユースケース、継続的インテグレーション、マイクロサービス、クラウドテクノロジーなど、多くのさまざまなプラクティスを記述するためのプラットフォームとして使用されています。そして、実践を迅速かつ簡単に記述できる実践を記述するための直感的な言語。 Essenceを使用する別の利点：これらのプラクティスは、方法論に非常に効果的に統合できます。 これは非常に賢明です。今日、私たちには、ほぼ無限の数のメソッドにコンパイルできる何百ものプラクティスがあるからです。



知識の再利用の問題に戻ります。 以前はひどくやっていました。 私たちは人々からアイデアを借りましたが、定評があり、説明がよく、読みやすく、応用できる方法を使用できる共通のエコシステムはありませんでした。 SEMATはこの問題を解決します。 現在、チームと組織が使用できるプラクティスのライブラリを作成し、適切なものを選択して、バランスの取れた作業のためにそれらを組み合わせています。 経験を積んだときに人々がこれを実行し、実践を改善できるツールがあります。 本当に知識を再利用できます！

人生で最も影響を受けたのは誰ですか？

何人かの人々が仕事に関連する私の人生の部分に大きな影響を与えました。



エリクソンの最初のマネージャーであるJan-Erik Nordinは、1964年に、電気機械システム（コンピューター化されたシステムではなくリレーで構築されたシステム）を使用して、物理設計よりも抽象的なレベルで設計について考えるように教えてくれました。 物理的なコンポーネントからシステムを構築する方法、およびコンポーネント間の相互作用[インターフェイス]を決定することがいかに重要かを理解したので、後でコンポーネントを簡単に最適なものに置き換えることができます。 後でソフトウェアに完全に統合されるコンポーネントでこの経験を使用しました。



その後、1978年にコペンハーゲンのDinesBjørner教授に会いました。 彼は、形式的な方法の重要性、特に言語を形式的に定義する方法に私の目を開いた。 私はこの経験をUMLの作業で使用し、最近ではEssenceで使用しました。 抽象構文と静的セマンティクスを正式に定義しましたが、実際的な理由から、操作セマンティクスは英語のみで確実に実行する必要があると感じました。 正式な方法の価値を理解して以来、私は自分がやることすべてに、より正確な思考を適用してきました。これは専門家の間で理解され評価されるのに役立ちます。



最後に、オタワのカールトン大学のデイブ・トーマス教授。 彼のおかげで、私は会社に柔軟な方法論を導入した最初の一人になりました。 これは、メソッドに関する研究を再考するのに役立ちました。 RUPで行ったようにそれらを最終的にしようとする代わりに、最も重要なもの（5％未満）に集中することにしました。 この方法には新しいユーザーエクスペリエンスが必要でした。その結果、カードは練習を表すトランプのサイズになり、わかりやすく使いやすくなりました。 最終的には、チーム自身が独自の方法を簡単に選択できるようにしたいと考えました。これにより、Essenceの基本と実践のライブラリが広く利用できるようになりました。

あなたの主な貢献は何だと思いますか？

それは複雑で、他の誰かが、それについて私があなたに話す必要はありません。 :)



しかし、私はこれを反映しました。 エリクソンは大企業であり、1967年には数百人のプログラマーがそこで働きました。 私は何度も自問しました。「なぜコンポーネントベースの開発を思い付かなかったのですか？ なぜ他の組織を説得してコンポーネント開発を促進する必要があったのですか？ 私が信じていることのためにみんなと戦ったので、私は何が悪いのですか？なぜ私はあきらめなかったのですか？ もし私が降伏していたら、その瞬間には何も起こらなかったでしょう-そして起こっていたでしょうが、その時にはそうではなかったでしょう。 そして再び：「なぜユースケースが私の頭に浮かんだのか、他の人はどうして？ 20年前に最も人気のあった方法論であるRUPを開発したのはなぜですか？」など。 判断するのは難しいですが、コンポーネント開発を導入することがおそらく私がした最も重要なことだと思います。 これは自信と新しいアイデアの出現につながりました。

振り返ってみると、チャンスがあったら何を変えますか？

この質問は、約2000人の聴衆の前で行われた非常に大きな会議で行われました。 これは1995年にアメリカで開催されたOOPSLA会議のパネルディスカッションで行われたようです。 私たちのグループには5〜6人がいましたが、ほとんど誰もが何も変えないと言っていました。 しかし、私に来たとき、私は異なる方法でやらなければならない2つのことがあると言いました、そして私の友人デイブ・トーマスは私に両方に影響を与えました。 デイブと私は田舎の家にいました。デイブは次のように提案しました。「150ページの非常にシンプルな本を書く必要があります。ユースケースについてのみです。 この本は市場のリーダーとなり、誰もが読みたいと思うでしょう。」 そして、私は言った：「いいえ、いいえ、いいえ、いいえ。 ソフトウェア開発は深刻すぎて150ページに収まりません。」 今、振り返ってみると、もちろん、私は彼のアドバイスに従います。



彼が提案したもう一つのこと：「この本で楽器を作りましょう。 私は10万のためにそれをします。」 そして私は答えた：「それはあまりにも単純で、すぐに高度なエンジニアリングであり、高度なツールも必要です。」 そこで、最初のバージョンで約100万ドルかかるツールを開発しました。



これら2つのことは、別の方法で行っていたはずですが、当時はマーケティングが理解できなかったことなどを示していたので、1997年に回答しました。

いくつかの本を書いていますが、新しい本をリリースする予定ですか？ もしそうなら、彼女は何について話しているのですか？

はい、新しい本、Software Engineering Essentializedは、まだドラフト形式です。 私たち4人は約2年間このプロジェクトに取り組み、ロシアを含む世界中から約50人が参加するプロジェクトを作成し、本の教材と演習を開発しました。 今、これらの専門家はそれをチェックしており、彼らのコメントに基づいて更新した後、本は出版されます。 これは、1年生の学生を対象としています。実際のソフトウェアを開発したことはないが、少数の小さなプログラムしか作成していない人です。

SECRでアジャイルとSEMAT-Perfect Partnersについて最後に話したとき。 SECR 2017の予定は？

私の講演は、Kill Methodologies-Free Practicesと呼ばれます。 つまり、「ブランド化された」方法論です。実際、私たちは他の誰かの「ブランド化された」方法論を必要とせず、すでに繰り返し使用されてきた実績から独自の方法を作成する必要があります。

最初のSECR 2005会議を覚えていますか？ もしそうなら、SECR 2013への前回の訪問と比較して印象を共有できますか？

最初の会議は最後の会議とは非常に異なっていたと思います。それはまだ若く、報告は他の国際会議と同じではなく、より「学術的」でした。 2013年の会議は、アメリカとヨーロッパでの大規模な会議に非常に似ていました。 実用的なトピックを取り上げました。 2005年と比較して、開発者にとってより多く、科学者にとってより少なかった。

サンクトペテルブルクに行ったことはありますか？

私はサンクトペテルブルクに何度も行きました。 1961年に初めて！



それで、あなたは都市がどのように変わったかを見ました。



間違いなく。 いろいろな意味で。 私はChalmers Institute of Technologyで学び、3年後、学生旅行に行きました。 通常これらの旅行は南ヨーロッパへでしたが、今年はソビエト連邦へ行きました。 旅行中、KGBエージェントは常に私たちと一緒にいました。 私たちが出会った人々は、後で私たちが議論していたことについて尋問されました。 これが起こるとは信じられなかったので、私たちは非常に興味がありました。 今日、サンクトペテルブルクへの旅行は、ヨーロッパの他の大都市を訪れるようなものです。

あなたは長年にわたって効果的に働いてきました。 あなたの秘密は何ですか？

楽しんでください！ :)



インタビュー：Anfisa Letucheva。

翻訳：Julia Kryuchkova、Anna Gorbatenko（翻訳の訂正は大歓迎です:)。 元のインタビュー： Ivar Jacobsonへのインタビュー 。