CLOSE

プリンシプル・オブ・“ともにつくる”~ Web Performerを支えるドクトリン ~(全2記事)

2020.03.17

Brand Topics

PR

工学の本質は“役に立つ”こと 共創型開発を実現するための6つのドクトリン

提供:キヤノンITソリューションズ株式会社

翔泳社が主催するソフトウェア開発者向けITカンファレンス「Developers Summit 2020」が2月13日~14日に開催されました。プレゼンテーション「プリンシプル・オブ・“ともにつくる”~ Web Performerを支えるドクトリン ~」に登壇したのは、キヤノンITソリューションズ株式会社 アドバイザリーソフトウェアデベロップメントスペシャリストの上田勲氏。歴史に刻まれた賢者たちの言葉を引用しながら、開発者にとっての「プリンシプル」について迫ります。

その他の3つのキーワード

上田勲氏:ここからはワードだけ説明します。

キルケゴールの「絶望」。

これは人間の宿命みたいなものに関するプリンシプルで、人はデフォルトで絶望状態なんですけど、そのために無意識化で不安に苛まれると言っています。なので、それを自覚して、なにか信じるものを外部に作って対策してほしいという内容です。

ユクスキュルの「環世界」。

これは人の認知、認識に関するプリンシプルで、それぞれ個々に見えている世界は異なるので、お互いの異世界を意識して世界をすり合わせていかなければならないという内容です。

最後ですね。ギブソンの「アフォーダンス」。

これは人間の行動に関するプリンシプルで、人間の行為は環境側にある程度規定されるので、人間の行為を設計するときには、環境、コンテキストをセットで考えなければならないというものです。

ドナルド・ノーマンの『誰のためのデザイン?』という名著があって、そこでアフォーダンスをご存知の方もいるかと思うんですけど、こちらのほうがオリジナルで適用範囲も広いので、こちらもおすすめです。

1部はこれで終了になります。2部に入る前に、前提知識として、「Web Performer」という製品の紹介を簡単に2〜3分ぐらいで行います。

Webアプリケーションを自動生成するツール「Web Performer」

「Web Performer」とは、専用のツールでシンプルな設計情報を入力してWebアプリケーションを自動で生成する開発ツールです。Webアプリだけではなくて、周辺の設計ドキュメントやテストケース、バッチアプリ、Webサービスなども自動生成できますし、ワークフローの機能も持っています。

これらのオートメーションのプラットフォームを使って、開発期間を大幅に短縮する超高速開発/ローコード開発を実現しています。また、試行錯誤しやすいという特徴があるので、ユーザーと開発者がともにつくる共創型開発も実現しています。

2005年より発売しておりまして、直近4年ではこの分野ではシェアNo.1を獲得しています。現在1,200社近くにご導入いただいています。

これは実際に生成したWeb画面なんですけど、入力に便利な部品をたくさん揃えていますので、操作性の高い画面を作成することができます。

さらに、歴史もあってかなり多くの機能を持っていますので、グラフ表示、多言語、スマホ画面など、さまざまなニーズ対応できるようになっています。

開発ツールは、Eclipseのプラグインになっていまして、このスプレッドシート的なところで設計情報を入力するようになっています。図は、データモデル、いわゆるDBのテーブル設計の画面なんですけど、実はこのデータモデルさえ作れば、簡単なアプリケーションはすぐに作れるようなツールになっています。

画面については、自動生成に完全に任せることもできますし、右下の図のようなGUIエディタもありますので、直感的にレイアウトを整えることもできます。

Web Performer開発を支える6つのドクトリン

では、ここからはWeb Performerを開発するなかで実際に使っているドクトリンを紹介します。抽象情報を製品開発という具体にどうやって落とし込んでいるかの実例を見てもらいたいと思って、前半のように(スライドを)作ってきたんですけど、時間の関係で全部ワードだけ紹介させてください。

「保守主義」。これはconservativeのほうですけど、バークによると「人間のあらゆる制度の基礎は歴史で、革命的なものは必ず失敗する。よって、歴史と現在を合わせて多数決しなさい」ということなので、我々も製品開発で培ってきた歴史とか良いDNAは変えないで、その上で時代に合わせて進化していくということに注意しています。

「フリクションレス」。これは摩擦ゼロという意味なんですけど、ザッカーバーグが提示したコンセプトで、技術が人になにかを強いることがなくなると実生活に溶け込むということです。我々も開発ツールへの入力というのは宣言型のパラダイムを採用して、ユーザーのやりたいことをストレスなく入力できるようにしています。

「プラガブル」。これはエリック・レイモンドのUNIX思想に多様性の原則というのがあって、これが「唯一の正しい方法はない」という内容なんですけど、これを背景に、自動生成したアプリケーションのほうには、これでもかというほど至るところに拡張ポイントを持つようにしています。

「家具の裏側」。これはジョブズの非公式発言だそうなんですけど、目に見えない部分こそ、クラフトマンシップ、職人魂が出るし、ここで手を抜かないことは結果的に全体の品質を上げるという内容です。我々も、例えばユーザーがぜんぜん見ない自動生成されたJavaのコードにも可読性を持たせるなどしています。

「まなざし」はサルトルですね。サルトルによると、人に見せるという前提が人の行動を変えるので、我々開発チームは、まったく開発しないユーザー専任のロールの人を必ず置くようにしています。

これが最後ですね。「卓越性」、アレテーというものです。アリストテレスによると、人には向いていること・やるべきことがあって、それをすることが人類全体の幸福の最大化につながると言っています。ということで、我々の組織でもキャリアやロールをできるだけたくさん用意して、好きと得意というのをできるかぎり活かすようにしています。

工学の定義は「役に立つものを追究すること」

2部はこれで終了です。最後に、エンジニアの方が多いと思いますので、「工学(エンジニアリング)」というプリンシプルを紹介して終わりたいと思います。

工学の定義なんですけど、科学と対比するとより鮮明になるかなと思います。科学が世界を解明するという方向なのに対して、世界を改善していくという方向が工学になります。要するに、物の理みたいなものを追究するのが科学というのに対して、工学の定義は役に立つものを追究することです。役に立つということが定義に入っている、それだけでも工学もすばらしい活動だなと思います。

工学がなぜ重要かというと、現実と相対しているのが工学だからです。まず、工学は科学とは異なる独自の高度な知の体系を持っています。工学ってたまに応用科学みたいに言われて科学の下請けみたいに言われることもあるんですけど、実は要素還元の手法、科学の手法では手に負えない現実世界の複雑さ、これを複雑系と言ってますけど、に対応するための独自の知恵を持っています。ソフトウェア工学もその1つだと思います。

その知恵を使って、工学は人の役に立つためのハブ&インターフェースになっています。科学や技術、それから数学など、さまざまな要素を設計、デザインという行為で結びつけて、人の役に立つための矢面になっているのが工学です。こう聞くと、本当にプログラミングとかソフトウェアはまさにこれに当たるのかなと思います。

うまく工学していく方法ですけど、自分的にはこれに気づいてできるまでにすごく時間がかかったところなんですけど、「役に立つ」転回。これはどういうことかというと、「目の前の仕事を『こなす』」というところから、「この仕事で『役に立つ』」というふうに視点を転回するという意味です。

これは外向けと内向けの両面効果があると思っていて。外向けの効果としては目線。これは上から目線というわけではなくて、いい意味で目線が上がって全体最適化を考えられるようになりますし、相手目線になれるので目的思考になって、結果的に人を助けることができる確率が上がると思います。

内向きのほうですけど、こちらのほうが大きいと思っていて、なによりそのことが自然で気持ちが楽になるからです。役に立つという行為は、人間の行為としておそらくより自然なほうなんじゃないかなと思っていて、大きな流れに順方向で乗っているかのような感じになって、気持ちが楽になるのだと思います。人類というものが協力とか分かち合って生き残ってきたという経緯も、おそらくその構造の証拠なんじゃないかなと思います。

自分の体験としても、以前大きく体調を崩しちゃったことがあるんですけど、それって今思うと、この流れに逆らって「こなす」というのを続けて、変な姿勢のまま無理していたのが大きな原因だったのかなと、今振り返るとそういうふうに思います。

ただ、ここで「役に立つ」転回というのはいいんですけど、これをするには1つ問題点があるので、次はその解決策の提案です。

「余らせる」という意識を持つようにしてほしいと思います。これ、精神的でも肉体的でも時間的でも金銭的でもなんでもいいと思っているんですけど、余らせてほしい理由は、余ってないと役に立ちにくいからです。

例えば、役に立つための判断って2択だったらたいてい楽なほうじゃない大変なほうを選択することになるんですけど、ただ、現実問題、目の前にやることがあって、進捗ももしかしたら詰められているかもしれないですし、一方で技術の進歩にもついていかなければならない。こういった余裕のない状況の中で、大変なほうを選択するというのは事実上不可能なんじゃないかと思います。本能レベルの判断なので抗いがたい部分かなと思っています。

かといって、余らせるといっても、ともにつくるなかで、人を削って余らせてはいけないと思います。ハーバーマスも言っているように、相手をないがしろに扱って自分を余らせるのは間違っていますし、その逆で、自分を犠牲にして相手とか誰かを余らせるのも正しくないと思います。

余らせてくれる確度の高い手段の1つがプリンシプルです。今日紹介した哲学とか現代思想といったものから、それこそDRYとかKISSとかそういったプログラミングの原理・原則まで、人類の成功パターンとかその逆の失敗の反省みたいなものがたくさん詰まっていて、多くの学びがあると思います。

これを理解して使えるようになってくると、コントロールできる部分が増えてきて、余る部分が必ず出てくると思います。なので、プリンシプルをうまく使って、余らせて、エンジニアリング、役に立つことをしていってほしいなと思います。

以上です。ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

キヤノンITソリューションズ株式会社

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!