ブロックチェーン技術の普及とともに、イーサリアムのネットワーク混雑や高騰するガス手数料が頻繁に取り沙汰されるようになりました。こうした問題を解決するための「Layer2ソリューション」が注目される中、Polygon（旧Matic Network） はイーサリアムとの高い互換性やマルチチェーン対応などを掲げ、高速かつ低コストで大量のトランザクションを処理できる基盤として急速に存在感を高めています。
Polygon公式Wikiにも詳しいドキュメントがある通り、PolygonはPlasmaやPoS (Proof of Stake) ブリッジを活用し、EVM互換を維持しながら拡張性を提供するLayer2エコシステムを形成しています。本記事では、その仕組みからメリット、スマートコントラクトの開発手順、代表的なユースケースまで、総合的に解説します。イーサリアム上での開発・運用を考えている方や、安価で高速なブロックチェーンインフラを探している方にとって、Polygonが一つの有力な選択肢となるでしょう。

Polygonの背景と特徴

イーサリアムのスケーラビリティ問題

イーサリアムは多くのDeFiやNFTプロジェクトを生み出しましたが、その人気の裏返しとしてネットワーク混雑時には手数料（ガス代）が高騰し、トランザクション処理速度も落ちるケースがしばしば起こります。こうしたスケーラビリティの制約を解消し、ユーザーが安価かつ迅速にDAppを利用できる環境を提供することがLayer2ソリューションの大きな使命です。

Polygonとは

Polygon（旧名 Matic Network）は、イーサリアムチェーンと互換性を持ちながら独自のサイドチェーンを運用し、高速・低コストを実現しているプロジェクトです。

• PoS (Proof of Stake) のチェーンを提供し、ブリッジを通じてイーサリアム上の資産やトークンを簡単に移動できる
• Plasmaフレームワークを用いたオプションのセキュリティモデル
• 2021年以降はPolygonという名前で活動の幅を広げ、PoSチェーンに加えてZK RollupやOptimistic Rollupなど複数のソリューションを取り込もうとする「マルチチェーンエコシステム」へと進化

MATICトークン

PolygonのネイティブトークンはMATIC（マティック）。PoSチェーンにおけるガス手数料の支払い、ステーキングによるバリデータのインセンティブなどに利用されます。Polygonネットワークの名称変更に伴ってトークン名を変える話もあったものの、最終的にはMATICが維持され、各種取引所で売買が行われています。

Polygonの技術アーキテクチャ

PlasmaとPoSの連携

もともとPlasmaはイーサリアムで提案されたオフチェーン処理の概念で、「小さなサブチェーン（子チェーン）」を構築し、大量のトランザクションをまとめて証明をイーサリアムに送信するという手法です。
Polygonの初期バージョンはPlasma + PoSのハイブリッドアプローチを採用し、安全性と高スループットを両立。具体的には、イーサリアムのメインネット上にCheckpointを定期的に記録し、PoSチェーンの状態が不正にならないよう保証する設計がなされています。

マルチチェーンエコシステム

Polygonは単なる1つのPoSサイドチェーンだけでなく、多様なスケーリング技術を取り入れる方向へ進化中です。

• Polygon PoS（メインのPoSチェーン）
• Polygon Hermez（ZK Rollupを統合）
• Polygon Miden, Polygon Zero（ZKプロジェクト）
• Polygon Nightfall（Rollup + プライバシー技術）
  開発者は自分のユースケースに合ったスケーリングソリューションを選択し、Polygon上でDAppを構築できるようになるという戦略が打ち出されています。

2層のセキュリティ

PolygonのPoSチェーンではバリデータたちがMATICをステークし、ブロックの提案・検証を行います。その一方でイーサリアム上のRoot ContractがPoSチェーンの最終状態を追認し、もしチェーンが不正に改竄されるならイーサリアムへのメインチェーンにあるセキュリティメカニズムで保護する形となります。
これにより、プルーフ・オブ・ステークでの高速処理と、**メインネット（イーサリアム）**での最終的な安全性というハイブリッドを実現します。

主要なメリットとユースケース

低手数料・高速トランザクション

Ethereumメインネットに比べると、数秒以内のブロックタイムかつガス代が数分の1〜数百分の1という環境が整えられています。そのため、マイクロペイメントやゲーム内トランザクション、多数のNFT発行など小額・高頻度のトランザクションが必要なユースケースに適しています。

DeFiの拡張

多くのDeFiプロジェクト（Aave、SushiSwap、Curveなど）がPolygon上でサービスを展開し、ユーザーはイーサリアムの資産をブリッジしてPolygonで運用することで大幅に手数料を節約できます。トレーダーや流動性提供者が混雑や高コストから解放され、DeFiの流動性が高まる効果が期待されます。

NFTとゲーム

NFTマーケットやブロックチェーンゲームでもPolygonが人気を得ています。メインネットより格段に安い手数料でミントやトレードができ、ユーザー体験が向上。OpenSeaなどの大手NFTプラットフォームもPolygonをサポートしているため、アーティストやコレクターが参入しやすい環境が整っています。

DAOsや支払いアプリ

PolygonのPoSチェーンを使えば、支払いや投票などのアクションを高速・安価に実行可能です。これによりDAOの投票コストが下がり、ユーザーの参加が活性化したり、公共サービスでの実装も検討される動きがあります。

開発の流れ：Smart Contract & DApp

Solidity互換

PolygonはイーサリアムとEVM互換があり、Solidity等で書かれたコントラクトをほぼそのままPolygon PoSチェーン上にデプロイできます。ツールチェーン（Truffle/Hardhatなど）もEVM互換のRPCエンドポイントを指定すればOKです。

Hardhatでの簡易設定例

hardhat.config.js:

require("@nomiclabs/hardhat-waffle");

module.exports = {
  solidity: "0.8.0",
  networks: {
    polygon: {
      url: "https://polygon-rpc.com/", // Matic/Polygon mainnet RPC
      accounts: ["0xyourprivatekey"] // テスト用秘密鍵
    },
    mumbai: {
      url: "https://rpc-mumbai.maticvigil.com", // テストネット
      accounts: ["0xyourprivatekey"]
    }
  }
};

あとは npx hardhat run scripts/deploy.js --network polygon のように実行するとデプロイされます。

ブリッジを利用した資産移動

イーサリアム上のERC-20やERC-721をPolygonに移す場合、公式ブリッジあるいはサードパーティツールを使って資産のロック＆Mintを行います。ユーザー目線では「イーサリアムからPolygonへ送金」のようなUIになることが多いです。

• PoSブリッジ: トークン転送にPoS検証を使う。数分〜数十分程度で完了（場合により異なる）
• Plasmaブリッジ: セキュリティがより厳格だが引き出しに長めのチャレンジ期間がある

コードサンプル：SolidityコントラクトをPolygonにデプロイ

以下の例は、先ほどの Hardhat config を使ってCounter.solを Polygon のMumbaiテストネットにデプロイするイメージ。

contracts/Counter.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Counter {
    uint256 public count;

    constructor(uint256 _initial) {
        count = _initial;
    }

    function increment() public {
        count++;
    }

    function reset() public {
        count = 0;
    }
}

scripts/deploy.js

async function main() {
  const [deployer] = await ethers.getSigners();
  console.log("Deploying contract with account:", deployer.address);

  const Counter = await ethers.getContractFactory("Counter");
  const counter = await Counter.deploy(10); // initial value
  await counter.deployed();
  
  console.log("Counter deployed to:", counter.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

実行:

npx hardhat run scripts/deploy.js --network mumbai

成功すれば、counter.address にコントラクトがMumbaiテストネット上でデプロイされる。あとはPolygonスキャンなどのブロックエクスプローラーでコントラクトを確認できる。

セキュリティとリスク

セキュリティモデル

Polygonはイーサリアムとは異なる独自のバリデータセットがPoSでチェーンを運営しているため、イーサリアム本体ほどの分散性を必ずしも持たない可能性があります。ただし、定期的にイーサリアムのマスター契約と同期することで、不正なチェーン改ざんが起きにくい仕組みを敷いています。
DeFiやNFT等の重要プロジェクトがPolygon上で稼働していることから、ハッキングやブリッジ攻撃などのリスクは常に存在し、セキュリティ監査やコミュニティチェックが不可欠です。

ブリッジ攻撃

過去にはクロスチェーンブリッジがハッキングされ、大量の資産流出が起こった事例が他プロジェクトで報告されています。Polygonでも同様のリスクがあり、ブリッジを利用する際は公式の信頼できるエンドポイントや、しっかりしたマルチシグや監査を受けているサービスを選ぶことが大切です。

中央集権的要素

Polygonが独自のバリデータ選出ルールや管理者コントラクトを持つため、ネットワーク運営にどれほど中央集権が介在するか、コミュニティ内で議論されることもあります。検閲耐性や永久改ざん防止がどの程度保障されるかは、イーサリアムやビットコインと比べると若干異なる評価となるでしょう。

今後の展望

ZK技術への注力

PolygonはPoSチェーンだけでなく、ZK RollupやZK EVMにも積極的に投資しています。ZK技術（ゼロ知識証明）を用いることでプライバシーとスケーラビリティを両立し、より安全かつ高速なブロックチェーンプラットフォームを形成する計画が進んでいます。

マルチチェーン時代との整合

今後、クロスチェーンブリッジやマルチチェーン対応がさらに進む中で、Polygonは**“イーサリアムのインターネットオブブロックチェーン”**を標榜し、さまざまなレイヤー2やサイドチェーンを統合するハブになる可能性があります。
他のLayer2（Arbitrum, Optimism, zkSyncなど）や独自チェーンとの競争・協調関係がどう変化していくかに注目が集まっています。

アプリ連合とエコシステム拡大

Polygon上で稼働するアプリケーション（Aave, QuickSwap, OpenSea, GameFi等）が増加することで、流動性やユーザー基盤が強化され、さらなる開発者や企業が参入する好循環が期待されます。特に大手ゲーム会社やエンタープライズ企業がPoSチェーンを導入するケースも増えれば、多くのユーザーがブロックチェーンを意識せずに使える世界がより近づくでしょう。

まとめ

Polygonは「イーサリアムのスケーリングソリューション」として、高速トランザクションや低手数料を提供しながら、イーサリアムとの高い互換性を保つLayer2/Sidechainプラットフォームです。PlasmaやPoSなどの技術を組み合わせて独自のアーキテクチャを実現し、多くのDeFiプロジェクトやNFTサービスが活用を進めています。

• メリット
  • EVM互換のため開発が容易で、Solidityや既存ツールを活用可能
  • トランザクション手数料が安く、高速処理が可能
  • 大手DeFiやNFTマーケットが次々に参入し、ユーザー体験が向上
• 注意点
  • イーサリアム本体ほどの分散度があるかは議論が分かれる
  • ブリッジ攻撃などクロスチェーン特有のリスク
  • コミュニティ主導やガバナンス強化が進みつつあるが、中央集権的要素への批判も残る
• 今後の見通し
  • ZK技術の採用拡大や複数ソリューションの取り込みで、ハブ的な役割を果たす方向へ
  • マルチチェーン時代に対応し、イーサリアムの主要なサイドチェーンとして位置づけを強化
  • 大規模ゲームや企業導入などのユースケースが増えれば、ユーザー数も急激に伸びる可能性

もしあなたがイーサリアムでDAppを開発中で、高いガス代や遅延に悩まされているなら、Polygonへのデプロイを検討してみる価値は大いにあります。EVM互換によって既存コードをほぼそのまま移植できるうえ、ユーザーはリーズナブルな手数料でトランザクションを行えます。ぜひ公式Wikiや開発者向けドキュメントを参照しながら、Polygonでのスマートコントラクト開発を試してみてはいかがでしょうか。

イーサリアムは、ビットコインに続く第二世代のブロックチェーンとして誕生し、「スマートコントラクト」と呼ばれる仕組みを世界に広めたプロジェクトです。ブロックチェーンが持つ分散型・改ざん耐性といった特性を活かしながら、プログラム可能な仕組みを導入したことで、金融（DeFi）やアート（NFT）、ゲーム、サプライチェーン管理など幅広い領域にインパクトを与えています。
公式ドキュメントでも言及されるように、イーサリアムは単なる暗号通貨プラットフォームではなく、「世界中の誰もが参加し、アプリケーションをデプロイできるグローバルコンピュータ」を目指す壮大なプロジェクトといえます。本記事では、イーサリアムの基本構造やスマートコントラクトの動作原理、開発に必要な言語・ツール、さらにはDeFiやNFTといったユースケースも含め、初心者にもわかりやすく解説していきます。
ブロックチェーンや暗号資産に関心を持つ方、具体的にdApp（分散型アプリケーション）を開発したい方にとって、本記事がイーサリアム理解の一助となれば幸いです。

イーサリアムの概要

ブロックチェーンとスマートコントラクト

イーサリアムは「ブロックチェーンの上でプログラム（= スマートコントラクト）を実行できるプラットフォーム」として登場しました。ビットコインが送金・決済を主な機能としていたのに対し、イーサリアムでは任意のロジックをチェーン上に載せることで、分散型アプリケーション（dApp）を作れるようにした点が最大の特徴です。
スマートコントラクトはブロックチェーン上で改ざん不能な状態で動作し、自動的に条件分岐を行ったり、アセットの移転を実行したりできます。従来のサーバーベースのアプリと異なり、特定の管理者が存在しなくても動き続けるため、金融サービスなどで新しい可能性が切り開かれました。

第二世代ブロックチェーンとして

ビットコインを「第一世代」とするならば、イーサリアムは「第二世代ブロックチェーン」と呼ばれます。以下のような進化が挙げられます。

• チューリング完全なプログラム実行: EVM（Ethereum Virtual Machine）を用い、複雑な条件分岐・計算が可能
• ERCトークン標準: イーサリアム上で独自トークンを発行・管理できる仕組み（ERC-20, ERC-721など）が普及
• コミュニティと開発者: オープンソースのエコシステムが爆発的に広がり、多数のツール・ライブラリ・フレームワークが整備

基本構造：アカウントとEVM

アカウントモデル

イーサリアムは「アカウント」という概念で資産と状態を管理し、以下の2種類が存在します。

1. 外部所有アカウント（EOA）: ユーザーが秘密鍵を持って操作するアドレス。残高（ETH）を保持し、トランザクションを送信する
2. コントラクトアカウント: コードとストレージを持つアドレス。スマートコントラクトがデプロイされる場所。EOAからの呼び出しやコントラクト間呼び出しで動作し、内部にstateを保持可能

EVM（Ethereum Virtual Machine）

イーサリアムのトランザクションが実行される際、EVMがバイトコードを解釈し、ガスコストに基づいて命令の実行を進めます。ハッシュ関数や算術演算、外部コールなど多数の命令が用意され、スマートコントラクトのあらゆる動作がEVM内部で再現される形です。
EVMはスタックベースのマシンであり、Solidityなどの高級言語がコンパイルされたバイトコードを読み取り、分散合意下で状態を更新する設計となっています。

ガスと手数料の仕組み

ガスとは

イーサリアムでスマートコントラクトを実行する際、計算やストレージ操作に応じて「ガス」という単位が消費されます。トランザクションを送信するユーザーは、gasLimitを設定して最大消費量を制限し、かつgasPrice（または EIP-1559導入後は baseFee + priorityFee）を指定して手数料を支払う形になります。
もしトランザクション実行中にガスが尽きれば、「Out of gas」エラーでロールバックされる仕組みです。こうした設計により、ブロックチェーン上でのリソース浪費（無限ループやスパムなど）を防いでいます。

EIP-1559とベース手数料

EIP-1559 で導入された手数料メカニズムでは、baseFeeがブロックごとに自動調整され、ネットワーク混雑時には値上がりし、空いているときは値下がりする仕組みになりました。さらにpriorityFee（tip）をマイナー（またはバリデーター）へ渡すことで、取引を優先してもらうことが可能です。
ガスモデルは複雑に見えますが、要するに「トランザクション実行にはリソースが必要で、それに応じたコストを支払うことでネットワークをスパムから守る」という理念がベースにあります。

スマートコントラクトの開発フロー

Solidity言語

現在最も一般的なイーサリアム向け言語はSolidityです。JavaScriptやC++の要素を取り入れた文法で、static typedかつEVMに最適化されています。以下はSolidityで書いた簡単なコントラクト例です。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Counter {
    uint256 public count;

    constructor(uint256 _initial) {
        count = _initial;
    }

    function increment() public {
        count += 1;
    }

    function reset() public {
        count = 0;
    }
}

• constructorはコントラクトの初期化処理。_initialの値をcountに格納して初期設定
• increment関数を呼ぶとcountが1つ増える
• reset関数でリセット可能

このシンプルなコントラクトをEVMバイトコードにコンパイルし、ブロックチェーンにデプロイすれば動的な状態管理が可能になります。

開発ツール: Hardhat / Truffle / Foundry

開発者は主に以下のようなツールを利用します。

1. Hardhat：JavaScript/TypeScriptでテストやスクリプトを記述しやすく、プラグインが豊富
2. Truffle：古参のフレームワーク。truffle initでプロジェクトを作り、truffle compile, truffle migrate, truffle testなどのコマンドで開発できる
3. Foundry：Rustに影響を受けた高速ツール。Solidity専用のテストフレームワークやデプロイ機能を備えている

これらのツールでテストネット（Ropsten, Goerli, Sepolia, etc）へデプロイし、動作確認やユニットテストを行い、本番ネットワークへのデプロイを準備します。

dAppとインタラクション

Web3ライブラリ

フロントエンド（webアプリ）がイーサリアムのスマートコントラクトと通信する場合、web3.jsやethers.jsなどのJavaScriptライブラリが広く使われます。ユーザーはMetaMask等のウォレットを介してトランザクション承認を行い、RPC経由でネットワークとやりとりします。
以下は ethers.js でシンプルにコントラクトを呼び出す例です。

import { ethers } from "ethers";

async function callContract() {
  const provider = new ethers.providers.Web3Provider(window.ethereum);
  await provider.send("eth_requestAccounts", []);
  const signer = provider.getSigner();

  const contractAddress = "0x1234..."; 
  const abi = [...]; // コントラクトのABI
  const contract = new ethers.Contract(contractAddress, abi, signer);

  const tx = await contract.increment();
  console.log("Transaction sent:", tx.hash);
  const receipt = await tx.wait();
  console.log("Transaction confirmed:", receipt.blockNumber);
}

• provider: ノード（またはMetaMask）へのRPC接続
• signer: ユーザー秘密鍵を持ち署名できるオブジェクト
• contract.increment()で実際にスマートコントラクトを呼び出す

フロントエンド + スマートコントラクト

多くのdAppはReactやVueなどのフロントエンドフレームワークと組み合わせ、ユーザーがボタンクリックやフォーム送信を通じてトランザクションを送信したり、コントラクトの状態を表示したりします。ブロックチェーンならではの特徴として、サーバーサイドを持たずにクライアント・分散ネットワーク構成をとることも可能です。

ユースケース：DeFi, NFT, DAOなど

DeFi (分散型金融)

イーサリアム最大の成功事例ともいわれるDeFiは、貸し借りプロトコル（Aave, Compound）、分散型取引所（Uniswap, SushiSwap）、**ステーブルコイン（DAI, USDCなど）**などが代表的です。スマートコントラクトが資産を自動管理し、中央の銀行や取引所を介さずに大規模な金融サービスを実現できる点が特長です。

NFTとデジタルアセット

ERC-721規格などを通じてNFT（Non-Fungible Token）を発行し、アートやゲームアイテム、メタバース資産をオンチェーンで表現する動きが盛んです。「CryptoKitties」や「Bored Ape Yacht Club」など、有名プロジェクトが大きな注目を集めています。NFTは唯一性を示すための仕組みとして、イーサリアムが最も活用されている分野のひとつです。

DAO（分散型自律組織）

イーサリアムがもたらす「誰もが参加でき、透明性のある投票や資金管理」が可能な組織形態としてDAOが登場しました。トークン保有者が提案や投票を行い、結果をコントラクトが自動で執行することで、トップダウンの指揮命令体系を排した組織運営を実現します。
この仕組みによりコミュニティが資金をプールし、共同でプロジェクトを立ち上げたり、クリエイティブ活動を支援したりと、多彩な試みがなされています。

イーサリアムの課題と拡張

スケーラビリティとガス高騰問題

イーサリアムはPoWからPoSへの移行（The Merge）を経て、エネルギー消費を大幅に削減しましたが、オンチェーンのスケーラビリティはいまだ課題です。混雑時にはガス価格が高騰し、一般ユーザーが小額取引を行うのが困難になることも。
これに対し、レイヤー2（Optimistic Rollup, ZK Rollupなど）やシャーディングが計画されており、将来的に大幅なTPS向上が見込まれています。

レイヤー2（L2）ソリューション

レイヤー2は、主にオフチェーンの処理やRollup技術で多量のトランザクションをまとめ、最終的な要約をメインチェーンに書き込むアプローチです。ArbitrumやOptimism、zkSyncなどが代表的で、EVM互換を維持しつつ手数料が低いDApp開発環境を提供しています。

セキュリティとユーザビリティ

Solidityのコントラクトはパワフルな反面、Re-entrancyやOverflowなどの脆弱性が存在し、過去にも多額の資金流出事件が起きています。開発者や監査会社がセキュリティツールやベストプラクティスを整備し、ユーザーが慎重にプロジェクトを選べるようになってきたとはいえ、依然として注意が必要です。
また、ウォレットの秘密鍵管理やガス代の仕組みなど初心者にはハードルが高く、ユーザビリティの向上も大きな課題として残っています。

今後の展望

イーサリアム2.0とシャーディング

イーサリアムはThe MergeでPoSへの切り替えを完了し、次なる段階としてシャーディングなど大規模アップグレードが計画されています。シャーディングによってチェーンが分割され、データハンドリングや検証を分担することで、ネットワーク全体のスループットとコスト効率が向上すると期待されています。

マルチチェーンと相互運用

DeFiやNFTがマルチチェーン化する流れの中で、イーサリアムがマルチチェーンの中心として機能する可能性が高いです。ブリッジやクロスチェーンソリューションが成熟すれば、イーサリアムの資産やNFTを他チェーンで利用したり、逆に他チェーンのトークンをイーサリアムDeFiで活用するなど、相互運用がより活発になるでしょう。

RollupやZK技術の普及

ZK-RollupやOptimistic Rollupがさらに発展すれば、レイヤー2上で多数のトランザクションをまとめつつEVM互換を保ち、実用的なdApp体験を提供できるようになります。これがグローバルスケールのサービス（SNSやゲームなど）にも対応できる道を開くと考えられています。

まとめ

イーサリアムは、ブロックチェーンを単なる送金だけでなく、汎用的な分散コンピューティングプラットフォームに進化させた先駆的プロジェクトです。EVMという仮想マシンを通じてスマートコントラクトを動作させ、DeFiやNFT、DAOなど多彩なユースケースを生み出しました。

• 特徴
  • EVMによるチューリング完全なスマートコントラクト実行
  • ガスモデルによってリソース乱用を防ぎ、トランザクションごとに手数料を徴収
  • 大規模コミュニティ・ツール・フレームワークが揃い、開発しやすい環境
• 開発フロー
  • SolidityやVyperでコントラクトを記述
  • Hardhat/Truffle/Foundryなどのツールでコンパイル・デプロイ・テスト
  • フロントエンドからweb3/ethers.jsでコントラクト呼び出し
• 課題と展望
  • スケーラビリティの不足をレイヤー2やシャーディングで解決へ
  • セキュリティとユーザビリティの向上が依然として重要
  • マルチチェーン化やZK技術など革新が続き、より幅広い分散アプリに対応

イーサリアムは暗号資産やブロックチェーンの世界を一変させた存在であり、今後もさらなるアップグレードや周辺技術の成長によって「分散型の世界コンピュータ」としての地位を確立していくでしょう。DeFiやNFT、DAOといったキーワードをきっかけに、イーサリアムが実現する次世代のインターネット（Web3）の姿を追いかける価値はますます高まっています。もし開発を始めたいなら、SolidityチュートリアルやHardhatなどのツールから入門し、公式ドキュメントやコミュニティリソースで最新の情報をキャッチアップするのが近道です。

　本記事では、オーストラリア出身で「経営学の父」とも言われるピーター・ドラッカーのマネジメント論をシステム開発に置き換えてみると、どんな効果が得られそうかを考えてみた記事です。ドラッカーは経営を主軸においていますが、経営とシステムは現代では切ってもきれない関係になっており、開発プロジェクトが頓挫すれば経営も傾いてしまう状態の会社もたくさんある。

　ベンダーやユーザーと言えどもあらゆる会社でソフトウェアやハードウェア、クラウドが開発・利用されていることを背景に、ドラッカーのマネジメント論を応用することでシステム開発を上手くリードすることが出来るのではないかと考察してみたい。

本記事の読み方

　ドラッカーはマネジメントを「組織に成果をあげさせるためのもの」と定義している。システム開発で言えば、プロジェクトそのものが組織に値し、開発プロジェクトの目的はQCDのバランスを考慮し、高品質なシステム・サービスを作り上げることが使命である。

　本記事ではドラッカーが組織を如何にマネジメントするかを、プロジェクトに置き換えて考えてみることにする。※本記事は下記の本を参考にしています。

開発プロジェクトのマネジメント

　ドラッカーのマネジメント論を開発に置き換えて見ると、プロジェクトをマネジメントをする上で最も大切な要素は次の3要素である。

プロジェクトの使命

　ドラッカーはどんな組織(政府や組織、教育機関、企業)であっても使命が大切で、誰かのニーズを満たすために存在していると論じている。

　開発プロジェクトも同様で、使命なきプロジェクトを完遂することなど不可能であり、システムやサービスは誰かに利用してもらうために開発プロジェクトが存在すると考える。本来プロジェクトでは特定の個人が、一時的な期間を伴った共通の目的のために存在しているものであり、ゴールに到達すれば解散するというのがプロジェクトの本質である。

　皆さんも、「このプロジェクトは何のためにやっているのだろうか」と思ったことはないだろうか。これはプロジェクトが存在する意味（使命）が伝達されていないか、そもそも明確に決められていないことが多く、このようなプロジェクトは大抵炎上している。少なくともプロジェクトをマネジメントする場合には、ドラッカーが掲げる5つの質問に答えられないのであれば、プロジェクトとして成り立っていないので、見直す必要があるだろう。

　ここで注意しておきたいと思うのが、「④　われわれにとっての成果は何か？」である。短期的に見ればシステムを納品することが成果になってしまうが、そうなってはいけないと考えている。他の問にもあるように、開発プロジェクトの目的は常に顧客（ユーザー）目線で、価値を提供することにあり、開発することが目的になってしまうことは避けたいところである。

プロジェクトの生産性

知的労働社会

　現代では1900年代の大量生産社会と違って、大量に同じものを作っても売れない。既に世の中にモノは溢れかえっている。そして2000年代には知的労働社会になり、単純に作って売るというビジネスモデルから、労働者の知識を活用して各企業独自の製品やサービスを作っていくことが必要である。

　最近ではアウトソーシングや副業なども流行ってきており、ますます個々人が持つ専門性に焦点が当てられている。また、大量生産社会では企業が生産設備を持ち、労働者はそれを利用することでモノを作っていたが、現代では専門性を持つ労働者達そのものが生産設備を所有していることと同等になっている。そのため、専門性を持つ方たちは生産設備を「移動」することが簡単になっている。

　このような時代に大事になってくるのは、専門性を持つ人達を如何にマネジメントして生産性をあげていくかということになる。ドラッカーは生産性向上のための条件を6つ定義している。

変化をマネジメントする

　知的労働社会では知識が生産設備となるため、常に知識をアップデート（変化）させていくことが必要になる。これは個人の労働者だけでなく企業も同様。ドラッカーが推奨している方法として、「体系的破棄」というものが存在する。

　これは、全ての仕事や作業を実行していないと考え、その上で今からでも実行するかと問い、「ノー」ならば破棄するという考え方である。プロジェクトを始めると報告のための資料作りや、大した意味もない進捗会議などあるのではないだろうか。プロジェクト開始直後であれば必要であったものでも、必要がないものはどんどん破棄していくことが必要だ。

　この考え方と似ている開発手法としてアジャイル開発/スクラム開発というものがある。アジャイル開発は簡単に言えば必要な要件を優先度を上げて開発し、常にリリース可能なシステムを開発していくことである。スクラム開発はアジャイル開発手法の一つであり、決定しない要件に対して柔軟に変更を加えていくことで、よりユーザーのニーズに合った開発をしていくことが可能になる。詳しい説明は下記を参照してください。

最近注目のスクラムによるアジャイル開発とは？メリットは何？

スクラム開発はユーザーのニーズが目まぐるしく変わる現代では、アジャイル開発とセットで用いられることが多い開発手法です。スクラムを導入することで強固で柔軟なチームを作り上げることが可能です。

techgrowup.net

強みにフォーカスする

　プロジェクトを複数メンバーで行っていれば、各個人によって「強み」「弱み」が出てくるだろう。ただ、この時に「弱み」に着目して克服しようとしないことが知的労働者会では重要になってくる。日本の教育制度だと受験などもあってか、弱い教科を重点的に克服することを求められるため、弱みを克服させようとする会社は多い。

　一方ビジネスでは、より専門性を持ったビジネスモデルや企業が勝つことは明確になっている。アップルでは従来コンピュータのハードウェアを製造していたが、中国などが台頭してきてからは撤退をしている。アップルでは製造は弱みだったからだ。

　開発プロジェクトでも同じで、各エンジニアに弱みを克服させようと無理に強いることは辞めておきたい。例えば、開発・実装が得意で管理が苦手なメンバーに、管理業務を割り当てることは必要ない。それならば管理が得意なメンバーに任せれば良い。ただ、1点注意しておきたいのは、その「弱み」によって「強み」が阻害されている場合は、早急に克服させるべきだろう。

プロジェクトの社会的責任

　ドラッカーは企業が果たすべき最も重要な社会的責任とは、特定の社会目的の達成、つまりは使命の遂行と論じている。これをプロジェクトに置き換えて考えてみると、少し大袈裟な感じもするが、プロジェクトにも必ず使命が存在し、その使命が社会的責任に繋がっていることは間違いない。

　現在日本では老年人口（65歳以上）が増え、生産年齢人口（15〜64歳）が減り続けている。2065年には生産年齢人口は現在の60%程度から50%程度まで減少し、人口全体では9000万人近くまで減少すると見られている。

　こうした中で1プロジェクトが社会的責任を負うというのは中々考えづらいところではあるが、製品やサービスを開発することで顧客（ユーザー）を想像し、ひいては経済的発展につながるということを考えれば、製品を生み出すことへの責任と、将来に対する責任を持つと言えるだろう。

　前者については言わずもがなで、新製品を作り経済を回していくことで社会に対して何らかの貢献ができることはイメージできる。後者については、例えば選挙における投票システムを開発したとしよう。日本が抱える人口減少による生産労働人口の減少を考えれば、現在のような投票所を運営していくことは到底困難になるとともに、投票システムが存在することで将来の労働者は、より専門的な仕事を行うことが出来る。こういった側面を考慮すると、将来の社会問題に対しての社会的責任を負っていると考えられる。

顧客（ユーザー）とは誰か？

　何度か顧客（ユーザー）という言葉が出てきているが、これをもう少し深堀りしてみよう。顧客にはシステム・サービスと直接している想像しやすい顧客と、潜在的な顧客がいると考えられる。ベンダー企業であれば目の前にいるクライアントが顧客になるだろう。ユーザー企業であればシステム・サービスを利用してもらうインターネットを介したユーザーかもしれない。

　しかし、実際には想像しやすい顧客（ユーザー）だけでなく、潜在的にいる顧客（ユーザー）を見落としてはいけない。例えば分かりやすい例で言うと、認証システムを伴った経理システムがあるとする。経理システムそのものは依頼元のクライアントが利用するためのシステムなので顧客（ユーザー）はクライアントになるだろう。

　一方認証システムのみが欲しい潜在的な顧客も存在するかもしれないという前提に立てば、認証基盤はベンダー企業で所有し、その上に経理システムをサービスとして乗せることで、潜在的に認証システムのみを利用したい顧客に別サービスをコストを下げて再開発することができる。いわゆるシステムの再利用性と言われるものだ。エンジニアだとライブラリなどがそれに値するだろう。こうした顧客を見落とさず、我々の顧客は誰になるのかということを本質的に考える必要がある。

まとめ

　今回は、ドラッカーのマネジメント入門を軸に、経営・企業マネジメントを流用して開発プロジェクトに応用できないかと考察してみました。少々強引な部分はあると思いますが、現代では開発プロジェクトそのものがビジネスになり得るケースが大半を占めており、活かせる部分は大いにあると思います。

　特に、プロジェクトの使命を考えることは最も大事なことがだと考え、企業が存在する意義からブレークダウンし、「なぜこの開発プロジェクトが必要なのか」ということを明確にした上で、プロジェクトを始めることが成功に繋がる大きな要因であることは間違いないと思う。

　一方実際に開発を行っていく上では、使命があるだけでは不十分で、アジャイル開発/スクラム開発のような具体的な手法を活かしていくことも必要だと考えます。下記にスクラム開発においてのアンチパターンを書いていますので、開発を行っている方はぜひ見ていただきたいと思います。

スクラム開発の半数が失敗？　失敗させるプロセスアンチパターン１０選

アジャイル開発手法の１つであるスクラム開発では、ソフトウェア開発を柔軟に正確に進めることを可能にします。一方間違った方法で行っていれば、上手く行きません。そんな失敗するパターンを10選まとめました。

techgrowup.net

　最後に、オススメのドラッカー書を紹介して終わりたいと思います。