製品や開発に関する記述
開発ストーリー
経本職人さんの伝統の技とノウハウ
＜記入日：2017.04.21＞
和紙は、蛇腹折りの強度を確保する上で秀でていますが、閲覧用途の経本と異なりシャープペンシルなど（ペン）での筆記用途としては不向きです。
一方、ペンでの筆記に適した洋紙を前提とし、使用頻度の高い手帳としての耐久性を確保するためには、蛇腹折りの用紙には相応の厚さや密度が求められます。ところが、それらが増せば折り加工の難易度が増すという矛盾が生じてしまいます。厚く密度の高い用紙の場合は元に戻ろうとする力が強い分、特に折り山の数が多い蛇腹折りでは、折りっ放しの仕上げ方では圧力を加えてもバネのように跳ね返り膨らんでしまう現象が発生します。
そこで、経本等を専門に手がける製本所ならではの「水寄せ」と呼ぶ特殊な加工を施すことで、折りの跳ね返り問題を解決しています（写真左＝水寄せ加工後）。
引き締まった折り上がりの製本を実現できる水寄せですが、手作業で行われる手間と技能を要するものです。その他にも折りを繋ぐ加工が手作業で行われるなど職人の技能、伝統に裏打ちされた技術やノウハウが随所に生かされており、市販向けとしては実に本格的な蛇腹折り製品に仕上がっています。
和紙は、蛇腹折りの強度を確保する上で秀でていますが、閲覧用途の経本と異なりシャープペンシルなど（ペン）での筆記用途としては不向きです。
一方、ペンでの筆記に適した洋紙を前提とし、使用頻度の高い手帳としての耐久性を確保するためには、蛇腹折りの用紙には相応の厚さや密度が求められます。ところが、それらが増せば折り加工の難易度が増すという矛盾が生じてしまいます。厚く密度の高い用紙の場合は元に戻ろうとする力が強い分、特に折り山の数が多い蛇腹折りでは、折りっ放しの仕上げ方では圧力を加えてもバネのように跳ね返り膨らんでしまう現象が発生します。
そこで、経本等を専門に手がける製本所ならではの「水寄せ」と呼ぶ特殊な加工を施すことで、折りの跳ね返り問題を解決しています（写真左＝水寄せ加工後）。
引き締まった折り上がりの製本を実現できる水寄せですが、手作業で行われる手間と技能を要するものです。その他にも折りを繋ぐ加工が手作業で行われるなど職人の技能、伝統に裏打ちされた技術やノウハウが随所に生かされており、市販向けとしては実に本格的な蛇腹折り製品に仕上がっています。
『SciKaku ポケット プロジェクト』が生まれるまで
＜記入日：2016.12.12＞
――構想は５年前から
以前務めていた企業では事業部の商品開発担当として幾つかのプロジェクトを推進していた。部門のプロジェクトでは関連組織の範囲が広がったこともありプロジェクトマネジメント手法の導入について本格的な取り組みが始まった。文書化、情報共有、進捗状況の見える化（数値化、定量化）など全体の推進管理の質を向上するための様々な模索があった。プロジェクトマネジメントという考え方に出会ったのもその時が最初である。
管理（マネジメント）手法そのものはあくまでも状況を客観的に把握すると同時に第三者と情報を共有するための手段であり、その活用は主たる開発業務に付随する一作業に過ぎない。従って開発者自身がプレーしながらマネジメントする必要がある中、いかに主業務の負担にならない程度に簡素化するかも当初の課題であった。
大規模なプロジェクト向けには専用のソフトウェアが存在したが、その使い方に合わせる時点で当初は不都合や負担が多かったため、本質的には相応の主旨で進めながらも、メンバーが使い慣れた表計算ソフトを用いるなどの簡素化を図ることとした。
全体で数年に及ぶいわゆる大規模プロジェクトについては、工程の種類が多くかつ長期のものが含まれるため、コンピュータ（ソフトウェア）上で計画を緻密に積み上げた上で進捗管理することは理にかなっている。使い慣れてしまえば、特にトラブル発生時の対応に際しては、他の業務間の調整も含めた計画の組み替えなどの検討が容易となる点でメリットが大きいだろう。
一方、現状の弊社で扱う案件やテーマの規模はと言えば、３〜４ヶ月前後の規模が殆どで開発要素を伴わないものも少なくない。進捗管理にコンピュータを使うまでもないある程度パターン化されたものもある。しかしながら諸々の事案が複数同時に重なるため当然ではあるが限られた人的資源の中で優先順位を設ける結果、必然的に難しい対応を余儀なくされる場面も出てくる。この状況で想定外のトラブルが重なれば厳しい状況は長引く。トラブルはチーム内だけでなく直接の管理が及ばない場所（外注先など）で発生する場合も考えられるため、問題を避けるためにはトラブルの芽を未然に摘み取る必要があり、進行過程で得られる最新の事実に基づいて計画を適宜調整し直すことは当然要る。このように、進捗状況の管理の重要性や難しさは扱う事案の規模だけでは図れないことは常々思うところである。
大規模な開発プロジェクトと並べ比べるつもりはなくその道の専門家でもないが、内外を含む複数組織との段取りの整合や並行する複数工程間の調整などの本質に大差はなく、プロジェクト管理の考え方や手法は、開発要素を伴わない小規模な事案しか取り扱うことの無い組織や個人にとっても導入メリットは少なからずある筈だと考えた次第である。これが５年前。
――時系列の俯瞰に合理的なカタチ
前職を通じて学んだ考え方を応用してコンピュータ上でプロジェクトを管理するための、より簡略化したフォームで運用を始めたが、ほんの僅かな隙間時間などでも頻繁に内容を確認し吟味したい私にとってはそれでもコンピュータの即応性に不満があった。セキュリティ管理を含めた持ち運びにおいても気が引けた。私の場合、開発の合間に営業も行うが、実際に商談先でコンピュータを操作する姿に対して印象面からも抵抗があった。画面の小さいスマホではそもそも閲覧性が乏しかったこともあり、ポケットで持ち歩けるオーソドックスな手帳でなんとかしたいという思いに至った。
一般的な手帳は手元にあったが、タスクの長さとの相性が馴染まず使いにくい印象があった。荒っぽい説明になるが、大なり小なり加工を外注すると納期マージンを含めた工数は凡そ一週間前後オーダーの回答が多く、この時点でウィークリー式の手帳ではページ見開きを超えてしまうため、前後の工程を同時に俯瞰できず相互のタイミングを検討し辛いのである。一般に巻頭にある月間カレンダーがこれを補うものなのかは分からないが、ページが離れているだけでなく、ウィークリー側との二重管理によるトラブルが懸念されるため、同じ目的で複数のカレンダーを同時に使うことには抵抗があった。壁掛けカレンダーなどでも良く目にするマンスリー式については、曜日単位で整然としており見慣れていることも手伝って一見問題なさそうだが、曜日に依存しない工数の長い複数タスクを扱う際には、同様に１週間でマーカーが分断されるため使い易さが感じられなかった。
素直に頭に浮かんだのは、時間軸のレイアウトは一直線でどこから切り取っても一定の期間が見渡せることが合理的であるとの考えであったが、当時これを満足する姿の手帳を目にした機会はなかった。
そのような中、偶然自宅の仏壇で「過去帳」を目にする機会があった。その小さな本は経本に見られる蛇腹折り（つづら折り）構造をしており、命日に応じたページに故人の名が記されていた。過去帳は１～31の日付けがページとして割り振られておりノートのようなものではない。その事実にその時初めて気づくと同時にこれが横レイアウトの月間カレンダーのようにも見えた。
実際に触れている中で、ある程度のボリュームがあるためか、蛇腹折りの本はページを繰る際も案外取り扱いやすく、離れた日付けのページを横並びに配置し閲覧する行為もたやすいなどの特徴もまた理解できた。
これらの気づきをもとに課題としていた時間軸の問題などが蛇腹折りの着想で上手く解決できる見通しが得られた。
しかしながら、弱点になりそうな要素も見つかった。その構造ゆえ、持ち運び時の方法と折り部分の耐久性にも不安が感じられ、次の設計課題となった。
――機能重視の設計思想
市場にある手帳のデザインには独自の長所があるものの、時間軸（日付）のレイアウトに不便さを感じている利用者はあるだろうという仮説から、その市場に向けた商品を開発するための準備から始めた。調査段階で蛇腹折りの手帳類が既に幾つか商品として存在する市場であることが判明したが、持ち運びする際の形状を含めて絶対的なスタイルというものは特に存在しなかった。
最初に検討を着手したのは大きさについて。前職での経験から夏場の軽装時でもペンと抱き合わせて胸ポケットに入れて持ち運べ、男女とも取り扱い易いサイズを目標とした。様々なシャツ等のポケットのサイズを調べ探った結果、巾は偶然ではあるが紙幣の短辺同様の寸法に辿り着き、天地はポケットの深さと見開き面積の確保とを考慮しB６判変型サイズにて設計した。
レイアウト内容については、プロジェクト管理のスケジューリング技法であるガントチャートが書き込み易くするために蛇腹折りを活かした横一文字の時間軸（日付）レイアウトを基本とした。
また、企業組織において進捗をレビューする報告会議や決裁のタイミングは最低でも１ヶ月に１回はあり、この月次日程にも連動して管理できることが必然であることから、時間軸を１ヶ月単位で区切ることとし、一ヶ月のまとめを記入する空欄を月末に設けた。
更に、顧客や所属組織、プロジェクト外の事案（プライベートを含む）の日程などについては曜日に依存する可能性を考慮し、自身の日程策定の前段階で予めマンスリー式で記入できるよう月初めにページをレイアウト。これを眺めつつ自身の日程はガントチャート上で策定するスタイルを構築した。なおマンスリー式ページを折り畳んでしまえば月をまたぐ日付の閲覧も連続して可能である。その逆も可。
懸案事項であった持ち運び時の問題については、弱点を覆うブックカバー（ホルダー）を装着することとした。
経本など一般的な様式では、表紙として前後に厚紙などを貼付けるが、落下時に用紙が伸びきった際の表紙自重によるストレスが懸念されるため、本体は折り加工のみの用紙とした。
また、鞄で持ち運ぶ際は他のモノと衝突しても直接のストレスを受けないよう、左右と背面に加え、前面も完全に覆い包むためのフラップを採用し、天地面には上製本に見られるチリ（散り）と呼ばれる表紙が中味より出っ張った部位に相当する構造を再現することとした。
素材は、ポケットに入れるため堅過ぎず薄くて軽いながらも、立った状態で片手に持ちながらの記入を想定してコシがあることを基準に採用した。
その他用途の品揃えでの展開も考慮して本体とバラ売りのスタイルとし、ブックカバーを着せ替え可能とした。
――構想は５年前から
以前務めていた企業では事業部の商品開発担当として幾つかのプロジェクトを推進していた。部門のプロジェクトでは関連組織の範囲が広がったこともありプロジェクトマネジメント手法の導入について本格的な取り組みが始まった。文書化、情報共有、進捗状況の見える化（数値化、定量化）など全体の推進管理の質を向上するための様々な模索があった。プロジェクトマネジメントという考え方に出会ったのもその時が最初である。
管理（マネジメント）手法そのものはあくまでも状況を客観的に把握すると同時に第三者と情報を共有するための手段であり、その活用は主たる開発業務に付随する一作業に過ぎない。従って開発者自身がプレーしながらマネジメントする必要がある中、いかに主業務の負担にならない程度に簡素化するかも当初の課題であった。
大規模なプロジェクト向けには専用のソフトウェアが存在したが、その使い方に合わせる時点で当初は不都合や負担が多かったため、本質的には相応の主旨で進めながらも、メンバーが使い慣れた表計算ソフトを用いるなどの簡素化を図ることとした。
全体で数年に及ぶいわゆる大規模プロジェクトについては、工程の種類が多くかつ長期のものが含まれるため、コンピュータ（ソフトウェア）上で計画を緻密に積み上げた上で進捗管理することは理にかなっている。使い慣れてしまえば、特にトラブル発生時の対応に際しては、他の業務間の調整も含めた計画の組み替えなどの検討が容易となる点でメリットが大きいだろう。
一方、現状の弊社で扱う案件やテーマの規模はと言えば、３〜４ヶ月前後の規模が殆どで開発要素を伴わないものも少なくない。進捗管理にコンピュータを使うまでもないある程度パターン化されたものもある。しかしながら諸々の事案が複数同時に重なるため当然ではあるが限られた人的資源の中で優先順位を設ける結果、必然的に難しい対応を余儀なくされる場面も出てくる。この状況で想定外のトラブルが重なれば厳しい状況は長引く。トラブルはチーム内だけでなく直接の管理が及ばない場所（外注先など）で発生する場合も考えられるため、問題を避けるためにはトラブルの芽を未然に摘み取る必要があり、進行過程で得られる最新の事実に基づいて計画を適宜調整し直すことは当然要る。このように、進捗状況の管理の重要性や難しさは扱う事案の規模だけでは図れないことは常々思うところである。
大規模な開発プロジェクトと並べ比べるつもりはなくその道の専門家でもないが、内外を含む複数組織との段取りの整合や並行する複数工程間の調整などの本質に大差はなく、プロジェクト管理の考え方や手法は、開発要素を伴わない小規模な事案しか取り扱うことの無い組織や個人にとっても導入メリットは少なからずある筈だと考えた次第である。これが５年前。
――時系列の俯瞰に合理的なカタチ
前職を通じて学んだ考え方を応用してコンピュータ上でプロジェクトを管理するための、より簡略化したフォームで運用を始めたが、ほんの僅かな隙間時間などでも頻繁に内容を確認し吟味したい私にとってはそれでもコンピュータの即応性に不満があった。セキュリティ管理を含めた持ち運びにおいても気が引けた。私の場合、開発の合間に営業も行うが、実際に商談先でコンピュータを操作する姿に対して印象面からも抵抗があった。画面の小さいスマホではそもそも閲覧性が乏しかったこともあり、ポケットで持ち歩けるオーソドックスな手帳でなんとかしたいという思いに至った。
一般的な手帳は手元にあったが、タスクの長さとの相性が馴染まず使いにくい印象があった。荒っぽい説明になるが、大なり小なり加工を外注すると納期マージンを含めた工数は凡そ一週間前後オーダーの回答が多く、この時点でウィークリー式の手帳ではページ見開きを超えてしまうため、前後の工程を同時に俯瞰できず相互のタイミングを検討し辛いのである。一般に巻頭にある月間カレンダーがこれを補うものなのかは分からないが、ページが離れているだけでなく、ウィークリー側との二重管理によるトラブルが懸念されるため、同じ目的で複数のカレンダーを同時に使うことには抵抗があった。壁掛けカレンダーなどでも良く目にするマンスリー式については、曜日単位で整然としており見慣れていることも手伝って一見問題なさそうだが、曜日に依存しない工数の長い複数タスクを扱う際には、同様に１週間でマーカーが分断されるため使い易さが感じられなかった。
素直に頭に浮かんだのは、時間軸のレイアウトは一直線でどこから切り取っても一定の期間が見渡せることが合理的であるとの考えであったが、当時これを満足する姿の手帳を目にした機会はなかった。
そのような中、偶然自宅の仏壇で「過去帳」を目にする機会があった。その小さな本は経本に見られる蛇腹折り（つづら折り）構造をしており、命日に応じたページに故人の名が記されていた。過去帳は１～31の日付けがページとして割り振られておりノートのようなものではない。その事実にその時初めて気づくと同時にこれが横レイアウトの月間カレンダーのようにも見えた。
実際に触れている中で、ある程度のボリュームがあるためか、蛇腹折りの本はページを繰る際も案外取り扱いやすく、離れた日付けのページを横並びに配置し閲覧する行為もたやすいなどの特徴もまた理解できた。
これらの気づきをもとに課題としていた時間軸の問題などが蛇腹折りの着想で上手く解決できる見通しが得られた。
しかしながら、弱点になりそうな要素も見つかった。その構造ゆえ、持ち運び時の方法と折り部分の耐久性にも不安が感じられ、次の設計課題となった。
――機能重視の設計思想
市場にある手帳のデザインには独自の長所があるものの、時間軸（日付）のレイアウトに不便さを感じている利用者はあるだろうという仮説から、その市場に向けた商品を開発するための準備から始めた。調査段階で蛇腹折りの手帳類が既に幾つか商品として存在する市場であることが判明したが、持ち運びする際の形状を含めて絶対的なスタイルというものは特に存在しなかった。
最初に検討を着手したのは大きさについて。前職での経験から夏場の軽装時でもペンと抱き合わせて胸ポケットに入れて持ち運べ、男女とも取り扱い易いサイズを目標とした。様々なシャツ等のポケットのサイズを調べ探った結果、巾は偶然ではあるが紙幣の短辺同様の寸法に辿り着き、天地はポケットの深さと見開き面積の確保とを考慮しB６判変型サイズにて設計した。
レイアウト内容については、プロジェクト管理のスケジューリング技法であるガントチャートが書き込み易くするために蛇腹折りを活かした横一文字の時間軸（日付）レイアウトを基本とした。
また、企業組織において進捗をレビューする報告会議や決裁のタイミングは最低でも１ヶ月に１回はあり、この月次日程にも連動して管理できることが必然であることから、時間軸を１ヶ月単位で区切ることとし、一ヶ月のまとめを記入する空欄を月末に設けた。
更に、顧客や所属組織、プロジェクト外の事案（プライベートを含む）の日程などについては曜日に依存する可能性を考慮し、自身の日程策定の前段階で予めマンスリー式で記入できるよう月初めにページをレイアウト。これを眺めつつ自身の日程はガントチャート上で策定するスタイルを構築した。なおマンスリー式ページを折り畳んでしまえば月をまたぐ日付の閲覧も連続して可能である。その逆も可。
懸案事項であった持ち運び時の問題については、弱点を覆うブックカバー（ホルダー）を装着することとした。
経本など一般的な様式では、表紙として前後に厚紙などを貼付けるが、落下時に用紙が伸びきった際の表紙自重によるストレスが懸念されるため、本体は折り加工のみの用紙とした。
また、鞄で持ち運ぶ際は他のモノと衝突しても直接のストレスを受けないよう、左右と背面に加え、前面も完全に覆い包むためのフラップを採用し、天地面には上製本に見られるチリ（散り）と呼ばれる表紙が中味より出っ張った部位に相当する構造を再現することとした。
素材は、ポケットに入れるため堅過ぎず薄くて軽いながらも、立った状態で片手に持ちながらの記入を想定してコシがあることを基準に採用した。
その他用途の品揃えでの展開も考慮して本体とバラ売りのスタイルとし、ブックカバーを着せ替え可能とした。